Crittografia end-to-end senza compromessi

Nota: Questo articolo descrive l’architettura e la progettazione di Mandraki. Alcune feature discusse vengono rollout progressivamente e potrebbero non essere ancora disponibili in tutti i piani.

La crittografia end-to-end è una di quelle feature che è facile da promettere e difficile da consegnare correttamente. Molte piattaforme di collaborazione affermano di offrire E2EE, ma i dettagli delle loro implementazioni variano enormemente — e i dettagli sono dove la sicurezza vive o muore.

Questo articolo spiega come Mandraki implementa la crittografia end-to-end, le scelte di protocollo che abbiamo fatto e i compromessi di cui siamo trasparenti.

Quello che crittografia end-to-end effettivamente significa

In un sistema con crittografia end-to-end, i messaggi e i media vengono crittografati sul dispositivo del mittente e possono essere decrittografati solo sui dispositivi dei destinatari. Il server che inoltra i dati vede solo testo cifrato. Non può leggere il contenuto, anche se obbligato da un ordine del tribunale, da un dipendente non autorizzato o da una violazione di sicurezza.

Questo è fondamentalmente diverso dalla crittografia di trasporto (TLS), che protegge i dati in transito tra un client e un server ma lascia il server con accesso al testo in chiaro. È anche diverso dalla crittografia a riposo, che protegge i dati su disco ma lascia il livello dell’applicazione con accesso al testo in chiaro durante l’elaborazione.

La vera E2EE significa che il server non è fidato per progettazione. È un relay, non un lettore.

Il protocollo MLS per la messaggistica

Per la messaggistica crittografata, utilizziamo il protocollo Messaging Layer Security (MLS), standardizzato come RFC 9420 dall’IETF. MLS è stato progettato specificamente per scenari di messaggistica di gruppo e offre molti vantaggi rispetto agli approcci più vecchi.

MLS utilizza una struttura di accordo delle chiavi basata su albero chiamata TreeKEM, che consente a un gruppo di partecipanti di stabilire un segreto condiviso in modo efficiente. Quando un membro entra o esce da un gruppo, il materiale chiave viene aggiornato tramite un messaggio Commit che avanza l’epoch del gruppo. Questo fornisce forward secrecy — compromettere le chiavi di un membro in un momento non rivela messaggi da epoch precedenti — e post-compromise security — il gruppo recupera la sicurezza dopo un compromesso non appena il materiale chiave del membro interessato viene ruotato.

Ogni dispositivo utente carica pacchetti di chiavi MLS al server. Questi sono bundle crittografici usa e getta che consentono ad altri dispositivi di aggiungerli a un gruppo senza richiedere che il dispositivo sia online in quel momento. Quando un pacchetto di chiavi viene consumato, il dispositivo deve caricarne di freschi. Il server conserva e distribuisce questi pacchetti ma non ha mai accesso al materiale chiave privato che contengono.

I gruppi MLS in Mandraki mappano a canali e thread di messaggi diretti. Quando invii un messaggio in un canale crittografato, il tuo client lo cripta usando la chiave dell’epoch corrente del gruppo. Il server riceve il testo cifrato, lo archivia e lo distribuisce ai membri del gruppo. I loro client lo decriptano localmente.

Crittografia dei media SFrame

La crittografia dei media in tempo reale — audio e video in una chiamata di gruppo — presenta sfide diverse dalla messaggistica. La tolleranza di latenza si misura in millisecondi, non secondi. I dati rate sono ordini di grandezza superiori. E i media passano attraverso una Selective Forwarding Unit (SFU), che ha bisogno di instradare i pacchetti ai partecipanti giusti senza poter vedere il contenuto.

Utilizziamo SFrame (RFC 9605) per la crittografia dei media, applicata tramite l’API WebRTC Encoded Transform. Questa API consente al codice JavaScript di intercettare i frame media codificati dopo la codifica ma prima del pacchettizzazione, crittarli e passare il testo cifrato al livello di trasporto. All’estremità ricevente, i frame vengono decrittografati dopo il riassemblaggio ma prima della decodifica.

Il vantaggio chiave di SFrame in un’architettura SFU è che l’SFU può ancora eseguire la sua funzione di routing — inoltramento di pacchetti da un partecipante a altri, prendendo decisioni adattative della larghezza di banda su quali livelli inoltrare — senza mai avere accesso ai media in testo in chiaro. L’SFU vede frame crittografati e li inoltra come blob opachi.

I compromessi di cui siamo onesti

La crittografia end-to-end non è gratuita. Introduce veri vincoli che crediamo valga la pena riconoscere.

La ricerca lato server non è possibile su contenuto E2EE. Se i messaggi vengono crittografati con chiavi che il server non possiede, il server non può indicizzarli per la ricerca. Mandraki affronta questo mantenendo un indice di ricerca crittografato locale sul client usando IndexedDB. Questo fornisce ricerca per dispositivo ma non supporta la ricerca cross-device della cronologia dei messaggi per i messaggi ricevuti prima che un dispositivo fosse aggiunto al gruppo.

Le feature IA lato server si escludono mutuamente con E2EE. Le nostre feature di trascrizione IA e riassunzione richiedono accesso lato server all’audio in testo in chiaro. Una chiamata o un canale non può avere sia E2EE che feature IA abilitate contemporaneamente. Questo è applicato architettonicamente, non solo da policy. Le organizzazioni scelgono a livello di chiamata o canale quale modello preferiscono.

I nuovi dispositivi vedono messaggi solo dal punto di join in poi. Quando aggiungi un nuovo dispositivo al tuo account, può decriptare messaggi dal momento in cui entra nel gruppo MLS in avanti. I messaggi storici crittografati sotto epoch precedenti non sono accessibili sul nuovo dispositivo. Questa è una proprietà fondamentale della forward secrecy. Stiamo esplorando meccanismi di backup sicuro che consentirebbero agli utenti di esportare la cronologia dei messaggi crittografata a un nuovo dispositivo, ma questo rimane un lavoro in corso.

La gestione delle chiavi aggiunge complessità. Ogni dispositivo deve mantenere il materiale chiave, caricare i pacchetti di chiavi freschi e elaborare gli aggiornamenti dello stato del gruppo. Investiamo uno sforzo di ingegneria significativo nel renderlo invisibile agli utenti. L’obiettivo è che la crittografia non sia qualcosa che configuri o su cui pensi — semplicemente accade.

E2EE e crittografia lato server coesistono

Vale la pena notare che il livello E2EE di Mandraki e la nostra crittografia lato server (la gerarchia di chiavi a tre strati descritta nell’articolo sulla nostra architettura di sicurezza) servono scopi complementari. La crittografia lato server protegge i dati a riposo sulla nostra infrastruttura — se un disco viene rubato o un backup del database viene compromesso, i dati sono illeggibili senza le chiavi di crittografia. E2EE va oltre assicurando che il server non veda mai il testo in chiaro in primo luogo.

Per le organizzazioni che abilitano E2EE, entrambi gli strati sono attivi simultaneamente. I dati vengono crittografati end-to-end dai client e anche crittografati a riposo sul server. Cintura e bretelle.

Crediamo che la crittografia end-to-end dovrebbe essere la scelta predefinita per le comunicazioni sensibili, non un componente premium o una casella di controllo che la maggior parte degli utenti non trova mai. Mandraki la rende semplice da abilitare, trasparente nei suoi limiti e robusta nella sua implementazione.