Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Beveiligingsexperts kritiseren The Guardian-artikel over WhatsApp-'backdoor'

Door , 95 reacties, submitter: WhatsappHack

Verschillende beveiligingsexperts hebben in een gezamenlijk artikel kritiek geuit op de berichtgeving van The Guardian over een vermeende 'backdoor' in WhatsApp. Zij vinden dat de krant onverantwoordelijk heeft gehandeld door deze term te gebruiken.

De experts, waaronder bekende namen als Matthew Green, Bruce Schneier en Jonathan Zdziarski, vragen de krant het stuk dan ook terug te trekken. De kwetsbaarheid in WhatsApp is volgens de ondertekenaars van het artikel niet te omschrijven als een backdoor. Zij omschrijven deze zelf als een ontwerpkeuze van WhatsApp, iets dat het bedrijf bij de publicatie aan het artikel ook al liet weten. Het lek is bovendien moeilijk te misbruiken.

Door de publicatie met de term 'backdoor' zou de krant voor veel verwarring hebben gezorgd, bijvoorbeeld onder journalisten, activisten en burgers. De beveiligingsexperts stellen dat er discussie kan zijn over de keuze van WhatsApp om gebruikers niet te waarschuwen voordat niet-verzonden berichten alsnog verstuurd worden. De keuze zou echter te verdedigen zijn. Ook Frederic Jacobs, die werkte aan het Signal-protocol dat aan WhatsApp ten grondslag ligt, schrijft dat het een 'redelijke keuze' of trade-off is, die vaker op het gebied van beveiliging moet worden gemaakt.

De beveiligde chatapp Signal kiest er bijvoorbeeld voor om gebruikers te waarschuwen als niet-verzonden berichten aan een persoon worden afgeleverd wiens beveiligingssleutels zijn veranderd. Hierover zeggen de experts dat gebruiksgemak en de mogelijkheid om met een grote groep mensen te communiceren een grote rol spelen. Het toevoegen van een waarschuwing in WhatsApp zou er niet voor zorgen dat gebruikers veiliger worden, maar juist dat zij bijvoorbeeld overgaan naar een onveilige variant zonder waarschuwingen zoals sms.

De kwetsbaarheid die door The Guardian als 'backdoor' was aangemerkt, is ontdekt door beveiligingsonderzoeker Tobias Boelter. Daarbij gaat het erom dat WhatsApp voor niet-verstuurde berichten, bijvoorbeeld omdat de ontvanger offline is, nieuwe sleutels aanmaakt en de berichten alsnog aflevert. Dit zou door een aanvaller gebruikt kunnen worden om de inhoud van berichten te achterhalen, onder andere door zich als de ontvanger voor te doen via spoofing. The Guardian heeft na de publicatie van zijn artikel enige wijzigingen gepland en de term 'backdoor' verwijderd.

Sander van Voorst

Nieuwsredacteur

20 januari 2017 17:55

95 reacties

Submitter: WhatsappHack

Linkedin Google+

Reacties (95)

Wijzig sortering
Hier is een artikel over de beveiliging bij sleutel wijzigingen van verschillende chat apps: https://medium.com/@pepel...-key-changes-5fd4334b809a

Bij Signal gaat een bericht verloren als de sleutel veranderd terwijl het bericht verzonden wordt.

Bij Telegram komt geen enkel bericht meer aan na wijziging van de sleutel.

Wire is de slechtste chat app. Het is inconsistent met waarschuwingen en je moet elk apparaat verifiëren. Na elke herinstallatie komt er een apparaat bij. Je moet handmatig alle tekens lezen in plaats van een QR code te scannen om de sleutel te controleren.

Allo heeft een dubbele opt-in. Je moet incognito chats gebruiken en de waarschuwing bij sleutel wijzigingen aanzetten. Je op een bericht tikken om hem te verzenden na wijziging van de sleutel. Als de sleutel van de ontvanger gewijzigd wordt terwijl je bericht verzonden wordt, kom je er pas achter als de ontvanger jou een bericht verstuurd en dan kan je ze pas opnieuw versturen (zelfs in de verkeerde volgorde).
Huh... Dat artikel... Resumerend:
de twee apps met de beste crypto-implementaties: Signal, WhatsApp.
Goed maar wat werk nodig: Allo.
Ronduit slecht: Telegram, Wire.

So far so good. Maar wat schetst mijn verbazing? In de comments staat... Tobias Boelter, die het eens is met die conclusie. :/ Wtf!? 8)7
Die zit dus eerst onterecht te zeuren tegen the Guardian over hoe *** WhatsApp's encryptie is, en nu vindt ie die conclusie opeens "very nice" en wil ie WhatsApp Voice key-auth ook eens gaan testen? :+
Dat is echt heel heel erg raar, of ben ik raar dat ik dat raar vind? :P

Granted, misschien is het een nep-account - maar zo te zien is ie al ff lid én is het gelinkt aan z'n Twitter (medium gebruikt dat voor SSO), dat maakt dat wel onwaarschijnlijk. :')
Heb je het artikel gelezen?
(WhatsApp)
Bad: Automatically re-encrypting messages in flight to new keys, even though the user is notified. If they made this require user approval, WhatsApp would be the best messenger I tested. Figuring out how to make this work well in groups while preserving message ordering could be difficult.
Overigens zou ik de tests die hij net heeft uitgevoerd eens op je gemak zelf gaan voeren, want Telegram geeft wél een leesbevestiging, geeft wél aan wanneer een e2ee chat niet meer beschikbaar is en communiceert key-changes door middel van een nieuwe end-to-end chat om extra duidelijk te maken dat je opnieuw je identificatieproces moet doorlopen. Als je mij niet gelooft, zou je deze auteur ook niet moeten geloven. Dus doe vooral je eigen tests.

Als je echt wilt weten hoe deze apps met elkaar vergelijken, zul je de minder flashy, minder aandachttrekkende en minder winst-gerichte websites van experts eens moeten raadplegen. Kijk bijvoorbeeld eens hier, en vergelijk dat met je eigen conclusie:

https://www.eff.org/node/82654

Zoals de disclaimer aangeeft, is deze scorecard out-of-date, echter is het encryptieschema van zowel WhatsApp, Signal als Telegram niet veranderd sinds deze scorecard voor het laatst geüpdatet is.

Leuk dat je overal je mening zo verkondigd, maar de feiten liggen toch echt anders; qua end-to-end security zijn de apps op z'n minst vergelijkbaar, waar de andere genoemde apps zijn niet eens gevoelig voor de zwakte waar dit Tweakers artikel over gaat.

Overigens, misschien dat het feit dat deze auteurs zo vaak van mening wisselen een beetje verraad wat hun level van expertise is.

[Reactie gewijzigd door Laloeka op 21 januari 2017 01:54]

Heb je het artikel gelezen?
Ja.

Voordat we verder gaan moet ik opmerken dat mijn post echt absoluut niet ging om een vergelijking tussen de diensten te maken, maar enkel om die opmerking van dhr. Boelter in de comment sectie waar ik echt heel verbaasd over was.
Ik tikte de conclusie van de auteur over, omdat ik het heel bizar vind dat dhr. Boelter het eens is met die conclusie; wat haaks staat op wat hij eerder deze week tegen The Guardian heeft verkondigd. That's all, verder heb ik niets gezegd. :)

Maar nu je er zelf over begint zal ik er toch op reageren, en for the sake of discussion zal ik Telegram v WhatsApp dan behandelen vanuit mijn visie:
(En maar hopen dat niemand boos wordt dat ik dat doe. Ik begon er niet over mensen, onthoud dat a.u.b.! :P)
Overigens zou ik de tests die hij net heeft uitgevoerd eens op je gemak zelf gaan voeren, want Telegram geeft wél een leesbevestiging, geeft wél aan wanneer een e2ee chat niet meer beschikbaar is en communiceert key-changes door middel van een nieuwe end-to-end chat om extra duidelijk te maken dat je opnieuw je identificatieproces moet doorlopen. Als je mij niet gelooft, zou je deze auteur ook niet moeten geloven. Dus doe vooral je eigen tests.
Dat klopt deels, en dat weet ik.
Ik ben het alleen alsnog eens met de conclusie dat Telegram een van de slechtste is omdat:
1.) Standaard er totaal geen encryptie plaatsvindt en je berichten en media doodleuk ge-upload worden naar de cloud waar het plain-text accessible is voor Durov en Co. Dat is pas bijzonder onveilig. En de meeste mensen denken dat Telegram ook in de normale modus veilig is, en Telegram doet er niets aan om dat belachelijke beeld te veranderen - sterker nog: ze proberen dat te stimuleren. Dat neem ik ze best wel kwalijk, al kan ik het me vanuit hun zakelijk oogpunt goed begrijpen.
2.) MTProto zeer grove lekken bevat, Signal en WhatsApp hebben dat niet.
De trade-off in WhatsApp, waar veel voor te zeggen is, verbleekt bij de problemen met MTProto waar helemaal niets voor te zeggen is en die gewoon echt heel erg fout zijn.

Dat het mechanisme dat daar beschreven wordt niet geheel accuraat is, of gewoon tijdens de tests niet lekker werkte: dat klopt. :)
Als je echt wilt weten hoe deze apps met elkaar vergelijken, zul je de minder flashy, minder aandachttrekkende en minder winst-gerichte websites van experts eens moeten raadplegen. Kijk bijvoorbeeld eens hier, en vergelijk dat met je eigen conclusie:

https://www.eff.org/node/82654
Ja, die ken ik.
Ben je er ook van op de hoogte dat EFF na die scorecard in eerste instantie is begonnen met het volledig aanraden van WhatsApp? https://ssd.eff.org/en/module/how-use-whatsapp-ios

Dit hebben ze later deels teruggedraaid vanwege het delen van telefoonnummers met Facebook, maar hebben daarbij heel duidelijk opgemerkt dat het geen invloed heeft op de encryptie zelf. Ze kunnen het enkel niet aanraden als beste keuze voor iemand die heel veel te verliezen heeft bij privacy, omdat een zeer klein gedeelte data gedeeld wordt met Facebook ALS je die opt-out nooit hebt gedaan. (Metadata wordt overigens NOOIT gedeeld met Facebook, iets wat de EFF ook heel nadrukkelijk vermeld - en daar heel blij mee is.)
Ze benadrukken dan ook:
We take no issue with the way this encryption is performed. In fact, we hope that the encryption protocol WhatsApp uses, the Signal Protocol, becomes more widespread in the future.
Die scorecard moet je dus gewoon helemaal vergeten, en absoluut niet meer gebruiken om een oordeel te vellen over de sterkte van de encryptie binnen de bekende messengers.

Telegram wordt overigens op geen enkele wijze aangeraden door de EFF, en ze weten heel goed dat die Scorecard een vertekend beeld geeft en niet het hele verhaal verteld: daarom hebben ze die ook deprecated, omdat mensen de illusie kregen dat Telegram veiliger was dan WhatsApp en een beter encryptie protocol had: terwijl dat absoluut in geen enkel opzicht waar is.
Leuk dat je overal je mening zo verkondigd, maar de feiten liggen toch echt anders; qua end-to-end security zijn de apps op z'n minst vergelijkbaar, waar de andere genoemde apps zijn niet eens gevoelig voor de zwakte waar dit Tweakers artikel over gaat.
Nou ten eerste weet ik niet waar die opmerking vandaan komt, want ik verkondigde in principe helemaal niets totdat jij dit poste... Ik maakte enkel de opmerking dat ik die conclusie + het commentaar van Boelter absoluut niet kon rijmen met zijn uitspraken tegenover The Guardian eerder deze week. ;)
Het waren dus ook niet *mijn* uitspraken, maar de uitspraken van de auteur.
De feiten blijven de feiten. :) Ik ben niet van mening dat die anders liggen.

Maar om daar inhoudelijk op voort te borduren gezien je zelf nu wél een vergelijking maakt waar ik graag op zou willen reageren:
Je kan WhatsApp/Signal naar mijn mening echter absoluut niet vergelijken met Telegram qua sterkte; daar verschillen we van mening. (Again :P) Telegram schiet gewoon veel te ver tekort in dat opzicht, waar WhatsApp dat juist niet doet.
Je kan die scorecard niet als argument gebruiken. Zeker niet gezien het standaard gedrag van Telegram.

Als je WhatsApp als onveilig wilt zien omdat er een "lek" inzit dat theoretisch met veel "MAAR" en "ALS" situaties misschien succesvol misbruikt zou kunnen worden, dan kan je toch niet serieus menen dat een applicatie die standaard helemaal geen encryptie heeft en dus in de default mode oneindig veel kwetsbaarder is dan WhatsApp toch niet werkelijk als "vergelijkbaar alternatief met vergelijkbare veiligheid" benoemen? No way. :P En dan komt daar dus nog bij dat in de non-default mode, de secret-chats, er grote vraagtekens zijn gezet bij het functioneren van het zelfgebouwde rare protocol dat Telegram gebruikt. Dat is dus dubbelop een probleem.

Dat zou dus niet eerlijk zijn. Dan vind je een minimale trade-off die WhatsApp heeft geïmplementeerd heel erg en reken je ze dat zwaar aan (terwijl de encryptie nog altijd uitermate goed functioneert en het nog steeds een zeer veilige applicatie is), maar de trade-off die Telegram gebruikt waardoor er totaal geen encryptie is én een self-made crypto gebruikt die barst van de fouten: daarvan suggereer je haast dat het wél acceptabel is (althans: zo komt het over. Immers stel je dat ze qua veiligheid vergelijkbaar scoren.), terwijl de impact op je privacy en veiligheid veel groter is; en Telegram vele malen onveiliger is dan WhatsApp in beide opzichten. :)

