Dietro le quinte della ricerca del contenuto dei messaggi di Proton Mail

La crittografia è al centro di tutti i nostri servizi. Questo offre enormi vantaggi perché fornisce tutti gli strumenti e le strutture necessarie per sviluppare funzionalità con sicurezza e privacy integrate. Tuttavia, occasionalmente questi strati di protezione possono ostacolare funzionalità di base a cui tutti si sono abituati dai servizi non focalizzati sulla privacy. Un esempio è la comunità di Proton che desidera poter cercare nel contenuto delle proprie email sull’app Proton Mail.

Il dilemma è tanto facile da spiegare quanto difficile da risolvere. In Proton, memorizziamo tutti i messaggi in stato crittografato sui nostri server in modo che solo il proprietario della chiave crittografica legittima possa accedervi. Poiché i server di Proton non hanno accesso alle chiavi, non possiamo decifrare le tue email, il che significa che non possiamo cercare nel loro contenuto. D’altra parte, le app web e mobili di Proton possono accedere ai messaggi decifrati ma tipicamente non hanno una visione completa su tutta la casella di posta perché scaricano i messaggi solo quando l’utente interagisce con essi.

In altre parole, il problema può essere formulato così: come possiamo cercare nel contenuto delle email mantenendo le solite garanzie di sicurezza e privacy che Proton ha sempre offerto?

Il nostro modello di sicurezza per la ricerca

Prima di addentrarci in qualsiasi dettaglio implementativo, è importante tenere a mente gli obiettivi che abbiamo fissato per la soluzione riguardo la sicurezza e la privacy che dovrebbe garantire. In Proton, il modello di sicurezza è il principale motore di tutte le scelte di design e decisioni tecniche. La ricerca del contenuto dei messaggi non poteva alterare fondamentalmente l’offerta di privacy che Proton Mail(new window) fornisce. La seguente lista fornisce una panoramica ad alto livello di alcune preoccupazioni sulla privacy relative alla ricerca del contenuto dei messaggi e come le abbiamo affrontate.

• Quando cerchiamo, non dovremmo rivelare la query.
• Quando cerchiamo, non dovremmo rivelare l’insieme dei risultati.
• Il server non dovrebbe essere in grado di effettuare una ricerca.
• Il server non dovrebbe essere in grado di apprendere il contenuto delle email.
• Se il dispositivo locale viene compromesso dopo che è stato spento, un attaccante non dovrebbe essere in grado di apprendere il contenuto o i metadati delle email.

Questi sono i criteri che abbiamo sempre tenuto a mente mentre valutavamo le nostre possibili soluzioni.

Crittografia ricercabile – Una soluzione teoricamente ottimale

Il campo della crittografia è pieno di costruzioni che vanno ben oltre il raggiungimento delle nozioni di sicurezza più basilari (ovvero autenticità, riservatezza e integrità dei dati) e offrono funzionalità avanzate per operare sui dati senza sacrificare troppo in termini di privacy. In altre parole, sono stati sviluppati diversi algoritmi per consentire l’applicazione di funzioni su testi cifrati, rendendoli capaci di preservare la riservatezza durante l’esecuzione di calcoli. Questi schemi crittografici sono chiamati algoritmi di crittografia ricercabile (SE) quando applicano una funzione di ricerca ai testi cifrati.

Utilizzando la SE, le email devono essere scaricate, crittografate con il nuovo algoritmo SE e ricaricate. Tuttavia, ciò sarebbe richiesto solo una volta per messaggio e potrebbe essere disponibile su dispositivi diversi senza fare affidamento sul disco di un dispositivo specifico. Da quel momento in poi, il server potrebbe applicare la funzione di ricerca consentita dallo specifico schema SE ogni volta che l’utente avvia una ricerca, e la riservatezza del contenuto dei messaggi rimarrebbe inalterata. Se questo sembra troppo bello per essere vero, è perché porta con sé gravi limitazioni, che ci hanno portato a scegliere un approccio più tradizionale. Il campo della crittografia SE è per lo più limitato all’interesse accademico poiché gli schemi crittografici in questa categoria presentano compromessi troppo restrittivi.

