skip to main | skip to sidebar
34 commenti

Telegram tiene i messaggi in chiaro? I tweet degli esperti

Questo articolo vi arriva gratuitamente e senza pubblicità grazie alle donazioni dei lettori. Se vi piace, potete incoraggiarmi a scrivere ancora (anche con un microabbonamento).

Telegram è indicata da molti come un’applicazione di chat molto sicura. Ma oggi nel mio flusso di tweet ho notato questo scambio:

tqbf
By default Telegram stores the PLAINTEXT of EVERY MESSAGE every user has ever sent or received on THEIR SERVER.
19/12/15 05:15

Un’accusa piuttosto pesante: i messaggi sarebbero custoditi in chiaro sui server di Telegram. Qualcuno chiede prove, e la risposta è questa: un link alla documentazione interna dell’app.

moxie
@sc0p3r It's just how Telegram works and is self-documented to work: https://t.co/GMD3mryXoN Only their marketing copy suggests otherwise.
19/12/15 15:24

A questo punto interviene nientemeno che Pavel Durov, fondatore ed ex CEO di Telegram, smentendo tutto:

durov
@tqbf This is false: @telegram never stores plaintext of messages, and deleted messages are erased forever. Do you get paid for posting BS?
19/12/15 17:49

Già così la cosa si fa interessante, ma poi arriva Edward Snowden:

Snowden
I respect @durov, but Ptacek is right: @telegram's defaults are dangerous. Without a major update, it's unsafe. https://t.co/pbBt2rHr5x
19/12/15 18:53


Snowden
To be clear, what matters is that the plaintext of messages is *accessible* to the server (or service provider), not whether it's "stored."
19/12/15 19:03

Mi piacerebbe saperne di più, per cui chiedo agli esperti che leggono questo blog di contribuire con i propri commenti, ma di certo sentir dire da Snowden che Telegram è insicuro dev’essere una mazzata notevole.

Il thread della discussione citata qui sopra prosegue su Twitter qui.

Andrea Draghetti mi segnala che ci sono dettagli su Zimperium.com su come Telegram salvi in chiaro i messaggi sul dispositivo dell’utente.
Invia un commento
I commenti non appaiono subito, devono essere tutti approvati da un moderatore. Lo so, è scomodo, ma è necessario per tenere lontani scocciatori, spammer, troll e stupidi: siate civili e verrete pubblicati qualunque sia la vostra opinione; gli incivili di qualsiasi orientamento non verranno pubblicati, se non per mostrare il loro squallore.
Inviando un commento date il vostro consenso alla sua pubblicazione, qui o altrove.
Maggiori informazioni riguardanti regole e utilizzo dei commenti sono reperibili nella sezione apposita.
NOTA BENE. L'area sottostante per l'invio dei commenti non è contenuta in questa pagina ma è un iframe, cioè una finestra su una pagina di Blogger esterna a questo blog. Ciò significa che dovete assicurarvi che non venga bloccata da estensioni del vostro browser (tipo quelle che eliminano le pubblicità) e/o da altri programmi di protezione antimalware (tipo Kaspersky). Inoltre è necessario che sia permesso accettare i cookie da terze parti (informativa sulla privacy a riguardo).
Commenti
Commenti (34)
Snowden dice: To be clear, what matters is that the plaintext of messages is *accessible* to the server (or service provider), not whether it's "stored."

Traduco: nelle chat segrete la cifratura è end-to-end che vuol dire che nessuno al di fuori dei due dispositivi, può decifrare i messaggi in transito... nemmeno i server di telegram. Nelle chat normali, il server fa da intermediario quindi tecnicamente deve esserci un certo grado di fiducia perchè si introduce una terza parte (il server) nel processo di cifratura.
Questo non vuol dire che il server tiene i messaggi in chiaro. Snowden sottolinea che per le chat normali questo è una vulnerabilità perchè il server tiene i messaggi cifrati ma li può aprire.

per i comuni mortali vuol dire: se devi parlare del più e del meno usa le chat normali, nessuno al di fuori di te, il tuo amico/amici (e telegram per i paranoici) potrà mai leggerle; se devi condividere il numero della carta di credito o simili usa una chat segreta, nessuno a parte te e il tuo amico potrà mai leggere il contenuto dei messaggi in transito nemmeno telegram stesso.

Per Snowden l'ideale sarebbe avere SOLO cifratura end-to-end per considerarlo "safe".

