per capire cosa stia succedendo davvero nel caso della cosiddetta direttiva “Chat Control”, occorre capire bene, e sfatare, un mito nel quale credono tutti. Occorre cioe' capire come funzionano (o meglio, NON funzionano) i cosiddetti sistemi con “Crittazione E2E”, cui tutti attribuiscono poteri immaginifici, ma per come viene implementata, non e' niente di quello che pensate.Prima smontiamo il mito, poi vediamo di capire come si sviluppa tutta la narrativa che circonda questa minchiata.

Normalmente, quando si parla di crittazione end-to-end, o E2E, si intende una situazione nella quale soltanto i dispositivi posti alle due estremità della comunicazione possono leggere il contenuto dei messaggi.

In una conversazione tra due persone, quindi, il vostro client — il cellulare, il programma installato sul computer, e così via — e il client del vostro interlocutore sono gli unici a possedere il materiale crittografico necessario per cifrare e decifrare i messaggi. Soltanto le due end di end-to-end possono leggere ciò che viene scritto. I server attraversati dai messaggi possono trasportarli, conservarli temporaneamente e consegnarli, ma non dovrebbero possedere le chiavi necessarie per comprenderne il contenuto.

A questo punto, però, nasce una domanda abbastanza ovvia: se esistono delle chiavi capaci di leggere i messaggi, per quale motivo qualcuno non potrebbe semplicemente rubarle?

Il punto è che la crittazione end-to-end può essere implementata in modi diversi. Nel campo della messaggistica, i tre schemi più importanti da conoscere sono:

• Off-the-Record Messaging, o OTR, uno dei primi protocolli pensati espressamente per rendere sicure le conversazioni istantanee;
• il Double Ratchet, usato dalla famiglia di protocolli resa popolare da Signal e progettato soprattutto per le conversazioni asincrone tra due interlocutori;
• Messaging Layer Security, o MLS, uno standard più recente, pensato soprattutto per gestire in modo efficiente le conversazioni di gruppo.

In questo articolo partirò dal Double Ratchet, non perché sia l’unico schema possibile, ma perché permette di capire con relativa facilità alcuni dei problemi fondamentali della messaggistica cifrata: come cambiare continuamente le chiavi, come limitare i danni causati dal furto di una chiave e come recuperare sicurezza dopo una compromissione temporane

Una volta chiariti questi concetti, sarà più semplice riconoscere problemi e soluzioni analoghe anche in altri protocolli, come Off-the-Record Messaging, o OTR, e Messaging Layer Security, o MLS.

I tre sistemi non funzionano nello stesso modo e non sono stati progettati esattamente per lo stesso scenario. Tuttavia devono affrontare una parte dello stesso problema generale: impedire che il possesso di una singola chiave trasformi un’intera conversazione, passata e futura, in un archivio leggibile da chiunque riesca a rubarla.

---

Il Double Ratchet cerca di risolvere il problema facendo in modo che le chiavi non rimangano ferme.

Una conversazione cifrata nel modo più semplice potrebbe funzionare così: Alice e Bob si accordano su una chiave, e da quel momento usano quella chiave per cifrare e decifrare tutti i messaggi. Il sistema può anche essere matematicamente solidissimo, ma ha un difetto abbastanza evidente: se qualcuno riesce a rubare quella chiave, può leggere tutto. Può leggere i messaggi futuri e, se ha conservato una copia del traffico precedente, può tornare indietro e leggere anche quelli passati.

Il Double Ratchet parte dall’idea che una chiave tanto importante non debba rimanere in circolazione così a lungo.

Anziché usare sempre la stessa chiave, i due client mantengono una specie di catena crittografica. Ogni volta che viene inviato un messaggio, dalla catena viene ricavata una nuova chiave, usata soltanto per quel messaggio. Subito dopo, il client fa avanzare la catena e cancella, per quanto possibile, la chiave appena utilizzata.

Il meccanismo si chiama ratchet, cioè cricchetto, proprio perché dovrebbe funzionare come un ingranaggio che può avanzare ma non tornare indietro.

