WhatsApp automatiseert cryptografische verificatie van gebruikersaccounts

WhatsApp gaat het proces rondom cryptografische verificatie van eindgebruikers automatiseren. Nu kunnen gebruikers de integriteit van hun gesprekspartners nog verifiëren via een qr-code, maar dat proces kan binnenkort ook automatisch via de open source Auditable Key Directory.

Moederbedrijf Meta zegt dat die functie inmiddels voor gebruikers wordt uitgerold. WhatsApp noemt de functie de Auditable Key Directory, een openbare en daarmee verifieerbare lijst met wijzigingen aan de public keys die gebruikers uitwisselen om hun identiteit te verifiëren. De functie draait om de qr-codes die WhatsApp sinds 2014 gebruikt voor berichten die end-to-end versleuteld zijn.

De versleuteling van WhatsApp werkt op basis van een private key die op het toestel blijft staan en een public key die kan worden gedeeld met andere gebruikers om een versleutelde verbinding op te zetten. Die public key wordt via WhatsApp van de verzender naar de ontvanger gestuurd. Om te controleren of een verzender met de juiste ontvanger praat, hasht WhatsApp die publieke sleutel. Die hash van zestig tekens kunnen twee gebruikers met elkaar vergelijken. Dat kan ook in de vorm van een qr-code. Als die hashes op beide apparaten overeenkomen, heeft er geen man-in-the-middleaanval plaatsgevonden.

Dat proces is echter omslachtig, erkent WhatsApp. Twee gebruikers moeten bijvoorbeeld fysiek bij elkaar zijn om de qr-code te scannen, of ze moeten een externe verbinding opzetten om de hashes te vergelijken. Bij groepsgesprekken is dat helemaal ingewikkeld. In de praktijk gebruiken daarom ook maar weinig mensen de feature. WhatsApp gaat precies dat proces nu automatiseren.

Dat doet het bedrijf via een nieuw protocol. Met dat protocol wordt op de servers van WhatsApp een publieke database aangemaakt, de Auditable Key Directory. In die directory staan mappings tussen gebruikersaccounts en hun publieke sleutels. Als die op de een of andere manier worden aangepast zonder tussenkomst van de gebruiker, krijgt een ontvanger dus te zien dat de publieke sleutel niet kan worden geverifieerd. WhatsApp raadt in dat geval aan dat proces alsnog handmatig te doen.

WhatsApp maakt de code achter die directory open source beschikbaar. Het gaat om een Rust-library die gebruikmaakt van verschillende key transparancy-protocollen zoals Coniks. De library verwerkt volgens WhatsApp 'tienduizenden key-veranderingen per dag' en is daarom een append-only-database.

Reacties (40)

WhatsApp zelf heeft er ook een blog over geschreven: https://blog.whatsapp.com...-automatic-security-codes

Verder gaat het niet alleen over key transparency, maar ook over device verification, wat ook nieuw is: https://engineering.fb.co...ion-protects-your-account. Dit moet er voor zorgen dat het overnemen van een account lastiger wordt.

Zelf ben ik dan wel benieuwd of ze zoals wel eens werd beweerd een achterdeur kunnen gebruiken om de encryptie te omzeilen als overheden en of rechters dat vragen. In berichtgeving werd gezegd dat Whatsapp de encryptie kon omzeilen na een verzoek van een overheid en of rechter en deze dan inzage had in elk verstuurd bericht.

Nee, dat ging alleen over metadata, niet over E2EE content. Metadata wordt namelijk (jammergenoeg) niet E2EE.

En met de hoeveelheid metadata maakt het ook niet echt meer uit of de gewone data E2EE is of niet; de metadata is zo uitgebreid dat je de gewone data niet eens meer nodig hebt.

Ben ik het niet mee eens. Voor mij is de content (berichten, media, noem maar op) belangrijker dan metadata. Maar daarmee zeg ik niet dat metadata niet belangrijk is, vandaar dat ik ook zeg "jammergenoeg".

Dan heb je geen idee wát en hoevéél metadata er over de lijn gaat bij Facebook en co

Spoiler alert: dusdanig veel dat je op basis van álle metadata die verzameld is echt wel kan pinpointen wie wat wanneer doet en met wie en welke reden. Woordelijk reproduceren? Misschien niet. Maar dat is dan ook niet echt meer nodig..

[Reactie gewijzigd door DigitalExorcist op 13 april 2023 21:46]

Heb je wat voorbeelden? Want ik heb de metadata bekeken, meerdere keren al.