In vergelijking met de andere messengers, blijft WhatsApp dus een van de veiligste messengers die er bestaan - en hoeven ze enkel Signal voor zich te dulden; wat, hoewel niet helemaal zuiver tot die conclusie is gekomen, de auteur van dat artikel ook stelde.
Overigens, misschien dat het feit dat deze auteurs zo vaak van mening wisselen een beetje verraad wat hun level van expertise is.
Ik gaf dan ook geen waarde oordeel over het artikel, maar ging in op de comment sectie die ik daar met stomme verbazing heb zitten aanschouwen. ;)

[Reactie gewijzigd door WhatsappHack op 21 januari 2017 04:07]

Geklets zonder fundering.

Zoals bij de oorspronkelijke publicatie al bleek zijn er twee methoden om dit 'lek' te misbruiken:
1) door heel strategisch op het juiste moment een telefoon te registreren tussen verzenden en ontvangen van een bericht. Extreem moeilijk, en verholpen doordat Whatspp 2FA invoerde.
2) als WhatsApp zelf haar servers en app zou zou aanpassen dat er een tweede bericht verstuurd wordt.

In beide gevallen krijg je als verzender echter een notificatie dat de encryptie-sleutel van je ontvanger gewijzigd is. Dus nee, geen NSA bruikbaar middel.

Overigens als je WhastApp niet vertrouwd, zou ik de software ook niet gebruiken. Hetzelfde geldt voor Signal waar je ook een voor jou closed source app download die met een voor jouw eveneens closed source server communiceerd.
In beide gevallen krijg je als verzender echter een notificatie dat de encryptie-sleutel van je ontvanger gewijzigd is.
Nou, niet dus. Tenzij je dit aanzet, maar > 95% van de gebruikers komt nooit in het instellingen menu, laat staan snapt wat dit soort instellingen doen. Overigens bestaat er niet iets als een encryptie schema waarbij je, ingebakken in het protocol, een notificatie nodig hebt die je erop attendeert dat je bericht mogelijk niet door de bedoelde ontvangen ontvangen is. Dat is gewoon bad design en bad practice. E2ee protocols zouden moeten falen wanneer sleutels niet meer overeen komen, niet blind het bericht opnieuw sturen.

Telegram kreeg een hoop rommel over zich heen omdat 'by default' je gebruik maakt versleutelde chats die gebruik maken van cloud storage, waardoor ze op alle apparaten beschikbaar zijn, in plaats van de secret chats die (net als bij WhatsApp) apparaatgebonden zijn. Echter Telegram heeft deze wél correct geïmplementeerd in de zin dat het veilige kanaal vervalt wanneer een van de twee gesprekspartners zijn of haar sleutel verliest of terugtrekt.

Maar omdat het dit keer om WhatsApp gaat, en mensen het niet leuk vinden als hun favoriete service bekritiseerd wordt, is het ineens prima om onveilige default settings te hebben en met een onveilig protocol te werken.

Het probleem zit hem ook niet in het feit dat er een zwakheid is ontdekt in WhatsApp's protocol, daar is niets mis mee, want zodra zoiets bekend wordt, fix je het. Daar worden we allemaal beter van. Het probleem zit er in dat WhatsApp dit intended behaviour acht, waarmee het bedrijf maar weer eens (voor de zoveelste keer) laat zien dat het niets snapt van security en puur het Signal protocol geïmplementeerd heeft om mee te kunnen doen met de marketing hype.

Signal: Open source, e2ee
Telegram: Open source clients, server-client crypto en e2ee voor wie dat nodig acht
WhatsApp: Closed source, broken e2ee.
Nou, niet dus. Tenzij je dit aanzet, maar > 95% van de gebruikers komt nooit in het instellingen menu, laat staan snapt wat dit soort instellingen doen.

Je mist mijn punt. Als je bang bent dat de NSA achter je aanzit, zet je deze feature uiteraard wél aan.

Dat het gros van de gebruikers - geheel terecht overigens - als gevaar vooral het gebruik van meeluisteren op publieke WiFi ziet (en zelfs dat een klein gevaar is) is waar. Die mensen hebben geheel geen behoefte aan zo'n bericht.

Dat is ook precies de kern van de kritiek op The Gardian. Je moet veiligheid wel zien in context van het gevaar, en je moet ook beseffen dat veiligheid en gebruiksgemak soms conflicterend zijn. En te moeilijk in gebruik zorgt ervoor dat veilige technieken niet gebruikt worden. Denk aan PGP. WhatsApp maakt daarom een uitstekend verdedigbare keuze door een zeer klein theoretisch gevaar toe te staan, voor verbetering van een veelvoorkomend probleem.

Realiteit is dat dit lek niet te exploiteren is zonder medewerking van WhatsApp. Maar als je WhatsApp niet vertrouwt voor die specifieke chats je uberhaupt deze app en diens servers niet moet gebruiken. Het is dus een non-issue.
Daarin ben ik het geheel met je eens, maar let wel op:
Realiteit is dat dit lek niet te exploiteren is zonder medewerking van WhatsApp.
Zelfs als dat waar is*: WhatsApp is een Amerikaans dochterbedrijf van Facebook. Facebook werkt mee met aanvragen van overheden, met name die van de VS maar ook met die in Nederland, dus WhatsApp zal dat zeer waarschijnlijk ook doen. Vooral nu bekend is dat dit een mogelijkheid is.

WhatsApp verkoopt z'n chatprogramma met de belofte dat niemand bij je chats kan, zélfs WhatsApp niet (deze melding zie je bovenaan iedere chat). Nu blijkt, WhatsApp kan er wel bij met een aanval waarvan de gebruiker, potentieel, kan achterhalen dat deze heeft plaatsgevonden wanneer het al te laat is.

*: GSM/SMS-interceptie of medewerking van je telefoonmaatschappij is voldoende, al is zelfs dat niet noodzakelijk wanneer een hacker/ISP/overheid/etc. toegang heeft tot de installaties die het SMS bericht verwerken. SMS schijnt pas versleuteld te worden op het moment van radio-transmissie. Tot die tijd hangt het volledig van de infrastructuur van de telefoonmaatschappij af hoe de SMS eruit ziet. Zeer waarschijnlijk hebben de systemen van de betrokken telefoonmaatschappijen toegang tot de plaintext van de SMS.
Zelfs als dat waar is*: WhatsApp is een Amerikaans dochterbedrijf van Facebook. Facebook werkt mee met aanvragen van overheden, met name die van de VS maar ook met die in Nederland, dus WhatsApp zal dat zeer waarschijnlijk ook doen. Vooral nu bekend is dat dit een mogelijkheid is.

Opvragen heeft geen zin, want deze truc werkt enkel real-time, en enkel bij berichten die nog 'in de lucht' zijn. Oude berichten kunnen niet worden herversleuteld (en zijn bovendien al reeds verwijderd van de server).

Wat dus zou moeten gebeuren is dat een overheid WhatsApp zou moeten vragen een nieuw wire-tap systeem te maken, zoals de FBI probeerde Apple te dwingen aangepaste software te maken. Iets wat WhatsApp zou aanvechten en anders dan sommige mensen schijnen te denken ook juridisch niet kan met een 'gag order'. Zelfs niet onder de mythische en inmiddels reeds grotendeels vervangen Patriot Act.

En het is uberhaupt twijfelachtig dat een overheid dit zou vragen, omdat het zoals gezegd enkel die typisch 1 a 2 'in flight' berichten onderschept, en bovendien de verzender zou alarmeren en dus enkel eenmalig werkt.

Dan moet men wel heel goed gokken op welk moment men die key-exchange doet, want men weet niet welke communicatie diegene is die interessant is.

Nu blijkt, WhatsApp kan er wel bij met een aanval waarvan de gebruiker, potentieel, kan achterhalen dat deze heeft plaatsgevonden wanneer het al te laat is.

Maar zo werkt het dus niet. WhatsApp kan er ook echt niet bij, maar zou in theorie een nieuwe software versie kunnen uitrollen die niet het Signal protocol volgt en jou eenmalig een andere key voorschoteld voor 'in flight' berichten.

Maar momenteel moet je toch al vertrouwen dat WhatsApp's closed source werkt zoals ze aangeven dat het werkt. Dit 'lek' verandert dus niets aan het 'thread model' zoals dat in de security wereld heet.

Merk verder op dat iMessage net zo werkt, maar anders dan WhatsApp geen notificatie heeft, omdat het inherent verschillende publieke keys ondersteund. Je moet dan al een network analyzer gebruiken om te kijken of er een extra key bijgeplaatst is. Toch is er tot nu toe nog geen vraag naar Apple geweest om zo'n backdoor te maken in iMessage. Bij WhatsApp zou het nut kleiner zijn, dus ik acht de kans dat zo'n verzoek komt grenzend aan nul.
Laten we een cryptosysteem niet waterdicht noemen omdat het juridisch gezien niet mogelijk is het te breken. Keer op keer blijkt uit gelekte documenten dat dit wel gebeurd waar technisch gezien mogelijk. En al zullen de omstandigheden echt uitzonderlijk zijn voordat zoiets in werking wordt gezet, de taak van cryptografie is juist om het technisch onmogelijk te maken zodat ook een 'gag order' (of het huidige equivalent) niets uithaalt..

Een realtime aanval (waarbij een partij voor langere tijd controle heeft over de connectiviteit van het apparaat van een van de gesprekspartners) is, zowel voor overheidsinstanties als aanvallers, toch zeker interessant.

[Reactie gewijzigd door Laloeka op 21 januari 2017 03:17]

Facebook werkt mee? Zoals jij het verwoord lijkt het alsof ze dat vrijwillig doen.

Vergeet even niet dat Facebook en anderen daar wettelijk tor verplicht zijn. Dat kan ik geen meewerken noemen, maar dwang.
En het verschil tussen dwang en medewerking is in het resultaat?
Het doet er dusdanig toe dat de schuld niet bij FB ligt, maar bij de Amerikaanse overheid.
"Dat is gewoon bad design en bad practice."

Nee, dat is eigenlijk public-key eigen; waarbij het altijd noodzakelijk is om de authenticiteit te controleren; maw: checken of je wel praat met wie je denkt te praten. Aan enkel de key kan je namelijk niet zonder controle zien met wie je praat. Dat werkt in Signal precies hetzelfde hoor. ;)
Ik kan tegen jou wel zeggen dat ik WhatsappHack ben en je een sleutel sturen, maar hoe weet je zeker dat ik het echt ben? Juist: controle.

Dat je dan een waarschuwing krijgt dat de sleutel wijzigt, is juist mooi omdat je het dan meteen even kan controleren...

Het is volslagen onzin om te stellen dat de E2EE van WhatsApp gebroken is, en geeft aan dat je eigenlijk zélf niet goed weet hoe het werkt en wat het doet... Maar jij weet het vast beter dan alle ondertekenaars van die brief en twee ontwikkelaars van Signal zelf. ;) (Moxie en Frederic)

[Reactie gewijzigd door WhatsappHack op 20 januari 2017 19:12]

Ik merk (ook door voorgaande reactie-threads over dit onderwerp) dat het bij jou nodig is dat ik deze disclaimer toevoeg aan mijn berichten:

