Introductie van Automatische Sleutelverificatie

Signal biedt nu een functie aan genaamd "automatische sleutelverificatie", die het bestaande systeem van veiligheidsnummers aanvult. Signal is altijd end-to-end versleuteld, en automatische sleutelverificatie biedt een extra, gestroomlijnde manier om te bevestigen dat er geen onverwachte partij tussen jou en het andere "uiteinde" van een end-to-end versleutelde sessie zit.

Het werkt via een systeem van verificaties die worden uitgevoerd door jou, je Signal-contacten en externe auditors. Samen bieden deze dezelfde zekerheid als het handmatig verifiëren van veiligheidsnummers. In tegenstelling tot veiligheidsnummers worden deze verificaties onafhankelijk uitgevoerd en is er geen persoonlijke ontmoeting of secundair communicatiekanaal voor nodig.

Dit systeem van verificaties zorgt ervoor dat de koppeling tussen een telefoonnummer of gebruikersnaam en de bijbehorende openbare versleutelingssleutel wereldwijd consistent is en transparant voor alle deelnemers in het Signal-ecosysteem. Dit beschermt tegen scenario's waarin een sleutel wordt gewisseld zonder dat de eigenaar hiervan weet — bijvoorbeeld als een kwaadwillende partij Signal zou compromitteren en een andere sleutel aan het telefoonnummer van je contact zou koppelen.

Om deze functie in actie te zien, ga je naar het profiel van een Signal-contact, tik op "Veiligheidsnummer bekijken" en vervolgens op de knop "Automatisch verifiëren" onder de kop "Automatische sleutelverificatie". De knop toont een groen vinkje en de tekst "Versleuteling geverifieerd" wanneer de functie beschikbaar is en de verificatie slaagt. Na verloop van tijd zorgt deze verificatie, in combinatie met de controles die continu worden uitgevoerd door je Signal-contact en externe auditors, voor de consistentie van de sleutel van dit contact binnen het Signal-ecosysteem.

Deze functie is gebaseerd op een concept dat bekendstaat als "sleuteltransparantie" (key transparency). Dit is de term die we in de rest van dit artikel zullen gebruiken om uit te leggen waarom we een systeem voor sleuteltransparantie hebben gebouwd en hoe dit op hoog niveau werkt.

Een introductie tot openbare en private sleutels

Asymmetrische cryptografie is wat het mogelijk maakt om berichten naar een vriend te sturen die alleen door die vriend gelezen kunnen worden. Hierbij wordt gebruikgemaakt van een paar wiskundig gekoppelde sleutels: de openbare sleutel (public key) en de private sleutel (private key). Deze kunnen in diverse toepassingen worden gebruikt, waaronder het verzenden en ontvangen van berichten.

Stel je voor dat je een afgesloten brievenbus hebt met een gleuf. Je openbare sleutel is als het adres van je brievenbus — je kunt dit delen met iedereen die post naar jou wil sturen. Je private sleutel is als de sleutel van de brievenbus. Jij bent de enige persoon die deze heeft, en je kunt hem gebruiken om berichten te lezen die naar jou zijn gestuurd. Iedereen kan post in je brievenbus gooien (versleutelen met je openbare sleutel), maar alleen jij kunt de bus openen en de post lezen (ontsleutelen met je private sleutel). Je adres moet openbaar beschikbaar zijn; je kunt immers geen post ontvangen als niemand weet waar deze naartoe gestuurd moet worden.

Wanneer je je aanmeldt voor Signal, genereert de Signal-app tijdens het registratieproces een paar openbare/private sleutels [1]. De private sleutel blijft op je apparaat — alleen jij hebt toegang tot deze sleutel, niet Signal en niemand anders. Je openbare sleutel wordt naar Signal gestuurd, dat fungeert als een centrale directory voor alle openbare sleutels van gebruikers. Wanneer je een bericht naar een andere Signal-gebruiker wilt sturen, vraag je aan Signal om de openbare sleutel van je contact en versleutel je het bericht met de sleutel die Signal terugstuurt en jouw eigen private sleutel.

De "Mallory-in-het-midden"-aanval

