Google DeepMind gebruikt AI-agenten om de kernmachinecode van Signal te verifiëren

Google DeepMind introduceerde AlphaProof Code op 10 november 2026. Het gebruikte teams van AI-agenten om door machines gecontroleerde Lean-bewijzen te produceren voor vastgelegde beveiligingseigenschappen van de gecompileerde libsignal-code van Signal. Het onderzoeksteam van vijf personen voltooide het bewijswerk in vier weken en stelde de specificaties en verificatiebestanden beschikbaar voor externe beoordeling.

Het onderzoek ging verder dan een abstract model van het protocolontwerp van Signal en richtte zich op de gecompileerde implementatie ervan. De onderzoekers bouwden een kleine opdrachtregelinterface om de ongewijzigde crates libsignal v0.105.4 en SPQR v1.6.0 heen en gebruikten vervolgens de standaardcompiler rustc om een statisch gelinkt uitvoerbaar bestand voor AArch64 Linux te bouwen. De technische paper beschrijft het resultaat als de eerste beveiligingsbewijzen op protocolniveau voor de ongewijzigde code van een veelgebruikte implementatie van een cryptografisch protocol.

Hoe AlphaProof Code het werk verdeelde

Vijf onderzoekers besteedden vier weken aan het bewijswerk. Ze lieten de agenten onafgebroken op hun werkstations draaien en werkten parallel aan symbolische en computationele bewijzen. Volgens de paper genereerden de agenten ongeveer 6,5 miljoen regels door machines gecontroleerde Lean-bewijscode, gebaseerd op circa 26.000 regels vertrouwde specificaties en AArch64-semantiek.

Mensen bepaalden de eigenschappen, losten onduidelijkheden en afwegingen op het gebied van beveiliging op, beoordeelden de specificaties en behielden de uiteindelijke goedkeuring. Agenten op basis van Gemini 4 Carbon en Claude Opus 5.5 stelden die specificaties op en beoordeelden ze; daarbij vond ook beoordeling plaats door een model uit een andere modelfamilie. Vervolgens genereerden agentteams van Gemini 4 Carbon alle bewijscode; geen van de auteurs schreef bewijscode. Bij gebruikelijke runs werden op één machine 40 tot 80 agenten ingezet, gedurende 24 tot 72 uur. Een coördinator en teamleiders stuurden de agenten aan die aan de bewijzen werkten, terwijl architecten en integrators de gedeelde bewijsbasis bijhielden.

Een poortwachter accepteerde een bewijs pas nadat de kernel van Lean het had gecontroleerd en een vergelijker had bevestigd dat het overeenkwam met de apart gehouden, door mensen goedgekeurde specificatie, inclusief elke transitieve definitie, en dat daarbij alleen de standaardaxioma’s van Lean waren gebruikt. Agenten konden kleine wijzigingen voorstellen wanneer bewijzen problemen in de specificaties aan het licht brachten, maar voor aanpassingen van vertrouwde aannames was menselijke goedkeuring of een door de gebruiker ingesteld beleid vereist; de wijzigingen werden met onderbouwing vastgelegd. Deze controle pakt een gedocumenteerd risico van door agenten gegenereerde bewijzen aan: een specificatie kan indirect worden afgezwakt via een van haar definities.

Beveiligingsdekking en tests met historische bugs

Het geverifieerde doel was de code voor één-op-één-sessies, met daarin de PQXDH-handshake en berichtenuitwisseling via Triple Ratchet. De onderzoekers melden twee onafhankelijke bewijzen: tien symbolische stellingen onder geïdealiseerde cryptografische aannames en een computationeel bewijs dat de voorsprong van een aanvaller begrenst aan de hand van cryptografische aannames en statistische termen. De onderzochte eigenschappen zijn onder meer voorwaartse geheimhouding, die eerdere berichten beschermt nadat de huidige status is buitgemaakt; authenticatie; beveiliging na compromittering, die betrekking heeft op herstel na een compromittering; en geheimhouding van de handshake. Het symbolische bewijs omvat daarnaast geheimhouding van de handshake na een latere doorbraak van Diffie–Hellman.

Om te testen of de specificaties echte fouten konden opsporen, draaide het team de oplossingen voor twee eerder verholpen libsignal-bugs terug, bekend als ‘weak state’ en ‘small subgroup’, en compileerde het de gewijzigde binaire bestanden opnieuw. In beide gevallen leverde het Lean-bewijzen op waaruit bleek dat de symbolische beveiligingsstelling niet opging. De openbare verificatierepository bevat afzonderlijke onderdelen voor de computationele bewijzen, de symbolische bewijzen, de gedeelde binaire bestanden en de AArch64-semantiek. Ook wordt beschreven hoe de bewijzen opnieuw kunnen worden opgebouwd en onafhankelijk gecontroleerd.

Ehren Kret, technisch directeur van Signal, zei dat het werk “ons nog meer vertrouwen geeft in de privacywaarborgen van onze code”.

Beperkingen en vervolgstappen

De garanties komen bij lange na niet neer op een certificering van de volledige applicaties van Signal. Ze hebben betrekking op de libsignal-cli-build van de onderzoekers, die als een nieuw proces wordt uitgevoerd. Het genereren van sleutels is niet geverifieerd, groepsberichten zijn uitgesteld tot toekomstig werk en sidechannels en de status van meerdere apparaten vallen buiten het onderzochte scenario. Voor primitieve cryptografische bouwstenen op laag niveau en geselecteerde uitvoer- en bibliotheekroutines zijn vertrouwde contracten opgesteld. Het resultaat hangt dus ook af van die contracten, de goedgekeurde specificaties, de kernel van Lean, de AArch64-semantiek en aannames over de primitieve bouwstenen.

Volgens de paper bewijst geen van beide benaderingen het postkwantumherstel dat SPQR moet toevoegen: de computationele stelling dekt klassieke aanvallers, terwijl de symbolische ratchetstellingen de aanvaller toestaan SPQR-sleutels te kiezen. Ook beperkt het computationele model verschillende acties van de aanvaller en wordt het betekenisloos wanneer het aantal berichten en sessies voldoende groot is. Deze grenzen bepalen wat een externe beoordelaar moet vertrouwen voordat de door machines gecontroleerde bewijzen als beveiligingsgarantie voor een specifieke implementatie kunnen gelden.

De onderzoekers willen naar eigen zeggen de stellingen versterken, de vertrouwde basis verkleinen door meer gekoppelde routines te verifiëren en cryptografische contracten te verbinden met geverifieerde implementaties, en de dekking uitbreiden naar groepsberichten, sealed sender en serverprotocollen. Hun streven om nieuwe libsignal-releases te verifiëren voordat ze worden uitgebracht, is een onderzoeksdoel en geen aangekondigde implementatie.

De directe betekenis van het resultaat ligt in de taakverdeling die het laat zien: AI-agenten verzorgden de bewijsconstructie, terwijl de waarborging nog steeds berust op door mensen beoordeelde specificaties en expliciete aannames. Door de bewijzen en controleprocedures vrij te geven, krijgen externe beoordelaars de mogelijkheid om die basis te toetsen, terwijl de onderzoekers eraan werken deze werkwijze toe te passen in de doorlopende ontwikkeling van libsignal.