Poi per cose più precise bisogna fare studi approfonditi, non basta leggere il sito di telegram.
l'attacco presentato su Zimperium vale sia per i messaggi "cloud" che per quelli end2end.
Ma mi sembra diverso da quanto detto su twitter. Lì la preoccupazione era: cosa fa Telegram se riceve la richiesta di un'agenzia governativa? Se i messaggi sono crittati sui loro server non ci sono problemi, se invece sono accessibili non è diverso dalla chat di google, facebook o altri.
Io rimango dell"opinione che ssh+talk sul mio linux sia la soluzione più sicura.
Sarà che sono anziano...
L'ho già scritto su Twitter ma lo riporto anche qui: conta poco se i messaggi sono salvati criptati sul loro server, quello che conta è se il server ha possibilità di decriptarli (i.e. se possiede la chiave). Telegram salva tutti i messaggi dell'utente (a parte, sembra, le chat segrete, che comunque sono criptate end-to-end), e si può leggere tutta la cronologia collegandosi da un qualsiasi dispositivo: questo comporta necessariamente che il server abbia la possibilità di ottenere il testo decriptato. Supponiamo per assurdo che il server non conosca la chiave per decriptare i messaggi: in questo caso per accedere ai dati da un dispositivo mai usato sarebbe prima necessario copiarci sopra manualmente la chiave contenuta nel nostro precedente device, visto che senza di essa dal server potrebbe uscire solo una sequenza indecifrabile di dati.
Le affermazioni di Durov sono magari tecnicamente corrette (i messaggi sono criptati sul server) ma nella pratica scorrette (un lucchetto con la chiave infilata non aiuta molto la sicurezza). Inoltre, nonostante la grande enfasi posta sulla presunta sicurezza di Telegram, ad oggi ci sono grossi dubbi sulla bontà del protocollo crittografico usato, che è stato inspiegabilmente creato ad-hoc ignorando le alternative esistenti e che per questo non è stato adeguatamente studiato dalla comunità scientifica. I pochi studi esistenti sono comunque piuttosto critici delle scelte fatte, e giusto poco tempo fa una tesi di laurea ha messo in luce diverse falle di sicurezza: http://cs.au.dk/~jakjak/master-thesis.pdf
Imho se hai bisogno di segretezza affidarsi a un app di larga diffusione solo perché si vende come sicura (per carità, magari lo è, ma magari hanno già trovato il modo di aggirare le sue protezioni; stesso discorso si può fare per Tor) è un po' scemo, se hai bisogno di segretezza devi usare dei sistemi che si faccia perfino fatica a sospettare che vengano usati per comunicare qualcosa... E devi inventarteli te. Altrimenti vai in fiducia, e se hai assoluto bisogno di segretezza se vai in fiducia sei un po' tardo, come dicevo prima.
@Fx quindi chi usa HTTPS per fare un bonifico online è tardo?
No, l'articolo dice chiaramente che i messaggi sono criptati sul server e inaccessibili, il problema è che il client è insicuro, memorizzandoli in chiaro.

L'affermazione originale è errata, ma giustamente se il server può decriptarli il discorso della sicurezza salta. Sì, solo ent-to-end la sicurezza è buona.