Het verzenden van berichten vereist het opvragen van openbare sleutels van ontvangers, en dat betekent dat men vertrouwt op een centrale directory. In theorie zou een kwaadwillende beheerder van de directory een zogenaamde "Mallory-in-het-midden"-aanval (Mallory in the middle attack) kunnen uitvoeren. Hoewel dit zou vereisen dat een buitenstaander de beveiliging van grote cloudproviders omzeilt of dat een bevoorrechte insider bewust een specifiek account target, willen we ons hiertegen beschermen, ook al is het een zeer geavanceerde en onwaarschijnlijke aanval. We gebruiken opnieuw de brievenbus-analogie om te illustreren hoe deze aanval hypothetisch zou werken.

Stel dat Bob een uitnodiging voor koffie wil sturen naar zijn vriendin Alice. Bob zoekt haar brievenbusadres op in de centrale directory. Als de directory is gecompromitteerd door een tegenstander (Mallory), kan Mallory Bob naar de brievenbus van Mallory sturen in plaats van die van Alice. Wanneer Bob zijn brief stuurt naar wat hij denkt dat de brievenbus van Alice is, komt deze in werkelijkheid terecht bij Mallory. Mallory gebruikt vervolgens haar eigen sleutel om Bobs bericht te openen, leest het, past het eventueel aan, stopt het in een nieuwe envelop en stuurt het door naar de brievenbus van Alice.

In haar aanpassing zou Mallory bijvoorbeeld de locatie van het koffiehuis of het tijdstip kunnen wijzigen, waardoor Alice op de verkeerde plek of tijd verschijnt. Alice heeft geen enkele indicatie dat het bericht is onderschept of aangepast; voor haar lijkt het alsof het bericht direct van Bob komt. Ondertussen wacht Bob vruchteloos tot Alice verschijnt. Zelfs als Mallory besluit Bobs bericht niet te wijzigen, vormt het feit dat zij het kan lezen een ernstige schending van de privacy van de communicatie.

Een miscommunicatie over koffie heeft relatief weinig gevolgen, maar dit soort aanvallen kan in andere contexten veel meer schade aanrichten.

Deze aanval werkt omdat Bob het adres van Alice nooit daadwerkelijk heeft geverifieerd. Bob vertrouwde er simpelweg op dat de brievenbus in de directory de hare was, wat een redelijke aanname is. Als Bob echter extra voorzichtig wilde zijn, zou hij Alice direct om haar adres kunnen vragen via een persoonlijke ontmoeting of een secundair, vertrouwd communicatiekanaal [2], wat mogelijk niet haalbaar is als Alice en Bob puur penvrienden zijn.

Hoe kan Bob het adres van Alice dus verifiëren als hij haar niet in persoon kan ontmoeten of een secundair kanaal kan gebruiken? In de rest van dit artikel beschrijven we hoe we een systeem hebben ontworpen waarmee Bob automatisch de gegevens in de centrale directory kan verifiëren zonder direct met Alice te hoeven communiceren.

Een analogie voor het ontwerp van een sleuteltransparantiesysteem

Een manier om Bob te helpen verifiëren dat de directory het juiste adres voor Alice heeft, is door een register bij te houden van elke wijziging die ooit in de directory is aangebracht. Als iemand het adres van Alice in de directory wijzigt, wordt dit vastgelegd in dit chronologische logboek en is het dus detecteerbaar. Laten we dit concreet maken met de brievenbus-analogie.

Stel dat een beambte alle adreswijzigingen bijhoudt in een openbaar grootboek (ledger) op het stadspostkantoor. Telkens wanneer iemand een nieuw adres krijgt of een bestaande update, voegt de beambte een nieuwe pagina toe aan de achterkant van het steeds groeiende grootboek en noteert daar de wijziging. De beambte doet dit met een permanente stift, zodat niemand terug kan gaan naar een pagina om deze eruit te scheuren of de inhoud te wijzigen. Iedereen kan het postkantoor bezoeken en een adres in het grootboek vinden, inclusief hun eigen.

Gebruik van het grootboek

Voor elk gegeven adres zijn er twee manieren waarop klanten van het postkantoor met het grootboek kunnen omgaan:

1. Een klant zoals Bob kan adressen opzoeken van andere mensen (zoals Alice).
2. Een klant zoals Alice kan haar eigen adres opzoeken om er zeker van te zijn dat het grootboek accuraat is.

