Zie hiervoor onder andere de wikipedia pagina over end-to-end versleuteling:
Ik denk dat die passage uit dat wikipedia artikel verwijderd moet worden, want er staat geen bron bij en het klopt ook niet helemaal.
Zowel bij iMessage als bij WhatsApp, kan je de TLS versleuteling met de serververbinding wel doorbreken: maar dan krijg je alsnog troep te zien. Zoals ook al in dit artikel op Tweakers staat: WhatsApp voldeed wel aan het verzoek om een tap te plaatsen, maar overhandigde vervolgens data die volslagen waardeloos was omdat er end-to-end encryptie wordt toegepast.
Bij iMessage is echter de pest dat Apple alle sleutels beheert en aan de server vertelt aan wie de server alle berichten moet doorsturen, en met welke sleutels dat versleuteld wordt. Apple kan dus, zonder dat je daar ooit iets van merkt, een extra (verborgen) apparaat toevoegen aan jou iCloud; die vervolgens ook netjes kopietjes krijgt van al jou berichten/media, en een sleutel heeft om die te decrypten. Dat is inderdaad een gebroken vorm van E2EE, en daar kan inderdaad een overheidstap op geëist worden; puur omdat er geen Authenticatie mogelijk is. Op geen enkele wijze.
Echter, dat gedeelte over WhatsApp: je kan de service provider niet forceren om foute sleutels uit te geven. Dat gaat niet, want de twee apparaten babbelen zelf met elkaar en wisselen lokaal gegenereerde sleutels uit die met elk verzonden bericht de oude key droppen en een nieuwe session-key genereren. (Op basis van
Perfect Forward Secrecy en
Future Secrecy. En de DH-keys kan je vervolgens op het ontvangende/verzendende toestel vergelijken dmv QR-Code en een cijfercode die je met elkaar kan controleren. Als daar iemand tussenin gaat zitten, dan klopt of de code die je scant niet: of de ontvanger kan niet meer lezen wat je verstuurd omdat er totaal andere session-keys aangemaakt worden nadat één bericht is verzonden.

En dan weet je hoe laat het is.
WhatsApp doet dus niet aan key management in een gecentraliseerd platform, zoals Apple, maar laat dat over aan de toestellen zelf!
Als resultaat moet het dan zo zijn dat ALS ze een backdoor zouden willen inbouwen waarmee een gesprek tussen twee personen uitgelezen moet worden, dat dan de client op een van de twee toestellen backdoored zal moeten worden om een unencrypted kopie te sturen of een tweede sessie opzet met een tweede ontvanger (Waarbij dus geeneens sprake is van een MITM aanval.). Maar als de overheid reeds toegang heeft tot die telefoon: dan is sowieso de encryptie al volslagen nutteloos geworden omdat ze met die toegang sowieso al je berichten kunnen zien.
Snap je het verschil en de problematiek?
Het breken van die SSL/TLS maakt dus eigenlijk geen verschil. Krijg je dat voor elkaar? Gefeliciteerd, je kan nog steeds niet meelezen.

Ja, wat control data misschien; that's it. Metadata zou te jatten vallen, maar daar ontkom je niet aan; dat valt namelijk wel te tappen. Immers moet WhatsApp/iMessage weten van wie het bericht is en naar wie het verstuurd moet worden. Maar de inhoud van de berichten? Die is netjes encrypt.
Dat kan inderdaad met de huidige implementatie. De Whatsapp client verifieert de identiteit van de chatpartners niet, waardoor het triviaal is om een "men in the middle" aanval uit te voeren.
Nou, "triviaal" is wel erg overdreven natuurlijk; het is iets lastiger om een MITM uit te voeren als je jezelf in een 1-op-1 chat moet injecteren. Een MITM is niet te detecteren, maar "triviaal" om een MITM uit te voeren, alsof het een peulenschil is die je buurjongetje nog kan uitvoeren, is het zeker niet. Dan moet je van behoorlijk goede huize komen.
Een developer van Whatsapp heeft echter aangegeven dat authenticatie wel in de planning staat.
Die functie is in een zeer ver gevorderd stadium.
Je krijgt overal notificaties als je encrypt bent, of wanneer dit niet zo is; en ook bijvoorbeeld een overzicht van hoeveel mensen in een groep/verzendlijst wel/geen encryptie ondersteunen. (en die mensen moet je dan ff een schop onder hun hol geven om WhatsApp te updaten.)
Maar ook als de beveiligingscode van een chatpartner wijzigt, krijg je direct een waarschuwing. Als de server die code zou wijzigen (en dat zou noodzakelijk zijn voordat een MITM aanval gestart kan worden) dan zou je dit dus ook doorhebben omdat je client opeens een andere key voor z'n neus krijgt. De normale burger zal dat niet snel boeien, maar een crimineel weet dan waarschijnlijk al snel wat er aan de hand is als blijkt dat z'n maatje helemaal geen nieuwe telefoon heeft.
Ik verwacht dat deze functie er ergens eind deze maand, misschien begin April, ingepropt zal worden en gepushed zal worden naar *alle* platforms. (Ja, tot mijn enorme verbazing zelfs inclusief Symbian S40 en S60.

)
De broncode is niet bekend, dus weet jij veel of je een andere versie doorkrijgt dan je buurman..)
Nou... Ja, als je het echt wil weten kan je altijd de binaries met elkaar vergelijken.