Per l'articolo che Paolo riporta invece....dilettanti allo sbaraglio....
1) Che il messaggio in memoria sia decriptato è _OVVIO_. Ad un certo momento è così per forza di cose visto che quel messaggio lo si sta mostrando! Da qualche parte nell'app ci sarà label.setText(testo) e testo conterrà il testo in chiaro. Una cosa banale, ovvia e inevitabile. Basta sapere come funzionano le UI.
2) Più interessante il discorso del database che mantiene il testo in chiaro. Ad una prima occhiata pare una falla, ma forse bisogna capire qual è la funzione ela scelta della cifratura end-to-end
La cifratura end-to-end su telegram nel caso serve per evitare un attacco sul canale di cifratura! Essendo la chiave di cifratura memorizzata in chiaro da qualche parte (viene richiesta ad ogni apertura della chat? No, quindi...) non ha alcun senso effettuare lo store dei messaggi criptati! Perché la chiave sarebbe comunque vicino al lucchetto!!!
Infine c'è da dire una cosa: se uno ha accesso fisico al dispositivo beh.......ha anche accesso alla chiave di criptazione, quindi di che stiamo a parlare?
Perchè dovrei usare Telegram o un qualunque altro tool "giurin-giuretta saremo bravi con i tuoi dati, quindi dàcceli"... quando esiste Signal Private Messenger (https://whispersystems.org/), che è peer-reviewed e *davvero* end-to-end encrypted?
Il postulato zero della security dice:
E' impossibile offrire sicurezza senza perdere in usabilità.

La sicurezza è vera sicurezza solo quando DA' FASTIDIO, ovvero ti fa gestire dei PIN, delle password, ti forza a passare "a mano" un certo file da un dispositivo all'altro, etc. Il problema è che a molti utenti non interessa la sicurezza, ma piuttosto la sensazione di sicurezza. E' per questo che le soluzioni "lucchetto con chiave infilata" alla Telegram hanno da sempre un certo successo.



@Unknown
Dal sito di Signal Private Messenger leggo:
> Use your existing phone number and address book. There are no separate logins, usernames, passwords, or PINs to manage or lose.
Questo viola il postulato zero, quindi mi dà la CERTEZZA che Signal Private Messenger NON sia sicuro. Quantomeno, non dicono chiaramente a cosa devo rinunciare per ottenere sicurezza.
@Heavymachinegun:

non conosco come funzionano né Telegram né Signal Private Messenger, ma basta che ciò a cui rinunciare sia la possibilità di accedere ai messaggi pregressi da un altro dispositivo, e il tutto torna a funzionare. L'app genera tacitamente una chiave privata all'installazione, da la pubblica a chi mi deve scrivere, una volta persa la privata sono persi i messaggi.

Concordo con Slash, anche secondo me se è possibile sincronizzare il pregresso in assenza di altri requisiti, allora il server ha accesso alle chiavi private e quindi a tutto, e questa è la pistola fumante.
Potrebbe essere diverso se è il mio vecchio dispositivo (che quindi deve essere acceso e reperibile) a passare la mia chiave privata al nuovo (anche automaticamente) e permettergli di sincronizzarsi, ma non so se ci sia questo requisito.

Per quanto riguarda il tweet oggetto dell'articolo non sono sicuro che l'esistenza di un API per leggere i messaggi implichi che questa API funzioni per tutti i messaggi, e non solo per quelli che sono notoriamente in chiaro (mi pare di aver letto che per le chat di gruppo questo è già noto).

Infine, riguardo l'articolo di Zimperium, come dice lufo88 è ovvio che se ho accesso, soprattutto se di root, a un dispositivo in grado di leggere i messaggi, allora posso leggere i messaggi, stiamo scoprendo l'acqua calda.
eLBati: stiamo parlando di tutt'altro contesto, qualcosa del tipo "sono un dissidente in uno stato oppressivo che ha grandi risorse per intercettare le mie comunicazioni" (questa la teoria, la pratica è "voglio vedere delle immagini pedopornografiche" "voglio comprare droga online" "ho un'organizzazione terroristica e vorrei fare il gruppo di Whatsapp ma non posso", tant'è che io sono fortemente contrario ai sistemi di cifratura più robusti di quanto un'organizzazione governativa possa intercettare perché per l'alibi di tutelare quell'uno su cento si fa ponti d'oro a quei 99 su cento che usano la cifratura per scopi illeciti), cose di ben altra importanza rispetto al banking online, per il quale l'HTTPS è un compromesso adeguato.
Ho letto il link di zimperium, ma mi domando una cosa: davvero è possibile fare in modo che il database contenga message criptati E evitare che il messaggio che appare sullo schermo possa essere nascosto da un dump della memoria del dispositivo?

Da quello che mi risulta, mi sembra impossibile ...
Parole sante quelle di FX e vorrei che tutti facessimo su queste una breve riflessione...
@Tukler
In realtà i danni all'usabilità sono maggiori. Cito da Wikipedia:

Signal has built-in mechanisms for verifying that no man-in-the-middle attack has occurred. For calls, Signal displays two words on the screen. If the words match on both ends of the call, the call is secure. For messages, Signal users can compare key fingerprints (or scan QR codes) out-of-band.

Quindi Signal Private Messanger è sicuro MA ANCHE significativamente meno usabile, cosa che si guardano bene dal dire esplicitamente nel sito.
Comunque visto che stiamo parlando di app di messaging telefoniche, il telefono E' esso stesso la chiave.

Se lo cripti con la funzione di sistema di crittografia dispositivo, non ci installi NIENTE che non sia Telegram(*), lo proteggi con un pin o meglio con una password di una discreta complessità e non lo lasci MAI incustodito, stai tranquillo che sei ragionevolmente sicuro che dal tuo terminale al server E sul server stesso il messaggio sia criptato. E' ovvio che il messaggio sia in chiaro nella memoria (RAM) del telefono, un po' meno ovvio che lo stesso sia, in chiaro, nella cache del dispositivo (perché banalmente la cache è teoricamente leggibile da remoto se hai i permessi giusti). Ma in questo caso devi partire dal presupposto che il telefono sia stato compromesso da un malware e quindi decadono tutti i ragionamenti precedenti. Già perché se posso leggere la cache presumibilmente posso leggere pure la RAM.

(*) anzi a quel punto ti conviene comprare un telefono qualsiasi, flashargli dentro una ROM AOSP da cui hai tolto TUTTO quello che non sai cosa fa, disabilitare tutto il disabilitabile (niente GPS, niente Wifi) e *forse* puoi dirti ragionevolmente sicuro. Anzi meglio ancora, non usare affatto il telefono.

Non è che sia esperto, magari dico cavolate, sto cercando di usare la logica.
@Heavymachinegun: hai troppe certezze, che -paradossalmente- basi a tua volta sulle tue "sensazioni di sicurezza" ("ho tanti PIN uno dopo l'altro, belli scomodi, quindi sto al sicuro"). A volte non è così.

L'e2e di Signal è basato su una chiave (simmetrica) conosciuta strettamente solo dalla coppia di peer che comunicano.
Se reinstalli su un nuovo smartphone, l'unico modo di recuperare i vecchi messaggi è export+reimport (sì, ecco un po' di "scomodità"). Al momento, piuttosto, il problema è che non c'è un modo friendly, afaik, di "importare" la vecchia identità sul nuovo terminale, e tutti i destinatari vedranno, al primo msg proveniente da te, il warning di "identità non verificata".