Mijn opmerkingen m.b.t. WhatsApp hebben niets met jouw te maken, en zijn vooral geen persoonlijke aanval richting alle fans en gebruikers van WhatsApp. (Ik hoopte dat dat uit m'n vorige bericht al duidelijk was, maar gezien de laatste alinea in je reactie is dat waarschijnlijk niet goed overgekomen. Laten we het vanaf nu inhoudelijk houden, is voor iedereen zo prettig ;) )

Goed. Inhoudelijk:
Nee, dat is eigenlijk public-key eigen; waarbij het altijd noodzakelijk is om de authenticiteit te controleren
Fijn dat we het daarover eens zijn, want dit is exact wat WhatsApp dus fout doet, en waar mijn commentaar "bad design/bad practice" op doelt. WhatsApp stuurt het bericht automatisch opnieuw wanneer het ongelezen was en er een sleutelwijziging heeft plaatsgevonden. Die controle die je op 2 januari hebt uitgevoerd kan stilletjes niets meer waard zijn als WhatsApp zomaar de sleutel kan aanpassen. En alhoewel WhatsApp hier een notificatie over kan weergeven, is de daad dan al gepleegd, informatie is met een andere sleutel potentieel naar een ander apparaat gestuurd. "Oeps".

Normaal wissel je sleutels uit, verifieer je via een ander kanaal dat de sleutels matchen met de persoon waarmee je wenst te communiceren, en verstuur je je bericht. WhatsApp maakt dit volledig onmogelijk voor onverzonden berichten wanneer iemand WhatsApp opnieuw installeert, een nieuwe telefoon aanschaft of wanneer WhatsApp's servers daar zin in hebben.

Dat deel is bad design, en wel degelijk een fout in de implementatie van WhatsApp. Immers, er kan zo (via onderscheppen/afkijken van inlogcodes) informatie die in een vertrouwelijk kanaal verzonden in, naar buiten lekken. Of de aanval op het gebied van de inlogcode onderscheppen erg praktisch is, is een heel ander verhaal. Maar mocht je zelf twee telefoons hebben liggen, kun je de aanval prima reproduceren.

Om nog even te reageren op je name-dropping. Het is vrij frustrerend dat tegenwoordig harde feiten niet meer opwegen tegen het noemen van een paar bekende mensen die het met je eens zijn. Vergeet niet dat dit zakenlui zijn, enorme stakeholders in een bedrijf als Facebook met een product als WhatsApp. Natuurlijk gaan ze het zo onschudlig mogelijk verkopen aan de media, en geef ze eens ongelijk. Met een simpele Tweet kunnen ze enorme twijfel wegnemen bij een groot deel van de consumenten. Echter lost dat niet het probleem op. Er zit weldegelijk een zwakheid in de manier waarop WhatsApp (niet Signal!) het protocol heeft geïmplementeerd. Dat is feit. Of het een realistische aanval is, daarover valt te discussiëren, maar in crypto wil je ook theoretische aanvallen verbannen.

PS. @ moderators, ik hoop dat ingezien kan worden dat dit, ondanks de off-topic disclaimer, toch een inhoudelijke reactie is dat op zoek is naar een nuttige discussie. Dat is wel mijn intentie.

[Reactie gewijzigd door Laloeka op 21 januari 2017 01:10]

Ik merk (ook door voorgaande reactie-threads over dit onderwerp) dat het bij jou nodig is dat ik deze disclaimer toevoeg aan mijn berichten:
Ik voel me totaal niet aangevallen, ook niet persoonlijk - dus je disclaimer is echt niet nodig hoor. :) Mijn excuses als ik je die indruk gaf, of als jij denkt dat ik jou aan het aanvallen ben.
Zoals je zelf ook stelt; ik probeer inhoudelijk te reageren om een discussie te voeren. ;) Ik val je dan ook niet (persoonlijk) aan.
Fijn dat we het daarover eens zijn, want dit is exact wat WhatsApp dus fout doet, en waar mijn commentaar "bad design/bad practice" op doelt. WhatsApp stuurt het bericht automatisch opnieuw wanneer het ongelezen was en er een sleutelwijziging heeft plaatsgevonden. Die controle die je op 2 januari hebt uitgevoerd kan stilletjes niets meer waard zijn als WhatsApp zomaar de sleutel kan aanpassen. En alhoewel WhatsApp hier een notificatie over kan weergeven, is de daad dan al gepleegd, informatie is met een andere sleutel potentieel naar een ander apparaat gestuurd. "Oeps".
Nee, niet als het ongelezen was. Als het niet afgeleverd was. Dat is een groot verschil.
User A stuurt een bericht naar User B. User B is offline. Nu krijgt een hacker het voor elkaar om in te loggen als User B.
Er vindt een re-key plaats, en User A verstuurt het bericht nu met de nieuwe sleutel opnieuw naar "User B" (nu de hacker) en toont een melding dat de sleutels gewijzigd zijn.
Dit is een logische trade-off voor WhatsApp om zorg te dragen dat te allen tijde een bericht wordt afgeleverd, en dus niet loos blijft hangen zonder prompts te accepteren. (Misschien hebben ze daar wat dedain, maar ik denk eigenlijk niet, als ik naar de gemiddelde internet gebruiker kijk, dat het onredelijk is om te stellen dat het merendeel van de gebruikers echt geen flauw benul heeft van wat zo'n prompt inhoudt als ze hem krijgen, en hem OF als heel vervelend ervaren (dat zorgt er mogelijk voor dat ze WA niet meer gebruiken) EN/OF gewoon negeren en blind op "OK" klikken, waardoor die hele prompt waardeloos is. Waarom zou WhatsApp dat risico dan lopen...)

Dat is, met het oog op WhatsApp en de gebruikersaantallen en userbase in generieke termen, dus naar mijn mening geen bad design nog bad practice: maar nogal logisch, en waarschijnlijk zelfs een van de veiligere implementaties. Er is overigens ook geen sprake van "zomaar wijzigen".
In een ideale wereld zou het anders gaan, maar we zitten nou eenmaal niet in een ideale wereld.
Normaal wissel je sleutels uit, verifieer je via een ander kanaal dat de sleutels matchen met de persoon waarmee je wenst te communiceren, en verstuur je je bericht. WhatsApp maakt dit volledig onmogelijk voor onverzonden berichten wanneer iemand WhatsApp opnieuw installeert, een nieuwe telefoon aanschaft of wanneer WhatsApp's servers daar zin in hebben.
Dat zou het veiligste zijn, ja (zolang je keys niet gejat worden, tenminste.)... Maar dat is een situatie die je voor een messenger als WhatsApp niet van de gebruikers kan verwachten. Het klopt ook niet dat de WhatsApp server dat zomaar kan doen.
Dat deel is bad design, en wel degelijk een fout in de implementatie van WhatsApp.
En daar zijn alle security researchers het dus niet mee eens. Wellicht ontstaat hier verwarring:
Ze zijn het ermee eens dat het een kwetsbaarheid is die in theorie misbruikt zou kunnen worden (alleen niet zo makkelijk als jij stelt): maar niemand is het ermee eens dat dit op enige wijze een *fout* is in de implementatie... En dat is een zeer belangrijk nuance verschil. :)

Ik zelf ben het er ook niet mee eens dat het een foute implementatie is, maar ik ben geen gerenomeerde security researcher - dus met die data mag je doen wat je wil. :P
Uiteraard mag jij de mening hebben dat het wél een fout is, maar ik zou dat niet presenteren als een feit; er zijn in ieder geval veel meer mensen die vinden dat het geen fout is, dan zij die denken dat het wel een fout is. WhatsApp had het eigenlijk, gelet op haar omvang en de gebruikers, niet anders kunnen doen... En zelfs met dit "lek" blijft het derhalve een van de veiligste, en meest bereikbare messenger app met E2EE-implementatie, die beschikbaar is op de markt. Enkel Signal is in principe nog net iets veiliger i.v.m. het "block before retransmit" gedeelte - maar is daardoor ook minder toegankelijk voor de massa; en WhatsApp wil juist wél de massa beveiligen zonder gedoe.

Maar daar mogen we het zeker oneens over zijn natuurlijk. :) Can't always agree, eh? :P
Immers, er kan zo (via onderscheppen/afkijken van inlogcodes) informatie die in een vertrouwelijk kanaal verzonden in, naar buiten lekken. Of de aanval op het gebied van de inlogcode onderscheppen erg praktisch is, is een heel ander verhaal. Maar mocht je zelf twee telefoons hebben liggen, kun je de aanval prima reproduceren.
Het klopt, en dat weet iedereen. Het is theoretisch en onder zeer specifieke omstandigheden mogelijk dat er een bericht lekt.
Dat je dit heel makkelijk kan reproduceren met je eigen toestellen: daar ben ik van op de hoogte.
Om nog even te reageren op je name-dropping. Het is vrij frustrerend dat tegenwoordig harde feiten niet meer opwegen tegen het noemen van een paar bekende mensen die het met je eens zijn.
Hm... Mja. Dat ligt er maar aan hoe je bekijkt.
Zo kan ik het namelijk ook: het is vrij frustrerend dat tegenwoordig harde feiten benoemd door gerenomeerde mensen in de cryptografie wereld weg worden geschoven met het argument dat ze bekend zijn en daarom minder geloofwaardig zouden moeten zijn. :P
Die gasten zijn niet beroemd geworden omdat ze maar wat ouwehoeren, maar omdat ze heel erg veel verstand van zaken hebben.

Het zijn trouwens niet alleen de auteurs van die brief die het er niet mee eens zijn dat het een implementatie fout is hoor... Zelfs mega-privacy voorvechter EFF vind dat het helemaal geen fout is in de implementatie; maar dat je het louter als zwak punt kan zien. (https://www.eff.org/deepl...-whatsapp-called-backdoor)

Overigens maakt de EFF daar wel een fout:
Nevertheless, this is certainly a vulnerability of WhatsApp, and they should give users the choice to opt into more restrictive Signal-like defaults.
Dat is dus precies wat ik eerst ook dacht, ik maakte precies dezelfde fout, en al een tijdje terug had voorgesteld aan WhatsApp: maar dat is dus een heel erg slecht idee.
Vergeet niet dat dit zakenlui zijn, enorme stakeholders in een bedrijf als Facebook met een product als WhatsApp.
Dat is gewoon pertinent onwaar, en als je het tegendeel wilt beweren dan zie ik daarvoor graag je bronnen. :) Het is namelijk nogal een bewering!
Voor Moxie en Fredric valt er misschien wat voor te zeggen omdat zij werken aan de Signal implementatie in WhatsApp (doch riskeren ze dan hun goede naam en aanzien, maar dat vergeten we voor het gemak hier even), maar dat kan je van professor Green en mensen als Bruce Schneier echt absoluut niet zeggen.
Echter lost dat niet het probleem op. Er zit weldegelijk een zwakheid in de manier waarop WhatsApp (niet Signal!) het protocol heeft geïmplementeerd. Dat is feit. Of het een realistische aanval is, daarover valt te discussiëren, maar in crypto wil je ook theoretische aanvallen verbannen.
Ah, nu noem je het wel een zwakheid in plaats van foute implementatie. :) Dat is een wereld van verschil, en dat er een zwakte inzit: dat ontkent niemand.
Het probleem is dat deze theoretische aanval niet te verbannen is zonder een grote impact te hebben op de gebruiksvriendelijkheid van WhatsApp, het is een necessary trade-off; een weloverwogen keuze en ook de meest logische en voor de hand liggende optie om encryptie bereikbaar te maken voor de massa. (En met 1 miljard gebruikers, is dat een behoorlijke massa die heel sterk beveiligd is! :o)

Zoals de EFF ook al stelt: WhatsApp was al heel groot (900 miljoen gebruikers destijds) toen zij E2EE implementeerden. Om dan meteen zwaar geschut in te zetten waar het merendeel van de gebruikers A.) Niet om gevraagd heeft B.) Niet eens weet wat het inhoudt C.) Het geen moer kan schelen, is onlogisch.
WhatsApp probeert E2EE zo bereikbaar mogelijk te maken voor haar gebruikers, maar wil niet dat ze opeens worden geconfronteerd met "vervelende prompts" waar ze geen hol van begrijpen.
PS. @ moderators, ik hoop dat ingezien kan worden dat dit, ondanks de off-topic disclaimer, toch een inhoudelijke reactie is dat op zoek is naar een nuttige discussie. Dat is wel mijn intentie.
Ik ben het geheel met je eens dat het een inhoudelijke reactie is, ondanks het feit dat de disclaimer echt nergens voor nodig was. :)
Ik denk overigens, al kan ik dat fout hebben, dat we het in essentie wel eens zijn; maar het niet eens zijn over of deze aanpak van WhatsApp een redelijke trade-off is ten faveure van haar gemiddelde gebruiker.

Daar zit het enige verschil in mening voor zover ik kan bepalen: we zijn het er niet over eens dat het een design fout is.
Ik zou het daar wellicht wel mee eens zijn als we het over een dienst hadden die echt 100% puur en alleen op veiligheid is gericht, maar WhatsApp heeft nog wat andere zaken om rekening mee te houden met oog op gebruikers en het toegankelijk maken van een met E2EE beveiligde messenger dienst; waardoor deze trade-off, die heel erg moeilijk te misbruiken is (daar zijn we het ook over eens zo te lezen), heel erg logisch is en niet als "fout" gezien kan worden. Het helpt mee dat ALS deze aanval succesvol wordt uitgevoerd, de aanvaller ook nog eens 1.) Heel veel mazzel moet hebben überhaupt iets te krijgen en 2.) ALS hij iets krijgt, dan zijn het waarschijnlijk niet meer dan de 1 a 2 laatste berichten in een chat die toevallig nog niet afgeleverd waren en 3.) Ook nog eens veel mazzel moet hebben niet gesnapt te worden wegens ontbrekende berichten en notificaties van gewijzigde sleutels. :)

[Reactie gewijzigd door WhatsappHack op 21 januari 2017 03:21]

Kan je me nou is precies vertellen in kort nederlands hoe die 'security experts' nou weerleggen dat het geen backdoor is? En het ineens een trade-off is geworden.
In korte woorden: omdat het zo is. :P
Okee, flauw. Maar het probleem is wel dat de technische beredenering ervoor redelijk uitgebreid is, het is geavanceerde technologie you see... Toch ga ik m'n best doen om het zo kort mogelijk in jip-en-janneketaal uit te leggen, het is alsnog een paar regels maar ik hoop dat het hierdoor heel makkelijker te begrijpen wordt:

Een backdoor is een functie die specifiek is ingebouwd om doelbewust (op afstand) de beveiligingsmechanismen te omzeilen.
Een Trade-off is het maken van een concessie waardoor de kwaliteit/functionaliteit van Deel A wordt verbeterd, maar dat helaas ten koste gaat van Deel B.

In het geval van WhatsApp is de trade-off als volgt beredeneerd:
Er moet sterke end-to-end encryptie worden geleverd aan de 1 Miljard+ gebruikers, maar dit moet op een manier gebeuren dat het ook toegankelijk is voor die mensen, ze er geen omkijken naar hebben en de betrouwbaarheid van message delivery absoluut niet op het spel komt te staan - want dat is het belangrijkste voor onze gebruikers. (WhatsApp had al voor E2EE 900 miljoen gebruikers, voor gebruikers is een makkelijk te gebruiken snelle en betrouwbare berichtendienst belangrijker dan extreme beveiliging. WhatsApp is foremost een consumer app.)

