La crittografia end-to-end, spiegata in modo semplice

Un ufficio fiduciario a Bellinzona invia una volta all’anno lo stesso modulo: redditi, immobili, figli, deduzioni. Sul sito dello strumento per i moduli c’è scritto «crittografato». È rassicurante, e non risponde alla domanda che conta: chi si ritrova, alla fine, con le risposte in chiaro?

La parola compare ormai su quasi ogni pagina di prodotto e significa cose diverse a seconda del punto in cui viene applicata. La differenza non è un dettaglio per tecnici: decide chi può leggere il contenuto. E ha un rovescio della medaglia che le spiegazioni di solito tralasciano: a che cosa si rinuncia quando nessuno, tranne chi riceve, può leggere? Questa seconda parte è la più interessante.

Tre significati di «crittografato»

Termine	Cosa è protetto	Chi può decifrare
In transito	Il percorso fra dispositivo e server	Entrambe le estremità: il browser e il server
A riposo	I supporti su cui i dati sono archiviati	Il servizio che gestisce la chiave
End-to-end	Il contenuto stesso, dall’inserimento alla lettura	Solo chi possiede la chiave

In transito è oggi la norma: il lucchetto nella barra degli indirizzi indica TLS. La specifica di TLS 1.3 lo dice senza ambiguità: dopo l’instaurazione del canale, i dati che vi transitano sono visibili soltanto alle estremità. È proprio questo il punto: il server è una di quelle estremità. Lì il contenuto torna in chiaro, prima che gli accada qualsiasi altra cosa.

A riposo significa che i dati non stanno sui dischi come testo leggibile. La chiave relativa è gestita dal servizio che quei dati li consegna. Protegge da un supporto rubato o dismesso. Non protegge dal software che la chiave la usa comunque.

End-to-end sposta una cosa sola: il punto in cui avviene la cifratura. Non sul server, ma sul dispositivo di chi compila — e la decifratura avviene solo sul dispositivo di chi è autorizzato a leggere. In mezzo, il contenuto non è in chiaro da nessuna parte.

Dove avviene la cifratura — e chi tiene la chiave

I browser sanno farlo di serie. La Web Cryptography API è una raccomandazione del W3C dal 26 gennaio 2017; descrive un’interfaccia JavaScript per le operazioni crittografiche di base — hashing, firme, cifratura e decifratura — e per la gestione del materiale di chiave necessario. Per la cifratura vera e propria si usa quasi sempre AES, definito dalla norma statunitense FIPS 197 nelle varianti AES-128, AES-192 e AES-256, dove il numero indica la lunghezza della chiave.

In una costruzione consueta le chiavi sono due, appaiate. Una è pubblica e sta nel modulo; con quella il browser di chi risponde cifra ciò che ha inserito. L’altra è privata, resta presso chi riceve ed è l’unica che rende il risultato di nuovo leggibile.

Così si sposta la questione della fiducia. Che un fornitore legga o no smette di essere una promessa e diventa una questione di costruzione: la chiave privata non ce l’ha, perché non l’ha mai ricevuta. È una differenza — ma non una garanzia. Chi tiene la chiave legge; chi la perde non legge più; e il software che cifra nel browser arriva comunque dal fornitore. Per questo chi costruisce così di norma documenta come lo fa.

Una cosa la crittografia end-to-end espressamente non la fa: protegge il contenuto, non le circostanze. Che un modulo sia stato inviato, quando, quante volte e quanto fosse grande un allegato continua ad accumularsi. Chi ritiene questi dati irrilevanti provi a scriverli una volta: su un modulo per segnalazioni interne, già l’orario dice qualcosa.

Un modulo d’iscrizione, passo per passo

Una scuola di musica a Locarno raccoglie iscrizioni: nome del bambino, indirizzo, strumento, indicazioni per un’eventuale tariffa ridotta. Ecco il percorso quando la cifratura è end-to-end.

1. La scuola crea il modulo. Nasce una coppia di chiavi. La parte pubblica appartiene al modulo, la parte privata appartiene alla scuola.
2. Un padre apre il link. Il suo browser carica il modulo insieme alla chiave pubblica.
3. Compila e invia. Prima dell’invio, il suo browser cifra le risposte. Ciò che lascia la linea non è più testo leggibile.
4. Il server riceve il risultato e lo archivia. Può catalogarlo, contarlo, datarlo — il contenuto non lo vede.
5. La segretaria della scuola apre la panoramica. Il suo browser recupera le voci archiviate e le decifra localmente con la chiave privata.
6. L’iscrizione compare sul suo schermo. Dal passo 3 non era leggibile da nessun’altra parte.

Per il padre l’uso non cambia in nulla. Per la segretaria cambia parecchio — ed è qui il tema vero.

A che cosa si rinuncia