Un sistema di comunicazione sicura e usabile che garantisca tecnicamente ai suoi utenti che chi lo gestisce non possa accedere al cleartext dei messaggi e dell'indirizzario ha un design intrinsecamente *molto complesso*, che richiede molta "motivazione progettuale". Telegram ha un genesi pregevole, ma a quanto vedo non si è mai spinto fin qui...
Telegram sui server ha tutto criptato, chiave pubblica compresa (con AES). Ogni nuovo dispositivo che si collega viene convalidato tramite un'integrazione (codice) col primo dispositivo configurato in modo da consentire la decriptazione AES della chiave pubblica (lato server la chiave pubblica può solo essere letta forzando l'algoritmo AES).

Tutto questo fa parte del loro sistema MTProto che è ben conosciuto e verificabile, data la natura open-source del client (dove avviene tutta la logica del sistema, la parte server alla fine è solo un tramite di trasporto cloud centrico), e se qualcuno fosse stato in grado di violare tale sistema immagino che avrebbe già reclamato i 300.000$ messi in palio dai Durov... mentre il gruzzoletto è ancora lì in attesa di un beneficiario...

Tutti quelli che affermano che l'MTProto non sia sicuro dovrebbero dimostrarlo concretamente e fiondarsi sui 300.000$ in palio... non credo che facciano schifo ad alcuno...

Ogni sistema di criptazione parte dal presupposto che i dispositivi finali non siano violati, non esiste nulla che possa proteggerci se si ha accesso fisico ai nostri di dispositivi, da qualche parte è ovvio che i msg venga decriptati... io comunque nella cartella del client desktop "portable" di accessibile non ho trovato nulla.
@Unknown
>> hai troppe certezze, che -paradossalmente- basi a tua volta sulle tue "sensazioni di sicurezza" ("ho tanti PIN uno dopo l'altro, belli scomodi, quindi sto al sicuro"). A volte non è così.

Ma io non ho detto questo. Ho detto semplicemente che i servizi che pubblicizzano sicurezza ai quattro venti ma poi non sono più noiosi da utilizzare hanno tutti il trucco. La sicurezza è illusoria. E' come per quelli che propongono le macchine-bufale per il moto perpetuo. E' inutile che portino 1000 dettagli di costruzione e 1000 disegni e quintali di technobabble. C'è sempre il trucco. Non ci perdo nemmeno tempo a capire cosa stanno dicendo.

Il problema è che la maggior parte della gente si fissa su quello specchietto per allodole che è la "cifratura sicura". La cifratura sicura non dà nessunissima garanzia. Il problema non è cifrare, quello lo sanno fare tutti. Il problema è NASCONDERE LA CHIAVE. Far sì che la chiave sia disponibile solo a chi la deve avere. Se io chiudo la bicicletta con 10 lucchetti, ma le chiavi le lascio infilate (o nascoste nel portaoggetti, che è la stessa cosa), ho ottenuto sicurezza? Per niente. Eppure molti direbbero di sì, dato che tecnicamente "ho chiuso a chiave la bici con molti lucchetti".
Scusate ma forse bisogna chiedersi quale sia il modello di business dei software citati..ovvero lavorano e manutengono i loro server xke unti dalla benevolenza del nostro signore o forse qualcosa riescono a rivendere dalle info che giriamo loro?
Al di là delle dietrologie:
1) bisogna capire se effettivamente l'utilizzo di quella API dimostra che sui server Telegram i messaggi sono memorizzati in chiaro. Ptacek e Moxie dicono di sì, Durov dice di no. Io non sono così esperto da riuscire a capirlo.
2) Se sono memorizzati in chiaro, sono d'accordo con Ptacek e Moxie: per me e per la privacy in generale, è un problema.
3) Se i messaggi sono criptati e memorizzati sui loro server CON la chiave per decriptarli, regge a pieno il paragone col lucchetto e la chiave inserita. Si ricade nel punto 2.
4) Snowden dice che il problema è l'accessibilità ai messaggi da parte del provider, non lo storage. Non so se questa cosa sia realizzabile poiché, ripeto, non me ne intendo ma l'unico modo che mi viene in mente è quello che il provider tenga i messaggi criptati ma non le chiavi per decriptarli.
5) Gli altri modi che mi vengono in mente sono il "Fidatevi di noi, non possiamo accedervi!" oppure il "non manteniamo i vostri messaggi sui server". Nel primo caso, c'è bisogno di una fiducia che non tutti sono disposti a dare, nel secondo caso non si realizzerebbero cloud chat.
@All
Secondo me in molti stanno analizzando la questione in modo errato senza porsi la domanda: qual è l'obiettivo di questo meccanismo di cifratura di telegram?
Per me la risposta è: "evitare che un malintenzionato intercettando il messaggio ne legga il contenuto".
In tal senso la soluzione di telegram è adatta. Il canale rimane sicuro. Bisogna violare il client.
Snowden, infatti, si lamenta che il server possa de-criptare i messaggi, ma non dice nulla sui client.
Criptare i messaggi sul client è un altro paio di maniche ed è normale che fallisca in questo compito, perché non è nato per questo.
Tutto IMHO.

