Crittografia lato dispositivo: come funziona e cosa protegge

Categoria

Sicurezza locale

Pubblicato

Settembre 19, 2026

Tempo di lettura

18 min di lettura

La crittografia lato dispositivo significa che un file viene cifrato sul tuo telefono, tablet o computer prima di essere caricato, sottoposto a backup, sincronizzato o inviato a un’altra persona. Il servizio che riceve i dati cifrati dovrebbe ricevere testo cifrato anziché il file originale leggibile. Questo riduce la fiducia che devi riporre nell’infrastruttura cloud, negli operatori di rete e nei fornitori di archiviazione, ma solo se anche le chiavi di cifratura sono protette da tali soggetti. La crittografia lato dispositivo è una componente centrale di un approccio ai file orientato alla privacy perché avvicina la protezione al punto in cui i dati vengono creati. Non elimina ogni rischio: un dispositivo compromesso, un blocco schermo debole, una chiave di recupero esposta o un destinatario autorizzato possono comunque compromettere la riservatezza.

Nell’uso quotidiano, la domanda pratica è semplice: l’app protegge il file prima che lasci il mio dispositivo e chi può sbloccarlo in seguito? La risposta stabilisce se la cifratura è soprattutto una protezione del trasferimento, una protezione rispetto al fornitore cloud o una difesa significativa contro entrambi.

La crittografia trasforma informazioni leggibili, chiamate testo in chiaro, in dati cifrati illeggibili, chiamati testo cifrato. Per invertire il processo sono necessarie le chiavi di crittografia dei file. Con la crittografia lato dispositivo, l’operazione inizia localmente: il tuo dispositivo trasforma una foto, un documento, un messaggio o un record di database in testo cifrato prima che un server remoto lo gestisca.

Questo modello differisce da un approccio cloud comune, nel quale un file raggiunge il fornitore in forma leggibile e viene cifrato solo dopo l’arrivo sui suoi server. La cifratura lato server può comunque essere utile: aiuta a proteggere i dati archiviati se dischi fisici vengono rubati o smaltiti in modo improprio. Da sola, però, non impedisce al servizio di accedere al file durante l’elaborazione e non protegge necessariamente da una compromissione dell’account presso il fornitore.

La crittografia lato dispositivo descrive dove inizia la cifratura, non una promessa completa di privacy. Per valutarne la protezione, chiediti dove vengono create e conservate le chiavi e chi può usarle.

L’espressione viene spesso usata insieme a crittografia lato client e crittografia locale. Nella maggior parte dei contesti rivolti ai consumatori, indicano la stessa idea generale: la cifratura avviene in un software eseguito sul dispositivo controllato dall’utente, anziché soltanto in un ambiente controllato dal fornitore. L’architettura esatta può comunque variare molto da un prodotto all’altro.

Per capire se una soluzione risponde alle tue esigenze, non basta verificare che la cifratura avvenga in locale. Occorre anche considerare il tipo di file, il percorso di condivisione, il modo in cui vengono gestite le chiavi e le possibilità di recupero dell’accesso.

Un flusso di crittografia lato dispositivo ben progettato include normalmente più livelli. La crittografia precisa e la gerarchia delle chiavi cambiano, ma la sequenza seguente spiega il modello senza presupporre una particolare app o un algoritmo specifico.

• Crei o selezioni un file in locale. Può trattarsi della scansione di un documento d’identità, di una foto privata, di un contratto o di un gruppo di allegati.
• L’app crea o recupera una chiave di cifratura. I sistemi moderni usano spesso una chiave dati unica per un file o per un evento di condivisione, anziché una chiave universale per tutto.
• Il dispositivo cifra il contenuto. Il file leggibile diventa testo cifrato prima della trasmissione o dell’archiviazione remota.
• L’app protegge la chiave dati. Può cifrarla con un’altra chiave collegata al dispositivo, a un segreto dell’account, a un metodo di recupero o al destinatario previsto.
• Solo i dati cifrati vengono trasmessi o archiviati da remoto. Un server può comunque richiedere informazioni operative minime per consegna, sincronizzazione, prevenzione degli abusi o gestione dell’account.
• Un dispositivo autorizzato decifra il file. La decifratura avviene solo dopo che il dispositivo dispone del materiale di chiave necessario e l’utente soddisfa le condizioni di accesso.

