¿Cómo puedo asegurarme de que un objeto Java (que contiene material criptográfico) esté en cero?

Question

Mi preocupación es que las claves criptográficas y los secretos administrados por el recolector de basura se pueden copiar y mover en la memoria sin cero.

Como posible solución, es suficiente con:

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: Tenga en cuenta que mi problema es con respecto no sólo zeroization de la copia oficial (referencia) del objeto, sino también todas las copias obsoletas las El recolector de basura puede haber hecho mientras baraja la memoria para ahorrar espacio y acelerar la eficiencia.

El ejemplo más simple es el marcado y barrido GC, donde los objetos se marcan como 'referenciados' y luego todos esos objetos se copian a otra región. El resto son basura y entonces son recolectados. Cuando se produce la copia, eso puede dejar datos de clave residual que el recolector de basura ya no está gestionando (porque los datos 'oficiales' están en la nueva región).

Una prueba de fuego para esto sería si utiliza una clave en el módulo de cifrado, ponga a cero la clave, luego inspeccione todo el espacio de proceso de JVM, debería no buscar esa clave.

Answer 1

Así que he llegado a la conclusión, de @jambjo y @james, de que realmente no hay nada que pueda hacer para evitar que las claves se copien y desaparezcan.

La mejor estrategia, como desarrollador, sería bajar la biblioteca de cifrado a C (o cualquier otro lenguaje no administrado) e implementar allí sus cosas.

Estaría más que dispuesto a aceptar una respuesta de otra persona si pudieran encontrar una solución mejor.

Answer 2

El Java Cryptography Extension Reference Guide aconseja utilizar siempre matrices de caracteres en lugar de cadenas para las contraseñas, de modo que puedan ponerse a cero posteriormente. También proporcionan un ejemplo de código de how you could implement it.

Answer 3

Lo mejor es utilizar allocateDirect en NIO. En una implementación sensata, eso no debería moverse. Pero probablemente sea elegible para buscar en el disco (podría sondearlo, supongo) e hibernación.

Answer 4

¿Qué si los datos en la memoria no se sobrescriben en un momento específico? Si tiene que preocuparse de que un atacante lea la memoria de su máquina, es el problema, no lo que pudo encontrar allí ni a qué hora.

¿Qué actual escenario de ataque ¿le preocupa dónde se han dejado las teclas en algún lugar en la memoria de una JVM podría ser un problema grave? Si un atacante puede mirar la memoria de la JVM, también puede capturar esas teclas mientras todavía las está usando.

Y si le preocupa que un atacante se ejecute como un usuario normal en el sistema al obtener la memoria descartada por la JVM: AFAIK todos los sistemas operativos modernos sobrescriben la memoria recién asignada con ceros.