@Edward-san
Il database si può criptare sicuramente, ma ha senso farlo se la chiave per de-criptarlo è memorizzata in chiaro? Secondo me è un passaggio inutile. Per cui o ogni volta si chiede la chiave di decriptazione (che al massimo sarà in RAM, effettuare un dump della RAM bypassa qualunque crittografia di cui abbia sentito parlare) oppure tanto vale non usarla per criptare i dati del db, ma usarla solo per criptare i messaggi in uscita.

Per il discorso di criptare in RAM. Assolutamente sì, si può fare, ma non si deve nemmeno mostrare a schermo la stringa. Prendiamo keepass, software di gestione password. Ti mostra gli utenti, con relative password, che hai memorizzato, ma finché non fai un "copia" o non gli chiedi esplicitamente di mostrarle il dato rimane criptato, ma neanche l'utente lo vede. Se a monitor si visualizza qualcosa in RAM ci sarà l'equivalente. Si può rendere la vita più o meno complessa all'attaccante, ma il dato è lì. Un pc non è magico!

@dangerotto
Spiega meglio per cortesia, perché non capisco cosa intendi con "integrare". Ad una chiave pubblica corrisponde solo ed una sola chiave privata. Se non ce l'ho non si va da nessuna parte.
@Fx e @MT
Non condivido il vostro ragionamento sulla privacy. Un'organizzazione criminale troverà sempre un modo di comunicare senza essere intercettata (e.g. frasi in codice) ed è a mio avviso ingenuo pensare che un'eventuale backdoor venga usata dai governi esclusivamente per scopi nobili. Inoltre, anche supponendo che i governi siano composti unicamente da santi incorruttibili, le backdoor hanno il brutto vizio di venire spesso scoperte da malintenzionati che - a quel punto - avrebbero vita facile. Per fare un esempio pratico, se i conti correnti sono protetti da una cifratura con backdoor per il governo per "tracciare le finanze dei terroristi" e questa backdoor cade in mano di un ladro, probabilmente possiamo dire ciao ai risparmi di tutta la gente che pensava di essere protetta e invece non lo era.
Mi permetto anche di consigliare un interessante talk, a mio avviso condivisibile, sui motivi per cui la privacy dovrebbe essere garantita anche a chi "non ha niente da nascondere":
http://www.ted.com/talks/glenn_greenwald_why_privacy_matters
(scusate il doppio commento, c'è un limite di caratteri e io sono prolisso)

@Dangerotto
Il problema del protocollo MTProto è proprio il non essere "ben conosciuto e verificabile", in quanto inventato per l'occasione dagli sviluppatori di Telegram. Nelle FAQ sul sito ufficiale si trovano proprio diversi punti che spiegano le motivazioni (IMHO abbastanza fumose) per cui si è scelto di creare un nuovo protocollo anziché affidarsi a quelli già conosciuti e testati.
Inoltre, secondo diversi esperti del settore, il motivo per cui ancora nessuno ha "bucato" il protocollo (e reclamato i 300000 $) è dovuto a due fattori: 1) i pochi studi effettuati e 2) le regole restrittive del contest. Cercando un po' si trova una lunga spiegazione di come le regole sono estremamente restrittive [1], un elenco di cattive idee in parte superate, in parte ancora presenti in MTProto [2], un esempio di protocollo estremamente vulnerabile che con le stesse regole del contest di Telegram risulta inviolabile [3].
Riguardo ai dati criptati sui server: le operazioni da te descritte non trovano riscontro nel protocollo di Telegram così come descritto dal loro stesso sito [4]. L'idea è che ci sia un segreto condiviso tra server e client (generato tramite Diffie-Hellman [5]) che, indirettamente, funge da chiave per la criptare/decriptare la comunicazione tra client e server. Dico chiave (singolare) in quanto AES [6] è un algoritmo di crittografia simmetrico, ovvero in cui la stessa chiave viene usata per cifrare e decifrare i dati; è quindi ovvio che entrambe le parti (client e server) possono leggere i contenuti dei messaggi scambiati. Il flusso di dati nell'invio di un messaggio tra Alice e Bob sarebbe quindi (a grandi linee): Alice cripta il messaggio M da inviare con la chiave AES KA concordata con il server e invia il messaggio codificato CA ottenuto; il server decripta CA con KA e ottiene il messaggio M originale, che viene criptato con la chiave AES KB concordata con Bob ottenendo il messaggio CB, che viene spedito; Bob decripta CB con KB ottenendo il messaggio originale M. In un contesto del genere il server può decidere di salvare M in chiaro, oppure CA codificato con KA oppure CB codificato con KB oppure un messaggio CC codificato con una terza chiave KC, ma il risultato non cambia: il server può sempre decifrare i messaggi. Da notare che un contesto in cui il server non ha possibilità di decifrare i messaggi richiede che KA = KB, ovvero che entrambi i client utilizzino la stessa chiave (eventualmente sconosciuta al server); in questo contesto, purtroppo, le alternative sono 1) usare la stessa chiave per tutti i client, vanificando quindi la riservatezza (buco un client e accedo alle conversazioni di chiunque); oppure 2) sfruttare un metodo sicuro per lo scambio di chiavi iniziale, ottenendo così un sistema con codifica end-to-end. La seconda opzione, per quanto preferibile, richiede una verifica preliminare dell'identità dell'interlocutore fuori banda (vedi: immagini o parole da confrontare, fingerprint da verificare...), in mancanza della quale il server potrebbe effettuare un attacco di tipo man-in-the-middle [7], ovvero far finta di essere Bob parlando con Alice e viceversa, e vanificando quindi il vantaggio della codifica end-to-end.

