Eliminazione sicura di un oggetto Java

In realtà non puoi davvero "cancellare in modo sicuro" un array di caratteri in Java. Java esegue l'allocazione della memoria tramite un garbage collector , un software complicato che, in pratica, sposterà la memoria oggetti nella RAM fisica su base regolare. Quindi ciò che pensi come "un'istanza char[] " verrà copiato in più punti e la cancellazione avverrà fisicamente solo in uno di questi luoghi.

In tale contesto, "cancellazione sicura" non può realmente esistere in Java. Se si utilizza Java, è necessario assicurarsi che il contesto di utilizzo sia tale che l'eliminazione sicura non sia necessaria: la "cancellazione sicura" è necessaria soprattutto quando il sistema operativo può allocare blocchi RAM non azzerati (quindi un'applicazione può ottenere estratti di RAM vecchia da altre applicazioni ), o in presenza di memoria virtuale (parti della RAM copiate su un disco rigido). Immagino che questi non si applichino a un BlackBerry, quindi le semplici istanze di String dovrebbero andare bene.

Un altro modo per dichiarare che se l'istanza di String è non va bene per le password, allora hai problemi di sicurezza più grandi della semplice perdita di password. Dopo tutto, usi una password per proteggere l'accesso ad alcuni dati, quindi se hai bisogno di "cancellazione sicura" per una password, allora, abbastanza logicamente, avresti anche bisogno di "cancellazione sicura" per i dati protetti, e tutto ciò che fai con esso.

(Si può intuire che non sono un grande fan del concetto di "cancellazione sicura".)

in case I store a password in an object, how can I securely delete it?

Penso che tu intenda; come puoi impedire a un utente malintenzionato con accesso al dispositivo di recuperare la password?

Dipende dal livello di accesso che l'attaccante ha acquisito.

Se l'autore dell'attacco è limitato all'API esterna che fornisci (non una buona ipotesi), allora il controllo degli accessi utilizzando java.security.AccessController dovrebbe essere sufficiente. Se si progettano correttamente i controlli di accesso (molto difficile da eseguire) e l'utente malintenzionato non può ignorare i controlli di accesso, il controllo degli accessi impedirà all'utente malintenzionato di ottenere i dati.

Se l'autore dell'attacco è limitato a operare all'interno della Java virtual machine ma non della propria API, è necessario proteggere i dati con KeyStore.PrivateKeyEntry. A questo livello non puoi fare affidamento sul corretto funzionamento del tuo progetto per proteggere i dati e devi fare affidamento sulla macchina virtuale Java per fornire protezione.

Se l'autore dell'attacco è limitato al sistema operativo (non alla macchina virtuale Java), non è possibile proteggere i dati. Se l'utente malintenzionato può impedire il funzionamento della macchina virtuale Java come progettato, l'utente malintenzionato può ignorare qualsiasi meccanismo di sicurezza Java.

Se l'utente malintenzionato ha accesso fisico al dispositivo, è impossibile proteggere i dati da tutti gli attacchi. A questo livello, l'utente malintenzionato può leggere i dati mentre vengono scritti su RAM, flash, moduli hardware, ecc.

Hai ragione. Come hai sottolineato, il ciclo di vita degli oggetti (come le stringhe immutabili) è gestito dal garbage collector. Pertanto, se le informazioni sensibili sono contenute in una stringa, non è possibile sovrascrivere i dati riservati. Inoltre, il ciclo di vita di un array è gestito dal garbage collector, ma puoi sovrascrivere il contenuto, quindi se sovrascrivi il contenuto con dati casuali (o zeri), cancelli i contenuti.

Guardando il sito BlackBerry [1], sembra che la loro JVM supporti gli array char []. Se, per motivi non chiari, questo costrutto di base non è disponibile da BlackBerry JVM, è necessario memorizzare i bit riservati in un array [byte] che sovrascrive l'utilizzo del post.

[1] link

Se non proviamo a eliminarlo ma a sostituirlo con un valore insignificante, è più semplice. Anche string.value può essere sovrascritto dal set di caratteri inutili.