Shasum en klaar.
Voor een uitgebreide discussie over het falen van de versleuteling van Whatsapp, lees deze interessante e-mail thread.
Die thread is van November 2014 toen WhatsApp *net* encryptie in testfase had ingeschakeld op Android. Dat kan je niet toepassen op de huidige situatie. Die server-side control (die noodzakelijk was om de encryptie opzet in eerste instantie ook maar te kunnen testen) is niet langer van toepassing; de clients beslissen het nu zelf en gaan dikke waarschuwingen weergeven als er geen E2EE opgezet kan worden omdat iemand te lui is om z'n client te updaten... De server beslist niet meer, het is nu de client die beslist; en die kan enkel beslissen geen E2EE toe te passen als de gesprekspartner op een te oude versie zit, MAARRRR: als E2EE eenmaal opgezet is met je chatpartner, dan kan je dit niet meer downgraden zonder dat de gebruikers het merken. Het is dus ook niet zo dat je de client dan kan overtuigen dat die persoon opeens weer op een te oude versie zit en dat encryptie uitgezet moet worden. Of nouja: dat zou trouwens wellicht wel kunnen, maar dan krijgt de verzendende partij dus opeens een melding dat de berichten niet langer E2EE zijn of dat de key gewijzigd. En dan kan je met elkaar gaan vergelijken dat... Et cetera.