[1] http://www.cryptofails.com/post/70546720222/telegrams-cryptanalysis-contest
[2] http://unhandledexpression.com/2013/12/17/telegram-stand-back-we-know-maths/
[3] http://thoughtcrime.org/blog/telegram-crypto-challenge/
[4] https://core.telegram.org/techfaq#q-how-does-server-client-encryption-work-in-mtproto
[5] https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange
[6] https://en.wikipedia.org/wiki/Advanced_Encryption_Standard
[7] https://en.wikipedia.org/wiki/Man-in-the-middle_attack
Sono un medico e da tempo sono interessato ad una modalita piu seria di comunicare elettronicamente tra medici e pazienti. Percio alcune punte *tecniche* della discussione che qui leggo mi preoccupano.

In vista di una perfetta crittografia (che tarda ad arrivare anche per gli addetti ai lavori) si cassano i timidi tentativi di migliorare la situazione... Ed intanto avanzano tonnellate di email e di attach medici nelle comuni caselle email colabrodo e commerciali.

Potete per favore indicare a medici e pazienti una via realmente *usabile* e relativamente semplice, che magari non sia il massimo tecnicamente, ma che sia almeno un passo in avanti rispetto alla sciagurata e sguaiata situazione in cui siamo?

Grazie, franco
@Fx:
tant'è che io sono fortemente contrario ai sistemi di cifratura più robusti di quanto un'organizzazione governativa possa intercettare

Quindi la tua proposta è di rendere illegale la matematica?

@lufo88:

Secondo me in molti stanno analizzando la questione in modo errato

No, l'oggetto del tweet originale e quindi dell'articolo è se il server sia in grado di decifrare i messaggi, quindi si discute di quello.

@Dangerotto:

se qualcuno fosse stato in grado di violare tale sistema immagino che avrebbe già reclamato i 300.000$ messi in palio dai Durov

I soldi sono in palio per chi intercetta e decripta messaggi dall'esterno, il fatto che il server sia in grado di decifrarli è un problema diverso.
Hai una fonte che spieghi l'algoritmo in caso di aggiunta di un nuovo dispositivo che riassumi tu?
@Franco:

Io ho realizzato in passato una piattaforma per il ritiro dei referti online (non è specificatamente quello che cerchi, non cerco di vendertela;)), per cui ho qualche ricordo delle direttive del garante della privacy in questione.