Om het huidige adres van Alice te vinden, zou Bob bij de laatste pagina van het grootboek moeten beginnen en pagina voor pagina terugbladeren tot hij een pagina voor Alice vindt. Bob begint aan het einde omdat hij het meest recente adres wil, en het adres van Alice kan in de loop der tijd zijn gewijzigd. Naarmate er meer pagina's aan het grootboek worden toegevoegd, kan dit veel werk worden voor Bob, vooral als Alice haar adres al een tijdje niet heeft bijgewerkt en Bob door veel wijzigingen van andere mensen moet zoeken.

Het grootboek stelt Alice in staat om te verifiëren dat haar eigen adres correct is vermeld, maar om dat te doen moet zij alle nieuwe pagina's bekijken sinds haar laatste bezoek om te controleren of haar adres nergens onjuist staat. Net als bij Bob wordt dit veel werk naarmate het grootboek groeit.

Als Alice en Bob in een drukke stad wonen waar mensen vaak verhuizen, zou het onhaalbaar zijn om het grootboek pagina voor pagina door te bladeren. Er is een efficiëntere manier nodig.

Introductie van indexboeken

In de echte wereld bevatten boeken vaak een alfabetisch gesorteerde index waardoor lezers snel kunnen vinden wat ze zoeken. We kunnen hetzelfde idee toepassen op ons grootboek door een alfabetisch gesorteerd indexboek te introduceren voor de namen van iedereen wiens adres tot nu toe in het grootboek is opgenomen.

Wanneer er nieuwe pagina's aan het grootboek worden toegevoegd, moet het indexboek ook worden bijgewerkt. De beambte publiceert dus een nieuwe kopie van het indexboek telkens wanneer er een pagina aan het grootboek wordt toegevoegd. Dit creëert een enorme bibliotheek van alle eerdere indexboeken die publiekelijk toegankelijk zijn.

Voor nu gaan we ervan uit dat Alice en Bob altijd naar hetzelfde indexboek kijken voor een specifieke pagina van het grootboek. In de volgende sectie bespreken we het onderdeel van het systeem dat Alice en Bob in staat stelt deze aanname te verifiëren.

Met deze constructie kan Bob nu gemakkelijker het adres van Alice opzoeken via een "binaire zoekstrategie" (binary search). Dit wordt het best uitgelegd met een voorbeeld:

Stel dat er gedurende een bepaalde periode 100 nieuwe of bijgewerkte adressen zijn, waardoor het grootboek 100 pagina's heeft en de beambte 100 verschillende edities van het indexboek heeft gepubliceerd. Voor de eenvoud zeggen we dat het adres van Alice slechts één keer in het grootboek voorkomt, toen ze voor het eerst naar de stad verhuisde.

Bob begint door naar het midden van het grootboek te bladeren. Hij controleert vervolgens het indexboek dat bij die pagina hoort. Omdat het indexboek alfabetisch is gesorteerd, is het eenvoudig om een naam te vinden. Als de naam van Alice in dat indexboek staat, is dit óf de eerste editie van het indexboek waarin een vermelding voor Alice staat, óf de eerste verschijning is in een eerdere editie (en dus op een eerdere pagina in het grootboek).

In beide gevallen kan Bob de achterste helft van het grootboek negeren en het proces herhalen met de voorste helft, totdat hij de exacte pagina vindt waar de adreswijziging van Alice plaatsvond. Specifiek eindigt Bobs zoektocht wanneer hij twee opeenvolgende indexboeken vindt waarbij het eerste boek het adres van Alice niet bevat en het tweede boek dat wel doet.

Dit zoekproces heeft een aantal voordelen:

• Efficiëntie: In een grootboek met een miljard pagina's hoeft Bob in het slechtste geval niet alle miljard pagina's terug te bladeren, maar hoeft hij maximaal 30 verschillende pagina's te bekijken om het adres van Alice te vinden.
• Determinisme: Het proces is deterministisch wanneer Alice en Bob naar hetzelfde aantal pagina's kijken. Alice kan hetzelfde zoekproces volgen als Bob en precies dezelfde pagina's controleren. Zo kan zij garanderen dat de informatie die Bob vindt, accuraat is.

Door overeen te komen over een methode om door het grootboek te zoeken, hebben Alice en Bob een manier gevonden om hun respectievelijke doelen praktisch te bereiken. Terwijl het grootboek groeit, heeft Bob een efficiënte manier om het adres van Alice te vinden, en heeft Alice een efficiënte manier om ervoor te zorgen dat dit adres correct is.

