La cifratura end-to-end non richiede che un servizio di messaggistica eviti l’archiviazione centralizzata. Un server può conservare messaggi cifrati per la sincronizzazione senza possedere i segreti necessari a leggerne il contenuto.
La parte difficile della messaggistica su più dispositivi è decidere quali dispositivi sono autorizzati, quali chiavi ricevono e se possono accedere alla cronologia precedente. Queste decisioni contano più del fatto che il sistema utilizzi o meno un database.
Quattro operazioni distinte spesso chiamate «sincronizzazione»
| Operazione | Cosa deve ottenere |
|---|---|
| Recapitare nuovi messaggi | Far arrivare i contenuti protetti ai dispositivi attualmente autorizzati |
| Collegare un nuovo dispositivo | Stabilire che il titolare dell’account approvi il nuovo endpoint |
| Trasferire la cronologia | Dare al nuovo dispositivo accesso a contenuti passati selezionati e al materiale per decifrarli |
| Recuperare l’identità | Ripristinare o sostituire le chiavi d’identità senza necessariamente ripristinare la cronologia dei messaggi |
Un prodotto può supportare una delle operazioni senza supportarle tutte e quattro. Un accesso riuscito non dimostra che la vecchia cronologia delle chat sia recuperabile.
Come il recapito cifrato può supportare più dispositivi
Un approccio mantiene sessioni separate per ogni dispositivo. La specifica Sesame di Signal descrive la gestione delle sessioni in un contesto asincrono multidispositivo, inclusi l’aggiunta o la rimozione di dispositivi e l’arrivo di messaggi fuori ordine.
È un esempio di progettazione documentato, non un requisito universale. Altri sistemi possono cifrare il contenuto una sola volta e distribuire chiavi di contenuto protette, usare meccanismi di gruppo o combinare diversi approcci. «L’E2EE richiede una copia completa del payload per ogni dispositivo» è un’affermazione troppo generica.
Qualunque sia il progetto scelto, aggiungere un dispositivo capace di decifrare significa aggiungere un endpoint da proteggere. Un portatile trascurato può esporre il testo in chiaro che riceve anche se il server non vede mai quel testo.
Il testo cifrato archiviato ha comunque implicazioni per privacy e conservazione
L’archiviazione cifrata non equivale all’assenza di archiviazione. I fornitori possono conservare informazioni di recapito, registri dei dispositivi, timestamp, appartenenze o cronologie di messaggi cifrate. I dettagli variano e dovrebbero essere indicati esplicitamente.
La documentazione di sicurezza di Livara afferma che il suo relay conserva testo cifrato e dati operativi per la sincronizzazione e il recupero dopo una riconnessione. Descrive instradamento, appartenenze, timestamp, stato di recapito e altri registri. Questo non dovrebbe essere descritto come una coda transitoria non documentata che scompare necessariamente appena tutti i dispositivi ricevono un messaggio.
La riservatezza dei contenuti e la conservazione dei metadati richiedono quindi domande separate. Chiedete che cosa viene conservato, per quanto tempo e cosa cambia con la cancellazione o la rimozione dell’account; non inventate un periodo di conservazione quando non ne è stato verificato nessuno.
Che cosa ripristina davvero il recupero v7 di Livara
Livara descrive v7 come un backup cifrato dell’identità, sigillato prima del caricamento con una chiave di recupero casuale a 256 bit. Il payload documentato comprende materiale delle chiavi d’identità e il formato autentica la propria suite, l’epoca dell’identità e la generazione.
La stessa pagina afferma che ripristina l’identità, non la cronologia delle chat. Una frase di recupero non dovrebbe quindi essere presentata come garanzia che un nuovo dispositivo possa mostrare tutte le vecchie conversazioni.
Prima di sostituire o cancellare un dispositivo, verificate le opzioni attuali di trasferimento della cronologia e di backup effettivamente a vostra disposizione. Mantenete privato tutto il materiale di recupero. Non inviate una frase di recupero a un account di assistenza e non incollatela su un sito web non verificato.
La segretezza in avanti non svuota la posta di un dispositivo autorizzato
Un meccanismo ratchet può limitare ciò che una successiva compromissione delle chiavi rivela sul traffico cifrato precedente, se le sue ipotesi sono rispettate e i segreti obsoleti vengono eliminati. Non può nascondere il testo in chiaro già archiviato da un endpoint né impedire a malware ancora attivo di leggere nuovi messaggi.
Analogamente, la sicurezza dopo una compromissione richiede un aggiornamento fresco appropriato dopo che l’attaccante ha perso l’accesso. Non promette che qualsiasi vecchio tablet diventi innocuo ogni volta che avanza un contatore di messaggi.
Una checklist più sicura per cambiare dispositivo
- Fate l’inventario dei dispositivi collegati prima di aggiungerne un altro.
- Usate il flusso di collegamento e verifica documentato dell’applicazione, non un codice QR inviato da uno sconosciuto.
- Controllate quale cronologia riceve il nuovo dispositivo con una conversazione di prova innocua.
- Confermate il materiale di recupero e ogni backup separato della cronologia prima di cancellare il vecchio dispositivo.
- Revocate i dispositivi che non controllate più e verificate se gli interlocutori ricevono un avviso di cambio d’identità.
- Esaminate download locali, notifiche e backup del sistema operativo su ogni endpoint.
Il modello di minaccia di Livara include esplicitamente i limiti degli endpoint e dei destinatari. Questi limiti restano rilevanti su ogni schermo. Una promessa multidispositivo utile spiega separatamente l’autorizzazione dei dispositivi, i dati conservati e l’ambito del recupero.