Om dat voor elkaar te krijgen, moet je hier en daar een trade-off maken om de gebruiksvriendelijkheid te bevorderen ten koste van maximale sterkte van de crypto-functies.
Als WhatsApp het op dusdanige wijze had geïmplementeerd dat het wel het absolute maximale zou geven zonder enige trade-off, dan was het voor een heel erg groot gedeelte van de gebruikers (het grootste gedeelte, zelfs) niet meer werkbaar of veel teveel moeite om te gebruiken; en zou men het niet kunnen gebruiken of niet willen gebruiken omdat ze helemaal geen zin hebben om moeite in hun beveiliging te steken. Dat moest voorkomen worden om die mensen toch te kunnen beschermen, en daarom heeft WhatsApp een balans gemaakt tussen hele sterke encryptie aanbieden - en gebruiksvriendelijkheid en toegankelijkheid hoog te houden; zodat met enkele trade-offs iedereen (zelfs je oma van 100 jaar oud) het kan gebruiken én kan genieten van hele sterke encryptie.

Waar het hier om gaat is zo'n trade-off, en daarom is het geen backdoor.
Er is nog een tweede punt waarom het geen backdoor is:
Als gebruiker heb je de beveiligingsnotificatie functie waardoor je het meteen kan opmerken als sleutels wijzigen. Enkel de client weet of die functie aan of uit staat, de server weet dat niet en kan dus nooit weten of iemand deze uit heeft gezet of aan - zonder deze informatie kan de server nooit weten of het transparant een MitM kan uitvoeren, dus überhaupt ongeschikt als backdoor.
Overigens is het dan wel de bedoeling dat je netjes, zoals WhatsApp aanraadt, de (nieuwe) sleutels vergelijkt met je chatpartner. ;)

Daar komt nog eens bij dat de situatie waarin je deze kleine "vulnerability by trade-off" kan misbruiken verschrikkelijk specifiek en heel erg moeilijk is: en zelfs ALS je hem succesvol weet uit te voeren, dat je dan mazzel moet hebben dat er berichten in de que staan omdat je anders helemaal niets krijgt; en je ook nooit méér informatie kan krijgen dan de bericht(en) die in de queue staan; als dat enkel een bericht is met "Hoi, hoe is het met je?": dan is dat het enige dat je hebt weten te achterhalen; dat is de tijd, moeite en geld om deze aanval te proberen niet waard. ALS dit een backdoor zou zijn, dan zou het dus zo verrekte waardeloos en risicovol zijn met een gigantisch hoog risico gepakt te worden, dat het derhalve zeer redelijk is om deze trade-off te maken; en er geen waardevolle negatieve impact is geleverd op de security. ;)

En last but not least heeft WhatsApp ook een 2TA-functie (die is al even in ontwikkeling, en zit al een paar maanden voor iedereen in de beta van Android en iOS.), en als je die inschakelt: dan is deze mini-kwetsbaarheid al helemaal niet meer te misbruiken omdat je dan eerst een code moet invoeren die een brute-force beveiliging heeft voordat je kan inloggen, een backup kan herstellen en kan re-keyen. Weet je de code niet? Dan kan je alsnog inloggen, maar kan er geen retransmission opgevraagd worden en gaan eventuele berichten in de que verloren: en krijg je dus een blanco WhatsApp account. (Je wordt ook direct uit alle groepen gezet.) Een aanvaller kan dan dus wel inloggen, maar krijgt nooit retransmitted berichten. Zo'n functie bouw je niet in als het een backdoor is, want dan sluit je effectief je eigen backdoor af. :') Dat zou niet snugger zijn.

Dat zijn dus al 3 punten, en daar hou ik het nu even bij voordat het een veel te lange post wordt (er is nog meer namelijk :P):
Dat alles bij elkaar opgeteld, maakt het dus dat die security experts (en dat hoef je niet tussen aanhalingstekens te zetten hoor, de namen die genoemd zijn en de brief ondertekend hebben zijn al vele jaren zeer prominente gezichten in de cryptografie, hebben vele onderzoeken op hun naam staan en sommige hebben doorbraken geleverd in het realiseren van nieuwe zeer sterke cryptografische functies) dit niet zien als een backdoor, omdat het gewoon absoluut geen backdoor is en op geen enkele wijze voldoet aan de criteria "backdoor".

Het is een theoretische kwetsbaarheid voortkomend uit een trade-off, die ook nog eens een extreem kleine impact heeft ALS iemand het weet te misbruiken (en de gebruiker heeft 2TA niet ingeschakeld): en de kans dat iemand dat lukt is ook nog eens heel erg klein: meer niet.


Ik hoop dat ik het zo, ondanks dat het niet heel kort was (het is te technisch daarvoor, sorry...) toch aan je heb kunnen duidelijk maken waarom er gesproken wordt van een trade-off in plaats van een backdoor. :)
Overigens als je WhastApp niet vertrouwd, zou ik de software ook niet gebruiken. Hetzelfde geldt voor Signal waar je ook een voor jou closed source app download die met een voor jouw eveneens closed source server communiceerd.
Signal is open source, src code staat gewoon op Github.

Er is momenteel overigens geen volledig open source alternatief voor je os en bepaalde essentiële apps (contacten bv.) in de smartphone wereld.

OT: zeer zwakke journalistiek van The Guardian. Het ergste van al vind ik nog dat ze gewoon de moeite niet gedaan hebben om Openwhsipersystems te contacteren alvorens dit te publiceren. Je schrijft een stuk over een softwareprotocol en laat het na de makers hiervan hun mening te vragen. Dat is simpelweg amateuristisch.

[Reactie gewijzigd door bertp1 op 20 januari 2017 19:11]

Signal is open source, src code staat gewoon op Github.

Je download echter een closed source binary van de App or Play Store. En deze communiceert met een server waarvan jij niet weet of die gemaakt is van de software.

Je moet dus de makers van Signal vertrouwen. Niet anders dan dat je de makers van WhatsApp moet vertrouwen.
Je kunt het zelf compileren en sideloaden als je wilt. Zelfs op een iPhone
Technisch gezien weet je niet zeker wat de bron is van het programma dat je downloadt, en dus ook niet of die openbaar is. Maar ik begrijp je punt: de code die je downloadt is voor jou niet inzichtelijk en kan dus van alles bevatten. Tenzij je die zelf compileert van een openbare bron, wat denk ik niet kan als je van push gebruik wilt maken in Android.

[Reactie gewijzigd door Cerberus_tm op 20 januari 2017 21:58]

Open source.. Niemand leest die code.

Ik vind changes reviewen van ~1000 regels code op producten waar ik zelf aan werk al lastig, laat staan dat ik even een ander project in zijn totaliteit op backdoors ga checken.
Enerzijds heb je gelijk dat de zo goed als niemand ooit die code zal bekijken, anderzijds KAN je die code wel nakijken. Je kan, zonder de hele code na te kijken & te analyseren al een hele hoop vinden, bv wat er via TCP/IP sockets verstuurd wordt. Je kan zelf de code compileren en draaien op je gsm, of controleren dat de apk in de Play Store overeenkomt met gecompileerde source code. Dat gegeven dat iedereen die mogelijkheden heeft is op zich al een enorme waarborg.

Dat is net hetzelfde argument als bij Whatsapp nu. Whatsapp zou perfect een foute public key kunnen doorgeven, meeste gebruikers zullen dat nooit controleren en Whatsapp kan al die communicatie doorgeven. Maar het feit dat iedereen dat kan controleren is een enorme waarborg, als 1 iemand er ooit achter komt dat een bedrijf als Whatsapp zijn/haar public key heeft vervangen is dat een énorme klap voor die dienst.

Vergelijk het met government surveillance. Het grootste wapen daarvan is niet dat mensen weten dat ze gecontroleerd worden of niet, het grootste wapen is juist dat burgers niet weten of ze al dan niet gecontroleerd worden. Dat werkt in alle richtingen zo.

Kortom je hebt inderdaad geen 100% zekerheid, maar met open source code heb je al veel meer zekerheid dan closed-source, waar je maar moet vertrouwen op de schoon ogen van de uitgevers (en beperkte controle over toegang voor een applicatie en wat je kan uitlezen met een programma als Wireshark, maar al die datagrabber apps versleutelen tegenwoordig toch al hun data).

Alleen al om die reden zou een website als Tweakers (elke zichzelf respecterende reviewer eigenlijk) bij softwarereviews standaard een pak "punten" moeten aftrekken voor closed source software.

Het is niet voor niets dat organisaties als het EFF pertinent aanraden van open source software te gebruiken, en dat privacy-inbreuken in opensource software minder voorkomen.

Tenslotte, voor het specifieke geval van Signal; daar is gewoon een audit van de source code (van het protocol) geweest, dus daar heb je wel degelijk een grote mate van controle door onafhankelijke partijen.
Het is niet voor niets dat organisaties als het EFF pertinent aanraden van open source software te gebruiken, en dat privacy-inbreuken in opensource software minder voorkomen.
De vraag is alleen: maken er ook evenveel mensen gebruik van opensource software als van closed-source software?

Stel je hebt bij opensource 1000 inbreuken op privacy.
Bij closed source heb je 100.000 inbreuken op privacy.

Het opensource pakket wordt gebruikt door 1 miljoen mensen.
Het closed source pakket wordt gebruikt door 500 miljoen mensen.
Naar rato zou je dan zelfs kunnen zeggen "Bij opensource gebeurde dit in 0.1% van de gevallen, bij closed source in 0.02% van de gevallen - ergo: closed source is veiliger".

Natuurlijk is dat absoluut geen conclusie die je er zomaar aan kan verbinden, maar het is wel een belangrijk vraagstuk. Een tweede vraagstuk is dan ook: in hoeverre was het voor de aanvaller lucratiever om closed source aan te vallen dan opensource, omdat er meer data te halen valt? En is daarom de opensource app misschien genegeerd/niet aangevallen vanwege een verhoogd risico? (Wel het risico lopen, maar er maar weinig voor terugkrijgen.)

Dat zijn allemaal zaken die uitgebreid onderzocht moeten worden voordat je echt conclusies kan gaan verbinden, maar dat is heel verrekte moeilijk.
Er zijn een paar onderzoeken geweest die geprobeerd hebben de veiligheid van opensource met closedsource te vergelijken, en de conclusie is eigenlijk steeds "undetermined" - ze lijken naar rato even veilig te zijn, mede dankzij code-audits die de CS partijen laten uitvoeren.

Ik gebruik zelf ook liever opensource, maar ik ga er niet vanuit dat het op enige wijze per se veiliger is dan een closed source variant die ge-audit is.
Daarnaast is het inderdaad nog maar de vraag voor hoeveel mensen het boeit... Immers, je kan wel opensource software gebruiken: maar als je de variabelen die je nodig hebt om er zeker van te zijn dat je gebruikt wat je denkt te gebruiken niet toepast (zoals het merendeel van de mensen dat FOSS gebruikt :P): wat biedt het dan voor meerwaarde?
Als je zelf de kennis niet hebt, is de situatie namelijk:
In het geval van closed source moet je vertrouwen op de ontwikkelaars en de bedrijven/mensen die de audit uitvoeren.
Bij open source moet je vertrouwen op de ontwikkelaars en de bedrijven/mensen die de audit uitvoeren.

Dat verschilt niet veel. Vandaar dat ik me soms ook afvraag wat het nut is om mensen te adviseren opensource te gebruiken, als zij de implicaties niet weten noch de kennis in huis hebben om de stappen te nemen die opensource in theorie meer potentie op veiligheid geven van closed source.
Dan heeft het eigenlijk weinig toegevoegde waarde, en soms denk ik zelfs dat het gevaarlijk kan zijn: sommige mensen hebben "opensource" nu synoniem gesteld met "veilig". Dat is een verrekte gevaarlijke aanname.

Don't get me wrong, ik ben voorstander van opensource en het heeft ook mijn voorkeur; alleen de discussies over FOSS vs Proprietary zijn naar mijn mening vaak veel te ongenuanceerd en er wordt te weinig rekening gehouden met de grootste zwakke schakel: de gebruikers en hun kennisniveau.

[Reactie gewijzigd door WhatsappHack op 21 januari 2017 00:46]

Volgens mij draait 95% van allle servers op internet op Linux, 80% van alle mobieltjes op Android, dus ja Open Source wordt best vaak gebruikt 😬.
En de meeste audits zijn een wassen neus, dus ik heb meer vertrouwen in Open Source software dat door iedereen die het wil gecontroleerd kan worden.
Ik heb het hier al vaker gezegd, als WA echt openheid en vertrouwen wil winnen moeten ze de boel OpenSource maken. En als ze toch niks te verbergen hebben moet dat geen probleem zijn. De gebruikers hebben ze al. Of zouden ze niet durven omdat ze toch stiekum 'foute' dingen doen?
Ik weet dat opensource veel wordt gebruikt, ik gebruik het zelf ook op servers en we ontwikkelen hier zelf opensource software die door miljoenen mensen over de wereld gebruikt wordt - dus dat snap ik wel. Ik heb dan ook niet gezegd dat opensource impopulair is. ;) Ik heb enkel gezegd dat je er niet vanuit mag gaan dat het per definitie veiliger is dan closed source of überhaupt per definitie veilig is.