Deze analogie is vereenvoudigd voor de duidelijkheid. In de praktijk kan Alice haar adres meerdere keren wijzigen, en het ondersteunen van dit soort zoekopdrachten vereist dat er meer gegevens in de indexboeken worden opgeslagen dan alleen namen. We hebben een open-source key transparency server gebouwd die deze ideeën toepast op Signal-berichten.

Hoe zit het met de beambte?

Tot nu toe is het zoekproces beschreven alsof Alice en Bob persoonlijk door de pagina's van het grootboek bladeren. In de praktijk is dat niet realistisch omdat het grootboek en de indexboeken te groot zijn. In plaats daarvan vragen Alice en Bob de beambte om de zoekopdracht namens hen uit te voeren en de resultaten terug te rapporteren.

Maar het postkantoor zou gecompromitteerd kunnen worden door een tegenstander zoals Mallory, die zich voordoet als de beambte en Bob wil misleiden door hem te laten geloven dat het adres van Alice in werkelijkheid het huis van Mallory is. Daarom kunnen Alice en Bob de beambte niet simpelweg vertrouwen; ze moeten het zoekproces onafhankelijk kunnen verifiëren.

Om dit te doen, vragen ze de beambte om alle gegevens aan te leveren van de specifieke pagina's en indexboeken die tijdens het zoekproces zijn geraadpleegd, zodat ze de resultaten zelf kunnen controleren.

Dubbelchecken werkt alleen als de gegevens die de beambte aanlevert betrouwbaar zijn. Wat als Mallory, in de rol van beambte, liegt over wat er in de registers staat? Mallory zou een geheim, tweede grootboek kunnen bijhouden met het verkeerde adres voor Alice, of twee verschillende edities van een indexboek voor dezelfde pagina kunnen publiceren. Mallory zou dan data uit de ene weergave aan Alice kunnen geven en data uit de andere aan Bob, waardoor beiden denken dat de gegevens geverifieerd zijn zonder dat ze de misleiding merken.

Alice en Bob hebben een onafhankelijke getuige nodig om de beambte eerlijk te houden.

Externe auditors

Om te voorkomen dat Mallory verschillende gegevens aan Alice en Bob verstrekt, vertrouwen zij op externe auditors. Deze auditors zijn als notarissen die over de schouder van de beambte meekijken terwijl elke nieuwe pagina aan het grootboek wordt toegevoegd en de bijbehorende editie van het indexboek wordt gepubliceerd.

Zij controleren of elke editie van het indexboek dezelfde gegevens bevat als de vorige editie, met uitzondering van één vermelding, en dat de auditor geen eerdere pagina's in het grootboek heeft verwijderd of stiekem heeft gewijzigd. Als aan deze voorwaarden is voldaan, zet de auditor een handtekening [3] onder die pagina en dat indexboek, wat aangeeft dat het record correct is toegevoegd.

Auditors zullen elke pagina en elk indexboek slechts één keer signeren. Als de beambte zou proberen verschillende versies van bijvoorbeeld de 50ste editie aan Alice en Bob te tonen, kan de beambte slechts voor één van die versies een geldige handtekening van de auditor overleggen. Door deze handtekeningen te controleren en te verifiëren, kunnen Alice en Bob er zeker van zijn dat de beambte precies één grootboek bijhoudt en dat zij beiden naar dezelfde set gegevens kijken.

Voor Signal's implementatie van sleuteltransparantie fungeren Cloudflare en Trail of Bits als vertrouwde externe auditors.

Monitoring

Externe auditors zorgen ervoor dat de beambte dezelfde set gegevens aan Alice en Bob verstrekt, maar ze kunnen de accuraatheid van de geregistreerde gegevens niet verifiëren. Mallory zou bijvoorbeeld een pagina aan het grootboek kunnen toevoegen met een valse adreswijziging voor Alice. Vanuit het perspectief van een auditor is dit een legitieme wijziging, zolang Mallory correct een nieuwe pagina toevoegt en een nieuw indexboek publiceert. Wanneer Bob vervolgens het adres opzoekt, vindt hij deze valse vermelding en gelooft hij dat dit het echte adres is.

