L’archiviazione cifrata separa i byte del file dalla facoltà di decifrarli, ma destinatari, metadati e copie locali restano nel modello di minaccia.
Un allegato cifrato end-to-end può essere conservato su un server senza fornire al server il file in chiaro. Un progetto comune cifra il file sul dispositivo del mittente con una nuova chiave del contenuto, carica il testo cifrato e invia la chiave ai destinatari previsti all'interno di un messaggio cifrato e autenticato.
La separazione è utile, ma «archiviazione a conoscenza zero» non è una specifica completa. Occorre ancora chiedere come vengono gestiti chiavi, riferimenti ai file, nomi, controlli di accesso e copie scaricate.
Il ciclo di vita di un allegato
- Preparare il file. Il mittente seleziona una foto, un video o un documento. Rimozione dei metadati e transcodifica sono passaggi separati; la sola cifratura non elimina EXIF o proprietà del documento.
- Creare il materiale crittografico. Un'implementazione sicura genera le chiavi e i nonce necessari secondo lo schema scelto.
- Cifrare prima del caricamento. Il servizio di archiviazione riceve byte cifrati anziché il contenuto originale.
- Consegnare un riferimento autenticato. Il messaggio di chat cifrato contiene le informazioni necessarie ai destinatari, come la posizione del file, la chiave di decifratura e i metadati di integrità pertinenti.
- Recuperare e verificare. Il client ricevente recupera l'oggetto dati e verifica l'autenticazione prima di considerare il risultato un contenuto valido.
- Gestire le copie locali. Visualizzazione, esportazione, modifica o salvataggio in galleria possono creare copie fuori dal confine originale dell'archiviazione cifrata.
La chiave può attraversare l'infrastruttura dello stesso fornitore in una busta cifrata. Definirla «fuori banda» può essere fuorviante: è separata logicamente dall'archiviazione dell'oggetto, ma non necessariamente consegnata tramite un canale di comunicazione indipendente.
Che cosa aggiunge la cifratura autenticata
Uno schema di cifratura autenticata protegge la riservatezza e rileva modifiche non autorizzate nel proprio ambito autenticato. La specifica GCM del NIST definisce una di queste costruzioni e i relativi requisiti. Sono essenziali la corretta gestione di chiavi e nonce e la verifica del risultato di autenticazione; il nome di un algoritmo riconosciuto non rende sicura ogni implementazione.
L'applicazione deve anche legare il file al messaggio e alla conversazione corretti. Un oggetto cifrato valido non dimostra, da solo, di appartenere a questa specifica chat. Identificatori del file, dimensione attesa, ordine dei blocchi e metadati dell'allegato richiedono un progetto autenticato adeguato.
Che cosa può ancora apprendere il servizio di archiviazione
| Informazione | La sola cifratura del contenuto la nasconde? |
|---|---|
| Byte originali del file | È progettata per nasconderli alle parti prive della chiave |
| Dimensione cifrata approssimativa | Di solito no |
| Tempi di caricamento e download | Di solito no |
| Quale account richiede un file | Dipende dal progetto di instradamento e controllo di accesso |
| Nome del file e didascalia | Solo se anche questi sono protetti dal protocollo |
| Copia salvata da un destinatario | No; il destinatario ha già accesso al contenuto in chiaro |
I controlli di accesso restano importanti anche quando gli oggetti sono cifrati. Possono limitare download indesiderati, abusi ed esposizione di identificatori. La cifratura non sostituisce autorizzazione, politiche di conservazione o disponibilità.
I file grandi richiedono più di uno slogan
Un progetto per file grandi può trasmettere i dati in streaming o dividerli in blocchi autenticati. Questo può ridurre l'uso di memoria, ma occorre definire numerazione, lunghezza finale, nuovi tentativi e gestione dei troncamenti. Non inventare dati prestazionali né sostenere che inserire un file in un messaggio provochi necessariamente un «rigonfiamento dello stato del ratchet»; tali risultati dipendono dall'implementazione.
Un test utile comprende un file valido, un byte modificato, un download troncato, un blocco fuori ordine e un tentativo di recupero non autorizzato. Esegui questi test solo in un ambiente di prova autorizzato con file non sensibili. Registra se il client rifiuta i dati non validi prima di aprirli.
Che cosa documenta Livara
La pagina di sicurezza di Livara descrive la cifratura prima del caricamento, una chiave casuale per file trasportata nella sessione protetta e la protezione di nomi e didascalie nelle conversazioni con E2EE attiva, inclusi i gruppi privati compatibili. I vecchi gruppi incompatibili sono esplicitamente esclusi. Distingue le conversazioni protette dai canali pubblici di diffusione. Sono dichiarazioni documentate sul prodotto, non un nuovo audit dell'implementazione svolto in questo articolo.
Il modello di minaccia riconosce inoltre che un destinatario o un dispositivo compromesso può esporre contenuti leggibili. L'archiviazione cifrata non può quindi promettere che un'immagine scompaia da ogni dispositivo quando viene eliminato il suo messaggio di chat.
Domande prima di condividere file sensibili
Verifica che il tipo di conversazione supporti E2EE, che tutti i destinatari previsti siano affidabili e che il file non contenga metadati identificativi. Esamina separatamente il salvataggio automatico in galleria e il backup delle foto nel cloud. Per un documento, valuta se rimuovere commenti, cronologia delle revisioni o proprietà incorporate prima dell'invio.
Infine, comprendi eliminazione e recupero. Rimuovere un oggetto dal server può impedire un download futuro, ma non ritirare la copia già in possesso di un destinatario. Perdere la chiave necessaria può rendere illeggibile un file cifrato rimasto. Un buon progetto degli allegati spiega chiaramente entrambi gli esiti.
