Il risultato forense dipende dallo stato reale del dispositivo e delle chiavi, non soltanto dal nome di un database o algoritmo.
La crittografia end-to-end e la protezione dei dati locali sono questioni collegate ma diverse. Un messaggio protetto durante il transito in rete deve diventare leggibile per essere visualizzato sul dispositivo. Il risultato di un esame forense dipende dallo stato del dispositivo, dal tipo di accesso, dalle versioni del sistema e dell’app e dalla posizione delle chiavi; nessun nome di algoritmo determina da solo il risultato.
Occorre quindi prudenza sia nell’affermare che «con l’accesso fisico tutto diventa subito leggibile», sia nel promettere che «l’estrazione non è mai possibile».
Esamina separatamente quattro livelli di protezione
| Livello | Funzione principale | Limite importante |
|---|---|---|
| E2EE dei messaggi | Proteggere il contenuto tra i dispositivi dei partecipanti | Non garantisce l’integrità del dispositivo o la protezione delle copie locali |
| Isolamento delle app | Limitare l’accesso delle app ordinarie ai dati delle altre | Un accesso privilegiato o una vulnerabilità possono cambiare il modello |
| Crittografia di file o disco | Proteggere i dati memorizzati in condizioni specifiche | Contano lo stato del blocco e la disponibilità delle chiavi |
| Crittografia del database nell’app | Aggiungere un confine di protezione al file del database | È decisivo come viene conservata e usata la chiave |
La documentazione FBE di Android distingue lo spazio dipendente dalle credenziali dell’utente da quello disponibile durante Direct Boot. «Il telefono è bloccato» non basta a conoscere lo stato di tutte le chiavi; può contare anche se sia già avvenuto il primo sblocco dopo l’avvio.
Che cosa dimostra un file SQLite?
SQLite è un formato e un motore di archiviazione, non un’etichetta che indichi da sola la presenza o l’assenza di tutte le protezioni. Il file può trovarsi in uno spazio crittografato dal sistema operativo oppure essere protetto da una soluzione separata.
Anche eliminare una riga non rimuove necessariamente ogni sua traccia da tutti i file. La documentazione SQLite spiega le impostazioni di eliminazione sicura e i limiti delle tabelle virtuali. Nell’esaminare il ciclo di vita dei dati vanno considerati anche i file ausiliari e i backup. Questo non garantisce il recupero di ogni messaggio eliminato su qualsiasi telefono.
Non eseguire comandi di manutenzione del database su dati reali senza conoscere l’app; modificare direttamente i suoi file può corrompere i dati o alterare le prove.
SQLCipher e Keystore sono soluzioni, non certificati di immunità
SQLCipher è progettato per la crittografia trasparente dei database, ma le sue specifiche vanno lette in relazione alla versione. La pagina di progettazione di SQLCipher descrive una struttura AES-CBC con autenticazione; la presentazione della versione 5 beta a settembre 2026 descrive il passaggio ad AES-GCM. Attribuire un’unica modalità crittografica a tutte le versioni è quindi inesatto.
Anche Android Keystore può proteggere le chiavi e controllarne l’uso, ma occorre stabilire quali funzionalità e quale livello hardware l’app utilizzi realmente. Citare StrongBox in un articolo non dimostra che un prodotto lo usi. Vedi la guida a Keystore.
Anche una chiave non estraibile può, in determinate condizioni, essere utilizzabile mediante operazioni autorizzate. «La chiave non può essere copiata» non equivale ad affermare che «un attaccante non può decifrare alcun dato».
Qual è il ruolo della RAM e del ratchet?
Limitare la durata delle chiavi e del testo sensibile riduce le occasioni di esposizione. Ma cancellare un buffer non dimostra che non rimangano altre copie in una libreria, un’anteprima o nel processo di visualizzazione.
Anche la portata del ratchet cambia in base al tipo di chiave compromessa e alla persistenza dell’accesso dell’attaccante. «Una chiave distinta per ogni messaggio» non implica che un’acquisizione della memoria esponga al massimo un messaggio. Conservare una cronologia leggibile sul dispositivo è una questione distinta dalle chiavi di trasporto.
Che cosa non è stato verificato su Livara?
Il modello di minaccia di Livara non garantisce protezione per un dispositivo infetto o sbloccato. Questo articolo non verifica indipendentemente che una specifica versione di Livara usi SQLCipher o StrongBox, cancelli completamente la RAM o non conservi dati locali delle chiamate. Queste proprietà non vanno attribuite al prodotto senza rapporti di test e prove dell’implementazione.
Inoltre, il pacchetto di recupero dell’identità nella documentazione di sicurezza non è un backup della cronologia. Verificare l’hash di un APK in Proof Lab può dimostrare che il file corrisponde a un hash attendibile; quel risultato non costituisce un audit dell’archiviazione o un test antiforense.
Quali informazioni deve includere un’affermazione forense credibile?
Chiedi il modello del dispositivo, le versioni del sistema e dell’app, lo stato del blocco, il metodo e il livello di accesso, il tipo di dati ottenuti e i limiti del test. Il fallimento di uno strumento in un esperimento non dimostra l’impossibilità di tutti i metodi; nemmeno un successo limitato autorizza generalizzazioni a tutti gli utenti.
Per l’utente comune, le priorità sono aggiornamenti, un blocco robusto, meno copie aggiuntive dei contenuti multimediali e la protezione dei metodi di recupero. In un incidente grave, rivolgiti a uno specialista autorizzato prima di intraprendere azioni che modifichino dati o prove.