Il passaggio di protezione della chiave è essenziale. Cifrare un file localmente offre una riservatezza limitata se lo stesso fornitore può recuperare silenziosamente la chiave di decifratura dai propri server. Al contrario, un modello in cui solo tu e i destinatari previsti detenete chiavi private utilizzabili crea una separazione più netta fra chi gestisce l’infrastruttura e chi è autorizzato a leggere il contenuto.

I metadati sono dati che descrivono il file, anziché il suo contenuto principale. Esempi sono nome e dimensione del file, ora di caricamento, identificativi di mittente e destinatario, informazioni sul dispositivo, struttura delle cartelle, indirizzo IP e cronologia di condivisione. La crittografia lato dispositivo può cifrare il corpo del file lasciando visibili o necessari alcuni metadati per il funzionamento del servizio.

Non è automaticamente un difetto di progettazione. Un servizio di consegna può dover sapere che un pacchetto cifrato è in attesa per un determinato account. Il punto importante è la trasparenza: le dichiarazioni sulla privacy dovrebbero distinguere fra contenuto cifrato, cronologia locale protetta e metadati minimi necessari per operare. Se anche i metadati sono sensibili, come un nome file rivelatore o la relazione con un destinatario, conviene cercare un modello che li riduca al minimo o li cifri a sua volta.

Se implementata correttamente, la crittografia lato dispositivo protegge soprattutto la riservatezza di un file mentre attraversa le reti e quando le sue copie cifrate risiedono su sistemi remoti. Può ridurre l’esposizione a violazioni dell’archiviazione cloud, accessi non autorizzati all’infrastruttura e accessi interni che non dispongono delle chiavi necessarie per decifrare il contenuto.

• Intercettazione di rete: il traffico cifrato acquisito non dovrebbe rivelare il documento sottostante senza le chiavi corrette.
• Esposizione dell’archiviazione remota: una copia di database o bucket di archiviazione contenente testo cifrato non dovrebbe bastare per leggere i file protetti.
• Accesso cloud troppo ampio: può ridurre la quantità di contenuti sensibili accessibili a un fornitore di archiviazione o al suo personale.
• Accumulo centrale non necessario: i modelli local-first possono evitare di trattare un archivio cloud permanente come destinazione predefinita di ogni file sensibile.
• Alcuni incidenti a livello di account: in base al modello di chiavi, un attaccante che ottiene la password di un account cloud potrebbe comunque non riuscire a decifrare il contenuto senza un segreto locale separato o un dispositivo affidabile.

Prendiamo il caso di un freelance che invia il documento fiscale di un cliente. Senza cifratura locale, il documento potrebbe risultare leggibile in più punti: nella casella email, in un servizio di anteprima cloud, nella cache degli allegati e nei backup. Con la crittografia lato dispositivo, il servizio remoto può invece gestire un pacchetto cifrato. Il modello di esposizione cambia, anche se il freelance deve comunque scegliere attentamente il destinatario e proteggere il proprio dispositivo.

La cifratura è efficace proprio perché i suoi confini possono essere descritti con chiarezza. La crittografia lato dispositivo protegge i dati prima che lascino l’ambiente locale; da sola non rende sicura ogni fase del ciclo di vita di un file.

• Un dispositivo rubato e sbloccato: se il dispositivo è aperto e l’app è accessibile, la cifratura a riposo potrebbe non costituire più una barriera efficace.
• Malware o spyware sul dispositivo: software dannoso può acquisire un file prima della cifratura, dopo la decifratura o mentre viene visualizzato.
• Autenticazione debole: un PIN facile da indovinare, una password riutilizzata o un canale di recupero non protetto possono esporre le chiavi che proteggono i dati cifrati.
• Il destinatario previsto: dopo aver decifrato un file, un destinatario può salvarlo, copiarlo, fotografarlo o inoltrarlo, salvo controlli separati che limitino tali azioni.
• Perdite di metadati: la cifratura del contenuto potrebbe non nascondere ogni informazione su chi ha comunicato, quando o quanti dati sono stati scambiati.
• Implementazione inadeguata: una progettazione crittografica debole, una gestione non sicura delle chiavi o codice non verificato possono annullare i vantaggi suggeriti dall’etichetta.