Il sistema funziona un po’ come la ruota di una cassaforte che, dopo ogni messaggio, cambia combinazione. La combinazione usata prima viene abbandonata, e quella nuova viene ricavata dallo stato corrente. Il Double Ratchet usa due meccanismi di questo tipo: uno cambia la combinazione a ogni messaggio, l’altro introduce periodicamente nuovo materiale segreto, in modo che anche chi avesse copiato una vecchia combinazione smetta, prima o poi, di poter seguire la conversazione.

Conoscendo lo stato attuale della catena è possibile calcolare il passo successivo, ma non dovrebbe essere possibile ricostruire quelli precedenti. Di conseguenza, chi ruba oggi le chiavi presenti nella memoria del telefono non dovrebbe poter risalire automaticamente alle chiavi usate ieri, purché quelle vecchie siano state davvero cancellate.

Questo è il primo ratchet: quello che fa avanzare la catena delle chiavi a ogni messaggio.

Ma da solo non basta.

Supponiamo che qualcuno riesca a compromettere il telefono di Alice e a copiare lo stato attuale della catena. Anche senza poter leggere il passato, potrebbe continuare a calcolare le chiavi successive e quindi leggere i messaggi futuri.

Per evitare che una singola intrusione condanni per sempre la conversazione, periodicamente Alice e Bob introducono nella catena nuovo materiale segreto, ottenuto attraverso uno scambio crittografico tra i due dispositivi. Quando uno dei due risponde usando una nuova chiave pubblica, entrambi possono ricavare un nuovo segreto e usarlo per avviare nuove catene di invio e ricezione.

Questo è il secondo ratchet.

Il nome Double Ratchet deriva appunto dalla combinazione dei due meccanismi: un cricchetto simmetrico, che produce una nuova chiave per ogni messaggio, e un cricchetto basato su Diffie-Hellman, che introduce periodicamente nuovo materiale segreto nella conversazione. Il primo serve soprattutto a proteggere il passato: rubare una chiave attuale non permette, almeno in teoria, di ricostruire quelle già usate e cancellate.

Ogni volta che dite qualcosa, lo stato crittografico della conversazione avanza. A partire dalla chiave corrente viene derivata una nuova chiave, destinata a un singolo messaggio, mentre quella precedente può essere eliminata.

Le due parti fanno avanzare indipendentemente le proprie catene: quella usata da Alice per inviare corrisponde a quella usata da Bob per ricevere, e viceversa. Quando Bob riceve il messaggio, usa le informazioni contenute nell’intestazione per portare la propria catena allo stesso punto e ricavare la stessa chiave del messaggio.

Se riesce a decifrarlo e a verificarne l’autenticità, significa che i due client hanno seguito correttamente la stessa evoluzione crittografica della conversazione.

Il secondo permette alla conversazione di recuperare sicurezza dopo una compromissione temporanea. Se l’aggressore ha copiato le chiavi in un determinato momento, ma in seguito perde l’accesso al dispositivo, prima o poi Alice e Bob introdurranno un nuovo segreto che l’aggressore non conosce. Da quel momento, le copie rubate in precedenza non saranno più sufficienti per leggere i nuovi messaggi.

Naturalmente, se l’aggressore controlla permanentemente il telefono, legge la memoria, registra la tastiera o vede direttamente lo schermo, nessun movimento delle chiavi può fare miracoli. Il Double Ratchet può guarire da una compromissione conclusa; non può guarire da una compromissione che continua.

C’è però un dettaglio importante: tutto questo descrive una conversazione tra due client.

Non necessariamente tra due esseri umani: tra due precise installazioni del programma, ciascuna con il proprio stato, le proprie catene e le proprie chiavi. Il Double Ratchet, preso da solo, sa gestire il dialogo tra il dispositivo di Alice e quello di Bob. Ma allora come si fa a creare una conversazione con Alice, Bob, Carlo, Daniela e altre cinquanta persone?

E, prima ancora: come si fa quando Alice possiede contemporaneamente un telefono, un tablet, un computer portatile e un computer fisso?

Come si può avere una conversazione di gruppo, oppure usare più di un client, se il Double Ratchet nasce come rapporto crittografico tra due soli dispositivi?