Hier komt monitoring om de hoek kijken. Herinner je dat er twee manieren zijn voor klanten om met het grootboek om te gaan: het opzoeken van iemand anders en het opzoeken van jezelf. Monitoring vereist dat Alice en Bob beide acties regelmatig uitvoeren, waarbij elk een ander soort manipulatie detecteert.

Alice monitort haar eigen gegevens in het grootboek door periodiek haar meest recente adresrecord op te zoeken en te verifiëren. Als ze een onverwacht adres vindt, moet ze Bob via een secundair, vertrouwd kanaal waarschuwen dat het adres dat hij van haar heeft ontvangen onbetrouwbaar is.

Bob moet ook periodiek het meest recente adres van Alice opzoeken en controleren of dit overeenkomt met wat hij eerder heeft ontvangen. Dit is belangrijk omdat Mallory, na het invoegen van een valse adreswijziging, haar sporen zou kunnen wissen door later een vermelding toe te voegen die het correcte adres van Alice herstelt.

Het is belangrijk om op te merken dat vanuit Bobs perspectief het vinden van een ander adres voor Alice identiek is aan een legitieme adreswijziging, wat de meest waarschijnlijke verklaring is. Toch moet hij bij Alice bevestigen via het secundaire kanaal of zij daadwerkelijk is verhuisd. Als dat niet zo is, moet hij het eerdere adres als onbetrouwbaar beschouwen.

Alice voert zelfcontroles uit met een regelmatige frequentie en Bob controleert het grootboek volgens zijn eigen schema. Hierdoor is er geen garantie dat Mallory's interferentie op het moment dat deze plaatsvindt direct wordt opgemerkt. Maar deze twee soorten monitoring, gecombineerd met externe auditing, vormen een compleet detectiesysteem: auditing garandeert dat Alice en Bob naar dezelfde gegevens kijken, en monitoring garandeert dat beiden deze gegevens regelmatig op accuraatheid controleren. Samen zorgen ze ervoor dat manipulatie door Mallory uiteindelijk zal worden ontdekt.

Terugkoppeling naar Signal

Hoe hangt dit alles nu samen met sleuteltransparantie in Signal?

In Signal kun je ervoor kiezen vindbaar te zijn via je telefoonnummer of via een gebruikersnaam. Als je hiervoor kiest, kan iemand je nummer of naam invoeren om een berichtverzoek te starten. Signal beheert een centrale directory die deze openbare identificatoren koppelt aan de openbare sleutel van de gebruiker, net als de "naam" en het "adres" in onze brievenbus-analogie.

Wanneer Signal-gebruikers zich registreren, hun telefoonnummer of gebruikersnaam wijzigen, of hun account opnieuw aanmaken, legt Signal deze wijzigingen vast in een logboom (log tree — "het grootboek") en faciliteert het zoeken in deze boom met prefixbomen (prefix trees — "de indexboeken"). Cloudflare en Trail of Bits fungeren elk als onafhankelijke auditors van deze twee soorten bomen, die samen het key transparency log vormen.

Alle gebruikersgegevens in het log zijn cryptografisch versluierd — openbare identificatoren worden verwerkt via een verifiable random function (VRF) en de waarden waarnaar ze verwijzen zijn beschermd door een keyed hash function. Hierdoor zien auditors nooit plaintext-gebruikersgegevens.

Je Signal-app controleert automatisch en periodiek je eigen openbare identificatoren in dit log, maar het verifiëren van die van een contact moet worden gestart op het scherm "Veiligheidsnummer bekijken". Alle verzoeken om identificatoren in het log op te zoeken zijn niet-geauthenticeerd, wat betekent dat ze niet aan een specifiek gebruikersaccount zijn gekoppeld.

Hoewel we in dit artikel niet ingaan op de implementatiedetails, kunnen geïnteresseerde lezers deze vinden in onze open-source repository. Deze is geïmplementeerd op basis van een eerdere conceptversie van het IETF key transparency protocol en bevat verfijningen om aan de specifieke use case van Signal te voldoen.

Sleuteltransparantie in de praktijk vandaag