• Questi schemi sono progettati per essere il più generici possibile per adattarsi a molteplici casi d’uso. Ciò significa che è necessario un certo livello di regolazione non banale del primitivo crittografico (ad esempio, i parametri di sicurezza).
• Le garanzie di sicurezza variano da un algoritmo SE all’altro. Si verifica addirittura che alcuni schemi sacrificano le prestazioni per una sicurezza eccessiva. Ad esempio, non ci interessa necessariamente che il server sappia se un’email è stata inserita nel database poiché sa già che è stata ricevuta una nuova email!
• Al contrario, la comunità crittografica non ha raggiunto un consenso sulle garanzie di sicurezza degli algoritmi SE, portando alla pubblicazione di nuovi e potenzialmente devastanti attacchi contro gli schemi più noti.
• Le implementazioni sono rare e non pronte per ambienti di produzione poiché questi schemi sono ancora piuttosto accademici. Qualsiasi tentativo di sviluppare tale funzionalità avrebbe richiesto un’implementazione ad hoc di quasi tutti i suoi componenti.
• A causa del punto precedente, le prestazioni sono poco comprese e i test sono stati effettuati solo in ambienti limitati e controllati, mai sul campo.

In definitiva, questo è probabilmente il campo più interessante nella ricerca del contenuto dei messaggi, ma non ha soddisfatto le nostre esigenze.

Il nostro approccio – Ricerca lato client

Affrontando il problema di come cercare il contenuto dei messaggi, ci sono due aspetti da considerare. Da un lato, il server ha tutti gli email all’interno di una casella di posta, ma sono criptati da una chiave che non possiede. Dall’altro, il client può decriptare qualsiasi messaggio ma non ha accesso all’intera casella di posta in ogni momento. Chiaramente, la ricerca del contenuto delle email, pur essendo una funzionalità utile, non dovrebbe compromettere il modello di sicurezza che Proton Mail offre già. Come abbiamo discusso, questo è difficile da realizzare con una soluzione lato server data l’attuale crittografia. Quindi, per la nostra prima implementazione della ricerca del contenuto dei messaggi, abbiamo deciso che il client dovrebbe essere responsabile della ricerca dei messaggi.

Questo è già un buon punto di partenza, poiché il client soddisfa diversi requisiti utili per implementare una funzionalità di ricerca crittografata.

• Nel momento in cui l’utente effettua l’accesso, le chiavi crittografiche con cui tutte le email sono criptate sono disponibili localmente e possono essere utilizzate in qualsiasi momento.
• Tutti i messaggi sono accessibili; è solo questione di inviare le richieste appropriate al server.

Nonostante sembri banale, questi due fatti di base di qualsiasi client Proton indicano già verso una possibile soluzione al problema della ricerca del contenuto delle email. Ogni volta che un utente effettua una ricerca, il client può:

1. Recuperare il messaggio dal server
2. Decriptarlo
3. Verificare se l’email corrisponde ai filtri di ricerca dei metadati (ad esempio, un intervallo di date)
4. Se corrisponde, cercare se la parola chiave inserita dall’utente si trova nel corpo o in altri metadati dell’email
5. Se corrisponde, mostrare l’email come risultato della ricerca

Non è difficile vedere che questo approccio presenta gravi problemi pratici. Per esempio, comporta molta ridondanza perché i messaggi vengono recuperati e decriptati per ogni ricerca. Non scala bene: gli utenti con caselle di posta piccole potrebbero trovarlo accettabile, ma man mano che il numero di messaggi aumenta, cresce anche il rallentamento. Infine, i server dovrebbero gestire un gran numero di messaggi per tutti gli utenti che cercano contemporaneamente nelle proprie caselle, rendendo il carico di lavoro totale proibitivo molto rapidamente.

Nonostante sia impraticabile, il semplice algoritmo sopra descritto e i suoi svantaggi offrono uno spunto interessante per migliorare la situazione. Ogni ricerca dovrebbe recuperare i messaggi dal server e decifrarli, ma questi passaggi sono completamente indipendenti da qualsiasi parametro di ricerca. In altre parole, possiamo implementarli come una fase di pre-elaborazione prima di ogni ricerca.

Chiamiamo questa la fase di indicizzazione perché indicizziamo i dati in un database locale sul client. Una volta completata, l’indice riflette perfettamente il contenuto dell’intera casella di posta. L’utente può eseguire ricerche sul contenuto dei messaggi memorizzati sul proprio dispositivo anziché dover recuperare i messaggi più volte, migliorando drasticamente prestazioni e scalabilità. La logica della procedura complessiva può quindi essere riassunta come segue.