Alla seconda domanda — come si fa ad avere più di un client — bisogna rispondere così: il nuovo dispositivo deve essere autorizzato e inserito tra quelli fidati. Per questo, normalmente, il programma mostra un codice QR, che il nuovo client legge per stabilire un collegamento sicuro con quello già autorizzato e ottenere il materiale necessario a creare le proprie chiavi. Da quel momento, però, i due dispositivi restano distinti: ciascuno mantiene le proprie sessioni e il proprio stato crittografico. Quando arriva un messaggio, il sistema deve quindi cifrarne una copia separata per ogni dispositivo.

Tuttavia, da quel momento, non vedrete voi stessi come due utenti distinti collegati da due dispositivi diversi. L’interfaccia continuerà a mostrarvi come un unico utente. Annotate bene questa cosa: nella conversazione possono essere presenti n client, mentre voi vedete soltanto pochi utenti. Un partecipante visibile potrebbe quindi corrispondere a un telefono, a un computer, a un tablet o a diversi dispositivi contemporaneamente. Questo significa che, a meno che il programma non mostri esplicitamente l’elenco dei dispositivi collegati, non vedete davvero tutti i client che partecipano alla conversazione. Vedete le identità degli utenti, non necessariamente tutte le estremità crittografiche alle quali i messaggi vengono consegnati.

Passiamo allora al caso dei gruppi.

La soluzione più semplice consiste nel fingere che il gruppo non esista.

Supponiamo che Alice scriva in una conversazione con Bob, Carlo e Daniela. Il suo client prende il messaggio e ne produce tre copie: una cifrata per Bob, una per Carlo e una per Daniela. Ciascuna copia viaggia dentro una sessione distinta tra due client, che può usare il proprio Double Ratchet.

Dal punto di vista di Alice esiste un solo gruppo. Dal punto di vista crittografico, invece, esistono numerose conversazioni a due che procedono in parallelo.

E ricordate che stiamo contando i client, non gli utenti. Se Bob possiede un telefono e due computer, Carlo un telefono e Daniela quattro dispositivi, il messaggio di Alice non deve essere cifrato tre volte, ma una volta per ciascun dispositivo autorizzato.

Il sistema funziona, ed è anche relativamente semplice da comprendere. Ma il costo cresce rapidamente: ogni messaggio deve essere cifrato, spedito e gestito molte volte. In un gruppo grande, con utenti che possiedono più dispositivi, il numero reale delle destinazioni può essere molto superiore al numero dei nomi mostrati sullo schermo.

Per evitare questa moltiplicazione, alcuni sistemi usano una chiave del mittente. Alice distribuisce in modo sicuro una propria chiave agli altri membri del gruppo, usando le sessioni individuali già esistenti. Dopo questa distribuzione iniziale, può cifrare il messaggio una sola volta, e tutti i membri autorizzati possono decifrarlo.

Ogni mittente mantiene la propria catena di chiavi: Alice ne possiede una, Bob un’altra, Carlo un’altra ancora. Quando Alice scrive, fa avanzare la propria catena e produce una nuova chiave per il messaggio successivo.

Ma questa soluzione introduce un altro problema. Quando una persona entra nel gruppo, esce dal gruppo oppure aggiunge un nuovo dispositivo, bisogna stabilire quali chiavi debba ricevere e quali non debba più conoscere.

Se Daniela viene espulsa, non basta rimuovere il suo nome dall’interfaccia. Occorre cambiare il materiale crittografico usato dal gruppo, altrimenti il suo client potrebbe continuare a leggere i messaggi futuri.

E se un nuovo dispositivo viene aggiunto all’account di Bob, bisogna decidere chi lo autorizza, quali chiavi riceve e da quale momento può leggere la conversazione.

A questo punto il problema non è più soltanto cifrare un messaggio. Il problema è mantenere una rappresentazione crittografica aggiornata di chi appartiene al gruppo, con quali dispositivi e da quale momento.

Ed è qui che entra in gioco Sesame.

Sesame non sostituisce il Double Ratchet. Serve a gestire molte sessioni Double Ratchet contemporaneamente, soprattutto quando ogni utente possiede più dispositivi e può collegarne di nuovi nel tempo.

Per Sesame, infatti, Bob non è una singola estremità crittografica. Bob può essere il telefono, il portatile, il computer dell’ufficio e un vecchio tablet dimenticato in un cassetto. Ciascuno di questi dispositivi può avere una propria sessione separata con ciascuno dei dispositivi di Alice.

