Come le app proteggono le chiavi di crittografia in locale

Categoria

Sicurezza locale

Pubblicato

Settembre 26, 2026

Tempo di lettura

11 min di lettura

Le app proteggono le chiavi di crittografia in locale mantenendo separata la chiave che cifra un file dal codice e dai dati che protegge, quindi ponendola dietro le difese del dispositivo. Un’architettura comune genera una chiave casuale per cifrare il file, la conserva nell’archivio protetto del sistema operativo e la cifra, o la incapsula, con un’altra chiave collegata al dispositivo, a un PIN oppure a entrambi. La biometria di solito sblocca l’accesso a questo materiale protetto, anziché diventare essa stessa la chiave di crittografia. Questo approccio a livelli fa sì che copiare soltanto un file cifrato non dovrebbe bastare per leggerlo. Evidenzia però anche un limite importante: se un dispositivo viene compromesso mentre è sbloccato, oppure se il sistema di recupero è debole, anche la crittografia locale può fallire. Le file encryption keys sono approfondite in un articolo dedicato.

Per una base più ampia, leggi cos’è una chiave di crittografia dei file e a cosa serve. In breve, è la chiave a eseguire il blocco crittografico; la differenza tra chiave e password è che password e PIN servono di norma a controllare l’accesso a quella chiave.

Le app ben progettate non cifrano ogni file direttamente con un PIN. Un PIN breve ha un’entropia troppo bassa per essere usato da solo e in sicurezza come chiave di file a lungo termine, soprattutto se un attaccante può effettuare tentativi illimitati. Le app combinano quindi normalmente più ruoli:

• Chiave di cifratura del file (DEK): un segreto casuale che cifra il file o il database locale.
• Chiave di cifratura delle chiavi (KEK): una chiave separata usata per cifrare, o incapsulare, la chiave di cifratura del file.
• Archiviazione sicura: un servizio protetto del sistema operativo che conserva chiavi sensibili o ne controlla l’uso.
• PIN o codice di accesso: la prova che chi apre l’app è autorizzato a richiedere la chiave.
• Verifica biometrica: un passaggio locale e pratico di approvazione, come l’autenticazione tramite impronta o volto, quando supportata dal dispositivo.

Questa separazione è utile perché i file possono essere cifrati con una chiave casuale robusta, mentre l’utente mantiene un modo pratico per sbloccare l’app. Consente inoltre di cambiare PIN o revocare una sessione senza dover necessariamente cifrare di nuovo ogni file protetto.

Il key wrapping, o incapsulamento delle chiavi, consiste nel cifrare una chiave con un’altra chiave. Puoi immaginarlo come una piccola chiave di grande valore riposta in un contenitore chiuso, invece di bloccare di nuovo ogni documento con un diverso segreto scelto dall’utente.

Per esempio, un’app può creare una chiave casuale per cifrare un documento privato. Poi cifra quella chiave casuale con una chiave vincolata al dispositivo e custodita nell’archiviazione sicura. L’app salva il documento cifrato e la chiave del file incapsulata. Quando l’utente autorizzato apre il documento, il sistema operativo consente di usare la chiave legata al dispositivo per rimuovere l’incapsulamento della chiave del file, che può così decifrare il documento.

Il key wrapping offre vantaggi pratici:

• La chiave del file può essere casuale e robusta senza dover essere memorizzata.
• Un database di file compromesso non espone automaticamente chiavi utilizzabili.
• Un’app può proteggere separatamente chiavi di file distinti, limitando l’impatto di un problema relativo a una singola chiave.
• Spesso si può aggiungere un nuovo metodo di accesso incapsulando nuovamente la stessa chiave del file, anziché cifrare di nuovo file di grandi dimensioni.

L’incapsulamento non è uno scudo magico. Se un attaccante ottiene dalla memoria la chiave già estratta su un dispositivo sbloccato e compromesso, oppure riesce a usare lo stesso percorso di autorizzazione dell’archiviazione sicura, la protezione può essere aggirata. La crittografia protegge al meglio i segreti quando il dispositivo e i relativi controlli di accesso restano affidabili.

Su telefoni e computer moderni, un’app dovrebbe evitare di conservare una chiave di crittografia in chiaro in un file di preferenze, in un normale campo di database, nei log, nei backup o nel codice sorgente. Può invece chiedere al sistema operativo di creare o proteggere una chiave nel portachiavi della piattaforma. A seconda del dispositivo, le operazioni crittografiche possono essere supportate da hardware progettato per isolare il materiale sensibile dalla normale archiviazione dell’app.

