Come posso garantire che un oggetto Java (contenente materiale crittografico) venga azzerato?

Question

La mia preoccupazione è che le chiavi e i segreti crittografici gestiti dal garbage collector possano essere copiati e spostati nella memoria senza azzeramento.

come una possibile soluzione, è sufficiente:

public class Key { 
    private char[] key; 
    // ... 
    protected void finalize() throws Throwable { 
    try { 
     for(int k = 0; k < key.length; k++) { 
     key[k] = '\0'; 
     } 
    } catch (Exception e) { 
     //... 
    } finally { 
     super.finalize(); 
    } 
    } 
    // ... 
} 

EDIT: Si prega di notare che il mio problema è per quanto riguarda non solo zeroization della copia ufficiale (riferimento) dell'oggetto, ma anche tutte le copie stantii le il garbage collector può averlo fatto mentre mescola la memoria in giro per lo spazio e velocizza l'efficienza.

L'esempio più semplice è il GC mark-and-sweep, in cui gli oggetti sono contrassegnati come "referenziati" e quindi tutti gli oggetti vengono copiati in un'altra regione. Il resto sono quindi spazzatura e quindi vengono raccolti. Quando la copia avviene, ciò potrebbe lasciare dati chiave residui che non vengono più gestiti dal garbage collector (perché i dati "ufficiali" si trovano nella nuova regione).

Un banco di prova per questo sarebbe se si utilizza una chiave nel modulo di crittografia, azzerare la chiave, quindi ispezionare l'intero spazio del processo JVM, si dovrebbe non trovare quella chiave.

Answer 1

Quindi sono giunto alla conclusione, da @jambjo e @james, che non c'è davvero nulla che possa fare per impedire che le chiavi vengano copiate e diventate inspiegabili.

La migliore strategia, come sviluppatore, sarebbe quella di rilasciare la libreria di crittografia in C (o qualsiasi altra lingua non gestita) e implementare le proprie risorse lì.

Sarei più che disposto ad accettare una risposta da qualcun altro se riuscissero a trovare una soluzione migliore.

Answer 2

Il Java Cryptography Extension Reference Guide consiglia di utilizzare sempre matrici di caratteri anziché stringhe per password in modo che possano essere azzerate in seguito. Forniscono anche un esempio di codice di how you could implement it.

Answer 3

La soluzione migliore è utilizzare allocateDirect in NIO. Su un'implementazione sana, non dovrebbe essere spostato. Ma probabilmente sarà idoneo per il paging su disco (si potrebbe sondarlo, immagino) e ibernazione.

Answer 4

Quindi cosa se i dati in memoria non vengono sovrascritti in un momento specifico? Se devi preoccuparti di un utente malintenzionato che legge la memoria della tua macchina, è il problema, non quello che è riuscito a trovare lì a che ora.

Quale scenario di attacco effettivo sei preoccupato per le chiavi lasciate in qualche luogo nella memoria di una JVM potrebbe essere un problema serio? Se un attaccante può guardare la memoria della JVM, può anche prendere quelle chiavi mentre le stai ancora usando.

E se sei preoccupato per un utente malintenzionato in esecuzione come utente normale sul sistema che si impadronisce della memoria scartata dalla JVM: AFAIK tutti i sistemi operativi moderni sovrascrivono la memoria allocata di recente con gli zeri.