Android opensource noemen is ook nogal een overstatement. :P
De meeste mobieltjes die met Android erop over de toonbank gaan, zijn modellen van Samsung, LG, HTC, Sony, Huawei, et cetera.
Stuk voor stuk toestellen die zijn voorzien van proprietary *CLOSED SOURCE* software van de fabrikant, en daarnaast allemaal voorzien zijn van closed-source GAPPS en frameworks.
Dat kan je nauwelijks nog opensource noemen gezien alle belangrijke en kritische data over CS apps gaan.

Dat Android opensource beschikbaar is in, als we het vergelijken, een stripped down version van want je in de winkel koopt, maakt het nog niet dat Android op de telefoons daadwerkelijk ook nog maar iets weg heeft van opensource; op een paar libraries na.
En de meeste audits zijn een wassen neus, dus ik heb meer vertrouwen in Open Source software dat door iedereen die het wil gecontroleerd kan worden.
De meeste audits zijn geen wassen neus, dat is onzin.
Ten tweede: dat iedereen het kan controleren, wil nog niet zeggen DAT iedereen het controleert; nog geeft het op ook maar enkele wijze een garantie dat de broncode veilig is.
Als je van wel denkt, dan zou ik je aanraden eens een kijkje te nemen naar HeartBleed, Shellshock, POODLE, et cetera.
Ik heb het hier al vaker gezegd, als WA echt openheid en vertrouwen wil winnen moeten ze de boel OpenSource maken. En als ze toch niks te verbergen hebben moet dat geen probleem zijn. De gebruikers hebben ze al. Of zouden ze niet durven omdat ze toch stiekum 'foute' dingen doen?
Leuk, zo'n suggestie vraag aan het einde. ;)
Er is totaal geen reden voor WhatsApp om de source te publiceren, het enige wat ze ermee doen is anderen de kans geven om hun werk te gebruiken. En dat willen ze niet.
De mensen, auditors, beveiligingsonderzoekers, overheden en privacy voorvechters (m.u.v. het delen van tel. nummers met Facebook) vertrouwen WhatsApp volkomen.
Er zijn al zoveel messengers in omloop, dus dat 'hun werk' gaan gebruiken gaat echt niet op. Zo bijzonder is WA nu ook weer niet. Ik geef alleen aan dat als ze echt 100% openheid willen geven ze alles Open Source kunnen maken. Want de gebruikers hebben ze al, en hebben dus niks te verliezen. Maar ja, wie weet is er toch ....
Ze willen geen 100% openheid geven. En waarom zouden ze ook? CS werkt prima voor WhatsApp, en zo is het heel moeilijk er vandoor te gaan met bepaalde technieken die WhatsApp aan boord heeft. Je arument dat er zoveel messengers zijn gaan niet op; er zijn er veel maar hebben allemaal net iets andere functies en optimalisaties. Vergelijk het met auto's: ze brengen je allemaal van punt A naar B, als het goed is :P, maar er zit een groot verschil in de auto's in termen van motortechnologie (verbruik/uitstoot), paardenkracht, design, comfort, ophanging en veiligheid; en no way dat al die fabrikanten alles met elkaar delen.

In elke business zijn bedrijfsgeheimen op proprietary ontwikkelingen normaal, zelfs in je favo restaurant kan de kok een geheim recept hebben. ;) Maar bij een softwarebedrijf zou dat opeens raar/verdacht/gevaarlijk zijn, en moeten ze wel een vreselijke backdoor verbergen? Dat is immers wat je nu al voor de tweede keer probeert te suggeren. ;)

Het is geen kwestie van durven of geen openheid over het functioneren willen geven, maar gewoon de technologie zo goed mogelijk beschermen. WhatsApp zit niet in deze business om hun producten en ontwikkelingen gratis weg te geven, hoe graag je dat uit een idealistisch oogpunt ook zou willen zien.

Dus nee, dat de bron gesloten is zegt helemaal niets over de intenties van WhatsApp, noch is het op enige wijze een aanwijzing dat ze iets ernstigs te verbergen hebben. Bij security onderzoekers, audits en (aldanniet illegaal opererende) third-parties die de boel proberen te reverse engineeren, is nooit iets gevonden dat wijst op de aanwezigheid van een backdoor of het zelfs maar suggereert.

[Reactie gewijzigd door WhatsappHack op 23 januari 2017 02:53]

Alleen al om die reden zou een website als Tweakers (elke zichzelf respecterende reviewer eigenlijk) bij softwarereviews standaard een pak "punten" moeten aftrekken voor closed source software.
Onzin. Alsof closed source per definitie verdacht is. Of spreek je uit je eigen werkervaring als softwareontwikkelaar van closed source SW?
En doordat het open source is, kunnen kwaadwillende redelijk makkelijk een backdoor inbouwen. De kans dat die gevonden wordt is minimaal. Bij closed source kan je als bedrijf domweg zeggen dat er geen backdoors worden ingebouwd. Punt. Als kwaadwillende daar wat in willen bouwen moeten ze infiltreren in een organisatie. En dat is een stuk lastiger dan OSS aanpassen.
Dat zijn dan ook projecten van beveiligings onderzoekers. Matthew Green en zijn studenten doen dat bv. Die publiceren regelmatig kwetsbaarheden. Je zult als samenleving tot een bepaalde hoogte elkaar moeten vertrouwen. Zonder dat vertrouwen stort de hele samenleving in elkaar.
Op de site van Signal hebben de makers daarvan zich ook reeds kritisch uitgelaten over dit artikel m.b.t. deze "backdoor".

There is no WhatsApp 'backdoor'
Wat op zich ook weer een rare titel is. Ten eerste bestaat de backdoor in kwestie wel degelijk, alleen is deze nauwelijks bruikbaar in de praktijk. Ten tweede kunnen er ander backdoors bestaan waar op dit moment nog niemand weet van heeft.
Ten eerste bestaat de backdoor in kwestie wel degelijk, alleen is deze nauwelijks bruikbaar in de praktijk.
Dat is waar de kritiek voornamelijk om gaat, eigenlijk.
Het voldoet totaal niet aan de definitie van een backdoor, en al helemaal geen een die je in staat stelt om een heel gesprek mee te lezen.

Het is dus geen backdoor, maar eerder een zwak punt in een deel van de implementatie waardoor je in theorie onder zeer specifieke situaties en met veel mazzel en "ik hoop dat..." condities je misschien een berichtje zou kunnen onderscheppen dat toevallig nog in de que staat ALS je als de ontvanger kan inloggen, de verzender wél online is en het bericht nog heeft staan.

[Reactie gewijzigd door WhatsappHack op 21 januari 2017 00:36]

Het is dus geen backdoor, maar eerder een zwak punt in een deel van de implementatie waardoor je in theorie onder zeer specifieke situaties en met veel mazzel en "ik hoop dat..." condities je misschien een berichtje zou kunnen onderscheppen dat toevallig nog in de que staat ALS je als de ontvanger kan inloggen, de verzender wél online is en het bericht nog heeft staan.
Klinkt als een pijplijn van honderden if else statements. Zelfs de nesting van Javascript kan daar nog wat van leren ;)
Dat valt erg mee. Ik krijg ontzettend veel meldingen over gewijzigde codes zonder wijzing van telefoon bijvoorbeeld. Zo vaak zelfs dat ik het uit heb gezet. Het is alleen maar irritant en voegt voor mijn veiligheid (gespreken die niet openbaar mogen worden vinden dan ook niet plaats op whatsapp) niet van extra toegevoegde waarde.
Dat komt omdat anderen dan WhatsApp bijvoorbeeld opnieuw installeren (of inderdaad een nieuwe telefoon hebben). Als je WhatsApp namelijk verwijdert, worden de private keys ook verwijdert van je toestel.
En dat is dus precies wat ik bedoel aangezien dat namelijk niet altijd het geval is. Zo heb ik contacten waarbij dat iedere week wel een keer gebeurt en dat zou dus met bovenstaand issue te maken kunnen hebben.

Geen idee, maar heb het wel uitgezet, omdat de melding voor mij geen toegevoegde waarde heeft. Gesprekken waarvan de inhoud belangrijk is voor mijn persoonlijke levenssfeer gaan gewoon niet over whatsapp of een soortgelijk iets. Gewoon F2F.
En dat is dus precies wat ik bedoel aangezien dat namelijk niet altijd het geval is. Zo heb ik contacten waarbij dat iedere week wel een keer gebeurt en dat zou dus met bovenstaand issue te maken kunnen hebben.
Dan raakt er waarschijnlijk iets corrupt op hun toestellen.
Komen jullie berichten wel bij elkaar aan? Dan is er sowieso al geen sprake van het bovenstaande, want door dit te exploiten zou het bericht niet meer aan kunnen komen bij de originele ontvanger - WhatsApp client is namelijk zo gebouwd dat een bericht dat eenmaal afgeleverd is (of dat nou bij de bestemming is of bij een aanvaller ;)) nooit nogmaals retransmit kan worden.
Zouden ze dat wel toestaan, dan zou je een replay kunnen uitvoeren en zo een compleet gesprek tot jaren terug kunnen opvragen uit het toestel - dat is natuurlijk niet wenselijk, dus doet de client het niet.

Maar, stel het heeft er misschien wel mee te maken... Ken je die mensen toevallig persoonlijk? Als het dan weer gebeurt: pak dan direct je key-verificatie functie erbij, bel ze op en vraag om sleutels te vergelijken.
Komen die overeen? Dan is er iets mis op hun toestel waardoor die key steeds reset. (Of ze herinstalleren WhatsApp wekelijks...)

Ik heb dit trouwens ook twee keer meegemaakt, en ik werd er knettergek van. Uiteindelijk eens gevraagd wat die gasten in godsnaam aan het doen waren..
Bij de eerste bleek uiteindelijk dat die persoon een Dual-SIM had, en steeds tussen WhatsApp accounts aan het wisselen was. :P Elke keer als hij wisselde, kreeg ik een key-notification change omdat hij opnieuw inlogde op WhatsApp.
Bij de tweede bleek dat hij elke dag na werk tussen privé en zakelijke telefoon wisselde; maar wel dezelfde SIM gebruikte. :+ (Vraag mij alsjeblieft niet waarom.)
Weet je zeker dat je niet grootschalig wordt afgeluisterd dan middels deze spoof techniek? ;) Ik heb zelf nog nooit zo'n melding gezien...
Staan ze wel aan?
Instellingen -> Account -> Beveiliging -> Toon beveiligingsmeldingen.
(Op iOS tenminste, op Android kan het mogelijk ietsjes anders zijn.)
Ik mag aannemen dat de NSA wel wat beters te doen heeft dan mij voor de geke proberen te houden voor een paar nietszeggende berichten die van dusdanig laag niveau zijn dat ik ze zelf vaak negeer.
NSA neemt WhatsApp servers over of "verzoekt" gegevens voor middleman-attack.

Vervolgens communiceer je met de NSA, en de NSA met je bedoelde contact. Merk je verder niks van.


Het tegenhouden van (geselecteerd) Internetverkeer is ook een NSA mogelijkheid, en leidt meen ik tot meer mogelijke exploits.

Maar je zegt het zelf eigenlijk al: deze crypto is veilig voor iedereen behalve WhatsApp zelf, en dus de NSA. Goed bedacht, klinkt dat.
NSA neemt WhatsApp servers over of "verzoekt" gegevens voor middleman-attack.
En dan?
WhatsApp heeft geen gegevens over wie je transparant slachtoffer kan maken van een MitM; dus kan helemaal niet meewerken met de NSA op dat vlak. :X

Daarnaast, om de eavesdropping trade-off vulnerability te misbruiken heeft de NSA WhatsApp niet nodig; immers kan de NSA gewoon tegen een telefonie provider zeggen "Yo, geef mij toegang tot +1123456789 zodat ik de SMS-verificatie van WhatsApp kan ontvangen" - en voila, ze zijn ingelogd ALS de gebruiker tenminste geen 2-TA ingeschakeld heeft staan ("Verificatie in twee stappen"); dat is ook nog een risico. :')
Het enige hele grote probleem dat de NSA dan nog heeft is dat het:
1.) Er een heel groot risico is gepakt te worden als ze deze aanval uitvoeren, vanwege de key-change notifications en key-verification opties.
2.) Het geld kost om de aanval uit te voeren
3.) Het uitvoeren van de aanval geen enkele garantie geeft dat je ook maar enige data weet te achterhalen, of ALS je data achterhaalt: dat die ook maar op enige wijze nuttige informatie oplevert of een gesprek is met de persoon waarvan je hoopt dat ze op dat moment praten.
Zodra de gebruiker weer inlogt als zichzelf, wijzigen de sleutels en kan de NSA de rest van het gesprek niet zien - en dus echt extreem veel mazzel moeten hebben willen ze ooit nuttige informatie verkrijgen EN niet gepakt te worden.
Vervolgens communiceer je met de NSA, en de NSA met je bedoelde contact. Merk je verder niks van.
Wel als je zoals WhatsApp duidelijk uitlegt als je de handleiding leest (die ze je bij elk gesprek aanbieden door op de notificatie van E2EE te tikken die *altijd* als eerste verschijnt.) de sleutels met je chatpartner(s) vergelijkt en de aanbeveling opvolgt om key-change notificaties in te schakelen.