I nomi esatti cambiano da una piattaforma all’altra, ma l’obiettivo progettuale è costante: l’app dovrebbe richiedere un’operazione crittografica autorizzata, invece di leggere liberamente una chiave principale di lunga durata in un file normale. L’archiviazione sicura può anche applicare criteri quali richiedere che il dispositivo sia sbloccato, una recente autenticazione dell’utente o l’invalidazione del materiale protetto dopo determinate modifiche alla sicurezza del dispositivo.

Per indicazioni pratiche, consulta la guida su dove conservare le chiavi di crittografia. Conservare contenuti cifrati e la relativa chiave utilizzabile nello stesso luogo non protetto vanifica gran parte dello scopo della crittografia.

L’archiviazione di chiavi supportata dall’hardware può rendere più difficile l’estrazione, perché il materiale crittografico può non essere esportabile: il software può chiedere all’hardware di decifrare o firmare, ma non può semplicemente recuperare i byte segreti. È un miglioramento significativo rispetto alla semplice archiviazione locale. Non protegge però da ogni rischio, inclusi malware che agiscono mentre l’utente è autenticato, un dispositivo rubato e sbloccato, vulnerabilità software o un attaccante che conosce il codice di accesso al dispositivo.

Un PIN può aggiungere un livello separato di controllo, ma una progettazione sicura lo tratta con cautela. Invece di trasformare direttamente 1234 nella chiave di cifratura del file, un’app può elaborare il PIN con una funzione di derivazione della chiave basata su password e un salt casuale univoco. La chiave derivata risultante può aiutare a sbloccare una chiave dell’app incapsulata o ad autenticare una richiesta d’uso del materiale locale protetto.

Una funzione di derivazione rende deliberatamente più costoso ogni tentativo. Il salt garantisce che lo stesso PIN non produca lo stesso risultato per utenti o dispositivi diversi. Limiti locali ai tentativi, ritardi progressivi e criteri dell’hardware sicuro possono ridurre ulteriormente i tentativi rapidi. Questi controlli sono importanti perché un PIN viene scelto per praticità, non per robustezza crittografica.

La biometria è normalmente diversa da una chiave derivata dal PIN. L’app riceve un segnale di esito positivo o negativo dal sistema biometrico del dispositivo; non dovrebbe ricevere né conservare un’impronta digitale o un modello facciale. In molte architetture, un’autenticazione biometrica riuscita autorizza l’archiviazione sicura a rilasciare o usare una chiave protetta per un periodo limitato.

Il seguente schema è una checklist decisionale illustrativa, non un test di prodotto né una verifica di una specifica app. Aiuta a distinguere una protezione locale concreta dalle affermazioni vaghe secondo cui un file è semplicemente «cifrato».

• Chiediti che cosa viene cifrato. Solo la trasmissione oppure anche i file e la cronologia locale a riposo sul dispositivo?
• Chiediti dove risiedono le chiavi utilizzabili. Cerca l’uso dell’archiviazione sicura del sistema operativo o di una protezione vincolata al dispositivo, non file di chiavi in chiaro.
• Chiediti che cosa sblocca la chiave. PIN, codice di accesso e approvazione biometrica dovrebbero controllare l’accesso; non andrebbero confusi con la chiave casuale del file.
• Chiediti quale resistenza esiste ai tentativi offline. Un sistema basato su PIN dovrebbe usare un salt, una derivazione lenta e controlli pratici sui tentativi quando possibile.
• Chiediti come funzionano recupero e backup. Se il dispositivo viene perso, l’utente può recuperare i dati in modo sicuro? Se esiste un recupero, quale nuova superficie di fiducia o attacco introduce?
• Chiediti cosa accade su un dispositivo compromesso. Una documentazione di sicurezza onesta riconosce che la crittografia locale non può proteggere pienamente i dati mentre un software dannoso ha accesso a una sessione sbloccata.

La privacy non dovrebbe dipendere dal fatto che gli utenti ricordino manualmente un rituale complesso prima di ogni condivisione. Le progettazioni quotidiane più solide rendono l’archiviazione locale protetta l’impostazione predefinita, spiegando al tempo stesso con chiarezza il compromesso legato al recupero.