Ecco perché la privacy non dovrebbe dipendere dal fatto che gli utenti ricordino una lunga lista di precauzioni a ogni condivisione. Sono importanti impostazioni predefinite solide: cifratura locale, sessione dell’app protetta, dati conservati al minimo e controlli di condivisione chiari lavorano insieme per rendere più semplice la scelta più sicura.

La distinzione più utile non è se un servizio afferma di “usare la cifratura”. La maggior parte dei servizi affidabili lo fa. La differenza è se il servizio cifra i dati dopo averli ricevuti oppure se il tuo dispositivo li cifra prima di inviarli, e se il fornitore può accedere alle chiavi di decifratura.

La cifratura cloud non è inutile né intrinsecamente insicura. È spesso appropriata quando un servizio richiede ricerca lato server, anteprime web, collaborazione in tempo reale, recupero dell’account gestito dal fornitore o amministrazione centralizzata. La crittografia lato dispositivo è più adatta quando la priorità è ridurre l’accesso del fornitore ai contenuti sensibili e mantenere il controllo sui file al di fuori di un archivio centrale permanente.

La crittografia lato dispositivo e la crittografia end-to-end si sovrappongono, ma non sono termini identici. La prima descrive la cifratura locale prima che i dati lascino il dispositivo. La crittografia end-to-end descrive un modello di comunicazione in cui solo gli endpoint, di norma mittente e destinatario previsto, possono decifrare il contenuto di messaggi o file.

Un sistema di condivisione file può usare la crittografia lato dispositivo senza offrire un modello end-to-end completo fra destinatari, per esempio quando i file vengono cifrati localmente per il backup personale dell’utente. Viceversa, un servizio di condivisione con cifratura end-to-end si basa normalmente sulla cifratura agli endpoint, ma la sua sicurezza dipende anche da come le chiavi dei destinatari vengono verificate, ruotate, recuperate e revocate.

Per la condivisione di contenuti sensibili, entrambi i concetti sono importanti. Una buona domanda è: “Il file viene cifrato prima del caricamento e solo mittente e destinatario previsto possono ottenere le chiavi necessarie per leggerlo?”. Se la risposta non è chiara, il solo termine “cifrato” non fornisce informazioni sufficienti.

Non tutti i file richiedono lo stesso livello di protezione. La crittografia lato dispositivo è particolarmente utile quando una copia leggibile in un sistema di terze parti creerebbe un rischio personale, professionale, legale o reputazionale rilevante.

• Documenti di identità e amministrativi: scansioni di passaporti e carte d’identità, documenti fiscali, domande per prestazioni e moduli firmati.
• Contenuti multimediali privati: foto di famiglia, immagini intime, immagini mediche o media con dettagli identificativi.
• File di clienti e dipendenti: contratti, fatture, materiali finanziari e documenti che contengono dati personali.
• Condivisione temporanea: un file di cui il destinatario ha bisogno per poco tempo, ma che non dovrebbe restare disponibile senza scadenza.
• Backup locali di dati sensibili dell’app: quando vuoi una copia recuperabile senza lasciare archivi leggibili in un generico account cloud.

Le foto private meritano attenzione specifica perché un file può esporre più della sua immagine visibile. I metadati della fotocamera possono rivelare luogo, orario, dettagli del dispositivo o cronologia delle modifiche. Prima di condividere, rimuovi dove possibile i metadati non necessari, cifra il file localmente e valuta se il destinatario abbia davvero bisogno di una copia alla risoluzione originale. La cifratura protegge trasferimento e archiviazione; non modifica automaticamente ciò che l’immagine rivela dopo l’apertura.

La protezione dipende anche dal momento in cui la foto viene aperta e da chi può conservarne una copia. Per questo, prima di inviare immagini particolarmente sensibili, è utile distinguere tra la sicurezza del file durante il trasferimento e il controllo che resta possibile dopo la visualizzazione da parte del destinatario.