Doe je dat allebei niet? Ja, dan is een MitM zonder op te vallen mogelijk ja - maar dat is standaard mogelijk bij PK-based encryptie. Als je als gebruiker niet even 10 seconden de tijd neemt om die sleutels te controleren, dan moet je niet gaan zeiken tegen WhatsApp als blijkt dat de NSA (of welke aanvaller/hacker dan ook!) het account van je buddy heeft overgenomen en je daar de hele tijd mee aan het praten was...
Het tegenhouden van (geselecteerd) Internetverkeer is ook een NSA mogelijkheid, en leidt meen ik tot meer mogelijke exploits.
Niet in deze context.

Zoals Armin al zegt: dit is voor de NSA absoluut geen bruikbaar middel.
In principe kan de NSA natuurlijk gewoon ongemerkt je Android toestel in, links of rechtsom. Het idee dat dit de beste hack is is dus interdaad onzinnig.

Het is wel gewoon weer een mogelijkheid extra. En een MitM is dus niet onrealistisch, ook niet voor mindere agencies dan de NSA, en wel degelijk erg risicovol.

Bijvoorbeeld: Een (minder technisch) persoon in de groep krijgt een nieuwe mobiel. Diens "nieuwe code" bericht wordt onderschept, en de codeverandering wordt geactiveerd. De rest ontvangt 1x een codewissel en verwacht dat ook. De persoon zelf krijgt misschien 2 berichten - geen schijnbare reden tot paniek. Vervolgens wordt de hele groep afgeluisterd. Misschien kan bij het toevoegen van een nieuwe persoon wel direct z'n sleutel verandert worden - dan valt het echt niet op.

De code checken lijkt me een zeldzame activiteit, zeker omdat whatsapp je op geen manier vertelt dat te doen. "eigen schuld dikke bult" Heb je al, Whatsapp is closed source auto-update van Facebook!
Als Facebook/Whatsapp iets in had gebouwd voor de NSA dan was dat wel makkelijker te gebruiken en dan zou dat meer/alle berichten hebben doorgestuurd.
Als je belangrijke dingen over WhatsApp gooit, ben je denk ik ook op andere manieren en makkelijke prooi voor zulke diensten.
Even denken hoor: Gerespecteerde onderzoekers als Bruce Schneier en Matthew Green zeggen A, @dragonlords1 zegt B.

Ik ga toch voor antwoord A. Vooral omdat ze een goed gefundeerd verhaal hebben met aantoonbare credentials.

Leuk dat je later die slides aanhaalt, maar daarin staat alleen dát en wannéér de NSA data is gaan verzamelen van bepaalde diensten. Niets over backdoors. In 2010 hebben wij ook een data collector geschreven voor publieke tweets en FB berichten voor geautomatiseerd marktonderzoek. Zo moeilijk is dat allemaal niet.
Ik kan me inderdaad vergissen.
Ik zal "Collection directly from the servers of these U.S. service providers" op slide 3 verkeerd geïnterpreteerd hebben.
Die is sowieso lastig te interpeteren, omdat het document zeer vaag is over wie wat aanlevert. Daarom ook "varies by provider", waar zelfs handmatige verzoeken nog tussenstaan. 8)7 Het is niet ondenkbaar als sommige bedrijven enkel aan dat laatste hebben meegewerkt, wat grotendeels een wettelijke verplichting is. Zeker niet omdat volgens de Washigton Post, die als een van de eersten de documenten kregen van snowden, dit meldde:
The speaker's notes in the briefing document reviewed by The Washington Post indicated that "98 percent of PRISM production is based on Yahoo, Google, and Microsoft".
98% van de data komt van Yahoo, Google en Microsoft; dan blijft er, van de in dat document genoemde diensten, slechts 2% over die verdeeld wordt tussen Facebook, Apple, Paltalk en AOL. (Gemiddeld 0.5% per dienst dus van alle data.)
Facebook en Apple hebben sowieso ontkend meegedaan te hebben met direct access, dus het kan best dat die enkel hebben meegewerkt aan "Special Requests" zoals op pagina 5 beschreven staat; en dus inderdaad geen onderdeel waren van het PRISM programma an sich; eerder "by proxy" door bepaalde verzoeken (verplicht) te behandelen.

Of dat ook zo is, dat is een heel ander verhaal en tot op de dag van vandaag onbekend wegens informatiegebrek. Maar gezien die 98 vs 2% is het niet ondenkbaar dat ze de waarheid vertelden en inderdaad nooit toegang tot hun servers hebben verschaft, enkel data op verzoek overhandigd hebben.

Time will tell, het komt ooit echt nog wel een keer boven tafel. Waar we nu op Discovery "secret prisons" hebben over WW2 en de Koude Oorlog, hebben we dat over 50 jaar misschien over secret operations op 't web. :P
Het probleem zit hem niet in de encryptie maar in de BACKUP die whatsapp maakt van de gesprekken bij google.
Voor de expers ga eens spelen met deze tools!
https://github.com/EliteAndroidApps
En kom er achter dat de media ongecrypt word opgeslagen fotos etc...
maar de chats in het zogeheten crypt12 format worden opgeslagen...
de sleutel aanmaak is alles BEHALVE random dat is het enige wat ik daar over wil zeggen.
De backdoor zet hem dus in de backup , iets waar Signap private messenger geen last vam heeft!
En FYI de melding voor sleutel verandering van gebruiker staat bij whatsapp standaard UIT!
Nee, ook dat klopt niet. De back-ups van WhatsApp naar Google Drive blijken wél encrypted te zijn. Zie hier: AnonymousWP in 'nieuws: 'WhatsApp laat kwetsbaarheid al bijna jaar ongewijzigd''
Nee, ook dat klopt niet. De back-ups van WhatsApp naar Google Drive blijken wél encrypted te zijn. Zie hier: AnonymousWP in 'nieuws: 'WhatsApp laat kwetsbaarheid al bijna jaar ongewijzigd''
De sleutels bevinden zich IN de encrypted .crypt12 file!
https://github.com/EliteAndroidApps
lees dit draadje maar eens
http://www.digitalinterna...12-database-messages/559/
De sleutel bestaat uit het emei , het telefoon nummer en het password , wat je zelf hebt gekozen , maar de manier dat dat is gedaan is dom..
namelijk de sleutel heeft 256 bit maar bijvoorbeeld bit 1-128 is beaseerd op imei bit 129-230 is gebaseerd op telefoon nummer , en de laaste 26 bits is het geheime password!
MAW die sleutel is zeer makkelijk te brute forcen!
je kan alle tools vinden in die githup ga er maar eens mee spelen :) leuk als je griep hebt en je toch binnen moet blijven :P
Als ik het zo lees, gaat dat om *lokale* back-ups. Daarvan is het redelijk logisch dat het toestel de keys opslaat.

Als je goed kijkt, zie je dat bij het script voor de GD-extractor, dat WhatsApp geinstalleerd moet zijn, ingelogd moet zijn én Google Drive reeds geactiveerd moet hebben.
Dat is een expliciete prerequisite.
Er staat geen methode die laat zien hoe je de backup vanuit Google Drive kan downloaden en die vervolgens kan decrypten zonder te authenticeren om de keys op te halen. (Er staat ook niet of GD hetzelfde type keying gebruikt.)

De vraag is dan ook: is dat verhaal ook toepasbaar op iets anders dan lokale back-ups?
Kan je dat artikel en die scripts op GitHub wel gebruiken om een Google Drive backup te extracten *zonder* de keys binnen te halen?

Dus stel he: Ik login op jou Google Drive.
Ik download de WhatsApp backup naar mijn computer/telefoon. Ik kan niet als jou inloggen op WhatsApp, ik weet je nummer namelijk niet en heb er ook geen toegang toe om de verificatie binnen te harken.
... Kan ik die scripts nu wel gebruiken? :P Ik heb immers de keys niet...

Naar het back-up gedeelte heb ik nooit veel onderzoek gedaan, dus ben eigenlijk wel benieuwd. Ik ga er zelf ook eens naar kijken, best geïnteresseerd nu :) - maar ben wel benieuwd wat jou ervaringen zijn op dit vlak en met deze methode. :) (Dus NIET het decrypten van je eigen lokale backup/een GD backup die je hebt gedownload **via WhatsApp**; maar een backup van een ander toestel dat jij wilt gaan openen op een ander toestel *zonder* eerst in te loggen naar dat WhatsApp account.)

Tot zover zie ik scripts die het mogelijk maken om een backup te decrypten als je toegang hebt tot zowel Google Drive als het WhatsApp account - maar staan er geen methodes beschreven om een backup te decrypten als je enkel toegang hebt tot Google Drive of enkel toegang hebt tot het WhatsApp account (zonder de backup/keyfiles); het gaat er steeds om dat je toegang tot beiden hebt, toegang die normaliter alleen jij hebt.

[Reactie gewijzigd door WhatsappHack op 21 januari 2017 01:22]

Tot zover zie ik scripts die het mogelijk maken om een backup te decrypten als je toegang hebt tot zowel Google Drive als het WhatsApp account - maar staan er geen methodes beschreven om een backup te decrypten als je enkel toegang hebt tot Google Drive of enkel toegang hebt tot het WhatsApp account (zonder de backup/keyfiles); het gaat er steeds om dat je toegang tot beiden hebt, toegang die normaliter alleen jij hebt.
Dat heb ik getest das niet nodig gebleken.
ik had google drive nooit gebruikt.
Je kan aleen met naam en password van je account naar binnen en de .crypt12 file ophalen.
met https://github.com/EliteAndroidApps/WhatsApp-Key-Generator kun je als je het mobiel nummer en het emei van de persoon weet , de key her contrueren!
het password is immers maar een klein deel van de key.
verder is dit informatie die bij de diensten standaard in xkey-score is op te vragen , IMEI ,IMSI , mobiel nummer allemaal zonder problemen te vinden en te koppelen.
Als je de key dus kun hercontrearen het je de KEY file van je telefoon dus niet nodig! :)
P.S als je delen van je sleutel mist is het leuk als je nog een paar oude video kaarten heb liggen die je ooit hebt gebruikt voor het minen van cryptocurrency zoals litecoin , als je dat servertje met 8 kaartjes uit het stof haalt kun je redelijk snel het missende deel van de key bruteforcen :)...
Hoe je dat doet zoeken jullie zelf maar uit jullie zijn immers tweakers toch?
Als je wil weten hoe een dienst jouw whatsapp overneemt kijk daqn eens naar dit filmpje met deze ss7 hack.
https://www.youtube.com/watch?v=fDJ-88e_06A SS7 toegang kun je forceren met een zogeheten Software defined radio card , icm openBTS / openLTE en dan gaan packet sniffen / manipuleren.
en omdat whatsaap key veranderings detectie standaard uit heeft staan slaat hij hier niet op aan...
Bij een programma als Signal private messenger is dit allemaal heel anders geregeld , de key generatie is gebaseerd op random factoren + erg lang paswoord , en het houd rekening met een vijandig netwerk.
en maakt geen backups , je kan door de backups te pakken te krijgen de converstaties van whatsapp zonder dat iemand het merkt prima volgen.
En dan nog iets hoe makkelijk is het voor een closed source programma een verborgen tag van de key file in de ongecrypte fotos en andere media files te verwerken.
die je met de juiste stenografische combinatie can extraheren uit de in de backup staande .jpg files?
https://stackoverflow.com...-survive-jpeg-compression er kan dus veel worden uitgehaald. met je veiligeid als je backups toe staat. in een closed source programma :)

[Reactie gewijzigd door bluegoaindian op 21 januari 2017 02:49]

Dank voor je reactie! :)
Die was wel ietsjes moeilijk te lezen trouwens. :$ Vanaf mobiel getikt? :P Een extra enter hier en daar zou geen kwaad kunnen. :)
Dat heb ik getest das niet nodig gebleken.
ik had google drive nooit gebruikt.
Dan ga ik dat eerst eens testen voordat ik meega in die conclusie. ;)
Forgive me, ik neem niet zomaar aan dat het hetzelfde werkt - mede omdat ik weet dat er de laatste tijd aan gesleuteld is, en mede omdat die artikelen en scripts het allemaal hebben over OF lokale back-ups OF een geactiveerde WhatsApp met toegang tot Google Drive.

Ik kan niet zomaar aannemen dat het hetzelfde werkt. Het zou kunnen, ik zeg dus absoluut niet dat je geen gelijk hebt!, maar ik wil dat toch wel graag helemaal zeker weten; en heb een paar twijfels. (Dat snap je hopelijk wel? :))

Ik weet namelijk niet of je de situatie van lokale backups ten opzichte van Google Drive/iCloud backups een op een met elkaar kan vergelijken zoals jij doet, en of hetzelfde mechanisme gebruikt wordt. De manier van storage is namelijk ook anders bij lokaal vs cloud, dus het is niet onaannemelijk dat de crypt ook anders is.
Zeker omdat encrypted backups naar iCloud pas sinds versie 2.16.8 geïntroduceerd zijn, dat is recenter dan die artikelen/scripts.

... Het lijkt er dus op dat ik van m'n luie hol af moet komen en toch een keer die backup functie moet gaan bekijken om een definitief antwoord te krijgen. :P
Zoals AnonymousWP al aangaf en van mij citeerde wist ik tot voor kort niet eens dat er überhaupt encryptie werd toegepast op de backups.. ;)

Als je wilt, zal ik je een DM sturen als ik de tests heb uitgevoerd. Dan weet jij ook meteen óf je gelijk had: óf dat de veiligheid daar totaal anders geregeld is ten opzichte van lokale backups.
Als je wil weten hoe een dienst jouw whatsapp overneemt kijk daqn eens naar dit filmpje met deze ss7 hack.
Die ken ik. :) Dat is onderhand bijna een klassieker.

