Un attacco al server di messaggistica non significa necessariamente che tutti i messaggi siano stati letti. L’esito dipende dai dati memorizzati, dalla posizione delle chiavi e dal livello di accesso dell’attaccante. Anche quando il testo delle chat è correttamente crittografato end-to-end, informazioni sull’account, orari, appartenenza ai gruppi e percorsi di consegna possono essere sensibili.
Per valutare un incidente, chiediti prima che cosa ha ottenuto l’attaccante: una copia del database, le chiavi dell’infrastruttura, un server attivo o il sistema di distribuzione del software? Questi scenari non hanno le stesse conseguenze.
Un database rubato è diverso da un server sotto controllo
Un attaccante che possiede soltanto una vecchia copia del database è limitato ai dati registrati al suo interno. Il controllo del servizio attivo può consentire di raccogliere nuovi dati, rubare sessioni, modificare risposte o tentare di sostituire la chiave di un contatto. L’accesso alla catena di distribuzione del software presenta un altro rischio: codice dannoso su un endpoint può vedere il testo prima della crittografia o dopo la decifratura.
L’affermazione «il database non contiene la chiave per leggere i messaggi» è quindi importante, ma non risponde completamente a ogni tipo di intrusione.
Confronto fra cinque modelli architetturali
Sono modelli didattici, non una classifica di cinque prodotti. Un servizio può adottare più modelli per funzionalità diverse.
| Modello | Dati accessibili dal database | Confine importante |
|---|---|---|
| Messaggi e password in chiaro | Contenuti e credenziali sono direttamente leggibili | Entrambi i tipi di dati mancano di una protezione adeguata |
| Password sottoposte a hash, messaggi in chiaro | I contenuti sono leggibili; potrebbe essere possibile verificare tentativi di password | Una buona conservazione delle password non protegge il testo delle chat |
| Contenuti crittografati con una chiave del server | Testo cifrato; la lettura dipende dall’accesso alla chiave | Conta la separazione effettiva tra chiavi e dati |
| Chat E2EE con backup accessibile al fornitore | La chat in tempo reale può essere protetta, ma la copia della cronologia offre un percorso distinto di esposizione | Occorre esaminare politica e chiavi del backup |
| Chat E2EE con recupero crittografato e chiave indipendente | Testo cifrato e dati operativi; la protezione dei contenuti dipende dalla progettazione e dalla protezione delle chiavi | Dispositivo, frase di recupero e autenticazione del contatto restano importanti |
La crittografia del disco del server aiuta contro il furto di un disco grezzo. Quando l’attaccante dispone anche del servizio in esecuzione o della chiave di decifratura, non bisogna presumere la stessa protezione. L’E2EE mira a far sì che il servizio intermediario non possieda la chiave necessaria per leggere i contenuti protetti.
Che cosa rivelano i metadati?
I metadati possono mostrare quali account hanno comunicato, quando erano attivi, a quali gruppi appartengono e quanti dati sono stati trasferiti. Non sono il testo dei messaggi, ma sono utili per conoscere le reti di comunicazione o gli schemi di attività.
La pagina sulla sicurezza di Livara descrive esplicitamente la conservazione e il trattamento di dati operativi, tra cui instradamento, appartenenze, orari, dimensione del testo cifrato e stato di consegna. La riservatezza dei contenuti privati non va interpretata come anonimato completo o assenza di qualsiasi dato sul server.
SRP non elimina il rischio di indovinare le password dai dati dell’account
SRP consente di dimostrare di conoscere una password senza inviare direttamente la password stessa. Il server conserva comunque dati di verifica, detti verifier. La sezione sulla sicurezza di RFC 5054 spiega che il furto del verifier può consentire un attacco a dizionario per indovinare la password.
Quindi «la password non viene inviata sulla rete» è diverso da «non esistono dati relativi alla password che possano essere rubati». Restano necessari una password forte e unica, la protezione del dispositivo e una risposta adeguata all’incidente. SRP non sostituisce neppure la crittografia dei contenuti o la protezione delle sessioni di accesso.
Quali confini dichiara Livara?
Il documento sulla sicurezza di Livara descrive LVR1 per i messaggi diretti e LGS1 per i gruppi protetti. La protezione del gruppo dipende dal suo stato effettivo; un vecchio gruppo incompatibile non deve essere etichettato E2EE. I canali pubblici sono fuori da questo confine di riservatezza.
Lo stesso documento presenta il recupero v7 come un pacchetto di identità crittografato e protetto prima del caricamento. Questo processo ripristina l’identità crittografica, non la cronologia delle chat. L’esposizione della frase di recupero o di un dispositivo che contiene le chiavi è uno scenario diverso dal semplice furto del database.
Queste sono descrizioni pubblicate del prodotto, non risultati di una verifica indipendente svolta in questo articolo. Neppure citare AES o ML-KEM dimostra, da solo, la correttezza della gestione delle chiavi e dell’implementazione dell’applicazione.
Quali domande porre quando viene annunciato un incidente?
- Quale periodo e quali sistemi sono stati coinvolti? L’espressione vaga «informazioni degli utenti» non basta.
- Erano accessibili testo in chiaro, file, chiavi, verifier, sessioni di accesso o soltanto testo cifrato?
- L’attaccante poteva modificare il servizio o il software distribuito agli utenti?
- Quali azioni sono necessarie attraverso i canali ufficiali: chiudere le sessioni, cambiare password, aggiornare o verificare l’identità dei contatti?
- Il recupero consigliato potrebbe cancellare la cronologia locale? Leggi i limiti prima di disinstallare l’app.
Non usare link contenuti in messaggi anonimi per una «verifica urgente dell’account». Apri autonomamente l’avviso dall’indirizzo ufficiale. Il modello di minaccia di Livara aiuta a capire i confini generali; la portata di un incidente reale deve essere stabilita con le prove relative a quell’incidente.