In realtà è tollerato anche l'invio dei referti via email, viene specificato che devono essere preferibilmente in forma criptata, ma su richiesta dell'utente si possono persino inviare in chiaro.
Quindi da parte del garante non c'è grande preoccupazione sul mezzo di trasmissione o su quello che può fare il server.
Qui si discute sulla possibilità che i server Telegram siano in grado di leggere i messaggi, ma questa è già quasi una certezza per qualunque provider di email. Questo non rende Telegram meno sicuro dell'email.

In ogni caso, a prescindere dal mezzo, la precauzione più importante è comunque quella di criptare il documento.
Non è necessariamente complicato, basta uno zip o un pdf con password (password per l'apertura, non per la modifica, quest'ultima ha valore nullo), qualunque utente è in grado di aprire questi formati, e se la password non è banale la sicurezza è ottima a prescindere dal mezzo di trasmissione.

Per quanto riguarda la comunicazione della password l'ideale sarebbe che venga scambiata di persona, ma anche l'invio della password tramite Telegram/Whatsapp e l'invio del documento criptato con quella password via email per come la vedo sarebbe un compromesso più che ottimo.
@Franco
> Potete per favore indicare a medici e pazienti una via realmente *usabile* e relativamente semplice, che magari non sia il massimo tecnicamente, ma che sia almeno un passo in avanti rispetto alla sciagurata e sguaiata situazione in cui siamo?

Purtroppo non esiste. Non riesco a dirlo in modo più semplice di così. Ci saranno sempre password da scegliere, PIN da ricordare, dispositivi OTP da tenere nel cassetto, schede con chip da tenere nel portafoglio. Quella che vuoi tu è una soluzione "lucchetto con chiave infilata", quindi Telegram va benissimo. Ti consiglio Telegram.
@Franco
Per la comunicazione medico-paziente un buon sistema è GPG [1], tra l'altro integrabile facilmente con Thunderbird [2]. Il sistema sfrutta come canale di comunicazione le email, senza bisogno di installare software aggiuntivo, aggiungendo però un livello di crittografia per garantire la sicurezza. In particolare, sia il medico che il paziente devono generare una coppia di chiavi (pubblica e privata) prima di poter comunicare, e devono scambiarsi le rispettive chiavi pubbliche. Questa operazione va effettuata una sola volta, e il medico può usare la stessa coppia di chiavi per comunicare con tutti i pazienti. L'idea dell'algoritmo è di cifrare la comunicazione con la chiave pubblica del destinatario, che quindi sarà l'unico a poter decriptare il messaggio con la propria chiave privata. Il mittente, inoltre, può firmare con la propria chiave privata il messaggio inviato, e il destinatario potrà avere conferma dell'identità del mittente verificando la firma con la sua chiave pubblica. Questo sistema è (ad oggi) sicuro, e - tolta la "scocciatura" dello scambio di chiavi iniziale - non presenta grossi problemi di usabilità, in quanto la codifica/decodifica delle informazioni e la verifica delle identità sono gestite automaticamente da un plugin del programma di posta elettronica.

[1] https://en.wikipedia.org/wiki/GNU_Privacy_Guard
[2] https://en.wikipedia.org/wiki/Enigmail
Ho installato Telegram su due dispositivi e fatto qualche prova.

L'ho installato sul dispositivo A autenticandomi col numero di telefono della sim su quel dispositivo (nA) e su un dispositivo B autenticandomi con nB. Ho mandato un messaggio normale da nA a nB, e creato una "chat segreta" tra nA e nB in cui ho scritto un altro messaggio.

Già l'avviso di creazione di una chat segreta (ache se non c'è comunque conferma dell'identità) fa capire tutto: viene spiegato che verranno create delle chiavi per la comunicazione end-to-end e che non ci sarà traccia dei messaggi sul server. Questo fa automaticamente pensare che per i messaggi normali non sia così.

Ho disinstallato Telegram dal dispositivo B, e per sicurezza l'ho riavviato. Con nB offline, ho quindi inviato un messaggio normale da nA a nB, e uno nella chat segreta.
Ho disinstallato Telegram da A, e l'ho reinstallato sempre su A, questa volta però autenticandomi con nB (non ho reinstallato nB su B per evitare che magari le chiavi siano funzione di qualcosa per cui vengano ricreate uguali).

Della chat segreta non c'è più traccia, ma ho ricevuto sia il messaggio normale che avevo inviato a nB mentre era offline, sia persino il pregresso.

Per me questo dimostra che le chat segrete sono presumibilmente tali, ma che il server ha tutto il necessario per decifrare i messaggi normali in ogni momento.
A qualcuno vengono in mente spiegazioni diverse?