Ik raad je aan deze discussie te volgen/te lezen:
https://news.ycombinator.com/item?id=11668567

Trouwens, volgens mij is een prerequisite voor die aanval dat je in de buurt moet zijn van het toestel dat je wilt aanvallen?
je kan door de backups te pakken te krijgen de converstaties van whatsapp zonder dat iemand het merkt prima volgen.
Dat klopt, als je daar aan kan komen en het weet te decrypten.
Echter is "geen backups" geen optie voor de gebruikers van WhatsApp. :P

[Reactie gewijzigd door WhatsappHack op 21 januari 2017 04:21]

Dank voor je reactie! :)
Die was wel ietsjes moeilijk te lezen trouwens. :$ Vanaf mobiel getikt? :P Een extra enter hier en daar zou geen kwaad kunnen. :)


[...]


Dan ga ik dat eerst eens testen voordat ik meega in die conclusie. ;)
Forgive me, ik neem niet zomaar aan dat het hetzelfde werkt - mede omdat ik weet dat er de laatste tijd aan gesleuteld is, en mede omdat die artikelen en scripts het allemaal hebben over OF lokale back-ups OF een geactiveerde WhatsApp met toegang tot Google Drive.

Ik kan niet zomaar aannemen dat het hetzelfde werkt. Het zou kunnen, ik zeg dus absoluut niet dat je geen gelijk hebt!, maar ik wil dat toch wel graag helemaal zeker weten; en heb een paar twijfels. (Dat snap je hopelijk wel? :))

Ik weet namelijk niet of je de situatie van lokale backups ten opzichte van Google Drive/iCloud backups een op een met elkaar kan vergelijken zoals jij doet, en of hetzelfde mechanisme gebruikt wordt. De manier van storage is namelijk ook anders bij lokaal vs cloud, dus het is niet onaannemelijk dat de crypt ook anders is.
Zeker omdat encrypted backups naar iCloud pas sinds versie 2.16.8 geïntroduceerd zijn, dat is recenter dan die artikelen/scripts.

... Het lijkt er dus op dat ik van m'n luie hol af moet komen en toch een keer die backup functie moet gaan bekijken om een definitief antwoord te krijgen. :P
Zoals AnonymousWP al aangaf en van mij citeerde wist ik tot voor kort niet eens dat er überhaupt encryptie werd toegepast op de backups.. ;)

Als je wilt, zal ik je een DM sturen als ik de tests heb uitgevoerd. Dan weet jij ook meteen óf je gelijk had: óf dat de veiligheid daar totaal anders geregeld is ten opzichte van lokale backups.


[...]


Die ken ik. :) Dat is onderhand bijna een klassieker.

Ik raad je aan deze discussie te volgen/te lezen:
https://news.ycombinator.com/item?id=11668567

Trouwens, volgens mij is een prerequisite voor die aanval dat je in de buurt moet zijn van het toestel dat je wilt aanvallen?


[...]


Dat klopt, als je daar aan kan komen en het weet te decrypten.
Echter is "geen backups" geen optie voor de gebruikers van WhatsApp. :P
Oke stuur maar een DM ik heb er mee gespeeld toen ik griep had. kon toen toch niet naar buiten , en was helder genoeg achter een scherm te zitten!
heb toen zonder problemen de backups inclusoef crypt12 file kunnen bhinnen lepelen zonder ook drive te hebben aangeraakt , kon gewoon met naam en password naar binnen van iemand die het ook wel wilde wten of t veilig was (mn moeder) en dus toestemming heeft gegeven! en geen idee heeft van het bestaan van google drive :)
Dat weet ik. Die encryptiemethode wordt echter wel steeds verbetert, heb namelijk zelfs nog een .crypt 8 bestand. Anyway, zelf heb ik mij niet verdiept in het kraken van back-ups van WhatsApp. Ik heb mijn test-toestel nog niet beschikbaar voor gesteld.

Dat de lokale back-up de sleutels bevat, is logisch. Anders kan je hem toch niet decrypten? :p Je gaat natuurlijk geen lokale back-up naar Google Drive of iCloud uploaden, want dan is het niet meer betrouwbaar qua veiligheid. De back-up die je met Google Drive kan maken is dus wel encrypted, en wel safe, want beide partijen hebben nooit de 2 benodigdheden (de keys én de back-up). Maar precies zoals WhatsappHack het al zegt hieronder.
Dat de lokale back-up de sleutels bevat, is logisch. Anders kan je hem toch niet decrypten? :p Je gaat natuurlijk geen lokale back-up naar Google Drive of iCloud uploaden, want dan is het niet meer betrouwbaar qua veiligheid. De back-up die je met Google Drive kan maken is dus wel encrypted, en wel safe, want beide partijen hebben nooit de 2 benodigdheden (de keys én de back-up). Maar precies zoals WhatsappHack het al zegt hieronder.
Dat is nog maar de vraag zie mijn reakties , de media is ongecrypt . whatsapp is closed source , t zou zomaar kunnen zijn dat de sleutel om een slinkse weize in de media word verspopt (stenografie) :)
verder is t niet al te veilig als je er een paar VGA kaarten tegen aan gooit!
De media is wél encrypt, evenals de berichten zelf. WhatsApp mag dan wel closed source zijn, maar het Signal protocol is bekend als veilig. Bovendien heeft Moxie (en nog een ander) het serverontwerp gedaan voor WhatsApp. Daarom weet hij dus zo goed hoe alles in elkaar steekt.
De media is wél encrypt, evenals de berichten zelf. WhatsApp mag dan wel closed source zijn, maar het Signal protocol is bekend als veilig. Bovendien heeft Moxie (en nog een ander) het serverontwerp gedaan voor WhatsApp. Daarom weet hij dus zo goed hoe alles in elkaar steekt.
Onzin! de backup functie is het probleem hier!
https://github.com/EliteAndroidApps/WhatsApp-GD-Extractor/ en je haalt zo de jpgs en filmjes eruit zonder encryptie!
Als je niet weer waar je over praat , houd dan gewoon je mond.

[Reactie gewijzigd door bluegoaindian op 23 januari 2017 10:43]

Ik weet waar ik over praat, maar ik heb het over de back-up van Google. En die WhatsApp extractor werkt nog steeds? Of praat je nu over 3 jaar geleden?

We kunnen ook gewoon normaal een discussie aan gaan, toch? Als je zo tegen me praat, ga ik niet eens verder in discussie.
mooie bewering - daar gaan we wat over verderlezen.
zie ook de blog van openwhispersystems

vooral dan:
The choice to make these notifications "blocking" would in some ways make things worse. That would leak information to the server about who has enabled safety number change notifications and who hasn't, effectively telling the server who it could MITM transparently and who it couldn't; something that WhatsApp considered very carefully.

[Reactie gewijzigd door moeilijkenaam op 20 januari 2017 18:08]

Waarom niet verplichten zonder optie om het uit te schakelen, zoals Signal dat doet? Dat lost het probleem ook op omdat iedereen dan geen phishingdoelwit meer kan zijn.

Waar Signal heeft gekozen voor veiligheid heeft WhatsApp gekozen voor gebruiksvriendelijkheid. Voor beide valt wat te zeggen, hoewel het natuurlijk belachelijk is dat de techniek nog steeds de gebruiker moet lastig vallen om veilig te zijn. Een commerciële partij mikt daarom op gebruiksvriendelijkheid.
Waarom niet verplichten zonder optie om het uit te schakelen, zoals Signal dat doet? Dat lost het probleem ook op omdat iedereen dan geen phishingdoelwit meer kan zijn.
Dat zijn ze aan het overwegen/overleggen: WhatsappHack in 'nieuws: 'WhatsApp laat kwetsbaarheid al bijna jaar ongewijzi...
Al heb ik wel verzocht of ze alsnog een "secure mode" willen inbouwen voor mensen die echt die-hard security freaks zijn; en dus graag een pak gebruiksgemak willen inleveren om nog betere beveiliging te krijgen; in die mode zou dan echt alles je bevestiging nodig hebben. Daar denken ze op dit moment nog over na, maar t wordt overwogen. :)
Hoi!
Dank dat je die gelinkt hebt :D

Ik moet er wel twee opmerkingen over maken, waarvan 1 na wat ontwikkelingen:
Ten eerste: hetgeen ik beschrijf is wél optioneel, wat The Zep Man voorstelt is een functie om het *niet* optioneel te maken: maar verplicht. (Dat gaat waarschijnlijk niet gebeuren in relatie tot het "blocking retransmission" gedeelte, ik kom daar zo op terug!! =)) Dat is een verschilletje in benadering. :)

Ten tweede, wat ik daar gezegd heb: daar moet ik op terugkomen.
Ik heb een fout gemaakt, en dat geef ik natuurlijk zonder probleem toe.
Het zal (gelukkig!) nooit optioneel worden ingebouwd zoals ik daar had voorgesteld...
Voor de mensen die het interesseert zal ik de technische beweegredenen daarachter even toelichten:

Er is een probleem met dat voorstel dat ik, helaas, over het hoofd had gezien toen ik hem maakte; Moxie Marlinspike had daar het volgende over te zeggen:
That would leak information to the server about who has enabled safety number change notifications and who hasn't, effectively telling the server who it could MITM transparently and who it couldn't.
Op dit moment kan WhatsApp *niet* zien wie notificaties ingeschakeld heeft staan, maar als ze zouden doen wat ik had voorgesteld: dan zou de server dat alsnog kunnen achterhalen door simpelweg de connectie te monitoren. Dat is niet wenselijk.

Als het optioneel is, dan kan de server in theorie zien wie de functie wel en niet aan hebben staan; immers is het duidelijk merkbaar als user A berichten in de que heeft staan en deze automatisch retransmit na re-login, terwijl user B dat niet doet omdat hij "secure mode" aan heeft staan. Dan weet je dus dat User A waarschijnlijk een heel makkelijk doelwit is, en weet je 100% zeker dat User B dat absoluut niet is en dat je die moet vermijden om niet gesnapt te worden. :P

Als er geen optionele optie is, dan kan WhatsApp dat onderscheid onmogelijk maken en moet je er dus *altijd* van uitgaan dat je gesnapt kan worden, en wordt de lat om het toch te gaan proberen derhalve vele malen hoger gelegd met oog op het risico gesnapt te worden: en zal een aanvaller dus wel 100x nadenken voordat hij het risico durft te lopen, dan moet ie wel heel erg graag de berichten in de que willen zien* en het hem geen hol uitmaken als hij gesnapt wordt. Dat maakt dit wel een heel erg extreem specifiek scenario, en dus vele malen veiliger dan mijn voorstel. WhatsApp zal dat monitoren niet doen natuurlijk, maar het feit dat het in theorie mogelijk is te doen maakt mijn voorstel alsnog minder veiliger dan de huidige situatie; puur omdat er dan meer zeer nuttige informatie beschikbaar is voor een eventuele aanvaller.
*= En dan moet ie ook nog eens de mazzel hebben dat er überhaupt berichten in die que staan... Het scenario is derhalve zeer hypothetisch, wie gaat er nou een groot risico lopen gesnapt te worden, en er veel tijd/geld/moeite in steken terwijl het tweede risico is dat je er ook nog eens helemaal geen enkel bericht mee weet binnen te halen? o0 Het is al bijna niet te exploiten, meerdere zaken moeten *perfect* zijn en er is een heel groot risico gepakt te worden; en dan nog heb je grote kans dat het je niets oplevert. :X

Derhalve over die specifieke suggestie tot een optionele "secure mode": I stand corrected, Moxie heeft helemaal gelijk - er mag absoluut geen optionele secure mode ingebouwd worden in WhatsApp.
Of ze wél die key-change notificaties (zonder het "block before transmit" gedeelte) verplicht gaan maken: dat is weer een ander onderwerp. :)


Het antwoord op de vraag
waarom niet verplichten zonder optie om het uit te schakelen, zoals Signal dat doet?
Dat staat uitgelegd in die blog als we het hebben over "blocking retransmission" :P Maar in essentie even uitgelegd: het is een trade-off om het de gebruiker makkelijker te maken zodat berichten niet verloren gaan als iemand offline is/her-authenticeert, en de keuze heeft of ze wel of niet geïnformeerd willen worden; voor WhatsApp is dat belangrijk met het oogpunt op gebruiksvriendelijkheid en betrouwbaarheid, én daarnaast rekening houdend met het oogpunt dat sommige gebruikers dat soort "block before transmit"-prompts toch als volgt behandelen:
-- Werkelijke notificatie: zie deze screenshot.
-- Hoe de gebruiker het leest: zie deze screenshot. :P

Er valt, zoals anderen al opmerken, iets te zeggen voor beide implementaties (blocking en non-blocking); zowel die van Signal als die van WhatsApp dus - maar de keuze van WhatsApp hoe ermee om te gaan is verre van onlogisch en, gezien hun gebruikersaantallen, eigenlijk gewoon de veiligste oplossing in combinatie met toegankelijkheid van de crypto functies voor de gebruikers.

[Reactie gewijzigd door WhatsappHack op 21 januari 2017 02:25]