Immagina che un’app conservi localmente un documento d’identità cifrato. Il documento è cifrato con una chiave casuale del file. Tale chiave è incapsulata da una chiave che l’archiviazione sicura del telefono usa solo dopo che il dispositivo è stato sbloccato e l’app ha ricevuto l’approvazione tramite PIN o biometria. Chi copia i file cifrati dell’app dal telefono smarrito dovrebbe comunque non avere la chiave utilizzabile necessaria per decifrarli.

Ora cambia le condizioni: il telefono è stato rubato mentre era sbloccato, oppure l’attaccante conosce il codice di accesso del dispositivo e può aprire l’app. La crittografia locale potrebbe non impedire più l’accesso. Ecco perché possono contare tutti il codice del dispositivo, il blocco automatico, gli aggiornamenti tempestivi del sistema operativo e un controllo di accesso a livello di app. Lo scenario illustra compromessi progettuali; non descrive un risultato misurato né garantisce protezione contro un attacco specifico.

Quando un’app di condivisione mantiene la cronologia operativa e i dati sensibili principalmente sul dispositivo dell’utente, la protezione locale delle chiavi diventa parte del modello di privacy, non un dettaglio tecnico sullo sfondo. Oblivio è progettato attorno a dati locali cifrati, accesso protetto da PIN e, dove supportata, biometria. Lo scopo è ridurre lo sforzo necessario per trattare i file sensibili in modo diverso dai normali allegati.

Per esempio, inviare un documento attraverso un canale generico può risolvere la consegna, ma lasciare al mittente poco controllo in seguito. Oblivio aggiunge controlli come accesso limitato nel tempo, revoca, registri locali delle condivisioni e dati locali cifrati. La gerarchia interna precisa delle chiavi e i dettagli implementativi non dovrebbero essere presunti oltre il design documentato; per gli utenti conta che proteggere un file includa sia il livello di cifratura sia il modo in cui viene controllato l’accesso alle sue chiavi.

• Usare un PIN come unico segreto di cifratura. I PIN brevi richiedono limiti ai tentativi e derivazione della chiave; le chiavi casuali sono più robuste per proteggere i file.
• Salvare le chiavi in chiaro accanto ai file. Una cartella copiata non dovrebbe contenere sia il contenuto cifrato sia una chiave immediatamente utilizzabile.
• Registrare segreti nei log. Log di debug, rapporti di arresto anomalo, eventi analitici e operazioni sugli appunti possono esporre materiale che l’archiviazione sicura era pensata per proteggere.
• Confondere biometria e cifratura. La biometria è in genere un meccanismo di approvazione, non il segreto usato per cifrare il file.
• Aggiungere il recupero senza valutarne il rischio. Una chiave di recupero, il deposito in cloud o un dispositivo secondario possono evitare il blocco dell’accesso, ma ampliano chi o che cosa può sbloccare i dati.
• Presumere che la cifratura blocchi ogni fuga. Un destinatario autorizzato può comunque copiare, fotografare o divulgare il contenuto. Controlli di accesso e tracciabilità possono aumentare la deterrenza, ma non possono promettere un controllo totale dopo la visualizzazione.

Se la perdita delle chiavi è la tua principale preoccupazione, leggi cosa succede quando si perde una chiave di crittografia. Una crittografia robusta spesso implica che non esista un pulsante universale di ripristino, quindi il piano di recupero deve essere intenzionale.

• Le app proteggono le chiavi di crittografia locali separando le chiavi dei file dalle credenziali utente e dai dati dell’app.
• Il key wrapping cifra una chiave del file con un’altra chiave protetta, creando un utile livello di separazione.
• L’archiviazione sicura del sistema operativo e i controlli basati sull’hardware possono rendere l’estrazione delle chiavi molto più difficile.
• PIN e biometria autorizzano normalmente l’uso della chiave; non sostituiscono chiavi di cifratura dei file ad alta entropia.
• Dispositivi persi, meccanismi di recupero, sessioni sbloccate e malware restano limiti importanti da comprendere.

Per chi confronta modelli locali e incentrati sul cloud, la nostra guida alla crittografia lato dispositivo e crittografia cloud spiega dove cambia il controllo. Quando un file richiede più di una normale consegna, Oblivio offre un approccio più controllato alla gestione dell’accesso dei destinatari, della durata e della revoca.