Ik run een SOC, het is m’n werk om metadata te zien…….

Maar voor een leuk inkijkje, “je hebt wél iets te verbergen” is een tof (luister)boek.

[Reactie gewijzigd door DigitalExorcist op 14 april 2023 07:57]

Interessant! Kan je eens wat laten zien van die metadata?
Je hoort vaak dat het veel is, maar ik heb nog nooit wat gezien. En de mensen die het beweren kunnen nooit wat laten zien.

Ik geloof wel dat er veel metadata is, anders is het product niet interessant voor Meta. Maar ik wil wel eens zien wat voor metadata dat dan is.

Technisch gezien kan dat, maar niet zonder NDA simpelste manier om het zélf te doen is door een PC'tje met een geschikte NIC in promiscuous mode te zetten en te gaan sniffen met bijv. Wireshark.

Let wel op de nuance: de communicatie is wel HTTPS-versleuteld, maar niet 'end to end'. Het is niet alsof ze plaintext via poortje 80 alles over de lijn kwakken. Je zal dus DPI (deep packet inspection) moeten toepassen; een soortement van MitM-'aanval' waarbij je je firewall toestaat om encrypted netwerkverkeer te decoderen. Niet onmógelijk, maar mogelijk wel wat gecompliceerder.

Er zijn apps die dat wel gewoon doen trouwens. Segway bijv. gooit gewoon leesbaar over HTTP welke versie van de app je gebruikt, welk OS je telefoon heeft, of je Wifi-verbonden bent, hoe je je telefoon houdt (portrait of niet), resolutie van je scherm, welk merk en type foon je hebt, álles.

[Reactie gewijzigd door DigitalExorcist op 14 april 2023 08:50]

Let wel op de nuance: de communicatie is wel HTTPS-versleuteld, maar niet 'end to end'. Het is niet alsof ze plaintext via poortje 80 alles over de lijn kwakken. Je zal dus DPI (deep packet inspection) moeten toepassen; een soortement van MitM-'aanval' waarbij je je firewall toestaat om encrypted netwerkverkeer te decoderen. Niet onmógelijk, maar mogelijk wel wat gecompliceerder.

Je hebt het dan niet meer over metadata, maar gewoon over de data zelf. En dat is data waarbij ISPs en iedereen tussen jouw computer en de server van de website geen toegang toe heeft. Althans, als het verkeer over een TLS verbinding gaat. MitM aanvallen op TLS verbindingen lukken alleen wanneer je aan legitieme certificaten weet te komen, of wanneer je al toegang hebt tot het apparaat dat je wilt afluisteren. Een SOC zal daar dus never nooit bij kunnen komen.

Metadata van regulier HTTPS verkeer vertelt je alleen welk IP met welk IP gepraat heeft en op welke poort, hoe lang dat duurde en hoeveel data er heen en weer gestuurd is. Meer niet. Niet eens welke domeinnaam opgevraagd is. Dus als het IP adres van de website waarnaar je verbind meerdere domeinnamen host, weten ze niet eens welke website je hebt bezocht. Wanneer je ook toegang hebt tot het DNS verkeer dat niet over HTTPS gaat, is het natuurlijk wel mogelijk om het verkeer te koppelen aan een domein.

Ja, met metadata kan je veel, en je kan veel (wellicht) correcte aannames maken aan de hand van die metadata, maar zeker weten doe je het nooit. Misschien belde je die abortuskliniek wel om ze de huid vol te schelden, of 113 om de trollen. Zonder de inhoudelijke data weet je het simpelweg niet.

[Reactie gewijzigd door Hatsjoe op 14 april 2023 12:02]

Tsja, ikzelf werk in een SOC. Overigens, hoe kom je erbij dat ik niks te verbergen zou hebben? Als er iemand is die het onzin vindt als mensen zeggen "ik heb niks te verbergen", dan ben ik het wel. Maar zie: AnonymousWP in 'WhatsApp automatiseert cryptografische verificatie van gebruikersaccounts'

Uiteraard, iederéén heeft iets te verbergen. Maar mensen struikelen vaak over de term 'verbergen'. Privacy en geheimhouding zijn twee héél verschillende dingen.

Iedereen weet prima wat er gebeurd als je op de WC zit, en tóch zit je daar met de deur dicht.

Dat is niet zo moeilijk. Iemand die belt met een abortuskliniek, doet dat vast niet om de weg te vragen. Iemand die belt naar 113 zelfmoordpreventie wil vast geen pizza bestellen. In sommige gevallen is alleen de metadata al genoeg om (grofweg) te bepalen wat er besproken is.