Il quadro seguente è uno strumento illustrativo di pianificazione, non un test di prodotto né una garanzia di riduzione del rischio. Usalo prima di scegliere un metodo di condivisione per un file che sarebbe difficile recuperare una volta copiato.

1. Classifica il danno. Chiediti cosa accadrebbe se il file fosse esposto: inconveniente, imbarazzo, furto d’identità, perdita finanziaria, violazione della riservatezza o danno a un’altra persona.
2. Mappa il percorso del file. Passerà da una casella email, una cartella cloud, il backup di un dispositivo, un sistema di anteprima o più destinatari? Più copie creano più punti in cui il controllo può venir meno.
3. Scegli il confine delle chiavi. Per contenuti molto sensibili, privilegia un modello che cifra prima del caricamento e non rende il fornitore l’unico detentore di chiavi di decifratura utilizzabili.
4. Imposta un limite temporale. Se l’accesso è temporaneo, usa una scadenza anziché lasciare disponibile indefinitamente un link o un allegato.
5. Pianifica il rischio legato al destinatario. Valuta se siano adatti revoca, limitazioni di visualizzazione, tracciamento o una versione meno dettagliata. Nessuna misura impedisce ogni copia, ma ciascuna può ridurre l’esposizione non necessaria.
6. Proteggi il recupero. Prima di affidarti al sistema, assicurati che accesso al dispositivo, PIN, biometria quando disponibile, materiale di recupero e backup cifrati siano protetti.

In uno scenario illustrativo, un piccolo studio di commercialisti deve inviare a un cliente due pagine di un documento d’identità e un modulo fiscale per una breve verifica. Lo studio non ha bisogno di una cartella condivisa permanente né di modifica collaborativa in tempo reale. Un flusso ragionevole consiste nel cifrare i file sul dispositivo del mittente, indirizzarli al destinatario previsto, impostare un breve periodo di accesso, conservare un registro locale di quanto condiviso e revocare l’accesso se cambia il destinatario. Questo non elimina la possibilità che un destinatario autorizzato copi il contenuto, ma restringe la finestra di esposizione ed evita che una normale casella email diventi l’archivio predefinito.

La cifratura prima del caricamento risolve un problema cruciale: limita l’esposizione mentre i file vengono archiviati e trasferiti. Non risolve del tutto il problema del controllo dopo che un destinatario può visualizzare il file. Per documenti, immagini e contenuti privati, la fase successiva alla consegna può essere il rischio maggiore.

Oblivio è progettato per questo problema di condivisione più circoscritto, ma importante. Protegge i file localmente e durante la condivisione con cifratura end-to-end, usando l’infrastruttura server per funzioni minime quali identificazione, consegna temporanea o sincronizzazione essenziale, anziché come archivio centrale permanente dei contenuti. La cronologia locale delle condivisioni può aiutare il mittente a capire quale destinatario ha ricevuto un file.

Quando appropriati per lo scenario di condivisione, scadenza e revoca dell’accesso aggiungono controlli che la sola cifratura non offre. Una scadenza può limitare il tempo in cui un file condiviso resta disponibile, mentre la modifica delle condizioni di accesso dopo l’invio può essere utile se le circostanze cambiano. Questi controlli gestiscono l’accesso tramite l’app e non costituiscono una promessa che un file già visualizzato non sia mai stato copiato.

Per le condivisioni a rischio più elevato conta anche la deterrenza. Oblivio può usare tracing collegato al destinatario e identificativi non evidenti nel file per rendere una ridistribuzione non autorizzata meno anonima. Può inoltre integrare misure anti-copia come controlli sugli screenshot supportati dal sistema operativo, visualizzazione condizionata e oscuramento basato su comportamento o sensori quando tecnicamente supportato. Queste misure dipendono dalle capacità del dispositivo e del sistema operativo. Possono rendere la copia meno immediata e aggiungere responsabilizzazione, ma nessun software può garantire che un destinatario non fotografi lo schermo con un secondo dispositivo.