1. All’attivazione della ricerca del contenuto dei messaggi, costruire l’indice locale. Il tempo necessario per questo varia notevolmente a seconda del numero di messaggi contenuti nella casella di posta.
2. Una volta fatto ciò, eseguire i passaggi 3, 4 e 5 dell’algoritmo sopra menzionato ogni volta che l’utente avvia una ricerca.

Dettagli sul database locale

Le ricerche stesse sono realmente descritte dai punti 3, 4 e 5 dell’algoritmo sopra. A parte alcuni dettagli minori, è praticamente ciò che fa la nostra implementazione. Il nucleo della soluzione – e il più interessante da ricercare e sviluppare – era l’indice locale.

Tecnologia sottostante

Sul nostro client web, utilizziamo la IndexedDB Web API(new window) per costruire l’indice locale. IndexedDB (IDB) è un sistema di database transazionale basato sul paradigma chiave-valore presente in tutti i browser moderni. Ci sono diverse ragioni pratiche dietro questa scelta, specialmente in relazione ad altri tipi di soluzioni di web storage(new window).

• IDB è progettato tenendo a mente gli oggetti JavaScript, rendendolo flessibile e adatto agli oggetti personalizzati.
• È pensato per memorizzare grandi quantità di dati grazie alla sua maggiore quota. Questo è necessario per poter indicizzare caselle di posta molto grandi.
• Il sistema di interrogazione è più flessibile. Ad esempio, è possibile limitare l’intervallo della query.

Costruzione del database

Il processo di indicizzazione inizia quando un utente attiva la ricerca del contenuto dei messaggi. Come accennato, è necessario costruire l’indice locale ed è una precondizione prima che possa avvenire qualsiasi ricerca del contenuto delle email. Il processo è abbastanza semplice, ma vale la pena esaminarlo per evidenziare alcuni aspetti di sicurezza. Per ogni messaggio, vengono eseguiti i seguenti passaggi:

1. È recuperato dal server.
2. Decifriamo localmente il messaggio OpenPGP utilizzando la chiave privata appropriata.
3. Il testo in chiaro del messaggio viene ripulito da qualsiasi markup HTML, in quanto non pertinenti alla funzionalità di ricerca.
4. Il testo in chiaro finale, insieme a tutti i suoi metadati, viene nuovamente cifrato, questa volta con una chiave di cifratura simmetrica, utilizzando WebCrypto.
5. Il testo cifrato è memorizzato in IDB.

La chiave di cifratura simmetrica viene generata all’inizio della fase di indicizzazione e viene utilizzata per cifrare tutti i messaggi per garantire la loro riservatezza e integrità, anche in caso di dispositivo compromesso. Utilizziamo AES-GCM per questo, poiché AES-GCM è implementato in tutti i browser moderni come parte della Web Crypto API(new window), che è più veloce di OpenPGP. La chiave simmetrica stessa è conservata in modo sicuro localmente, cifrata con la chiave di contatto dell’utente.

Poiché IDB è una semplice tabella chiave-valore dove il valore può essere (quasi) qualsiasi valore JavaScript, al termine della fase di indicizzazione, ogni riga è indicizzata per ID del messaggio e contiene la cifratura del messaggio corrispondente. Da notare che, nonostante le Web API siano ragionevolmente veloci, il recupero e la decifratura dei messaggi da IDB hanno un costo in termini di prestazioni. Per evitare di sostenere questo costo per ogni ricerca nella stessa sessione, l’IDB viene (completamente o parzialmente, a seconda delle sue dimensioni) memorizzato nella cache in forma non cifrata.

Indice diretto vs. indice invertito

Abbiamo scelto di utilizzare la struttura dell’indice diretto(new window) per la ricerca del contenuto dei nostri messaggi. Questo significa che le chiavi sono gli identificatori unici dell’email e i valori sono i messaggi stessi (meno alcune pulizie HTML, come detto sopra).

Se astraiamo dalla struttura effettiva del database, possiamo rappresentarlo come la tabella sottostante. Il valore di ogni riga è un’email (sia il corpo che i metadati).