Quando Alice manda un messaggio a Bob, il sistema deve quindi conoscere l’elenco dei dispositivi attribuiti a Bob e consegnare una copia cifrata a ognuno di essi. Sesame si occupa di creare, conservare, sostituire e chiudere queste sessioni, anche quando i dispositivi sono temporaneamente offline.

Ma nell’interfaccia Alice continua a vedere soltanto Bob.

E in un gruppo continua a vedere Alice, Bob, Carlo e Daniela, non necessariamente tutti i telefoni, i tablet e i computer che ricevono davvero i messaggi.

Questo è il punto da annotare bene: l’elenco dei membri del gruppo e l’elenco delle estremità crittografiche non sono la stessa cosa.

Un gruppo che mostra dieci utenti potrebbe distribuire ogni messaggio a venti, trenta o cinquanta client. Alcuni programmi permettono di ispezionare separatamente i dispositivi associati a ciascun contatto; altri rendono questa informazione poco visibile o la mostrano soltanto quando cambia una chiave.

Di conseguenza, guardando il semplice elenco dei partecipanti, non vedete davvero tutte le macchine che fanno parte della conversazione. Vedete le identità logiche alle quali quelle macchine sono attribuite. E questo significa anche che la sicurezza del gruppo dipende da dispositivi che gli altri partecipanti potrebbero non aver mai visto, né sapere che esistono.

---

La domanda che vi pongo ora è questa: che cosa succede se nel gruppo esiste un’identità che non vi viene mostrata come partecipante, ma viene nascosta facendola apparire come un semplice dispositivo appartenente a qualcun altro? La risposta è: dal vostro punto di vista, non succede nulla.

Supponiamo che nel gruppo esista un’estremità crittografica chiamata “sbir” — nome scelto del tutto casualmente, senza voler suggerire governi, polizie o altre istituzioni particolarmente curiose. Se il vostro client non vi mostra il dispositivo sbir, voi non saprete mai che esiste. Continuerete a vedere Alice, Bob e Carlo, mentre i messaggi vengono cifrati e consegnati anche a una quarta estremità crittografica.

La crittografia, da sola, non può avvertirvi. Dal suo punto di vista, sbir è semplicemente un altro dispositivo autorizzato, dotato delle chiavi necessarie per ricevere i messaggi.

Il problema, quindi, non è che il Double Ratchet sia stato spezzato. Il Double Ratchet sta funzionando perfettamente: sta cifrando il messaggio anche per sbir.

Il problema è che il vostro client non vi permette di sapere per chi lo sta cifrando.

Se non potete vedere e verificare tutti i dispositivi associati ai membri del gruppo, non potete escludere che tra essi esista un client che non conoscete. Vedete gli utenti dichiarati dall’interfaccia, ma non necessariamente tutte le estremità crittografiche alle quali la conversazione viene realmente consegnata.

---

Il secondo metodo è MLS, cioè Messaging Layer Security.

A differenza del Double Ratchet, MLS non parte da una conversazione tra due dispositivi che viene poi estesa artificialmente a molti. Nasce direttamente per gestire gruppi composti da numerosi client, anche quando non sono tutti collegati nello stesso momento.

L’idea generale è che i client del gruppo vengano organizzati in una struttura ad albero. Ogni estremità crittografica occupa una posizione nell’albero e condivide parte del materiale necessario a ricavare le chiavi del gruppo. Quando un client entra, esce o aggiorna le proprie chiavi, non è necessario ricostruire da zero una relazione separata con tutti gli altri. Viene aggiornata soltanto la parte dell’albero interessata, e da quell’aggiornamento tutti i membri legittimi possono ricavare il nuovo stato crittografico del gruppo.

È, in sostanza, un modo molto più efficiente di far avanzare insieme le chiavi di un numero elevato di client. MLS è stato progettato proprio per fornire ai gruppi proprietà analoghe alla protezione del passato e al recupero dopo una compromissione offerte dal Double Ratchet. Ma anche qui bisogna osservare attentamente che cosa significhi la parola membro.