Dan heb ik het nog niet eens over de metadata die Facebook verzamelt. Ik denk dat Facebook kan voorspellen wie er verliefd is op wie, puur door bezoekgedrag op profielen te analyseren en te vergelijken met gedrag uit het verleden van mensen die Facebook vertellen dat ze een relatie hebben. En dat is dan nog redelijk onschuldig.

Er zijn talloze dingen te bedenken die bedrijven kunnen voorspellen op basis van alleen metadata. Was er laatst niet zo'n nieuwbericht dat Bing nauwkeuriger dan een arts kan voorspellen of iemand leukemie heeft? Puur op basis van zoektermen van de bezoekers.

We geven echt veel te veel data weg over onszelf, en de meesten van ons hebben dat niet door. Omdat we er vanuit gaan dat al die losse stukjes data niet met elkaar gecombineerd kunnen worden. Maar bedrijven als Facebook en Google kunnen dat dus wel.

Die voorbeelden zijn inderdaad legitiem, maar die zijn voor mij niet relevant, want bedenk wel: waarom zou je als Nederlander Dominos of 113 gaan bellen via WhatsApp? Dat doe je via normaal bellen. Niet dat dat nou per se veilig is, maar nogmaals: de inhoud is voor mij belangrijker, maar dat wil niet zeggen dat de metadata niet belangrijk is voor mij.

. Iemand die belt met een abortuskliniek, doet dat vast niet om de weg te vragen. Iemand die belt naar 113 zelfmoordpreventie wil vast geen pizza bestellen. In sommige gevallen is alleen de metadata al genoeg om (grofweg) te bepalen wat er besproken is.

Dat zijn leuke voorbeelden, maar ze dekken maar een heel klein aantal situaties af. Kun je aan de metadata van 113 afleiden of iemand echt zelfmoord overweegt, of eigenlijk alleen maar aandacht wil? Kun je aan de metadata zien of ik zelf gebeld heb, of mijn telefoon heb uitgeleend aan een vriendin die niet getraceerd wilde worden? Als ik regelmatig met een studiegenoot bel, is de metadata dan toereikend om te bepalen of ik verliefd ben, samen een belangrijk project doe, of een aanslag op de premier uitwerk?

Je hoort mij niet beweren dat metadata waardeloos is, in tegendeel. Ik denk dat metadata heel waardevol is omdat het zo makkelijk automatisch te verwerken is. Maar dat metadata de data zelf geheel overbodig maak dat bestrijd ik, als dat zo was zouden militaire partijen bijvoorbeeld niet zoveel geld in encryptie steken.

het zal altijd moeilijk zijn om de aanbieder van encryptie te vertrouwen, maar voordien was er zelfs geen E2EE, waardoor ze zéker alles konden zien.
Er zullen altijd wel groepen mensen zijn die wantrouwig staan tegenover zulke beweringen security-puristen aan de ene kant (hun volste recht uiteraard) en criminelen langs de andere kant (ook hun volste recht, maar voor een iets minder maatschappelijke reden).
Het verschil zit hem in de partij waarvoor je je communicatie verborgen wil houden en als encryptie ervoor zorgt dat criminelen die bvb je nummer spoofen niet zomaar alles kunnen lezen en jou persoonlijk aanvallen, dan is voor de meesten een backdoor een aanvaardbaar risico (of ze weten gewoon nix over security en willen enkel chatten)

Dat is denk ik dan ook meteen het dilemma. Met al de landen in de wereld en hun verschillende interpretaties van recht kan de beschermer in het ene land voor de andere landen juist de dief zijn die bij onschuldige mensen wil meekijken.

Alleen hoef je geen security purist te zijn om volledige e2ee nodig te hebben, omdat je in de meeste gevallen EN zelf geen controle hebt over wat het risico is EN geen controle hebt over wie er toegang toe heeft EN niet vooraf controle hebt of wie wel toegang heeft aan de eigen verwachtingen voldoet.

Dat ze het eerder nog minder encryptie hadden is dus niet zomaar relevant. Want je hebt niet zomaar meer controle over al die punten met de veranderingen die daarna zijn gedaan.

Puur nattevingerwerk gok ik dat maar een héél klein percentage van de gebruikers het als "noodzaak" aanziet.

