Eliminar un objeto Java de forma segura

En realidad, usted no puede realmente "borrar de forma segura" una matriz de caracteres en Java. Java realiza la asignación de memoria a través de un recolector de basura , un software difícil que, en la práctica, moverá la memoria objetos en la memoria RAM física sobre una base regular. Entonces, lo que piense como "una instancia de char[] " se copiará en varios lugares, y el borrado solo ocurrirá físicamente en uno de esos lugares.

En ese contexto, la "eliminación segura" no puede existir realmente en Java. Si usa Java, debe asegurarse de que el contexto de uso sea tal que la eliminación segura no sea necesaria: la "eliminación segura" es necesaria principalmente cuando el sistema operativo puede asignar bloques de RAM no a cero (por lo tanto, una aplicación puede obtener extractos de RAM antigua de otras aplicaciones). ), o en presencia de memoria virtual (partes de la RAM que se copian en un disco duro). Supongo que estos no se aplican a un BlackBerry, por lo que las instancias String simples deberían estar bien.

Otra forma de decirlo es que si String instance no está bien para las contraseñas, entonces tiene mayores problemas de seguridad que la mera fuga de contraseñas. Después de todo, usa una contraseña para proteger el acceso a algunos datos, por lo que si necesita un "borrado seguro" para una contraseña, entonces, lógicamente, también necesitará un "borrado seguro" para los datos protegidos, y todo lo que haga. con ello.

(Se puede suponer que no soy un gran fanático del concepto de "borrado seguro".)

  

En caso de que almacene una contraseña en un objeto, ¿cómo puedo eliminarla de forma segura?

Creo que quieres decir; ¿Cómo puede evitar que un atacante con acceso al dispositivo recupere la contraseña?

Depende del nivel de acceso que haya ganado el atacante.

Si el atacante está limitado a la API externa que proporciona (no es una buena suposición), entonces el control de acceso usando java.security.AccessController debería ser suficiente. Si diseña sus controles de acceso correctamente (es muy difícil de hacer) y el atacante no puede pasar por alto los controles de acceso, entonces el control de acceso evitará que el atacante obtenga los datos.

Si el atacante está limitado a operar dentro de la máquina virtual Java pero no a su API, debe proteger los datos con KeyStore.PrivateKeyEntry. En este nivel, no puede confiar en el correcto funcionamiento de su diseño para proteger los datos y debe confiar en la máquina virtual Java para brindar protección.

Si el atacante está limitado al sistema operativo (no a la máquina virtual Java), no podrá proteger sus datos. Si el atacante puede evitar que la máquina virtual de Java funcione como se diseñó, entonces el atacante puede omitir cualquier mecanismo de seguridad de Java.

Si el atacante tiene acceso físico al dispositivo, es imposible proteger los datos contra todos los ataques. En este nivel, el atacante puede leer datos a medida que se escriben en la memoria RAM, flash, módulos de hardware, etc.

Tienes razón. Como señalaste, el recolector de basura administra el ciclo de vida de los objetos (como cadenas inmutables). Por lo tanto, si la información confidencial está en una cadena, no puede sobrescribir los datos confidenciales. Además, el recolector de basura administra el ciclo de vida de una matriz, pero puede sobrescribir el contenido, por lo que si sobrescribe el contenido con datos aleatorios (o ceros), "eliminará" el contenido.

Mirando el sitio de BlackBerry [1], en realidad parece que su JVM admite matrices char []. Si, por razones poco claras, esta construcción básica no está disponible desde BlackBerry JVM, debe almacenar sus bits confidenciales en una matriz de bytes [] que sobrescriba el uso posterior.

[1] enlace

Si no intentamos eliminarlo, pero lo anulamos con un valor sin sentido, es más fácil. Incluso string.value puede ser anulado por un conjunto de caracteres inútil.