Of dat encryptie opeens uitstaat, dan krijg je dus ook een waarschuwing...
Dit wordt trouwens in die thread ook netjes uitgelegd door Moxie zelf:
Yes, clients need to negotiate encryption capability until all clients
support encryption. We'll be surfacing this into the UI for each client
once protocol support is complete on that client. Rolling something
like this out to 600MM+ devices is an incremental process that takes time.
(
https://moderncrypto.org/...essaging/2014/001140.html)
(Intussen zijn het er 1B+ trouwens, fancy that!

)
Kortom: dat is allemaal al lang en breed geregeld, en dit stond altijd al op de planning; al die doomscenarios van toen het nog in pre-beta zat moet je niet al teveel aandacht aan besteden in de context van de huidige implementatie; hoewel het vaak wel zeer interessante discussies zijn.

Dat hebben ze bijvoorbeeld bij WhatsAPI (zie GitHub) en, non-publique, bij de EFF ook al opgemerkt trouwens. Toppie dus!
Als die functie er weer in zou komen, dan zouden we dat merken. De client weet immers met wie je wel en niet encrypt bent, en waarschuwt je actief als de sleutel wijzigt of als de encryptie gedeeltelijk wegvalt. (Bij groepen bijvoorbeeld, als je iemand toevoegt die geen E2EE ondersteund krijg de hele groep een waarschuwing "
WARNING:
This group is no longer fully end-to-end encrypted because <user> must upgrade WhatsApp! Tap for more details". Die persoon forceren te upgraden of gewoon uit de groep trappen zal een key-renegotiate uitlokken waardoor je weer "This group is now end-to-end encrypted! Tap to verify security codes." krijgt.

En dan ben je weer netjes beveiligd.

)
Dus gelukkig kan je die thread, die op dat moment nog relevant was (alleen iets te snel vraagtekens stelde omdat er nog geen sprake was van een werkende omgeving), negeren als het gaat om de huidige implementatie; en al helemaal kan negeren op het moment dat de Auth functie is toegevoegd. (Let op dat retransmission backdoors onmiddelijk zouden opvallen in software als WireShark... Dat inbouwen zou een mega risico zijn.)
Gelukkig "faalt" deze encryptie intussen dus totaal niet meer en zit het enorm goed in elkaar.
(Falen is sowieso een raar woord, je kan niet zeggen dat een huis slecht geïsoleerd is als enkel nog maar de heipalen in de grond zitten. Zo kan je ook niet zeggen dat encryptie faalt als ze enkel nog maar het grondwerk in Alpha versie naar één OS hebben gepushed.)
Lees anders even hoe Axolotl werkt. Als het zo zou zijn dat de encryptie die nu in WhatsApp zit slecht is, dan zou dat automatisch betekenen dat heel Axolotl slecht is en dat je dus ook Signal niet zou kunnen vertrouwen.
Er is een reden dat de EFF, en mensen zoals Snowden, Signal aanbevelen: omdat de encryptie bewezen extreem goed werkt en ijzersterk is.
Deze zal even sterk zijn in WhatsApp op het moment dat de uitrol met Auth is voltooid. Het is nu al bijzonder sterk: het enige probleem is inderdaad dat je de Authenticatie zelf nog niet kan verifiëren. (Dat betekend echter niet dat de encryptie zelf niet werkt!! Het betekend enkel dat je het zelf nog niet kan controleren; en dat er nu inderdaad minimale risico's zijn. Die verdwijnen binnenkort als sneeuw voor de zon.)
Die functie komt eraan, en dan is het even veilig als Signal...
Tenzij er een backdoor in moet van de overheid.

Maar zo ver zijn we nu nog niet.
Kortom: die encryptie faalt niet, die e-mail thread is te oud; en derhalve niet langer van toepassing op de huidige situatie.

Gelukkig maar!
Ja, dit was een probleem. Nee, dit zit er nu niet meer in en is dus geen probleem meer.
Het "probleem" voor Amerikaanse autoriteiten is dus niet per se het niet kunnen breken van de versleuteling, maar het feit dat ze daarvoor ofwel een SSL certificaat moeten namaken (dat wil zeggen, een van de CA's dwingen een certificaat uit te schrijven) met alle risico's van dien, of bij Facebook moeten vragen om een verbinding te kraken. Nu kan ik me voorstellen dat Facebook nog wel meewerkt als het om een paar specifieke verbindingen gaat, maar de autoriteiten willen natuurlijk een sleepnet uitgooien..
Facebook kan helemaal niet mee meewerken om een paar specifieke verbindingen uit te lezen, dat is het mooie van dit alles...
Die hebben de sleutels ook niet tot hun beschikking. De keys en session keys staan enkel opgeslagen op het verzendende en het ontvangende toestel; en de session keys wisselen met elk verzonden bericht.
Zelfs ALS Facebook het voor elkaar zou krijgen om één session-key te achterhalen/te kraken, dan kunnen ze alsnog niet berichten uit het verleden kraken; maar ook geen toekomstige berichten. Immers gebruikt het constant een nieuwe SK voor elk bericht dat verzonden wordt...
Hoe WhatsApp, natuurlijk dankzij Axolotl van Open Whisper System; waarbij Moxie Marlinspike himself de boel implementeert bij WhatsApp, encryptie toepast zorgt ervoor dat het onmogelijk wordt voor zowel WhatsApp/Facebook als de overheid om de berichten mee te kunnen lezen zonder toegang tot het toestel... En dat is geniaal.
Ze moeten het dus écht hebben van een backdoor in de software, het volstaat niet meer om tegen Facebook/WhatsApp te zeggen "werk mee met ons, en overhandig ons de gespreksinhoud". Het *kan* gewoon niet. (Zie ook de hele rel in Brazilië op dit moment.)
Derhalve zal de senaat toch echt WhatsApp moeten verplichten om een backdoor in te bouwen, anders zullen ze nooit en te nimmer iets kunnen tappen zonder toegang tot het toestel. En in het geheim een backdoor toevoegen: dat heeft ook geen functie, want die zal men toch achterhalen. Waarschijnlijk heel snel... De broncode van WhatsApp wordt echt mega vaak reverse-engineered en decompiled, en de traffic echt rete vaak geanalyseerd.
Kortom: zo'n backdoor kan niet anders dan obvious zijn, en er moet eerst een verplichting vanuit de senaat komen. En dat gaat sowieso nog wel ff duren.
In de tussentijd kan niemand je WhatsApp gesprekken aftappen, zelfs WhatsApp zelf niet. Prima!
[Reactie gewijzigd door WhatsappHack op 22 juli 2024 22:49]