Wat ik onder security-purist beschouw is iemand of een firma waarbij die noodzaak afhangt van een MoSCoW-analyse en als je die al zou doen, dan zal het gratis whatsapp meestal in de laagste 2 prio's vallen en zoek je voor de hoogste 2 beter een andere, professionelere oplossing.

Dat kan heel makkelijk in de app zelf worden gebouwd en is lastig te controleren. Niet via aftappen van communicatie (mitm)

Whatsapp kan je laatste 5 berichten inzien als je een bericht rapporteert. Nu zegt het niks over een mogelijke backdoor maar het zou mij niet verbazen als de cliënt in opdracht van de autoriteiten in staat is om berichten door te sturen naar een centrale locatie:

https://marketresearchtel...s-a-complaint/146906/amp/

Zelf ben ik dan wel benieuwd of ze zoals wel eens werd beweerd een achterdeur kunnen gebruiken om de encryptie te omzeilen als overheden en of rechters dat vragen.

Natuurlijk. Ik zie drie mogelijkheden voor de uitvoerder:

- Aangepaste APK/IPA naar het apparaat sturen. Hiervoor moet de uitvoerder van het gerechtelijke bevel waarschijnlijk bij Google of Apple zijn, als de gebruiker niet de apk/ipa van een andere partij haalt, gezien Facebook zelf de distributie niet zo nauw kan bepalen zover ik weet. Hier zou je al écht in de materie moeten zitten én weten dat er iets mis is met jouw apparaat voordat iemand erachter komt, dus het laagste risico.

- De Facebook servers sturen een public key naar de client waar Facebook zelf de private key van heeft (waarmee je ontsleutelt), ook wel een machine in the middle-aanval genoemd. Normaliter sturen ze de public key van de persoon waar je daadwerkelijk mee praat, wiens private key dus enkel op diens apparaat staat. Hierbij riskeren ze dat de persoon tech-savvy genoeg is, of het laat onderzoeken door iemand die dat wel is, om dit te controleren. Maar een gemiddeld persoon die niks vermoed (waarom zou je ook, tenzij je dealer bent en opeens al je contacten worden opgepakt of zo) zou dat natuurlijk nooit laten doen.

- Er zit al een backdoor in de app en de server zet het aan bij mensen waarvoor zo'n bevel bestaat. Zou eventueel gebruik kunnen maken van dezelfde code als de rapporteerfunctie zodat het minder opvalt. Hierbij neemt Facebook een aannemelijk risico (het grootste van de drie naar mijn idee) dat het gevonden wordt en veel mensen WhatsApp niet meer vertrouwen. (Then again, WhatsApp was vroeger ook niet versleuteld maar was toen wel al heel populair, dus of dat uit zou maken...)

[Reactie gewijzigd door Lucb1e op 13 april 2023 20:37]

Dit snap ik niet helemaal. Je kunt al langer aanzetten dat je een melding krijgt als de sleutel van je contacten verandert, meestal doordat de app wordt geherinstalleerd of omdat mensen een nieuwe telefoon krijgen.

WhatsApp beheert hier de server en de verbinding, waarzom zou de enige re-key wel reden voor paniek zijn en de ander niet?

Je krijgt dan die melding, maar als je wil verifiëren of je vriend inderdaad van telefoon is gewisseld moet je fysiek bij hem langs gaan om de qr-code te scannen. Dat wordt nu geautomatiseerd.

Maar hoe kan dat worden geautomatiseerd? Het hele punt van dit soort verificatie is dat het via een veilig, losstaand kanaal gaat.

Zonder een zijkanaal dat niet door WhatsApp wordt bestuurd, zie ik niet hoe dit een vervanging is van handmatige verificatie. Het is wel een goede vervanging voor het automatische sleutelsysteem dat WhatsApp al heeft natuurlijk, alhoewel ik niet me niet 100% veilig voel bij het publiceren van alle public keys met de bestaande problemen van WhatsApp (zoals hoe je eenvoudig de naam en foto kan scrapen bij ieder telefoonnummer).

Ik zou zeggen: lees de blog van Meta: https://engineering.fb.co...hatsapp-key-transparency/. Dan zou het makkelijker te begrijpen moeten zijn.

Ik heb die blog gelezen, maar ik begrijp nog steeds niet welk probleem het precies oplost. Het wordt snel technisch, maar het blijft voor mij onduidelijk precies welke aanval je nu voorkomt met deze oplossing. Zoals @GertMenkel ook zegt, je kan al een melding krijgen wanneer iemand z'n public key verandert (dus nieuwe telefoon, bijv.). Je hebt dan toch altijd nog een secure channel (in het echt langsgaan, via ander kanaal contact opnemen e.d.) om te bevestigen dat diegene inderdaad een actie heeft ondernomen (zoals een nieuwe telefoon nemen) waardoor diens code is gewijzigd.