Sleuteltransparantie geeft aan dat alle apparaten in het Signal-ecosysteem hetzelfde beeld hebben van de koppelingen tussen een identificator en de bijbehorende openbare versleutelsleutel. Het verifieert niet de identiteit van de gebruiker die een bepaald telefoonnummer of gebruikersnaam beheert. Concreet betekent dit dat Alice en Bob sleuteltransparantiecontroles kunnen uitvoeren om er zeker van te zijn dat ze beiden de juiste openbare sleutel hebben voor een gegeven account, maar aanvullende verificatie (zoals het opvolgen van een wijziging in het Veiligheidsnummer) is nog steeds nodig om scenario's te detecteren waarin Mallory volledig de controle over het account van Alice heeft overgenomen.

Op dit moment verifieert je Signal-app automatisch je eigen telefoonnummer en gebruikersnaamgegevens in het log. Maar om dit voor iemand anders te doen, heb je hun telefoonnummer nodig. Dit betekent dat als je contact met iemand hebt opgenomen via een gebruikersnaam en geen telefoonnummers heeft uitgewisseld, je hen niet zult kunnen verifiëren.

Je hebt waarschijnlijk het telefoonnummer van je Signal-contact als aan een van de volgende voorwaarden is voldaan:

• Je bent een Signal-chat met deze persoon gestart via de optie "Vind via telefoonnummer".
• Je hebt deze persoon in het adresboek van je telefoon opgeslagen (en zij hebben ervoor gekozen vindbaar te zijn via hun telefoonnummer in Signal).
• Je contact heeft de optie geselecteerd waarmee iedereen hun telefoonnummer in Signal kan zien (standaard kan niemand dit).

Houd er rekening mee dat Signal het telefoonnummer van een contact alleen in de app toont als zij in je adresboek staan of als zij de zichtbaarheid van hun nummer op "iedereen" hebben gezet.

Het is ook mogelijk dat je een verouderd telefoonnummer hebt in het geval dat je contact zijn nummer wijzigt. Deze actie heeft geen invloed op de openbare versleutelingssleutel of de onderliggende versleutelde berichtensessie. Het betekent echter wel dat je automatische sleutelverificatie voor dit contact niet kunt gebruiken, omdat je telefoon het oude nummer behoudt dat niet langer overeenkomt met het meest recente record in het grootboek. Dit is vergelijkbaar met de situatie waarin Bob een ander adres voor Alice ziet dan hij eerder had ontvangen. De kans is groot dat dit een legitieme wijziging is, maar je apparaat kan dit niet onderscheiden van interferentie door de server, en je dient dit te bevestigen via een secundair, vertrouwd kanaal.

Om privacy als standaard te waarborgen, maken we automatische sleutelverificatie in al deze gevallen onbeschikbaar. We raden gebruikers aan om het bestaande systeem van veiligheidsnummers te gebruiken, waarmee handmatig kan worden geverifieerd of dezelfde versleutelingssleutels worden gedeeld door een QR-code te scannen of een lang verificatienummer te vergelijken. Gebruikers die liever niet vertrouwen op derden (inclusief Signal en de auditors), kunnen de functie voor automatische sleutelverificatie uitschakelen in de instellingen via "Privacy" > "Geavanceerd" > "Automatische sleutelverificatie" en handmatige verificatie blijven gebruiken.

Conclusie

Sleuteltransparantie biedt een gebruiksvriendelijke manier om een belangrijk onderdeel van berichtbeveiliging te bevestigen, als aanvulling op ons bestaande systeem van veiligheidsnummers.

Dit werk is het resultaat van een significante samenwerking binnen en buiten Signal. We zijn vooral dankbaar naar Cloudflare en Trail of Bits voor hun rol als onafhankelijke auditors. Onze dank gaat uit naar hen en de vele anderen in ons ecosysteem die dit mogelijk hebben gemaakt.

***

Voetnoten: [1] In de praktijk genereert Signal verschillende soorten sleutelparen en afgeleide sleutels die samenwerken als onderdeel van het Signal-protocol, in plaats van te vertrouwen op één enkel openbaar/privaat sleutelpaar. [2] Op het Signal-platform is dit analoog aan onze bestaande "Veiligheidsnummer"-functie, die een persoonlijke verificatie of het vergelijken van veiligheidsnummers via een tweede, vertrouwd platform vereist. [3] In de fysieke wereld kunnen handtekeningen gemakkelijk worden vervalst. Maar in het sleuteltransparantiesysteem dat in deze analogie wordt beschreven, gebruiken de externe auditors van Signal cryptografische handtekeningen, die niet eenvoudig te vervalsen zijn.