SHARE THE PERSPECTIVE
Una chiave dedicata a un file non significa visualizzazione singola né recupero della copia del destinatario.

Per proteggere un allegato, un’app di messaggistica può cifrare il file sul dispositivo del mittente con una chiave casuale, caricare la copia cifrata e consegnare al destinatario la chiave del file all’interno di un messaggio cifrato end-to-end. Questo schema viene talvolta chiamato crittografia a busta: il file di grandi dimensioni e le poche informazioni necessarie per aprirlo seguono percorsi diversi ma collegati.

Questa spiegazione riguarda gli allegati nelle conversazioni con E2EE; inviare un file in qualsiasi app o tipo di canale non offre necessariamente la stessa protezione.

Il percorso di una foto privata dal dispositivo al destinatario

  1. Il dispositivo del mittente genera una chiave di contenuto per il file.
  2. Il file viene cifrato con crittografia autenticata; il destinatario deve poter rilevare modifiche non autorizzate ai dati.
  3. La copia cifrata viene collocata su un servizio di archiviazione file.
  4. L’indirizzo o l’identificatore del file e la chiave necessaria vengono inviati al destinatario in un messaggio protetto.
  5. Il dispositivo destinatario scarica il file, lo convalida e poi lo apre.

La documentazione di sicurezza di Livara descrive per gli allegati una chiave casuale specifica per il file e la sua trasmissione nella sessione di messaggistica. Questo articolo illustra tale architettura dichiarata, non il risultato di un audit dell’implementazione.

Una «chiave specifica per il file» non significa «file apribile una sola volta»

Una chiave generata per un file può servire per leggere più volte quello stesso file. Una chiave dedicata non implica eliminarla subito dopo la prima visualizzazione, cancellare automaticamente il file o impedire al destinatario di salvarlo.

Allo stesso modo, una chiave di messaggio monouso e l’impiego di una chiave di contenuto per un allegato sono due concetti differenti. Funzioni come la visualizzazione singola o i messaggi effimeri non vanno dedotte dal solo nome dell’algoritmo.

Perché contano sia la chiave sia il nonce?

AES-GCM offre, oltre alla riservatezza, una verifica dell’autenticità dei dati; usarlo correttamente è però essenziale. Lo standard NIST SP 800-38D spiega le regole di GCM. Riutilizzare una combinazione di chiave e nonce per dati diversi può compromettere la sicurezza.

Per l’utente, la conseguenza pratica è questa: la dicitura «AES-256» da sola non basta. Occorre esaminare anche le specifiche di gestione delle chiavi, generazione casuale, convalida dei file e gestione degli errori. La modifica di un byte dovrebbe causare il rifiuto del file non valido, non la visualizzazione di contenuti manomessi come se fossero un file integro.

Che cosa vedono il destinatario, il server e l’app della galleria?

Posizione Domanda di sicurezza
Servizio di archiviazione file Possiede soltanto byte cifrati o può accedere anche alla chiave?
Messaggio contenente la chiave La chiave, il nome del file e la sua descrizione sono protetti nella conversazione E2EE?
Dispositivo destinatario Dopo l’apertura, dove rimane il file: in memoria, nella cache o nella galleria?
Backup cloud La copia salvata entra nel backup delle foto e quale protezione ha quel backup?

La crittografia durante la trasmissione non controlla la copia che il destinatario salva nella galleria. Prima di inviare un documento sensibile, controlla anche le parti superflue dell’immagine, le scritte sullo sfondo e le informazioni di posizione del file.

Che cosa cambia per un file in un gruppo privato?

Aumenta il numero di persone autorizzate a possedere la chiave. Livara descrive la copertura degli allegati dei gruppi privati compatibili in modalità E2EE nell’ambito di LGS1; questa affermazione non va estesa ai canali pubblici. Ogni membro che ha ricevuto il file può conservarne una copia. Rimuovere un membro o ruotare le chiavi future non recupera la sua copia precedente.

Lista di controllo per inviare un file sensibile

  • Ricontrolla lo spazio di conversazione e i suoi destinatari.
  • Se l’identità del contatto è importante, verifica l’impronta della chiave tramite un percorso fidato.
  • Invia soltanto le informazioni necessarie; non serve sempre una foto completa di un documento.
  • Concorda con il destinatario la gestione del salvataggio in galleria, dei download automatici e dei backup cloud.
  • Non lasciare il file decifrato su un dispositivo condiviso o non bloccato.

Domande frequenti

Una chiave specifica per il file garantisce un invio sicuro?

No. Servono anche dispositivi integri, l’autenticazione del destinatario e un’implementazione corretta. Leggi il modello di minaccia di Livara insieme alle specifiche crittografiche.

Un’immagine in un canale pubblico ha la stessa protezione?

Secondo il confine dichiarato da Livara, i canali sono pubblici e leggibili; per essi non viene promessa la riservatezza degli allegati privati.

È sufficiente il solo link al file?

Dipende dalla progettazione del servizio. Esamina separatamente il link, la chiave e l’autorizzazione di accesso; il semplice fatto che un URL sia lungo o casuale non dimostra l’E2EE.

Esamina in modo trasparente il codice di sicurezza nel laboratorio Livara
CONTINUE THE THREADPrivate messaging ↗
YOU’VE REACHED THE ENDBack to the reading room ↗