In MLS, l’appartenenza al gruppo viene gestita al livello dei singoli client. Normalmente un client corrisponde a un dispositivo. Se Bob possiede tre dispositivi, nel gruppo MLS possono quindi esistere tre client distinti, anche se l’interfaccia continua a mostrarvi un solo utente chiamato Bob.

MLS può garantire che soltanto i client presenti nell’albero possano ricavare le chiavi del gruppo. Ma non stabilisce, da solo, come questi client debbano essere rappresentati sul vostro schermo, né garantisce che l’applicazione vi mostri chiaramente a quale essere umano siano attribuiti.

Torniamo quindi al nostro dispositivo chiamato sbir.

Se sbir viene inserito regolarmente nell’albero MLS, riceve gli aggiornamenti necessari e possiede credenziali considerate valide dall’applicazione, dal punto di vista crittografico è un membro perfettamente legittimo del gruppo.

Se poi l’interfaccia decide di nasconderlo sotto il nome di Bob, presentandolo come uno dei suoi dispositivi, voi continuerete a vedere Bob una sola volta.

MLS non è stato violato. Nessuno ha decifrato abusivamente i messaggi. Nessuno ha spezzato le chiavi.

Il messaggio è stato cifrato correttamente anche per sbir, perché sbir faceva parte del gruppo crittografico.

Ancora una volta, quindi, la crittografia può garantire che soltanto i membri autorizzati leggano la conversazione. Ma se non potete vedere e verificare l’elenco REALE dei client autorizzati, non potete sapere chi siano davvero questi membri.

---

Il terzo metodo è OTR, cioè Off-the-Record Messaging.

OTR nasce per riprodurre, nel mondo digitale, alcune proprietà di una conversazione privata avvenuta a voce.

Durante la conversazione, Alice deve poter essere ragionevolmente sicura di parlare con Bob. Nessuno all’esterno deve poter leggere i messaggi, modificarli senza essere scoperto o inserirne di falsi.

Ma, una volta conclusa la conversazione, Alice non dovrebbe poter prendere la trascrizione e dimostrare crittograficamente a un giudice, a un giornalista o a un’altra persona che una determinata frase è stata certamente scritta da Bob.

In altre parole, OTR cerca di ottenere contemporaneamente due risultati apparentemente contraddittori: autenticare l’interlocutore durante la conversazione, ma evitare che i messaggi diventino firme digitali permanenti contro di lui.

Per ottenere questo risultato, OTR cambia periodicamente le chiavi e, dopo averle utilizzate, rende pubbliche alcune chiavi di autenticazione ormai scadute. Da quel momento, chiunque potrebbe teoricamente costruire un messaggio compatibile con quelle vecchie chiavi.

La conversazione era verificabile mentre avveniva, ma la sua trascrizione non costituisce più una prova crittografica incontestabile.

Da qui il nome Off the Record: ciò che viene detto è riservato, ma soprattutto non viene trasformato automaticamente in una dichiarazione firmata e utilizzabile contro chi l’ha pronunciata.

Anche OTR, tuttavia, nasce essenzialmente come conversazione tra due client. Nelle versioni tradizionali, inoltre, i due interlocutori devono normalmente essere collegati nello stesso momento per iniziare lo scambio delle chiavi.

E anche qui ritorna il nostro problema.

Se Bob possiede più dispositivi, non esiste un unico Bob crittografico: esistono più client, ciascuno con le proprie sessioni. E se un programma costruisce un gruppo sommando diverse conversazioni OTR, deve ancora una volta decidere quali dispositivi includere e quali mostrare nell’interfaccia.

Supponiamo quindi che, oltre ai dispositivi visibili di Alice, Bob e Carlo, esista il solito client chiamato sbir.

Se il software apre regolarmente una sessione anche con sbir, e poi nasconde quel client sotto l’identità di Bob, OTR non può protestare. Dal suo punto di vista, la sessione è cifrata, autenticata e perfettamente valida.

Ancora una volta, nessuno ha spezzato la crittografia.

È il sistema che ha deciso di includere un destinatario senza mostrarvelo.

Double Ratchet, MLS e OTR affrontano il problema delle chiavi in modi differenti. Ma tutti arrivano allo stesso limite: possono proteggere la conversazione soltanto rispetto all’elenco dei client che il sistema considera autorizzati.

Se non potete vedere e verificare quell’elenco, la crittografia può dirvi che soltanto i membri del gruppo stanno leggendo.