Ik heb de indruk dat de redacteur de klok heeft horen luiden. Dit artikel is verwarrend door (opnieuw) deze zin:
Daarbij gaat het erom dat WhatsApp voor niet verstuurde berichten, bijvoorbeeld omdat de ontvanger offline is, nieuwe sleutels aanmaakt en de berichten alsnog aflevert.
Hoezo maakt WhatsApp nieuwe sleutels aan voor niet verstuurde berichten? De enige die sleutels aan kan maken is de ontvanger, die moet immers de private key aanmaken waar de public key op gebaseerd is.

De WhatsApp verzender maakt helemaal geen nieuwe sleutels aan iedere keer als de ontvanger offline is. De ontvanger maakt (sporadisch) nieuwe sleutels aan, waarna deze sleutels automatisch geaccepteerd worden door de verzender.

Een kwaadwillende kan dit misbruiken door het account van de ontvanger te klonen.

Bij ssh (Linux) was dat vroeger bij sommige distro's ook zo. Totdat ze de "StrictHostKeyChecking" optie hebben toegevoegd. Die staat tegenwoordig default op "yes" of "ask", resulterende in de volgende waarschuwing:
WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.

The authenticity of host 'some.ssh.machine (1.2.3.4)' can't be established.
RSA key fingerprint is a1:b2:c3:d4:e5:f6:a1:b2:c3:d4:e5:f6:a1:b2:c3:d4.
Are you sure you want to continue connecting (yes/no)?
De reden dat ie (vroeger) gewoon werd geaccepteerd is hetzelfde als bij WhatsApp
  1. Gemak en de gebruiker niet lastig vallen met nerd-zaken.
  2. De kans dat dit gebeurt is megaklein.
  3. Als het gebeurt kom je er na 5 minuten achter, omdat de server (of ontvanger iemand) anders is.
Als dit op semi-grote schaal zou gebeuren, dan zou dit meteen bekend worden, omdat iedereen die key notifications aan heeft staan:

Settings > Account > Security > Show Security Notifications > aan

bij elk bericht twee keer de keys ziet veranderen en alarm slaat. De waarde van WhatsApp zou in elkaar storten.

Dit artikel is net iets minder verwarrend dan de vorige, welke ook al verwarrend was, gebaseerd op een misleidend en verwarrend artikel van The Guardian.

[Reactie gewijzigd door Redsandro op 21 januari 2017 12:37]

De Britse kranten staan bekend om hun sensationele koppen die ver verwijderd zijn van de waarheid. Ik denk dat ze de kritiek naast zich neer zullen leggen en denken 'wij hebben toch gekregen wat we wilde, namelijk meer kranten verkopen.'
Als de average gebruiker zo bezorgd is over beveiliging kunnen ze best wel Telegram of Signal gebruiken. Niemand geeft er iets om ook al weten ze dat hun data bekeken worden lol!
Als je je zorgen maakt over de beveiliging, zou ik geen Telegram nemen, maar Signal. Misschien niet zoveel gebruikers, maar veeeeel veiliger dan Telegram. Telegram is het laatste waar ik aan denk qua privacy en beveiliging. Lees hier maar eens:

http://thehackernews.com/...ram-security-privacy.html

http://gizmodo.com/why-yo...gram-right-now-1782557415
Dat laatste artikel zou je voor de grap eens serieus door moeten lezen (alsin, verder lezen dan de titel).

Hier is de officiële reactie van Telegram (doe ermee wat je wilt):
This is an astounding example of shoddy reporting (which is probably no surprise, considering the source). Incorrect and misleading statement upon incorrect and misleading statement.

Just to give a few examples:

1. The author deliberately confuses encryption and end-to-end encryption and claims that some data on Telegram is sent and stored unencrypted. This is not true.

All data is encrypted. Secret chats use end-to-end encryption, cloud chats use sever-client encryption in transit. Cloud chats are of course encrypted in storage as well. The decryption keys are split and stored in multiple data centres controlled by different legal entities spread across different jurisdictions. As a result, an unrealistic level of inter-governmental cooperation is required to force us to give up any data. (E.g. several court orders from different jurisdictions.)

2. A professor mentions "security by obscurity" and claims it's not possible to analyse Telegram's encryption scheme. This is also not true.

Telegram's protocol specification is open (detailed: https://core.telegram.org/mtproto overview: https://core.telegram.org/techfaq).

Our app code, which together with the docs allows to fully evaluate the end-to-end encryption implementation, is also open (https://telegram.org/apps#source-code).

Security researchers have all the necessary tools to evaluate Telegram's protocol.

3. The part about metadata and seeing other users online – also not true. Unlike in Whatsapp, you actually have control over who exactly sees you online/offline. It doesn't matter, which app is used, the setting is on the server side.

See:
https://telegram.org/faq#q-can-i-hide-my-last-seen-time
and:
https://telegram.org/faq#q-who-can-see-me-online
Okee, ik moet even opmerken dat ik dit frappant vindt.
Eerst zeg je in een reactie naar mij dat je de mening van security experts moet negeren "omdat ze mogelijk een aandeel hebben in Facebook", en dat je het frustrerend vindt dat mensen die meningen aanhoren; maar hier plak je vervolgens wél een "Wij van WC-eend" bericht van de makers van Telegram over hoe veilig Telegram is om aan te tonen dat het veilig is? :P
Is dat niet... Een beetje raar en heel erg tegenstrijdig met wat je eerder tegen mij zei? :)

Maar afijn, laten we dat even nuanceren:
1. The author deliberately confuses encryption and end-to-end encryption and claims that some data on Telegram is sent and stored unencrypted. This is not true.

All data is encrypted. Secret chats use end-to-end encryption, cloud chats use sever-client encryption in transit. Cloud chats are of course encrypted in storage as well. The decryption keys are split and stored in multiple data centres controlled by different legal entities spread across different jurisdictions. As a result, an unrealistic level of inter-governmental cooperation is required to force us to give up any data. (E.g. several court orders from different jurisdictions.)
Met andere woorden: ja, het klopt dat het niet unencrypted is (volgens mij is dat ook niet geclaimed?) maar er wordt even niet bij opgemerkt dat de plain-text accessible is voor Telegram!
Dat zij de sleutels distributen over andere servers dan de servers waar de encrypted data opstaat: dat is hartstikke leuk voor het geval iemand een harde schijf uit de server jat of iets dergelijks, maar het neemt niet weg dat de server plain-text access heeft tot AL je data; en dus AL je gesprekken, AL je media, AL je contacten, et cetera.

Edward Snowden had daar ook wat over te zeggen:
https://twitter.com/Snowden/status/678274362609426432

En daar heeft ie gewoon gelijk. Het maakt niet uit of de data encrypted wordt opgeslagen in de cloud, als de beheerder van de cloud in kwestie de sleutels ook in bezit heeft!
Zij kunnen er heel makkelijk bij, en ze noemen zelf in principe (al doen ze hun best het werkelijk benoemen van het probleem te omzeilen) ook al dat het niet ondenkbaar is dat ze verzoeken vanuit "different jurisdictions" krijgen om de data geforceerd te overhandigen.
professor mentions "security by obscurity" and claims it's not possible to analyse Telegram's encryption scheme. This is also not true.

...

Security researchers have all the necessary tools to evaluate Telegram's protocol.
Dat is wel waar, als je kijkt naar de fouten die in MTProto gevonden zijn.
Daarmee zou het, in theorie: of het echt kan blijft nog even giswerk, voor de server mogelijk zijn om relatief makkelijk, en tenminste tegen redelijk lage kostprijs, een secret-chat te decrypten zonder dat de gebruikers daar ooit iets van door kunnen krijgen.
Geen key wijzigingen, geen afgebroken secret-chats: nee, ze blijven gewoon werken en de server kan rustig eavesdroppen.

Gezien we niet kunnen zien wat er op de servers gebeurd, is er dus helemaal geen mogelijkheid voor onafhankelijke security researchers om Telegram's protocol daadwerkelijk 100% te evalueren - die claim van Telegram is dus een wat verbloemde representatie van de werkelijkheid.

Ik zeg dus niet DAT Telegram het doet: maar het feit alleen al dat er zo'n mogelijke kwetsbaarheid zit in MTProto die dit mechanisme mogelijk maakt zonder dat er op enige wijze iets tegen te doen is, dat werpt wel vraagtekens op bij de veiligheid.
Ze hebben dus ergens misschien wel een punt als ik er zo over nadenk en je een op en bepaalde manier beredeneert... Security researches hadden dan inderdaad alles wat ze nodig hadden om Telegram's protocol te analyseren: en de conclusie is dat er kwetsbaarheden inzitten die het gehele protocol onbetrouwbaar maken.

[Reactie gewijzigd door WhatsappHack op 21 januari 2017 04:44]

Jawel. Want whatsapp heeft de sleutels niet in handen. Telegram wel. Whatsapp kan per definitie helemaal niets met de messages doen. Is puure bs text wat ze doorkrijgen. De ontvanger kan er pas wat leuks van maken.
Dat maakt dus geen drol uit. Ik weet ook niet wat er op een mailserver van bedrijf X gebeurt, maar als ik de mail versleutel met PGP kun je op de server alleen maar headers zien waar iets heen moet. De inhoud is pure gibberish.

Ik hoef dus niet te weten wat er op de server allemaal kan gebeuren aangezien "ik" (mijn telefoon) de sleutels beheer. Dat is het hele idee van E2E encryptie.

Als ik een bericht verstuur haalt het toestel via de server van Whatsapp de publieke sleutel op van de ontvanger, daarme codeer ik mijn bericht en alleen de ontvanger heeft de sleutel om het weer om te zetten.

En dat kan je controleren door die qr codes.
Als je je echt zorgen maakt over beveiliging, dan moet je überhaupt geen smartphone bezitten.
Jawel, maar eigenlijk is dat gek. Het is mijn smartphone en mijn data en mijn gesprekken.

Sommige apps eigenen zich dat toe alsof het normaal is.

Het moet gewoon normaal worden dat zoiets niet gebeurt
Je bent er zelf bij als je ok klikt als apps toegang vragen aan je hele hebben en houden bij het installeren. Zoals watsap bijvoorbeeld... Maar dan nog, het zijn gewoon apparaten waar vrij makkelijk toegang tot veel "gevoelige" informatie te krijgen is, danwel op afstand, danwel door fysieke toegang.
Met een BlackBerry ben je in ieder geval een stuk veiliger als de rest. ( De blackberry priv is sinds release nog steeds niet geroot )
Het gerucht gaat dat BlackBerry zelf toen der tijd de sleutel had gegeven aan de Canadese politie.

Dus niet gehacked of geëxploiteerd. Ook had het alleen effect op het bis en niet het bes netwerk. Dat is nog steeds een van de of misschien wel de beste Enterprise server
Haha Tweakers noemt het in dit artikel een lek, volgens mij snapt de redacteur niet waar het artikel over gaat.
Ik vind het ook verwarrend door (opnieuw) deze zin:
Daarbij gaat het erom dat WhatsApp voor niet verstuurde berichten, bijvoorbeeld omdat de ontvanger offline is, nieuwe sleutels aanmaakt en de berichten alsnog aflevert.
Hoezo maakt WhatsApp nieuwe sleutels aan voor niet verstuurde berichten? De enige die sleutels aan kan maken is de ontvanger, die moet immers de private key aanmaken waar de public key op gebaseerd is.
Ik denk dat "WhatsApp" in dit geval slaat op de clients; zowel voor ontvanger als verzender.
Ben het met je eens dat het wel verwarrend kan zijn, je kan die zin immers interpreteren als "WhatsApp (server/bedrijf) maakt die sleutels aan"; specifiek erbij opmerken dat het om de applicatie op het toestel gaat zou een fijne toevoeging zijn geweest om dat duidelijk te maken. :)

En het klopt inderdaad ook niet dat er nieuwe sleutels aangemaakt worden omdat iemand offline is. Dat iemand on- of offline is maakt niets uit voor keygen. Er worden pas nieuwe sleutels aangemaakt als de keys verloren gaan of niet beschikbaar zijn.
(Eg: WhatsApp opnieuw installeren, nieuwe telefoon, een aanvaller die inlogt op de account van iemand anders, et cetera.) Enkel je mobieltje uitzetten zal geen re-key tot gevolg hebben nee. :P
Ik denk opnieuw dat de redactie dit wel correct heeft bedoeld trouwens, maar dat je het verkeerd kan lezen; een zin als deze is dan misschien wat begrijpelijker:
Daarbij gaat het erom dat WhatsApp voor niet verstuurde afgeleverde berichten, bijvoorbeeld omdat de ontvanger offline was, nieuwe sleutels aanmaakt en de berichten alsnog aflevert als iemand zich weet aan te melden met de account voor wie de berichten bedoeld waren.
Het was me nog niet eens opgevallen dat dat in het artikel stond - Feedback melden aan de redactie zodat ze het kunnen corrigeren is in dit geval denk ik wel terecht. :)

Zowel ontvanger als verzender wisselen nieuwe sleutels uit trouwens als een van de twee wijzigt van PK, anders kunnen ze geen session-key en FP overeenkomen waar doorheen geratchet kan worden, en zou je dus geen Forward Secrecy en Future Secrecy krijgen.

[Reactie gewijzigd door WhatsappHack op 22 januari 2017 14:37]

Op dit item kan niet meer gereageerd worden.


Apple iPhone X Google Pixel XL 2 LG W7 Samsung Galaxy S8 Google Pixel 2 Sony Bravia A1 OLED Microsoft Xbox One X Apple iPhone 8

© 1998 - 2017 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Hardware.Info de Persgroep Online Services B.V. Hosting door True

*