Zo, eens een "het is midden in de nacht en ik heb tijd over terwijl de compilers nog staan te pruttelen, wat ga ik eens doen?" post. Voor de duidelijkheid: de content in deze post heb ik niet heel veel aandacht aan besteed, dus het kan prima zo zijn dat ik iets over het hoofd heb gezien... Het was gewoon iets wat spontaan in me opkwam in een paar minuten verveling, en op basis daarvan heb ik het op "papier" gezet.
Ik geloof dat dit wel het juiste board is hiervoor? Het gaat immers om Security...
Zo niet, verwijder dan maar; dan gooi ik het wel in een blog.
Dit is een heel erg lange post met een behoorlijk aantal technische/cryptografische details.
Ga het alsjeblieft niet lezen als dit je niet interesseert, en ga alsjeblieft geen "TL;DR" reacties geven. Als je het niet interessant genoeg vond om helemaal door te lezen om het hele idee te snappen inclusief de implementaties ervan: reageer dan ook gewoon alsjeblieft NIET. "TL;DR, maar ik vind dat je..." posts hebben geen toegevoegde waarde. Bij voorbaat dank!
Als je dit leest; hou dan dus in gedachte: dit is meer m'n (zeer vermoeide) gedachten neerpennen dan een werkelijk super hoogstaand onderzoek/idee wat ik hier neerplemp.
Anyway;
Introductie
Na een *kuch* leuke *kuch* discussie met meningmods die hoogtij vieren, ben ik nog eens gaan kijken naar de algemene beveiliging van de op de cloud opgeslagen data.
Het blijft me verbazen dat de encrypted data opgeslagen wordt met de decryptie sleutel erbij, dat zeggen ze namelijk:
Het ondermijnt echter wel de veiligheid. Dat je data encrypted opgeslagen is, dat is allemaal leuk en aardig: maar als het systeem gekraakt wordt dan heeft het natuurlijk nogal weinig nut als de sleuteltjes er gewoon bij zitten. De server kan die terugvinden als je inlogt, dan moet een hacker dat dus ook kunnen zien als hij toegang krijgt tot het Telegram systeem. Dat houdt in dat al die data die je uitwisselt met Telegram (al je contacten, berichten, foto's en video's) naar mijn mening eigenlijk helemaal niet zo veilig opgeslagen staan als ze beweren; en alsmede wat de meeste mensen denken.
Wat ik me dan toch afvraag... Waarom is er eigenlijk gekozen voor een constructie waar de server de decryptie sleutel kent? Wat is er in hemelsnaam het nut van, behalve een stapje minder gebruikers input dat iets meer usability geeft? Waarom zou je zo'n opzet maken, terwijl er een stuk veiligere methodes te bedenken zijn: zelfs binnen een cloud opzet?
Lokaal key management
Want laten we wel zijn: de sleutel kan ook gewoon gebaseerd worden op een wachtwoord dat lokaal een decryptie sleutel genereert.
Dan zou de data encrypted in de cloud staan, maar zonder de encryptie sleutels erbij. Je apparaat, ongeacht het type apparaat, is dan verantwoordelijk voor zowel de encryptie als decryptie van de data, en de servers van Telegram komen daar vervolgens totaal niet meer aan te pas.
Neem even KeypassX als voorbeeld: je hebt een bestand op je server staan, dat is encrypted data. Je kan het downloaden naar welk apparaat dan ook dat KeyPass (of compatible variant) geinstalleerd heeft staan, en vervolgens moet je een wachtwoord intikken die al je wachtwoorden kan decrypten. Het bestand zelf is waardeloos zonder de sleutel! Het staat dus veilig op je server (met een beetje wachtwoord tenminste...), en zelfs als iemand volledige toegang tot je server krijgt kunnen ze er nog geen hol mee. Prima! Waarom wil Telegram dan niet zo'n opzet? Ik bedoel, er wordt zo op gehamerd dat het allemaal heel veilig moet en privacy vriendelijk moet zijn en blabla: maar op deze manier is de cloud wel een erg zwak punt.
De enige factor is usability... Maar voor een app met al die claims, waarom is usability (gebruiksvriendelijkheid) dan kennelijk belangrijker?
Het is namelijk natuurlijk veel handiger als je enkel je wachtwoord in een client hoeft in te tikken, en vervolgens wordt al je data gedownload inclusief de decryptie key. Joepie, je hebt 5 seconden bespaard. Maar besef je je wel hoeveel je inlevert op de veiligheid van je data...? Zeker met die brakke privacy policy die ze nog altijd hanteren?
Want wat nu als deze data encrypted in de cloud wordt opgeslagen, maar dat die encryptie plaatsvindt op basis van de sleutel die je opgeeft in de client, en die dus nooit met de servers wordt gecommuniceerd? Die client is open-source, dus waarom niet? Dan kan je namelijk ook checken of het wel werkelijk op die manier encrypt wordt en of die sleutel inderdaad niet met de server wordt uitgewisseld.
Het enige probleem is dat voor de hoogste veiligheid, deze data enkel decrypt moet kunnen worden met een ander wachtwoord (anders dan waarmee je inlogt) dat je enkel lokaal ingeeft en dat nooit en te nimmer wordt uitgewisseld met de Telegram cloud. Telegram kent die sleutel niet, slaat deze dus ook niet op: en derhalve is de veiligheid veel hoger en heb je een veel hogere mate van garantie dat je data werkelijk veilig is en niet wordt doorverkocht. (Want ze mogen je data doorverkopen bij Telegram.)
Telegram servers gehacked? Boeie, m'n data is veilig!
Telegram lekt de sleutels? Nee dat kan dan dus niet meer, want die hebben ze dan niet eens.
Telegram heeft een brakke privacy policy? Geeft niet, want ze kunnen m'n data toch niet inzien. (Op groupchats na.)
Maar wat is dan nu het probleem...? Nouja, je moet dus 2x een wachtwoord ingeven.
1x om in te loggen naar Telegram en je daar te authenticeren en al je data binnen te halen, en nog een wachtwoord om deze data vervolgens te decrypten.
Dit wachtwoord moet je op elke client die je instelt intikken. Dat is een extra stap. Weliswaar een extra stap die naar mijn idee een stuk hogere mate van veiligheid geeft, maar het is en blijft een extra stap.
Je krijgt twee wachtwoord prompts in plaats van slechts 1... Oh noes! Uiteraard hoef je die tweede prompt, voor het encrypten/decrypten, maar een keer in te vullen: daarna wordt de sleutel lokaal opgeslagen.
Bijkomend probleem is dat als je dat wachtwoord wilt wijzigen: dan moet de data geheel opnieuw decrypt worden en moeten alle apparaten dat nieuwe wachtwoord ook krijgen (en opnieuw de data downloaden). Opzich geen ramp, maar niet 100% gebruiksvriendelijk. (Maar wat wil je nou liever...?)
Toch is het maar een zeer kleine extra moeite, en dus enkel een probleem als je je wachtwoord wilt wijzigen van de encryptie: dan moet je overal "opnieuw inloggen". (Maar dat moet ook bij een normale password change, dus waar hebben we het over?)
Is een opzet als deze niet veel veiliger, dan een server die data voor je encrypt en vervolgens de decryptie sleutels lokaal opslaat voor distributie naar de clients waarmee je inlogt...?
End-to-end encryptie buiten secret chats
Een bijkomend voordeel van deze opzet, en nogmaals: dit zijn gewoon even snelle gedachten; ik heb dit nog niet helemaal 100% uitgezocht en ik schrijf nu gewoon 1 op 1 m'n gedachten even op over hoe ik deze situatie benader, lijkt mij dat Telegram dan standaard end-to-end encryptie kan toepassen.
Sterker nog: het zal dit zelfs toe *MOETEN* passen om werkelijk veiligheid te bieden. Win-win!
Nu is dat niet mogelijk omdat de server alle data unencrypted wil hebben om door te sturen en op te slaan (en dan pas wordt het encrypt), maar als de data toch al op de apparaten zelf wordt encrypt/decrypt: dan is die stap niet meer noodzakelijk. Dan kan end-to-end encryptie standaard ingeschakeld worden, immers stuurt je apparaat het bericht dan end-to-end encrypted naar de ontvanger, maar tegelijkertijd encrypt aan de hand van je wachtwoordzin je apparaat het bericht dat je zojuist verstuurd hebt en stuurt *dat* naar de Telegram cloud toe... Zo krijgen alsnog al je apparaten dat bericht binnen, en wordt het alsnog opgeslagen in de cloud waardoor je apparaten zo alle historie kunnen binnenhalen: maar de Telegram server kan er niet meer bij en kan niet meer meelezen. (Als ze iets anders gaan gebruiken dan dat verrotte protocol van ze tenminste.) Je hebt dus exact dezelfde functionaliteit met de cloud opslag en alles: maar de berichten zijn nu wel end-to-end encrypted!
En dat is ook noodzakelijk, anders heeft die hele lokale encryptie weinig nut. Ja het beschermt je tegen een hack van de Telegram servers, maar daar is dan ook meteen alles mee gezegd: meer veiligheid heb je niet.
Als het bericht alsnog client>server->server>client wordt uitgewisseld, dan zou Telegram alsnog constant kunnen aftappen en zelfs kopietjes maken, dus weet je nog steeds niets zeker...
En waarom *MOET* je dan wel end-to-end encrypten, eigenlijk?
Nou, dat is nogal simpel. Enkel jij hebt je encryptie/decryptie sleutel. Als je die data dus encrypted naar Telegram verstuurd, dan kan de ontvanger hier helemaal geen ene hol mee: die krijgt enkel wat leipe tekentjes te zien, maar je bericht? Dat is onleesbaar, hij kent immers je sleutel niet. De Telegram server kan het namelijk ook niet decrypten (tenzij je het alsnog unencrypt (doch wel via MProto client-server beveiligde verbinding) naar de server stuurt, maar we willen juist zorgen dat die server je data niet kan zien, terwijl het toch een cloud systeem blijft...).
En nu willen we dus dat:
- Telegram nooit mee kan lezen, ook niet met de data die je op hun cloud infrastructuur opslaat
- Je ontvangers de berichten wel kan lezen, zonder dat hij de sleutel hoeft te kennen waar al je data mee wordt encrypt/decrypt
Met end-to-end encryptie en de encryptie op de data die ik omschreef los je dit allemaal in 1 klap op, dunkt mij.
1.) De data in de cloud wordt encrypted opgeslagen met een sleutel die enkel jij kent, en de servers van Telegram niet. Die kunnen het dus niet decrypten. Wel zo fijn.
2.) Naast dat je computer het encrypt en de cloud in gooit, stuurt hij het berichtje ook nog eens end-to-end encrypt naar de ontvanger toe. Die hoeft jou sleutel voor de cloud opslag/functionaliteit dus niet te kennen, hij moet enkel de sleutels kennen om de communicatie tussen jullie twee te ontsleutelen!
3.) Hierdoor wordt ook de communicatie in 1 klap een stuk veiliger: mocht de client-server sleutels gestolen worden, dan hebben ze alsnog de end-to-end sleuteltjes niet: en is het pakket dus alsnog onleesbaar!
-- Op deze manier heb je dus op alle fronten een win situatie. Je cloud functies, dus inloggen met meerdere devices, blijft beschikbaar.
Het enige nadeel? Het kost extra dataverkeer... Je moet alles namelijk twee keer versturen... En dat is ff de pest! (Al kan daar omheen gewerkt worden, maar dan wordt m'n post *nog* langer.)
Maar... WhatsappHack... dit is wel leuk en aardig, maar hoe zit dat dan met die meerdere devices en die end-to-end encryptie? Je zegt dat je end-to-end encryptie wil toepassen *en* de data in de cloud wil zetten. Maar als jij end-to-end gaat praten met Pietje via je iPhone, en je stapt over naar je computer (alle berichten zijn te lezen, want die worden uit de cloud opgehaald en decrypt met behulp van je lokale sleutel.): hoe kan die computer dan nog verder praten met Pietje...? Immers kent je computer die end-to-end sleuteltjes toch niet?
Mol jij hier dus potverdikkie en driewerf in de satanische gloria niet gewoon het hele systeem op deze manier, voor die irritante veiligheidsneiging van je?
... Neen. Want je encrypt de data al lokaal met je eigen encryptie sleutel.
Derhalve kan je *ook* de public en private key van dat gesprek VEILIG uitwisselen met je andere devices!
Ja, hoe meer devices je dan hebt: hoe groter het risico dat die sleutels gestolen worden.
... Maar op dit moment heb je helemaal die beveiliging niet, en valt er niet eens iets te jatten: dus ben je in mijn situatie nog altijd veiliger dan nu, niet waar?
Ja maar... En "secret chats" dan...?
Nou, dat heeft nog steeds een doel!
Het schakelt de end-to-end encryptie niet meer in, want die staat standaard al aan, maar als je "secret chats" gebruikt: dan wordt de kopie van het berichtje niet meer naar de cloud gestuurd.
(En dus niet te lezen op meerdere devices.) Die functie wijzigt dus verder totaal niet, behalve dan dat je niet meer afhankelijk bent van de secret chats voordat de boel end-to-end encrypt is: nee, het wordt vanaf dan *altijd* end-to-end encrypt.
Je secret-chats zijn dus nog steeds geheel secret, maar nu heb je opeens ook end-to-end encryptie in je normale gesprekken zonder dat hier ook maar op enige wijze iets gemold wordt aan je cloud functies en het kunnen inloggen vanaf meerdere devices. Als dat geen win-win is, dan weet ik 't ook niet meer.
Zelfs met hun huidige opzet zou je dit kunnen implementeren... Al verslaat het dan wel een beetje het doel omdat je zelf geen controle meer hebt over je sleutel: en derhalve is het minder betrouwbaar.
Telegram zegt met betrekking tot end-to-end encryptie op normale "cloud chats" zelf het volgende over:
Opmerking2: Wat ze daar zeggen is leuk, maar het legt eigenlijk niet uit *waarom* het niet end-to-end encrypt zou zijn. Je bent al server-client encrypt, dus zelfs in de huidige opzet kan je end-to-end decrypten en alsnog met de cloud babbelen en daar je berichten opslaan. Dat maakt de communicatie an sich nog altijd veiliger dan geen end-to-end encryptie in z'n totaliteit.
Afsluitend
Het leek mij een simpele doch zeer doeltreffende oplossing, waarmee alle functies behouden blijven; je hebt enkel 1 stap extra: het wachtwoord om te decrypten is lokaal, en dien je dus apart in te voeren. Dat is het enige... 1 lullige stap van 1 a 2 seconden extra, en je hebt zo enorm veel extra veiligheid!
Het enige probleem is als je je wachtwoord kwijt raakt... Ja, dan ben je de lul. En die kan je niet resetten.
... Maar hebben ze daar nou niet toevallig password managers voor uitgevonden?
Dat is werkelijk het enige probleem met deze opzet. Het valt en staat ermee dat de gebruiker zijn de/encryptie wachtwoord onthoudt.
Maarja, hebben we dat niet met veel meer diensten? Is dat een probleem? Is het een grote ramp? Voor de meeste mensen niet waarschijnlijk, het is alleen klote dat je dan je oude berichten en foto's niet meer kan inzien.
Maar daar tegenover staat dat als je netjes je wachtwoord onthoudt: je veel en *veel* meer beveiliging hebt dan nu.
Voor een app die claimt zichzelf extreem op privacy en veiligheid te willen focussen, snap ik niet waarom Telegram niet zo'n oplossing heeft ingezet.
Ze moeten toch weten dat hoe het nu werkt, het eigenlijk niet veilig is: maar dat ze het veel veiliger kunnen maken met een paar simpele tussenoplossingen?
... But then again: ik heb er nog niet 100% over nagedacht en nagekeken of ik niet iets over het hoofd zie of iets heb gemist in de technische specificaties van hun huidige systeem. Misschien zit ik wel mis en kan mijn oplossing niet eens geimplementeerd worden. Misschien zit er in mijn oplossing zelf zelfs een enorme redeneerfout en is het even makkelijk te hacken... Wie weet... Maar dat zie ik morgen wel!
Wat ik wel weet is dat dit in ieder geval niet voor groepschats gaat werken, althans: het end-to-end gedeelte niet. De opslag wel.
Ik ben benieuwd wat jullie van een opzet als dit vinden, en wat jullie gedachten er over zijn.
Ik denk niet dat Telegram dit ooit gaat implementeren trouwens, maar ik vond het wel een grappig ideetje.
Het enige nadeel dat ik er in kan vinden is dat het bandbreedte gebruik verdubbelt voor je normale chats...
Dat is voor sommige mensen wel een behoorlijk nadeel natuurlijk, maarja... Hoeveel gebruikt die app nou werkelijk? Ik geloof dat WhatsApp, inclusief plaatjes en videos, bij mij gemiddeld 50 tot 60MB per maand opslurpt voor duizenden berichten. Is 100 tot 120MB dan werkelijk zo'n ramp als het je veiligheid enorm vergroot...?
En ik heb het nu wel over Telegram, want door die discussie begon ik er weer eens over na te denken, maar het kan natuurlijk op meerdere cloud diensten van toepassing zijn. (Sommigen doen dit mischien ook al?
)
Het zal me benieuwen!
Zo. Iedereen die het helemaal gelezen heeft: hartelijk dank.
Ik hoop niet dat het al te onsamenhangend was en dat ik duidelijk heb uitgelegd wat ik precies bedoel.
En nogmaals: ik heb deze post niet helemaal goed doordacht, ik heb het geschreven terwijl ik al 36 uur wakker ben (en over een uurtje kan ik eindelijk gaan slapen!): dus als ik iets finaal over het hoofd heb gezien/een grove fout heb gemaakt in m'n redenatie: kijk me er niet al te boos op aan, 'mkay?
Het is een ruwe schets van een idee, geen uitgewerkt plan. Het is meer discussie voer dan een onderzoek, en heb meer tijd besteed aan het uittypen/uitleggen van m'n idee dan aan het idee zelf wat slechts enkele minuten in beslag nam.
Thanks!
Ik geloof dat dit wel het juiste board is hiervoor? Het gaat immers om Security...
Zo niet, verwijder dan maar; dan gooi ik het wel in een blog.
Dit is een heel erg lange post met een behoorlijk aantal technische/cryptografische details.
Ga het alsjeblieft niet lezen als dit je niet interesseert, en ga alsjeblieft geen "TL;DR" reacties geven. Als je het niet interessant genoeg vond om helemaal door te lezen om het hele idee te snappen inclusief de implementaties ervan: reageer dan ook gewoon alsjeblieft NIET. "TL;DR, maar ik vind dat je..." posts hebben geen toegevoegde waarde. Bij voorbaat dank!
Als je dit leest; hou dan dus in gedachte: dit is meer m'n (zeer vermoeide) gedachten neerpennen dan een werkelijk super hoogstaand onderzoek/idee wat ik hier neerplemp.
Anyway;
Introductie
Na een *kuch* leuke *kuch* discussie met meningmods die hoogtij vieren, ben ik nog eens gaan kijken naar de algemene beveiliging van de op de cloud opgeslagen data.
Het blijft me verbazen dat de encrypted data opgeslagen wordt met de decryptie sleutel erbij, dat zeggen ze namelijk:
Vanuit een praktisch oogpunt zou je denken dat dit erg logisch is: alle apparaten moeten erbij kunnen, dusja... Die moeten dan wel die sleuteltjes hebben!All data is stored heavily encrypted and the encryption keys in each case are stored in several other DCs in different jurisdictions.
Het ondermijnt echter wel de veiligheid. Dat je data encrypted opgeslagen is, dat is allemaal leuk en aardig: maar als het systeem gekraakt wordt dan heeft het natuurlijk nogal weinig nut als de sleuteltjes er gewoon bij zitten. De server kan die terugvinden als je inlogt, dan moet een hacker dat dus ook kunnen zien als hij toegang krijgt tot het Telegram systeem. Dat houdt in dat al die data die je uitwisselt met Telegram (al je contacten, berichten, foto's en video's) naar mijn mening eigenlijk helemaal niet zo veilig opgeslagen staan als ze beweren; en alsmede wat de meeste mensen denken.
Wat ik me dan toch afvraag... Waarom is er eigenlijk gekozen voor een constructie waar de server de decryptie sleutel kent? Wat is er in hemelsnaam het nut van, behalve een stapje minder gebruikers input dat iets meer usability geeft? Waarom zou je zo'n opzet maken, terwijl er een stuk veiligere methodes te bedenken zijn: zelfs binnen een cloud opzet?
Lokaal key management
Want laten we wel zijn: de sleutel kan ook gewoon gebaseerd worden op een wachtwoord dat lokaal een decryptie sleutel genereert.
Dan zou de data encrypted in de cloud staan, maar zonder de encryptie sleutels erbij. Je apparaat, ongeacht het type apparaat, is dan verantwoordelijk voor zowel de encryptie als decryptie van de data, en de servers van Telegram komen daar vervolgens totaal niet meer aan te pas.
Neem even KeypassX als voorbeeld: je hebt een bestand op je server staan, dat is encrypted data. Je kan het downloaden naar welk apparaat dan ook dat KeyPass (of compatible variant) geinstalleerd heeft staan, en vervolgens moet je een wachtwoord intikken die al je wachtwoorden kan decrypten. Het bestand zelf is waardeloos zonder de sleutel! Het staat dus veilig op je server (met een beetje wachtwoord tenminste...), en zelfs als iemand volledige toegang tot je server krijgt kunnen ze er nog geen hol mee. Prima! Waarom wil Telegram dan niet zo'n opzet? Ik bedoel, er wordt zo op gehamerd dat het allemaal heel veilig moet en privacy vriendelijk moet zijn en blabla: maar op deze manier is de cloud wel een erg zwak punt.
De enige factor is usability... Maar voor een app met al die claims, waarom is usability (gebruiksvriendelijkheid) dan kennelijk belangrijker?
Het is namelijk natuurlijk veel handiger als je enkel je wachtwoord in een client hoeft in te tikken, en vervolgens wordt al je data gedownload inclusief de decryptie key. Joepie, je hebt 5 seconden bespaard. Maar besef je je wel hoeveel je inlevert op de veiligheid van je data...? Zeker met die brakke privacy policy die ze nog altijd hanteren?
Want wat nu als deze data encrypted in de cloud wordt opgeslagen, maar dat die encryptie plaatsvindt op basis van de sleutel die je opgeeft in de client, en die dus nooit met de servers wordt gecommuniceerd? Die client is open-source, dus waarom niet? Dan kan je namelijk ook checken of het wel werkelijk op die manier encrypt wordt en of die sleutel inderdaad niet met de server wordt uitgewisseld.
Het enige probleem is dat voor de hoogste veiligheid, deze data enkel decrypt moet kunnen worden met een ander wachtwoord (anders dan waarmee je inlogt) dat je enkel lokaal ingeeft en dat nooit en te nimmer wordt uitgewisseld met de Telegram cloud. Telegram kent die sleutel niet, slaat deze dus ook niet op: en derhalve is de veiligheid veel hoger en heb je een veel hogere mate van garantie dat je data werkelijk veilig is en niet wordt doorverkocht. (Want ze mogen je data doorverkopen bij Telegram.)
Telegram servers gehacked? Boeie, m'n data is veilig!
Telegram lekt de sleutels? Nee dat kan dan dus niet meer, want die hebben ze dan niet eens.
Telegram heeft een brakke privacy policy? Geeft niet, want ze kunnen m'n data toch niet inzien. (Op groupchats na.)
Maar wat is dan nu het probleem...? Nouja, je moet dus 2x een wachtwoord ingeven.
1x om in te loggen naar Telegram en je daar te authenticeren en al je data binnen te halen, en nog een wachtwoord om deze data vervolgens te decrypten.
Dit wachtwoord moet je op elke client die je instelt intikken. Dat is een extra stap. Weliswaar een extra stap die naar mijn idee een stuk hogere mate van veiligheid geeft, maar het is en blijft een extra stap.
Je krijgt twee wachtwoord prompts in plaats van slechts 1... Oh noes! Uiteraard hoef je die tweede prompt, voor het encrypten/decrypten, maar een keer in te vullen: daarna wordt de sleutel lokaal opgeslagen.
Bijkomend probleem is dat als je dat wachtwoord wilt wijzigen: dan moet de data geheel opnieuw decrypt worden en moeten alle apparaten dat nieuwe wachtwoord ook krijgen (en opnieuw de data downloaden). Opzich geen ramp, maar niet 100% gebruiksvriendelijk. (Maar wat wil je nou liever...?)
Toch is het maar een zeer kleine extra moeite, en dus enkel een probleem als je je wachtwoord wilt wijzigen van de encryptie: dan moet je overal "opnieuw inloggen". (Maar dat moet ook bij een normale password change, dus waar hebben we het over?)
Is een opzet als deze niet veel veiliger, dan een server die data voor je encrypt en vervolgens de decryptie sleutels lokaal opslaat voor distributie naar de clients waarmee je inlogt...?
End-to-end encryptie buiten secret chats
Een bijkomend voordeel van deze opzet, en nogmaals: dit zijn gewoon even snelle gedachten; ik heb dit nog niet helemaal 100% uitgezocht en ik schrijf nu gewoon 1 op 1 m'n gedachten even op over hoe ik deze situatie benader, lijkt mij dat Telegram dan standaard end-to-end encryptie kan toepassen.
Sterker nog: het zal dit zelfs toe *MOETEN* passen om werkelijk veiligheid te bieden. Win-win!
Nu is dat niet mogelijk omdat de server alle data unencrypted wil hebben om door te sturen en op te slaan (en dan pas wordt het encrypt), maar als de data toch al op de apparaten zelf wordt encrypt/decrypt: dan is die stap niet meer noodzakelijk. Dan kan end-to-end encryptie standaard ingeschakeld worden, immers stuurt je apparaat het bericht dan end-to-end encrypted naar de ontvanger, maar tegelijkertijd encrypt aan de hand van je wachtwoordzin je apparaat het bericht dat je zojuist verstuurd hebt en stuurt *dat* naar de Telegram cloud toe... Zo krijgen alsnog al je apparaten dat bericht binnen, en wordt het alsnog opgeslagen in de cloud waardoor je apparaten zo alle historie kunnen binnenhalen: maar de Telegram server kan er niet meer bij en kan niet meer meelezen. (Als ze iets anders gaan gebruiken dan dat verrotte protocol van ze tenminste.) Je hebt dus exact dezelfde functionaliteit met de cloud opslag en alles: maar de berichten zijn nu wel end-to-end encrypted!
En dat is ook noodzakelijk, anders heeft die hele lokale encryptie weinig nut. Ja het beschermt je tegen een hack van de Telegram servers, maar daar is dan ook meteen alles mee gezegd: meer veiligheid heb je niet.
Als het bericht alsnog client>server->server>client wordt uitgewisseld, dan zou Telegram alsnog constant kunnen aftappen en zelfs kopietjes maken, dus weet je nog steeds niets zeker...
En waarom *MOET* je dan wel end-to-end encrypten, eigenlijk?
Nou, dat is nogal simpel. Enkel jij hebt je encryptie/decryptie sleutel. Als je die data dus encrypted naar Telegram verstuurd, dan kan de ontvanger hier helemaal geen ene hol mee: die krijgt enkel wat leipe tekentjes te zien, maar je bericht? Dat is onleesbaar, hij kent immers je sleutel niet. De Telegram server kan het namelijk ook niet decrypten (tenzij je het alsnog unencrypt (doch wel via MProto client-server beveiligde verbinding) naar de server stuurt, maar we willen juist zorgen dat die server je data niet kan zien, terwijl het toch een cloud systeem blijft...).
En nu willen we dus dat:
- Telegram nooit mee kan lezen, ook niet met de data die je op hun cloud infrastructuur opslaat
- Je ontvangers de berichten wel kan lezen, zonder dat hij de sleutel hoeft te kennen waar al je data mee wordt encrypt/decrypt
Met end-to-end encryptie en de encryptie op de data die ik omschreef los je dit allemaal in 1 klap op, dunkt mij.
1.) De data in de cloud wordt encrypted opgeslagen met een sleutel die enkel jij kent, en de servers van Telegram niet. Die kunnen het dus niet decrypten. Wel zo fijn.
2.) Naast dat je computer het encrypt en de cloud in gooit, stuurt hij het berichtje ook nog eens end-to-end encrypt naar de ontvanger toe. Die hoeft jou sleutel voor de cloud opslag/functionaliteit dus niet te kennen, hij moet enkel de sleutels kennen om de communicatie tussen jullie twee te ontsleutelen!
3.) Hierdoor wordt ook de communicatie in 1 klap een stuk veiliger: mocht de client-server sleutels gestolen worden, dan hebben ze alsnog de end-to-end sleuteltjes niet: en is het pakket dus alsnog onleesbaar!
-- Op deze manier heb je dus op alle fronten een win situatie. Je cloud functies, dus inloggen met meerdere devices, blijft beschikbaar.
Het enige nadeel? Het kost extra dataverkeer... Je moet alles namelijk twee keer versturen... En dat is ff de pest! (Al kan daar omheen gewerkt worden, maar dan wordt m'n post *nog* langer.)
Maar... WhatsappHack... dit is wel leuk en aardig, maar hoe zit dat dan met die meerdere devices en die end-to-end encryptie? Je zegt dat je end-to-end encryptie wil toepassen *en* de data in de cloud wil zetten. Maar als jij end-to-end gaat praten met Pietje via je iPhone, en je stapt over naar je computer (alle berichten zijn te lezen, want die worden uit de cloud opgehaald en decrypt met behulp van je lokale sleutel.): hoe kan die computer dan nog verder praten met Pietje...? Immers kent je computer die end-to-end sleuteltjes toch niet?
Mol jij hier dus potverdikkie en driewerf in de satanische gloria niet gewoon het hele systeem op deze manier, voor die irritante veiligheidsneiging van je?
... Neen. Want je encrypt de data al lokaal met je eigen encryptie sleutel.
Derhalve kan je *ook* de public en private key van dat gesprek VEILIG uitwisselen met je andere devices!
Ja, hoe meer devices je dan hebt: hoe groter het risico dat die sleutels gestolen worden.
... Maar op dit moment heb je helemaal die beveiliging niet, en valt er niet eens iets te jatten: dus ben je in mijn situatie nog altijd veiliger dan nu, niet waar?
Ja maar... En "secret chats" dan...?
Nou, dat heeft nog steeds een doel!
Het schakelt de end-to-end encryptie niet meer in, want die staat standaard al aan, maar als je "secret chats" gebruikt: dan wordt de kopie van het berichtje niet meer naar de cloud gestuurd.
Je secret-chats zijn dus nog steeds geheel secret, maar nu heb je opeens ook end-to-end encryptie in je normale gesprekken zonder dat hier ook maar op enige wijze iets gemold wordt aan je cloud functies en het kunnen inloggen vanaf meerdere devices. Als dat geen win-win is, dan weet ik 't ook niet meer.
Zelfs met hun huidige opzet zou je dit kunnen implementeren... Al verslaat het dan wel een beetje het doel omdat je zelf geen controle meer hebt over je sleutel: en derhalve is het minder betrouwbaar.
Telegram zegt met betrekking tot end-to-end encryptie op normale "cloud chats" zelf het volgende over:
Opmerking: okee, toegegeven, die "server search" functie heb ik niet getest; maar dat zie ik niet als "zo nuttig, dat moet er in blijven!": een zoekfunctie kan namelijk ook prima lokaal op je toestel z'n dienst doen. WhatsApp kan het, dan kan Telegram het ook. Er zit geen voordeel aan de zoekquery op de server uitvoeren in plaats van lokaal. Behalve een paar CPU cycles en wat I/O.Q: Why not just make all chats ‘secret’?
While all Telegram messages are always securely encrypted, messages in Secret Chats use client-client encryption, while cloud chats use client-server/server-client encryption and are stored securely encrypted in the Telegram Cloud (more here). This enables your cloud messages to be both secure and immediately accessible from any of your devices, you can also easily find them using server search — which is very useful at times.
Opmerking2: Wat ze daar zeggen is leuk, maar het legt eigenlijk niet uit *waarom* het niet end-to-end encrypt zou zijn. Je bent al server-client encrypt, dus zelfs in de huidige opzet kan je end-to-end decrypten en alsnog met de cloud babbelen en daar je berichten opslaan. Dat maakt de communicatie an sich nog altijd veiliger dan geen end-to-end encryptie in z'n totaliteit.
Ja, daar kan ik inkomen. Maar gewoon een wachtwoord prompt: daar hoeft nog steeds geen enkele gebruiker precies te weten hoe de security werkt. Het "who understand nothing about security and want none of it" verhaal blijft dus staan, het enige dat wijzigt is dat je twee wachtwoord promptjes hebt bij de eerste keer aanmelden: in plaats van twee. (Dat wachtwoord wordt vervolgens lokaal bewaard natuurlijk, aldanniet reeds in decrypt hash vorm. Hij wordt *NOOIT* met de server uitgewisseld! De open-source client moet daar zorg voor dragen.) Ik vind dit dus GEEN overtuigende reden om het niet te doen... Of op z'n minst om het totaal niet eens aan te bieden.The idea behind Telegram is to bring something more secure to the masses, who understand nothing about security and want none of it. Being merely secure is not enough to achieve this — you also need to be fast, powerful and user friendly. This allows Telegram to be widely adopted in broad circles, not just by activists and dissidents, so that the simple fact of using Telegram does not mark users as targets for heightened surveillance in certain countries.
Afsluitend
Het leek mij een simpele doch zeer doeltreffende oplossing, waarmee alle functies behouden blijven; je hebt enkel 1 stap extra: het wachtwoord om te decrypten is lokaal, en dien je dus apart in te voeren. Dat is het enige... 1 lullige stap van 1 a 2 seconden extra, en je hebt zo enorm veel extra veiligheid!
Het enige probleem is als je je wachtwoord kwijt raakt... Ja, dan ben je de lul. En die kan je niet resetten.
... Maar hebben ze daar nou niet toevallig password managers voor uitgevonden?
Dat is werkelijk het enige probleem met deze opzet. Het valt en staat ermee dat de gebruiker zijn de/encryptie wachtwoord onthoudt.
Maarja, hebben we dat niet met veel meer diensten? Is dat een probleem? Is het een grote ramp? Voor de meeste mensen niet waarschijnlijk, het is alleen klote dat je dan je oude berichten en foto's niet meer kan inzien.
Maar daar tegenover staat dat als je netjes je wachtwoord onthoudt: je veel en *veel* meer beveiliging hebt dan nu.
Voor een app die claimt zichzelf extreem op privacy en veiligheid te willen focussen, snap ik niet waarom Telegram niet zo'n oplossing heeft ingezet.
Ze moeten toch weten dat hoe het nu werkt, het eigenlijk niet veilig is: maar dat ze het veel veiliger kunnen maken met een paar simpele tussenoplossingen?
... But then again: ik heb er nog niet 100% over nagedacht en nagekeken of ik niet iets over het hoofd zie of iets heb gemist in de technische specificaties van hun huidige systeem. Misschien zit ik wel mis en kan mijn oplossing niet eens geimplementeerd worden. Misschien zit er in mijn oplossing zelf zelfs een enorme redeneerfout en is het even makkelijk te hacken... Wie weet... Maar dat zie ik morgen wel!
Wat ik wel weet is dat dit in ieder geval niet voor groepschats gaat werken, althans: het end-to-end gedeelte niet. De opslag wel.
Ik ben benieuwd wat jullie van een opzet als dit vinden, en wat jullie gedachten er over zijn.
Ik denk niet dat Telegram dit ooit gaat implementeren trouwens, maar ik vond het wel een grappig ideetje.
Het enige nadeel dat ik er in kan vinden is dat het bandbreedte gebruik verdubbelt voor je normale chats...
Dat is voor sommige mensen wel een behoorlijk nadeel natuurlijk, maarja... Hoeveel gebruikt die app nou werkelijk? Ik geloof dat WhatsApp, inclusief plaatjes en videos, bij mij gemiddeld 50 tot 60MB per maand opslurpt voor duizenden berichten. Is 100 tot 120MB dan werkelijk zo'n ramp als het je veiligheid enorm vergroot...?
En ik heb het nu wel over Telegram, want door die discussie begon ik er weer eens over na te denken, maar het kan natuurlijk op meerdere cloud diensten van toepassing zijn. (Sommigen doen dit mischien ook al?
Het zal me benieuwen!
Zo. Iedereen die het helemaal gelezen heeft: hartelijk dank.
Ik hoop niet dat het al te onsamenhangend was en dat ik duidelijk heb uitgelegd wat ik precies bedoel.
En nogmaals: ik heb deze post niet helemaal goed doordacht, ik heb het geschreven terwijl ik al 36 uur wakker ben (en over een uurtje kan ik eindelijk gaan slapen!): dus als ik iets finaal over het hoofd heb gezien/een grove fout heb gemaakt in m'n redenatie: kijk me er niet al te boos op aan, 'mkay?
Het is een ruwe schets van een idee, geen uitgewerkt plan. Het is meer discussie voer dan een onderzoek, en heb meer tijd besteed aan het uittypen/uitleggen van m'n idee dan aan het idee zelf wat slechts enkele minuten in beslag nam.
Thanks!
[ Voor 3% gewijzigd door WhatsappHack op 19-08-2015 07:21 ]
Geen quote of mention @WhatsappHack? Dan niet raar opkijken als je geen reactie krijgt. ;)