Non può dirvi che il programma vi abbia mostrato tutti i membri del gruppo.

---

In conclusione, se il vostro sistema di messaggistica consente di accedere allo stesso account da più dispositivi, continuando a mostrarli tutti sotto il nome di un solo utente, allora può teoricamente associarvi un dispositivo aggiuntivo — chiamiamolo ancora sbir — capace di ricevere e registrare tutto ciò che scrivete.

E nulla, nel sistema di cifratura in sé, può impedirlo.

Dal punto di vista crittografico, infatti, sbir non è un intruso. È un dispositivo regolarmente autorizzato, al quale i messaggi vengono cifrati e consegnati nel modo previsto dal protocollo.

Lo stesso problema si presenta nei gruppi. Se il sistema può aggiungere un client all’insieme dei partecipanti senza mostrarvelo chiaramente, quel client riceverà legittimamente le chiavi necessarie a leggere la conversazione.

L’interfaccia che vi mostra l’elenco dei dispositivi associati al vostro account, o ai membri del gruppo, non è necessariamente soggetta allo stesso contratto crittografico che protegge i messaggi.

Quell’elenco può essere prodotto dal server, filtrato dall’applicazione o rappresentato nel modo deciso dal fornitore del servizio. La crittografia può garantire che il messaggio sia stato consegnato soltanto ai dispositivi autorizzati dal sistema.

Non può però garantirvi che l’interfaccia vi abbia mostrato l’elenco completo di quei dispositivi.

A meno che l’elenco non sia verificabile indipendentemente, firmato, registrato in modo trasparente e controllabile dagli altri partecipanti, dovete fidarvi del software quando vi dice chi sta ricevendo davvero i messaggi.

La cifratura end-to-end può quindi impedire al server di leggere direttamente il contenuto.

Ma non può impedirgli di autorizzare un’estremità aggiuntiva, se il protocollo gli consente di presentarla come un vostro dispositivo o come il dispositivo di un altro partecipante.

Il problema successivo, quindi, non è più la cifratura dei messaggi.

È la directory dei dispositivi.

Quando scrivete a Bob, il vostro client deve sapere quali siano i dispositivi autorizzati a ricevere i suoi messaggi: il telefono di Bob, il suo portatile, il tablet e così via. Questa informazione deve arrivare da qualche parte, e normalmente arriva dal server.

Ma se il server può semplicemente dichiarare che Bob possiede un nuovo dispositivo, allora può aggiungere anche sbir all’elenco.

A quel punto il vostro client cifrerà diligentemente una copia del messaggio anche per sbir, convinto di stare semplicemente comunicando con un nuovo telefono di Bob.

Per evitare questo problema serve qualcosa che, in termini generali, viene chiamato key transparency, cioè trasparenza delle chiavi.

L’idea è che l’elenco delle chiavi e dei dispositivi associati a ogni utente non venga consegnato dal server come una semplice informazione modificabile a piacere. Deve invece essere inserito in un registro verificabile, coerente e resistente alle modifiche invisibili.

Se Bob aggiunge davvero un nuovo telefono, il cambiamento deve lasciare una traccia. Il vostro client deve poter verificare che l’elenco attuale sia una continuazione coerente di quello precedente, e possibilmente deve avvertirvi che qualcosa è cambiato.

Il server non dovrebbe poter mostrare a voi una versione dell’elenco e a Bob una versione diversa, aggiungendo sbir soltanto nella copia destinata al vostro client.

Questo tipo di attacco si chiama spesso equivocation: il server presenta realtà differenti a utenti differenti.

Un sistema di trasparenza cerca quindi di ottenere almeno tre cose.

Primo: ogni modifica all’elenco dei dispositivi deve essere registrata.

Secondo: il server non deve poter cancellare retroattivamente una modifica senza lasciare tracce.

Terzo: client diversi devono poter controllare di stare vedendo una storia compatibile dello stesso registro.

A questo punto, però, compare un’altra difficoltà.

Chi controlla il registro?

Se il registro è mantenuto dallo stesso fornitore che gestisce il server, l’applicazione e gli aggiornamenti del client, allora la verifica rischia di diventare circolare: il sistema vi assicura che il sistema non sta mentendo.