In [dit medium blog](https://medium.com/asecur...transparency-2d56bce47396) wordt het ook nog eens uitgelegd, lekker met plaatjes (altijd fijn), maar daar wordt meer gesuggereerd dat het gaat om een MITM voorkomen bij een gecompromitteerde WhatsApp server. Is dit dan echt de enige aanval waar deze nieuwe techniek tegen bedoeld is? En als een gecompromitteerde WhatsApp server binnen scope van de aanvallen ligt, heb je dan niet veel meer om zorgen over te maken? Met andere woorden, moet deze techniek er nou voor zorgen dat je de WhatsApp server niet meer blind hoeft te vertrouwen?

@TijsZonderH Kun jij hier misschien meer duiding over geven?

Om te controleren of een verzender met de juiste ontvanger praat...

Weet je misschien wat voor een aanval nu mogelijk is, maar door automatisch verifiëren van cryptografische sleutels wordt voorkomen?

Je hebt per gesprek een apart sleutelpaar, om zowel mee te versleutelen als te ontsleutelen. Die sleutels worden gegenereerd en de public key wordt uitgewisseld met het persoon waarmee je aan het chatten bent. Cryptografisch gezien kan je sleutels vergelijken of de ene sleutel bij de andere sleutel hoort qua sleutelpaar. Om dat te checken moet je nu nog fysiek bij een ander persoon zijn (bekijk het zelf maar: ga naar een gesprek en tik op 'Versleuteling').

Nu hoeft dat dus niet meer, omdat:

• Dit in een 'publieke' database staat (de koppeling, welke een hacker niet kan wijzigen, want immutable)
• Dit geautomatiseerd is

Is dat wat duidelijker? Maar leuk artikel van Medium, vandaag eens doorlezen. Maar nee, dit gaat niet over het problemen met betrekking tot WhatsApp-servers, maar om MITM-aanvallen tussen twee personen.

@Chiwn Edit: Maar als het inderdaad mogelijk is om de server te compromitteren, dan zou het alsnog niet mogelijk moeten zijn, want de database is immutable (oftewel: bestaande entries kunnen niet aangepast worden, en dus kunnen de sleutels niet gewijzigd worden). Als de hele infrastructuur gehackt is en de hackers toegang hebben tot het wijzigen van de configuratie en ze maken het mutable, dan ja, dan ben je het haasje. Maar goed, als ze als hackers toegang hebben kunnen ze ook hele andere dingen doen natuurlijk.

En het gaat dus om een MITM-aanval.

[Reactie gewijzigd door AnonymousWP op 14 april 2023 08:54]

Thanks voor de uitleg!

Hoe zou zo'n MITM er nu uitzien dan? Heeft WhatsApp niet al een manier om spoofen te voorkomen? Want dat is v.g.m. waar dit allemaal om gaat Authenticatie bewijzen van degene die een bericht verstuurt.
Zou ik dan nu nog, in de huidige situatie, via WhatsApp berichten naar iedereen kunnen versturen lijkend alsof die van wie dan ook komen? Ik ging ervan uit dat iedereen nu een soort self-signed certificate zou hebben, en dat een gebruiker kan zien a.d.h.v. een melding wanneer de ondertekenaar niet langer dezelfde is. Ik dacht dat op basis daarvan je de melding zou krijgen dat je contactpersoon van security code is veranderd.

Als ik dat goed begrepen heb, wat is dan de toegevoegde waarde van heel die nieuwe techniek? Gaat het dan meer om een verhoogd vertrouwen bij het opstarten van een communicatie met iemand, omdat je dan niet de melding kan krijgen dat iemand z'n code is gewijzigd?

Dit zou wel kunnen helpen om het te begrijpen, denk ik: https://www.veracode.com/security/man-middle-attack

Naja, dat zal niet eenvoudig zijn om dat zelf te doen, maar als je een exploit kan maken die een kwetsbaarheid uitbuit, waarschijnlijk wel. Zijn voorbeelden over te vinden. Lees anders de whitepaper eens: https://www.whatsapp.com/...p-Security-Whitepaper.pdf

Dan op pagina 24:

WhatsApp users additionally have the option to verify the keys of their devices and the devices of the users with which they are communicating in end-to-end encrypted chats, so that they are able to confirm that an unauthorized third party (or WhatsApp) has not initiated a man-in-the-middle attack. Verification can be done by scanning the QR code or by comparing the 60-digit number between two primary devices. WhatsApp users can also verify individual companion devices manually by using a primary device to check the same QR code or 60-digit number.

The QR code contains:
1. A version.
2. The user identifier for both parties.
3. The full 32-byte public Identity Key for all devices of both parties.

When either device scans the other’s QR code, the keys are compared to ensure that what is in the QR code matches the Identity Key as retrieved from the server. The 60-digit number is computed by concatenating the two 30-digit numeric fingerprints for each user’s device Identity Keys. To calculate a 30-digit numeric fingerprint:

1. Lexicographically sort public Identity Keys for all of the user’s devices
and concatenate them.
2. Iteratively SHA-512 hash the sorted Identity Keys and user identifier 5200 times.
3. Take the first 30 bytes of the final hash output.
4. Split the 30-byte result into six 5-byte chunks.
5. Convert each 5-byte chunk into 5 digits by interpreting each 5-byte
chunk as a big-endian unsigned integer and reducing it modulo 100000.
6. Concatenate the six groups of five digits into thirty digits.

[Reactie gewijzigd door AnonymousWP op 14 april 2023 09:41]

Thanks voor het meesturen van die linkjes. Ik snap het idee van een MITM wel, maar het gaat me juist om dat detail wat je benoemt als "een exploit" die "een kwetsbaarheid uitbuit". Die conceptuele details, i.p.v. precies welke cryptografische technieken, is v.g.m. zo van belang hier.

Kom ik toch weer terug bij mijn eerdere vraag, waarom wordt deze techniek uitgerold? Welke aanval houdt het precies tegen? Een MITM omdat iemand de servers van WhatsApp is binnengedrongen? En dat dan alleen voor initieel contact, omdat je anders al zou zien dat iemand z'n code is veranderd?

Misschien helpen deze Tweets: https://twitter.com/matth...tatus/1646529341797572608

Thanks dat helpt inderdaad.
Mijn conclusie uit die tweet is alleen dat er effectief nog niks wordt bereikt. De aanval had nu al een MITM nodig zoals ik dacht + toegang tot de keyserver van WhatsApp, dat wordt nog eens bevestigd in die tweets.
Nu is deze nieuwe oplossing iets tegen MITM, maar als je nog steeds toegang tot de key server hebt kun je nog steeds een ghost user toevoegen, zoals in die tweets gezegd wordt.

Dit lijkt dus meer een stap in de goede richting, maar netto wordt het voor een aanvaller dus niet echt moeilijker. En daarmee ben je als gebruiker netto ook niet méér beschermd hierdoor.

Als ik de (technische) artikels goed begrijp, zal whatsapp vanaf nu een publieke databank aanbieden met public keys gelinkt aan accounts. Een account is een telefoonnummer wellicht; het wordt dus nog net iets gemakkelijker om op te zoeken of iemand whatsapp gebruiker is. Daarnaast kunnen we uit deze gegevens afleiden hoe vaak deze persoon van key wisselt, en dus nieuwe toestellen in gebruik neemt.

In het verleden waren vrienden en kennissen vaak al een beetje “onder de indruk” als ik heb wist te vragen of ze een nieuwe smartphone hadden gekocht. Dat had ik namelijk gezien omdat hun beveiligingscode werd veranderd. In de toekomst zal je daar dus zelfs geen “levend” gesprek meer voor nodig hebben, maar dit gewoon wereldwijd kunnen nagaan in de publieke databank.

Ik weet niet of ik hier blij van word.

Facebook hoofdkwartier: Hey niemand controleert de cryptografische sleutels die we ze sturen vanaf onze servers. We moeten dit makkelijker maken. Laten we publiek maken welke mensen allemaal WhatsApp hebben en hun sleutels erlangs zetten, en dan kan iedereens whatsapp-app die data van onze servers downloaden om het wel helemaal zeker te weten!

Voordeel: mensen voelen zich veiliger
Voordeel: media-aandacht
Nadeel: het doet niks

(De device keys heb ik me niet in verdiept, dit gaat over de automatische verificatie waar de Tweakers headline mee pronkt.)

Via hun blog post kom je op een GitHub repository waar de readme linkt naar een paper SEEMless: Secure End-to-End Encrypted Messaging with less trust. "we formalize the notion of [zo'n key directory]: a system which allows users to monitor the keys that the service is distributing on their behalf". Dus het gaat specifiek om dat de persoon van wie de key is ook kan controleren of de juist key wel wordt uitgegeven. Maar wat de ene persoon toegestuurd krijgt hoeft helemaal niet hetzelfde te zijn als wat de andere persoon toegestuurd krijgt als reactie van de directory-server. Als je hetzelfde IP-adres hebt en er geen andere metadata wordt meegestuurd, wordt dat wel lastig om te differentiëren voor de aanvaller, maar behalve op de toevallige momenten dat je met iemand op hetzelfde WiFi zit, is dat niet het geval. Of als je dat wel zit dan stuurt de aanvaller een reactie terug "de dienst is tijdelijk niet beschikbaar". Ik kan me nauwelijks voorstellen dat WhatsApp het dan zou blokkeren of een waarschuwing zou geven, maargoed deze situatie is sowieso enkel van toepassing wanneer de aanvaller niet kan weten welk apparaat vraagt dus zelfs al zouden ze het goed implementeren dan maakt het meestal niet uit.

Het lijkt zo nutteloos dat ik me afvraag of ik het wel goed snap. Dieper in die publicatie lezend zie ik echter precies de problematiek aangehaald en de oplossing bevestigd als zijnde "tsja dan moet de persoon wiens key het is maar aan facebook blijven vragen welke key ze hebben geüpload":

we expect the server to be able to prove to Bob that he is seeing Alice’s latest key [..] This is trivial to achieve if we assume that Alice can always sign her new public key with her old secret key. But this is a completely unreasonable assumption from an average user who may lose her device or re-install the software, thereby losing her previous secret key; the user will only have access to her latest secret key which is stored on her latest device. It is crucial to not assume that Alice or Bob can remember any cryptographic secret. Under this constraint, we need Alice to monitor her key sufficiently often to make sure her latest key is in the server directory. Only then, we can talk about Bob getting Alice’s latest key in a meaningful way.

Voor iemand die thuis meespeelt en verder leest: de publicatie zegt vervolgens nog "The server [publishes updates] in batches, and publishes a commitment to the current state of the database com and proof Π Upd that a valid update has been performed", maar hoe helpt dat? De server signeert de update met diens eigen sleutel. De definitie van end-to-end encryption is "a system of communication where only the users communicating can read the messages." Niet de server maar uitsluitend de gebruikers. In theorie is dat ook zo, tot de server eenzijdig besluit zich ermee te bemoeien zonder tussenkomst van de gebruikers. (Zie ook de vraag elders in deze reacties over of een rechter kan bevelen dat ze mee willen gaan lezen. Hier is je methode. Je hebt dan geen historie, maar wel de chat vanaf nu.)

TL;DR: je vertrouwt niet op een cryptografisch pad, je vertrouwt niet op iets dat de partijen zich nog herinneren wanneer een cryptografisch pad niet beschikbaar is, maar je vertrouwt erop dat de server eerlijk is tegen beide partijen.

Ookwel bekend van Keybase, die zeggen dat de chat end-to-end versleuteld is maar je kan het alleen niet nakijken. Je moet de server maar vertrouwen eerlijk te zijn tegen de beide partijen.

[Reactie gewijzigd door Lucb1e op 13 april 2023 21:08]

Door Lucb1e:

De definitie van end-to-end encryption is "a system of communication where only the users communicating can read the messages."

E2EE is zinloos en is ook helemaal niet wat gebruikt wordt en wat WhatsApp probeert te verbeteren (met een soort PGP keyservers?).

Het gaat hier om End to End Authentication and Encryption.

Nb. bizar vind ik het telkens weer hoe weinig mensen snappen dat, zonder authenticatie (weten wie de sleutel heeft of hebben), encryptie zinloos is.

Indien de apps betrouwbaar zijn en de client-devices niet zijn gecompromitteerd, is face to face uitwisselen van public keys altijd de veiligste methode.

Alles wat je als alternatief verzint kan nooit tippen aan die betrouwbaarheid.

Nb. dit lijk jij ook te stellen, maar ik kon dit niet goed uit jouw reactie halen.

Het gaat hier om End to End Authentication and Encryption.

Die benaming heb ik nog niet eerder gehoord, maar je hebt natuurlijk gelijk. Ik denk wel dat we kunnen stellen dat deze betekenis (van de term die jij noemt) wel bedoeld wordt wanneer iemand E2EE zonder A zegt, anders is het inderdaad nutteloos. Ik gebruik zelf de term opportunistic encryption voor encryptie zonder authenticatie, al is dat ook niet helemaal juist omdat OE is wanneer je terugvalt op niet-versleutelde (noch geauthenticeerde) communicatie. Maar dingen namen geven is een van de twee moeilijkste dingen in computer science

Anyway, de A is hier precies waar het aan short. WhatsApp (de client software) doet wel mooi aan encryptie, dat geloof ik direct, maar wiens key versleutel je voor? Dat probeert Facebook hiermee te verbeteren door het aan zichzelf te vragen. Fijne authenticatie heb je dan idd ⁻\_(^^)_/⁻

Gewoon QR-verificaties (or equivalent) dus blijven doen zoals jij ook zegt.

[Reactie gewijzigd door Lucb1e op 13 april 2023 23:46]

Dank voor de respons!

Door Lucb1e:

[...] wanneer iemand E2EE zonder A zegt, [...]

En strikt genomen kloppen die eerste 3 karakters ook niet, want ik ben niet de enige die moeite heeft met asymmetrische encryptie "uit het hoofd" (nog los van het niet kunnen onthouden van voldoende lange private keys). Elke "End" is een "App op een (hopelijk) End Device" waarbij AitM's (Attacker in the Middle) tussen die App en de gebruiker niet kunnen worden uitgesloten, het afwachten is wie de gebruiker is en of deze een bericht voor zichzelf houdt of verder verspreidt.

Ik gebruik zelf de term opportunistic encryption voor encryptie zonder authenticatie,

Veel mensen denken dat https servercertificaten noodzakelijk zijn voor een versleutelde verbinding, maar een TLS v1.2 verbinding kan zelfs helemaal zonder certificaat (DH_Anon) en sowieso zegt een self signed cert niets (in elk geval de eerste keer niet).

Maar dingen namen geven is een van de twee moeilijkste dingen in computer science

It's always DNS

[Reactie gewijzigd door ErikvanStraten op 14 april 2023 00:51]

Aardig off-topic maar nu we hier toch zo lekker keuvelen

sowieso zegt een self signed cert niets (in elk geval de eerste keer niet).

Heb ik jarenlang gebruikt voor mijn server thuis. De eerste keer met Firefox op LAN bezoeken, iig vroeger toen er nog niet 20 andere apparaten ook op dat LAN zaten, vond ik toch vrij zeker dat het dan in orde was (met de kennis van nu zou ik de fingerprint direct exporteren bij het instellen van de server). Daarna weet je als je onderschept wordt. Ik gebruikte dus ook de TOFU, maar ook de eerste keer op LAN heeft het nut om dan het cert uit te wisselen. Ik snap nog altijd niet dat het niet als kwetsbaarheid in Chromeium en MSIEdge gezien wordt dat ze dat beide niet hebben, maar dat je elke keer weer het foutmeldingscherm krijgt. Over mensen aanleren voorbij waarschuwingen te klikken gesproken, naast ontbrekende TOFU. Hoeveel organisaties, zeker toen (spreek 2011), self-signed certs niet gebruikten voor intranetsites (tegenwoordig met Let's Encrypt veel minder).

Opportunistic encryptie heeft ook mijn kont een keer gered toen mensen op MBO ICT lollig waren en een half forum van me verwijderd hadden met duizenden berichten, maar ze konden (zag ik in access logs) niet voorbij de adminlogin (met gejatte session cookie) omdat dat naar een wachtwoord vroeg en dat was client-side gehasht (ode aan SMF) en ze hadden schijnbaar alleen meegelezen en niet een andere javascript geïnjecteerd om de hashing uit te schakelen (véél moeilijker ook, en je moet al voorbedachte raden hebben). Daardoor was er uiteindelijk nog iets van over. (Daarna heb ik een backup leren maken ook van "cloud" / "not my server" diensten...) Zelf had ik als scriptkiddie ook moeite met dingen op publieke WiFis injecteren, maar airmon en wireshark aan lukte wel. Het stopt dus wel aanvallen. Niet per se de geavanceerde, maar hoeveel niet-geavanceerde kunnen we voorkomen?

Ik vind client-side hashing, self-signed certs, of andere dergelijke half-veiligheden wel meetbaar wat toevoegen en dat het ondergewaardeerd is in de security community. Sorry dat jouw opmerking me triggerde, ik snap natuurlijk waar je algemeen op doelt