Una chiave persa resta persa. In un sistema simile la password non è la chiave, e reimpostare la password non ripristina l’accesso ai dati. Proton lo descrive apertamente per i propri account: dopo una reimpostazione serve un’opzione di recupero configurata in precedenza — una frase di recupero, un file di recupero, un backup del dispositivo o la vecchia password — altrimenti si rischia di perdere definitivamente l’accesso all’account e ai dati. Il fornitore non può sostituirsi: è esattamente in questo che consiste la costruzione.

Il server non può cercare, ordinare, mostrare un’anteprima. Tutto ciò che altrimenti passerebbe sul contenuto lato server scompare o si sposta nel browser. Google lo descrive esplicitamente per la propria cifratura lato client in Workspace: il contenuto di questi file non può essere cercato, né filtrato per tipo di file, né mostrato in anteprima; i controlli per la prevenzione della perdita di dati non hanno accesso al contenuto; e i file e le e-mail cifrati lato client non vengono esaminati alla ricerca di phishing e malware, perché i server il contenuto non lo vedono. Non è una particolarità di un fornitore, ma la conseguenza logica della costruzione.

L’e-mail di notifica non contiene il contenuto. «Nuova iscrizione ricevuta»: di più non può dire, perché parte da un server che la risposta non la può leggere. Chi è abituato a scorrere il contenuto direttamente nella posta in arrivo lavora in un altro modo.

Le analisi avvengono nel browser. Una statistica su 4000 risposte non si calcola sul server, ma sul proprio dispositivo dopo la decifratura. Con una manciata di iscrizioni non si nota nulla. Con moltissime voci si nota.

L’accesso per più persone è un compito a sé. Se in segreteria tre persone devono leggere le risposte, tutte e tre devono arrivare alla chiave. È risolvibile, ma è un passaggio in più rispetto alla creazione di un account — e all’uscita di una collaboratrice è di nuovo un passaggio in più.

Quando è lo sforzo sbagliato

Non ogni modulo ne trae vantaggio. Un sondaggio pubblico sul menu di mezzogiorno di una mensa, anonimo e senza dati personali, ne paga il prezzo senza ricevere nulla in cambio. Un modulo d’ordine i cui dati devono confluire automaticamente nella contabilità o presso un servizio di spedizione richiede, da qualche parte, un software capace di leggere il contenuto: a quel punto la catena è comunque interrotta. E dove le risposte devono restare raggiungibili in caso d’urgenza anche quando l’unica persona con la chiave non è disponibile, il lavoro vero è la gestione delle chiavi, non la cifratura.

Il calcolo si rovescia non appena nelle risposte compaiono cose che non riguardano nessuno all’esterno: anamnesi, candidature, segnalazioni interne, documenti fiscali.

Cosa dice il diritto svizzero

La legge sulla protezione dei dati non prescrive alcuna tecnica. Chiede che titolare del trattamento e responsabile garantiscano, mediante misure tecniche e organizzative adeguate, una sicurezza dei dati adeguata al rischio, e lascia i requisiti minimi al Consiglio federale (art. 8 LPD). L’ordinanza sulla protezione dei dati nomina poi obiettivi anziché strumenti: in funzione del loro bisogno di protezione, i dati trattati devono essere accessibili solo alle persone autorizzate (confidenzialità), disponibili quando servono (disponibilità), non modificati senza autorizzazione (integrità) e trattati in modo tracciabile (tracciabilità) (art. 2 OPDa). Nella scelta delle misure rientrano fra gli elementi da considerare lo stato della tecnica e i costi di attuazione (art. 1 cpv. 4 OPDa).

La parola «cifratura» in queste disposizioni non compare. Significativo è piuttosto che confidenzialità e disponibilità stiano l’una accanto all’altra — e che l’ordinanza richieda anche che l’accesso ai dati possa essere ripristinato rapidamente dopo un incidente (art. 3 cpv. 2 lett. d OPDa). La decisione di cui tratta questo articolo sta esattamente fra questi due obiettivi.

A cosa si riduce

«Crittografato» non è una proprietà, ma una domanda su due cose: in quale punto avviene la cifratura e chi tiene la chiave? Entrambe stanno nella documentazione di un fornitore, oppure non stanno da nessuna parte. End-to-end è la risposta con la cerchia di lettori più ristretta — e con il maggior numero di limitazioni quotidiane. Le due cose vanno insieme; raccontare solo la prima metà è raccontare metà della storia.

Stiamo sviluppando Moduli, un’app in cui le risposte vengono cifrate nel browser di chi risponde e la chiave privata resta presso chi riceve. L’app è pianificata e non è ancora disponibile; come sia costruita nel dettaglio la cifratura e cosa comporti nell’uso quotidiano lo illustreremo prima del lancio.