Per avere una garanzia più forte servono controlli indipendenti, confronti tra client, registri pubblicamente verificabili oppure meccanismi che rendano evidente quando il server mostra versioni differenti della stessa realtà.

1. La crittografia end-to-end protegge dunque il messaggio durante il viaggio.
2. La trasparenza delle chiavi cerca invece di proteggere l’elenco dei destinatari.

Senza la prima, il server può leggere il messaggio.

Senza la seconda, può semplicemente aggiungere qualcuno tra coloro che hanno il diritto di leggerlo.

---

A questo punto, però, rimane un problema ancora più profondo.

Chi esegue tutte queste verifiche?

Il vostro client.

È il client che controlla il registro, confronta le chiavi, verifica la presenza di nuovi dispositivi e decide se mostrarvi un avviso.

Ma quel client, nella maggior parte dei casi, viene distribuito e aggiornato dallo stesso soggetto che gestisce il servizio.

Il fornitore controlla quindi il server, la directory dei dispositivi e anche il programma che dovrebbe accorgersi se il server sta mentendo.

Può pubblicare un sistema di key transparency perfettamente progettato e, nello stesso tempo, distribuire a un utente specifico una versione modificata del client che non esegue davvero i controlli, ignora le anomalie oppure nasconde la presenza del solito dispositivo sbir.

Anche in questo caso, la crittografia può continuare a funzionare perfettamente.

Le firme sono valide. Le chiavi coincidono. I messaggi arrivano cifrati. Il registro può perfino contenere davvero il nuovo dispositivo.

È soltanto l’interfaccia a non dirvelo.

Il problema, quindi, si sposta ancora una volta. Non basta che il protocollo sia sicuro. Bisogna anche potersi fidare del programma che lo implementa.

Il fatto che il software sia open source aiuta, ma non risolve automaticamente il problema. Potete leggere il codice pubblicato, ma dovete ancora sapere se il programma installato sul vostro telefono sia stato costruito proprio da quel codice e senza modifiche.

In altre parole, occorre poter verificare la corrispondenza tra il codice sorgente esaminabile e il file binario realmente distribuito.

È il problema delle build riproducibili.

Se persone indipendenti possono compilare lo stesso codice e ottenere esattamente lo stesso programma distribuito dal fornitore, diventa più difficile inserire modifiche nascoste soltanto nella versione pubblicata sugli store.

Ma anche questo non chiude completamente il problema.

Il fornitore potrebbe distribuire una versione speciale soltanto a un singolo utente. Oppure potrebbe inserire il comportamento sospetto soltanto quando il server invia un comando particolare. Il programma sarebbe apparentemente innocuo durante l’analisi, ma cambierebbe comportamento nel momento desiderato.

E così arriviamo al punto essenziale.

La sicurezza end-to-end non dipende soltanto dagli algoritmi crittografici.

Dipende dalla directory dei dispositivi, dal registro delle chiavi, dal client che esegue le verifiche, dal sistema di aggiornamento e dalla possibilità di controllare che il programma installato sia davvero quello che pensiamo.

Più precisamente: la crittografia può proteggere molto bene una conversazione da chi si trova all’esterno del sistema.

È molto meno efficace contro chi controlla la definizione stessa di quali dispositivi facciano parte del sistema.

Insomma, se usate il client di WhatsApp per collegarvi ai server di WhatsApp, la dicitura “crittografia end-to-end” non vi protegge da WhatsApp stesso qualora WhatsApp controlli il client, la directory dei dispositivi e il modo in cui questi dispositivi vengono mostrati.

Non vi ha mai protetto da questo specifico tipo di attacco.

Non vi protegge oggi.

E non potrà proteggervi in futuro, finché il soggetto dal quale volete difendervi controlla anche il programma che decide quali estremità siano autorizzate a ricevere i vostri messaggi.

La crittografia end-to-end di WhatsApp può impedire a un osservatore esterno, a un provider di rete o a un server che si limiti a trasportare i messaggi di leggerne il contenuto.

WhatsApp dichiara inoltre di usare una directory verificabile delle chiavi e meccanismi di key transparency.

