Una copia del disco, il controllo attivo del server e l’accesso a un telefono sono tre scenari diversi; una garanzia generale non basta per tutti e tre.
Se viene preso il controllo del server di un servizio di messaggistica, la risposta precisa a «Che cosa viene esposto?» dipende dai dati memorizzati, dalla posizione delle chiavi e dal tipo di accesso dell’attaccante. Ottenere una copia del disco non equivale a controllare il servizio in funzione e il percorso di distribuzione dell’applicazione.
Questo articolo esamina uno scenario ipotetico sulla base della documentazione pubblica di Livara. Non fa affermazioni sulla posizione dei suoi datacenter, su un sequestro realmente avvenuto o sul funzionamento garantito del servizio durante un’interruzione di Internet. Cifratura dei contenuti, disponibilità della rete e sicurezza dell’infrastruttura sono questioni distinte.
Identificare prima il tipo di accesso
Una copia memorizzata del server: L’attaccante accede ai file, ai database o ai backup presenti in quella copia. Se i contenuti privati sono stati cifrati correttamente sul dispositivo e il server non possiede la chiave per decifrarli, quella copia da sola non rivela il testo della conversazione.
Controllo attivo del servizio: Oltre a leggere i dati esistenti, l’attaccante può bloccare alcune richieste, restituire dati vecchi o modificare il comportamento dei componenti sotto il suo controllo. La verifica dell’identità del contatto, il controllo delle versioni e l’integrità del client assumono maggiore importanza in questo scenario.
Accesso simultaneo al dispositivo: Un telefono sbloccato, un malware o una copia leggibile posseduta da un membro della conversazione possono esporre i contenuti attraverso un percorso completamente diverso. Anche il modello di minaccia di Livara non garantisce la protezione di un dispositivo sbloccato o infetto.
Quali dati sono visibili sul server secondo la documentazione di Livara?
La pagina sulla sicurezza di Livara, contrassegnata come versione 0.1.68, distingue i contenuti delle chat dirette sotto LVR1 e dei gruppi privati compatibili sotto LGS1 dalle informazioni operative. La stessa pagina afferma che un gruppo precedente incompatibile rimane esplicitamente al di fuori dell’E2EE; occorre quindi verificare lo stato della specifica conversazione.
| Categoria di dati | Limite documentato e possibile conseguenza |
|---|---|
| Testo e allegati di una conversazione protetta | Il server conserva una copia cifrata; per leggerla serve la chiave appropriata |
| Metadati di comunicazione | Il servizio dispone di informazioni come partecipanti, orario, dimensioni e stato di consegna |
| Appartenenza al gruppo | Rientra nelle informazioni e nei poteri operativi del server |
| Canale pubblico | Il contenuto è pubblico e leggibile dal server |
| Pacchetto di recupero dell’identità v7 | Cifrato prima del caricamento e richiede un segreto di recupero separato |
| Modalità facoltativa di registrazione sul server | L’indicatore REC la distingue dalla modalità E2EE; non va presunta una riservatezza end-to-end per questa modalità |
La documentazione cita codice LSS1 per la protezione dei metadati, ma non è collegato al normale invio dei messaggi. La presenza del nome di un protocollo in un progetto non dimostra che sia attivo in tutte le comunicazioni.
Questa tabella descrive affermazioni del prodotto, non i risultati di una prova di sequestro reale o di un audit indipendente di tutte le versioni del database.
Quanto possono essere importanti i metadati?
Le informazioni sulle comunicazioni tra persone, sugli orari e sull’appartenenza ai gruppi possono essere sensibili anche senza il testo dei messaggi. Tuttavia, affermare che «l’intero grafo delle comunicazioni viene esposto per sempre» non è preciso senza conoscere i tempi di conservazione, la copertura dei log e la versione dei dati ottenuti.
Una valutazione reale deve chiedere quali campi sono stati raccolti, per quanto tempo sono stati conservati e quali backup sono accessibili. La cifratura dei contenuti, da sola, non definisce la politica di conservazione dei dati. Né si può dedurre dall’architettura di un servizio di messaggistica che tutti conservino necessariamente gli stessi metadati.
Quali rischi comporta il controllo del server per i messaggi futuri?
Una valutazione di sicurezza deve testare separatamente la manipolazione dell’elenco dei membri, la fornitura di una chiave d’identità diversa, il blocco degli aggiornamenti e la distribuzione di un client malevolo. Gli effetti di ciascun caso dipendono dalla validazione lato client, dalla visualizzazione delle modifiche e dalla verifica dell’identità.
Senza testare l’implementazione, non si può affermare che ogni server compromesso possa necessariamente aggiungere un membro nascosto; allo stesso modo, non si può dire che il controllo attivo del server non abbia alcun effetto. Per le conversazioni sensibili, i cambiamenti inattesi d’identità o dei membri vanno esaminati. Confrontare le impronte delle chiavi con il contatto attraverso un canale indipendente e fidato fornisce più informazioni che affidarsi al solo nome visualizzato.
Se l’attaccante modifica il codice eseguito sul dispositivo, potrebbe vedere il testo prima della cifratura. Ecco perché la sicurezza della distribuzione e degli aggiornamenti dell’applicazione fa parte di questo scenario, anziché essere un tema estraneo alla cifratura.
Che cosa aggiunge la caratteristica post-quantistica?
Lo standard NIST FIPS 203 per ML-KEM aiuta a stabilire un segreto condiviso. Il suo corretto utilizzo in una costruzione ibrida può ridurre il rischio di alcuni attacchi futuri allo scambio di chiavi. Questa caratteristica non sostituisce la sicurezza del dispositivo, la conservazione limitata dei metadati o i controlli di accesso al server.
Anche Proof Lab dimostra soltanto alcune operazioni locali P-256, HKDF e AES-GCM ed esclude da quel test la composizione completa LVR1/LGS1. Un risultato positivo non garantisce la resistenza dell’intero prodotto alla presa di controllo dell’infrastruttura.
Che cosa fare in una valutazione o in un incidente reali?
- Registrare il tipo di accesso e le informazioni confermate; non equiparare voci di disservizi a un incidente di sicurezza accertato.
- Verificare la versione dell’applicazione e lo stato della cifratura della specifica conversazione.
- Esaminare tramite i canali ufficiali le modifiche d’identità, i membri del gruppo e le sessioni sconosciute.
- Non consegnare segreti di recupero, password o contenuti privati a sconosciuti per un «controllo di sicurezza».
- Per rischi gravi o questioni legali, chiedere assistenza a un esperto appropriato e non intraprendere azioni irreversibili sulla base di un articolo.
Una conclusione affidabile deve precisare quali dati sono protetti, in quale versione e contro quale tipo di accesso. «Anche se il server viene sequestrato, non succede nulla» non sostituisce questa risposta.
