Oblivio
Un PIN può proteggere le chiavi di crittografia quando un’app usa il PIN per derivare una chiave di sblocco e poi usa quella chiave per decifrare, o unwrap, la chiave casuale separata che cifra davvero i file. In una progettazione solida, il PIN non è la chiave che cifra direttamente i file. È una parte di un sistema locale di controllo dell’accesso che dovrebbe includere anche un salt univoco, una funzione di derivazione della chiave deliberatamente onerosa, cifratura autenticata e limiti significativi ai tentativi ripetuti. Senza queste protezioni, un PIN breve può essere soltanto un blocco della schermata oppure può risultare vulnerabile a tentativi rapidi offline se qualcuno ottiene i dati cifrati e il materiale di supporto delle chiavi.
Questa distinzione è importante perché la privacy non dovrebbe richiedere di diventare crittografi. Un PIN è pratico nell’uso quotidiano; il compito dell’app è trasformare quel gesto semplice in una barriera progettata con cura attorno alle chiavi crittografiche che proteggono i dati locali.
Il ruolo del PIN, della chiave di crittografia e della chiave protetta
Una chiave di crittografia è un segreto ad alta entropia, di solito generato casualmente dal software. Un PIN è invece un segreto breve scelto o inserito da una persona. Hanno funzioni diverse: la chiave di crittografia protegge i dati dal punto di vista crittografico, mentre il PIN può controllare l’accesso a quella chiave.
- Chiave di cifratura dei dati (DEK): una chiave casuale usata per cifrare un file, un database o un archivio locale.
- PIN: un segreto inserito dall’utente per autorizzare l’accesso.
- Chiave di cifratura delle chiavi (KEK): una chiave derivata dal PIN e usata per proteggere la DEK.
- Chiave protetta: la forma cifrata della DEK, conservata insieme ai dati cifrati invece che in formato leggibile.
Il key wrapping consiste nel cifrare una chiave con un’altra chiave. Consente a un’app di cifrare i dati con una DEK casuale e robusta, permettendo al tempo stesso all’utente di sbloccare quella DEK tramite un processo basato sul PIN. Il PIN non deve essere memorizzato: quando viene inserito correttamente, l’app deriva di nuovo la stessa KEK.
Per una spiegazione più ampia del motivo per cui password o PIN non sono intercambiabili con una chiave crittografica, leggi la nostra guida sulle differenze tra chiave di crittografia e password.
Come funziona la protezione delle chiavi derivata dal PIN
Una progettazione locale tipica segue una sequenza come questa. Nel passaggio dalla teoria all’implementazione, è utile progettare PIN sicuri nelle app considerando l’intero flusso di sblocco.
- L’app genera casualmente una DEK ad alta entropia.
- La DEK cifra i file o il database locale usando cifratura autenticata.
- L’app genera un salt casuale e univoco.
- Quando scegli o inserisci il PIN, una funzione di derivazione della chiave combina PIN e salt per ottenere una KEK.
- La KEK protegge la DEK tramite key wrapping; vengono conservati la DEK protetta, il salt e i parametri necessari alla derivazione.
- Al successivo sblocco, l’app deriva nuovamente la KEK dal PIN inserito e usa quella chiave per sbloccare la DEK.
Se il PIN è errato, la KEK derivata non può sbloccare correttamente la DEK. Se la cifratura è autenticata, l’app può inoltre rilevare che il tentativo non è valido senza trattare dati corrotti o non autentici come se fossero contenuto leggibile.
Perché il PIN non dovrebbe cifrare direttamente i file
Un PIN, soprattutto se breve, ha molte meno possibilità rispetto a una chiave casuale moderna. Un PIN di quattro cifre ha soltanto 10.000 combinazioni; anche sei cifre restano una quantità limitata se un attaccante può provare ipotesi senza restrizioni.
Usare direttamente il PIN come chiave di cifratura dei file lega la sicurezza dell’intero archivio a un segreto facile da digitare ma relativamente debole. Separare i ruoli risolve questo problema: una DEK casuale protegge i dati, mentre il PIN controlla l’accesso alla DEK attraverso una procedura progettata per rendere costosi i tentativi.
Salt e derivazione lenta: perché entrambi contano
Il salt è un valore casuale non segreto associato al PIN. Viene conservato insieme ai dati cifrati perché non deve restare segreto. Il suo scopo è fare in modo che lo stesso PIN produca chiavi derivate diverse in archivi o dispositivi diversi, riducendo l’utilità delle tabelle di tentativi precalcolate.
Una funzione di derivazione lenta, o che richiede memoria, aggiunge un secondo ostacolo. Trasforma ogni tentativo di PIN in un’operazione più costosa per chi prova molte combinazioni. Non rende forte un PIN debole, ma rallenta in modo concreto il ritmo dei tentativi, soprattutto quando il materiale cifrato può essere copiato e analizzato offline.
La cifratura robusta protegge i dati solo finché la chiave resta inaccessibile. Se un PIN breve sblocca quella chiave, la derivazione lenta e i limiti ai tentativi diventano parte essenziale della protezione.
I limiti ai tentativi proteggono dal guessing
Un ritardo dopo ogni tentativo errato, un aumento progressivo dell’attesa, il blocco temporaneo o una politica di cancellazione sono misure diverse, ma perseguono lo stesso obiettivo: impedire che un PIN venga indovinato rapidamente sul dispositivo. Sono più efficaci quando l’ambiente che custodisce la chiave applica davvero tali limiti e non permette di aggirarli copiando il materiale necessario per provare i PIN altrove.
Per questo possono essere importanti anche le protezioni offerte dal sistema operativo o dall’hardware, come un archivio di chiavi protetto. Tali componenti possono richiedere un PIN, un codice del dispositivo o una verifica biometrica prima di autorizzare l’uso di una chiave, con controlli che un’app non può sempre applicare da sola.
Le app che proteggono file sensibili dovrebbero quindi considerare il PIN come un elemento di un insieme più ampio: cifratura locale, chiavi casuali, key wrapping, archiviazione protetta delle chiavi, limiti ai tentativi e un percorso di recupero valutato con attenzione.
Verifica in cinque domande della protezione da PIN a chiave
Quando valuti un’app o un archivio locale protetto da PIN, queste cinque domande aiutano a distinguere un semplice blocco dell’interfaccia da una progettazione che protegge effettivamente le chiavi. Sono utili anche per scegliere un’app per file privati con PIN e crittografia.
- Il PIN sblocca una chiave casuale separata? Cerca un modello in cui una DEK casuale cifra i dati e una chiave derivata dal PIN protegge quella DEK.
- La derivazione usa salt e parametri adeguati? Un salt univoco e una derivazione costosa riducono l’efficacia dei tentativi su larga scala.
- I dati sono cifrati e autenticati? La protezione dovrebbe rilevare modifiche o tentativi di decifrazione non validi, non solo nascondere il contenuto.
- Esistono limiti effettivi ai tentativi? Ritardi, blocchi e protezioni del sistema operativo riducono il rischio di tentativi ripetuti sul dispositivo.
- Esiste un piano di recupero che non annulli la sicurezza? Recuperare l’accesso può essere utile, ma una copia non protetta della chiave o un recupero troppo facile può creare un nuovo punto debole.
Questo schema è illustrativo: non sostituisce una verifica tecnica dell’implementazione. Aiuta però a porre le domande giuste prima di affidare file privati a un PIN.
PIN, biometria e archivi di chiavi protetti
L’impronta digitale o il riconoscimento del volto non derivano normalmente una chiave crittografica dalla caratteristica biometrica. Più spesso, una verifica biometrica riuscita autorizza il dispositivo a usare una chiave già protetta nell’archivio di chiavi del sistema operativo.
La biometria può rendere più pratico lo sblocco quotidiano, ma non elimina il ruolo del PIN o del codice del dispositivo. Questi rimangono importanti come alternativa, come percorso di recupero e come parte del modello di sicurezza scelto dal sistema operativo.
Per approfondire come le app possono conservare le chiavi sul dispositivo, leggi la guida su come le app proteggono le chiavi di crittografia in locale.
Un PIN può essere sufficiente?
Un PIN può offrire una protezione quotidiana significativa se è supportato dal dispositivo, da limiti ai tentativi e da un archivio di chiavi protetto. Non è però un segreto ad alta entropia per natura. Se un attaccante può copiare la chiave protetta, il salt e gli altri parametri e poi verificare ipotesi offline senza limiti, un PIN breve da solo è una difesa insufficiente.
La valutazione pratica dipende quindi da cosa protegge il PIN, da dove sono custodite le chiavi e da quanto è difficile provare tentativi ripetuti. Per il contesto più ampio sulla sicurezza dei file con PIN, è utile distinguere tra il blocco dell’accesso e la protezione effettiva dei dati.
La pianificazione del recupero è parte della sicurezza
Un sistema sicuro deve considerare anche cosa accade se il PIN viene dimenticato, il dispositivo viene perso o la chiave non è più disponibile. Un recupero progettato male può indebolire l’intero modello: per esempio, una chiave di recupero conservata senza protezione in un servizio remoto può diventare un punto di accesso più semplice del PIN stesso.
Prima di attivare una protezione, chiarisci quali dati possono essere recuperati, chi può avviare il recupero e quali copie esistono. Se perdi l’accesso al materiale crittografico, i file cifrati potrebbero restare irrecuperabili. Leggi anche cosa succede quando si perde una chiave di crittografia.