Ma questa protezione non equivale alla garanzia assoluta che il produttore del client non possa mai modificare il client, l’elenco dei dispositivi oppure il modo in cui quell’elenco vi viene presentato.

In altre parole: la crittografia vi protegge da chi si trova fuori dal sistema.

Non può, da sola, proteggervi da chi possiede il sistema, distribuisce il client e stabilisce quali siano le estremità legittime della comunicazione.

---

E allora, per quale motivo esiste tutta questa opposizione al cosiddetto Chat Control dell’Unione Europea?

Perché molti pensano che stia distruggendo garanzie di sicurezza che oggi possiedono, o che almeno possedevano fino a ieri. Garanzie associate a espressioni come crittografia end-to-end, key transparency, verifica dei dispositivi e sicurezza delle conversazioni.

Il problema è che quelle garanzie, nella forma assoluta in cui vengono normalmente immaginate, non le avete mai avute.

Avete avuto una protezione contro alcuni tipi di attacco. Contro chi intercetta il traffico sulla rete. Contro un server che trasporta passivamente messaggi cifrati. Contro un aggressore esterno che non controlla i dispositivi, il client o la directory delle chiavi.

Ma non avete mai avuto, per il solo fatto che sullo schermo compariva la scritta end-to-end encrypted, la garanzia che il produttore del sistema non potesse aggiungere un destinatario, modificare il client, nascondere un dispositivo oppure cambiare il modo in cui vengono gestite le chiavi.

Il Chat Control può certamente introdurre nuovi obblighi, nuovi sistemi di scansione e nuove superfici di abuso. Ma non sta violando una specie di sacramento crittografico che prima rendeva impossibile al fornitore del servizio accedere alla conversazione.

Quella impossibilità non esisteva.

Esisteva, al massimo, entro un preciso modello di minaccia: il client è onesto, il sistema operativo è onesto, la directory dei dispositivi è completa, il server non mente, gli aggiornamenti non sono mirati e il produttore non decide di collaborare contro di voi.

Una volta tolte queste ipotesi, la frase «protetto dalla crittografia end-to-end» diventa molto meno rassicurante di quanto sembri.

Perché, se pensate che il vostro problema di sicurezza sia stato risolto semplicemente dalla crittografia, allora le possibilità sono due.

• O non avete capito la crittografia.
• Oppure non avete capito la sicurezza.

In questo senso, chi vi convince a lottare contro il Chat Control vi sta convincendo a difendere garanzie che, nella forma in cui le immaginate, non avete mai posseduto.

E più vi terrà occupati a pensare che il problema cominci con il Chat Control, meno sarete inclini a porvi la domanda davvero scomoda: quelle garanzie di privacy e sicurezza che credete di voler salvare, esistono davvero già oggi?

Perché non potete salvare qualcosa che non avete.

Potete impedire che la situazione peggiori. Potete opporvi a nuove forme di sorveglianza, a nuovi obblighi di scansione e a nuovi abusi. Ma è un’altra cosa.

Se vi raccontano che prima esisteva una cittadella crittografica inviolabile e che il Chat Control sta per abbatterne le mura, vi stanno descrivendo una fortezza che, in realtà, non è mai esistita.

Esistevano protocolli capaci di proteggervi da alcuni aggressori, in determinate condizioni. Non esisteva la garanzia assoluta che il fornitore del servizio, controllando client, server, directory dei dispositivi e aggiornamenti, non potesse introdurre il solito dispositivo sbir.

Presentare il Chat Control come il momento preciso nel quale perderete la vostra privacy serve quindi anche a non farvi chiedere quanta privacy abbiate realmente avuto fino a quel momento.

È il trucco del prestigiatore.

Vi indica con enfasi una mano, vi ordina di guardare il pericolo che si sta avvicinando da quella parte, e intanto esegue il trucco con l’altra.

Il diversivo funziona perché vi fa sentire impegnati nella difesa della privacy.

Mentre evita accuratamente che vi domandiate se quella privacy sia mai stata davvero nelle vostre mani.

Uriel Fanelli

—
Written using Blogfrei: https://git.keinpfusch.net/loweel/blogfrei
Fedi: @uriel@bbs.keinpfusch.net
XMPP: uriel@keinpfusch.net
vecchio blog: https://blog.keinpfusch.net
email: blog@keinpfusch.net