Sarei curioso di vedere cosa afferma Telegram per i messaggi normali.
Effettivamente il tweet di Durov riportato nell'articolo è molto ambiguo: come già detto da tutti il fatto che il server abbia solo i messaggi cifrati non significa che non sia in grado di decifrarli, e l'affermazione non petita sul fatto che una volta cancellati non siano più recuperabili sa tanto di spostare il discorso sull'ovvio invece di rispondere in merito.
Grazie Slash per l'analisi e le info
@Tukler

"Per me questo dimostra che le chat segrete sono presumibilmente tali, ma che il server ha tutto il necessario per decifrare i messaggi normali in ogni momento."

Per la prima parte ok, ma perché dimostrerebbe anche la seconda parte?
@tukler
La mia affermazione era relativa all'analisi della questione in essere. Tutta la dimostrazione e la prova che hai effettuato per me è inutile e superflua.
Che il server abbia accesso ai messaggi è deducibile dal semplice fatto che da dispositivi diversi (anche dal pc) posso accedere a tutta la mia cronologia messaggi senza dover inserire alcunché (a meno che la chiave di cifratura non sia il numero di telefono, ma allora non cambia una ceppa perché il numero di telefono è pubblico). Per questo non capisco tutta la sorpresa in merito ai tweet.

Intendiamoci, porre la questione non è sbagliato, né interessarsi alla cosa, tuttavia ritengo che l'intero esercizio sia errato in quanto si vuol dimostrare qualcosa che non è attinente alla funzionalità di telegram.
Per Telegram l'obiettivo è rendere sicura la trasmissione del messaggio, non il suo storage. Quindi fanno bene quelli di telegram a limitare la possibilità di attacco alla sola intercettazione e non alla violazione di client/server. Perché non è quello l'obiettivo di telegram, né lo è mai stato.

In soldoni: sarebbe come dire che le Ferrari fanno schifo perché non possono affrontare i sentieri di montagna. Per forza, non nascono per quello scopo.

Io sono anche d'accordo con snowden, che infatti vorrebbe una crittografia end-to-end e stop. Giustissimo, ma se si rompe lo smartphone niente auto-sincronizzazione dei messaggi :-)
@ Tukler
> Già l'avviso di creazione di una chat segreta (ache se non c'è comunque conferma dell'identità) fa capire tutto: viene spiegato che verranno create delle chiavi per la comunicazione end-to-end e che non ci sarà traccia dei messaggi sul server. Questo fa automaticamente pensare che per i messaggi normali non sia così.

Le domande chiave (scusa il gioco di parole) rimangono aperte. Chi crea le chiavi? Come fa a trasmetterle all'altro peer? L'ipotesi più probabile è che il client crei una coppia di chiavi asimmetriche (una segreta e una pubblica), e che spedisca in chiaro la sua chiave pubblica all'altro peer. Questo sistema è vulnerabile all'uomo-nel-mezzo. In pratica: come faccio a sapere se colui da cui sto ricevendo una chiave pubblica sia proprio tu? Potrebbe essere qualcuno che si spaccia per te.

Un'altra ipotesi è che venga creata una chiave di sessione tramite un protocollo Diffie-Hellman non autenticato. Anche questo sistema è vulnerabile all'uomo-nel-mezzo. Come faccio a sapere che chi sta eseguendo il Diffie-Hellman con me sia proprio tu?

> Per me questo dimostra che le chat segrete sono presumibilmente tali [...]

Per me questo dimostra proprio il contrario! (Scusa, eh.) Se prima avevo dei dubbi riguardo alla segretezza dei messaggi, adesso ho dei dubbi sull'intero protocollo Telegram. Ma davvero nessuno è riuscito a montare un attacco man-in-the-middle contro questo accrocchio? E sai che 300,000 dollari son tantini...
@Heavymachinegun
Gli attacchi man-in-the-middle sono i più pericolosi. Difficile riuscire a farci qualcosa.

@Fx
Mi stavo dimenticando di rispondere. Posto che la percentuale su chi ne abusa non le stai sostenendo con alcun fatto. Anche se fosse? Allora proibiamo tutte le auto, perché ci sono un sacco di p***** al volante. Perdonami, ma il ragionamento non sta in piedi.
Altra cosa: introdurre un limite alla cifratura o inserire una backdoor "di stato" porta ad una sola conseguenza: i malintenzionati approfitteranno delle debolezza del sistema. A tutt'oggi ci sono problemi di sicurezza per i limiti stabiliti anni fa dagli USA per la lunghezza delle chiavi.
Adesso si è scoperto che del codice di ScreenOS (Juniper) conteneva una backdoor che pare sia stata inserita da NSA. Indovina che hanno fatto i governi stranieri appena l'hanno scoperto? L'hanno usata a loro vantaggio.
Come puoi vedere la storia dimostra già che non è strada da percorrere, perché i pessimi risultati si sono già visti.
La storia insegna o almeno dovrebbe.