• Supporre che “cifrato” significhi inaccessibile al fornitore. Verifica se la cifratura avviene prima del caricamento e se il fornitore può accedere alle chiavi.
• Ignorare la progettazione del recupero. Un reimpostazione della password comoda può essere utile, ma è importante capire se offre al servizio una via per decifrare i dati.
• Lasciare non protetti nomi rivelatori. Un nome come Referto-medico-Giulia-Rossi.pdf può divulgare informazioni sensibili anche quando il corpo del documento è cifrato.
• Confondere un canale sicuro con una condivisione controllata. Un trasferimento protetto non offre automaticamente scadenza, revoca, responsabilizzazione del destinatario o deterrenza contro le copie.
• Fare una condivisione irreversibile per un’esigenza temporanea. Invia una versione meno dettagliata, riduci la durata dell’accesso o evita l’invio se il destinatario non ha bisogno dell’originale completo.
• Dimenticare la sicurezza degli endpoint. Mantieni aggiornato il software del dispositivo, usa un blocco robusto e considera i codici di recupero chiavi sensibili, non semplici appunti.

Scegli in base al compito che il servizio deve svolgere, non soltanto all’etichetta “cifratura”. Un cloud privato può essere la scelta adatta per archiviazione cifrata a lungo termine e accesso generale ai file. Uno strumento di data room sicura può adattarsi alla collaborazione strutturata con clienti, autorizzazioni e controlli amministrativi. Uno strumento di condivisione controllata è più adatto quando, dopo l’invio, contano disponibilità del file, destinatario e possibile ridistribuzione.

• La cifratura avviene prima del caricamento ed è dichiarata chiaramente?
• Chi genera, conserva e può usare le chiavi?
• Quali contenuti e metadati vengono cifrati?
• Come vengono gestiti i nuovi dispositivi e il recupero dell’account?
• Puoi impostare, modificare o revocare l’accesso dopo la condivisione?
• Il sistema conserva per impostazione predefinita una copia cloud permanente?
• Puoi vedere localmente cosa è stato inviato e a chi?
• Cosa accade se la consegna diretta non è disponibile?
• Per i contenuti multimediali sensibili, esistono misure proporzionate per scoraggiare copie occasionali o identificare una diffusione non autorizzata?

Per chi ha bisogno soprattutto di un archivio personale cifrato e di un accesso ai file in stile cloud, strumenti come un archivio cloud con file cifrati possono rispondere a un’esigenza diversa e complementare. Oblivio è particolarmente adatto quando la preoccupazione non è soltanto dove viene archiviato un file, ma mantenere più controllo su un file sensibile dopo l’invio: associazione al destinatario, accesso temporaneo, revoca e responsabilizzazione diventano tutti parte della scelta.

Inizia identificando i file che non dovrebbero restare indefinitamente come comuni allegati email, caricamenti in chat o link cloud aperti. Per questi file, preferisci la cifratura locale prima del caricamento, usa un dispositivo protetto e scegli controlli di condivisione coerenti con la sensibilità effettiva e la durata necessaria dell’accesso. Rivedi questa configurazione quando aggiungi un nuovo dispositivo, cambi metodo di recupero o inizi a gestire informazioni più sensibili.

Quando il problema è la perdita di controllo dopo l’invio, più che il semplice trasferimento, Oblivio può aiutare a combinare protezione locale, durata dell’accesso, revoca, dati locali cifrati e registri di condivisione incentrati sul destinatario. La privacy diventa più pratica quando queste tutele sono parti normali di un flusso di lavoro, anziché passaggi riservati agli esperti da ricordare sotto pressione.

• La crittografia lato dispositivo cifra i file sul tuo dispositivo prima che raggiungano un server o una destinazione di rete.
• L’architettura è solida quanto la gestione delle chiavi: chiediti chi può ottenere chiavi di decifratura utilizzabili.
• Può proteggere il contenuto in transito e nell’archiviazione remota, ma non mette al sicuro un dispositivo infetto o sbloccato.
• Non impedisce automaticamente ai destinatari di copiare i file dopo la decifratura.
• Scadenza, revoca, registri locali delle condivisioni e tracing possono integrare la cifratura quando conta il controllo dopo l’invio.
• Valuta separatamente la cifratura del contenuto e la protezione dei metadati.