Vale la pena menzionare che abbiamo esplorato un altro approccio popolare per affrontare questi scenari, ovvero l’indice invertito(new window). La tabella sottostante rappresenta un esempio astratto di esso.

In questo caso, le parole chiave sono le chiavi principali e il valore corrispondente è un elenco di messaggi che contengono ciascuna parola chiave. Questo approccio è di solito molto più veloce dell’indice diretto perché deve solo cercare nel database le parole chiave esatte (o quasi) inserite dall’utente, leggere l’elenco dei messaggi e visualizzarli. L’indice diretto deve cercare ogni possibile messaggio, il che diventa rapidamente impraticabile su scale molto grandi.

Nonostante questa differenza di prestazioni, abbiamo comunque scelto di utilizzare un indice diretto per questa prima implementazione della nostra ricerca del contenuto dei messaggi. Abbiamo riscontrato che gli indici diretti offrivano diversi vantaggi:

• È concettualmente più semplice e più vicino all’interfaccia dei messaggi del client web già in uso.
• Eseguire query più complesse (ad esempio, la ricerca di frasi esatte) è più facile utilizzando un indice diretto perché abbiamo accesso all’intero documento. In un indice invertito, non avremmo un elenco ordinato di parole chiave senza fare lavoro aggiuntivo, il che significa che le frasi vengono spezzate.
• La dimensione della casella di posta tipica rientra benissimo in ciò che un indice diretto può gestire rapidamente, rendendo il vantaggio prestazionale di un indice invertito marginale nella maggior parte dei casi.

Tuttavia, continueremo a ottimizzare la nostra implementazione e ad esplorare approcci alternativi, incluso un indice invertito o addirittura la cifratura ricercabile, se si dimostra fattibile e necessaria per le prestazioni.

Conclusioni

Se riconsideriamo il modello di sicurezza che abbiamo detto che la nostra soluzione doveva soddisfare, vediamo che la soluzione che abbiamo scelto supera tutti i test:

• La ricerca viene eseguita localmente sul dispositivo dell’utente, quindi la query non viene trasmessa a un server Proton.
• Tutto ciò che è necessario per mostrare i risultati è memorizzato localmente sul dispositivo dell’utente (ad esempio, i metadati), quindi i risultati non vengono trasmessi al server. Un avvertimento è che, all’apertura di un risultato di ricerca, questo deve essere recuperato di nuovo poiché la versione memorizzata localmente non contiene l’HTML necessario per la visualizzazione. Tuttavia, il server non può dedurre se l’apertura di più email appartiene alla stessa query (o a una ricerca) poiché nessuna query viene inviata al server durante la ricerca.
• La chiave privata dell’utente è necessaria per decifrare il database locale dei messaggi, quindi il server non può eseguire una ricerca.
• L’indice è memorizzato localmente e non viene mai inviato al server, quindi il server non può leggere il contenuto delle email dall’indice.
• I messaggi e i metadati sono memorizzati criptati sul dispositivo, il che aiuta a proteggerli dagli attacchi in caso il dispositivo venga compromesso. Ciò richiederà comunque attenzione da parte dell’utente: uscire dal proprio account Proton non rimuove l’indice, ma impedisce all’app di effettuare automaticamente l’accesso all’apertura del browser. Proteggere il dispositivo con una password e la crittografia completa del disco sono anch’esse buone pratiche e possono impedire agli attaccanti di leggere il contenuto del disco del dispositivo in caso di furto.

Sicurezza e privacy non sono mai gratuite. A volte può sembrare che lo siano perché il prezzo è minimo, come una penalità di performance appena percettibile durante l’esecuzione di alcuni codici. Altre volte, richiedono una completa riprogettazione di funzionalità e caratteristiche.

Il nostro percorso con la ricerca del contenuto dei messaggi dimostra che, nonostante tutte le difficoltà, è possibile costruire prodotti ricchi che rispettano la privacy degli utenti. E la funzionalità di ricerca che abbiamo sviluppato potrà eventualmente essere utilizzata da altri servizi Proton, inclusi Proton Drive(new window) e Proton Calendar(new window). In definitiva, crediamo che lo sforzo che abbiamo messo nel rielaborare queste funzionalità affinché possano funzionare con la nostra crittografia sia un piccolo prezzo da pagare rispetto alla privacy che preservano.