Intercambio de DEK y KEK (claves de cifrado) entre el servidor de aplicaciones y el servidor de claves

7

En mi aplicación, es necesario cifrar los datos de un usuario antes de insertarlo en la base de datos mysql. Estoy utilizando el algoritmo AES para cifrar los datos mediante un hash de 256 bits (y lo llamo clave de cifrado de datos, o DEK en breve).

Para hacer que el sistema sea más seguro, en lugar de almacenar DEK en texto sin formato en el servidor de aplicaciones, se almacena en forma cifrada (en_dek) en el servidor de aplicaciones. La clave para cifrar el DEK se almacena en un servidor totalmente independiente y se denomina Clave de cifrado de clave (KEK). Así que cada vez que se deben cifrar / descifrar datos, primero se usa KEK para descifrar el en_dek, que me da el DEK real, y luego se usa este DEK para cifrar / descifrar los datos del usuario.

Ahora mi pregunta es:

[1] ¿Debo enviar (en_dek + datos) al servidor de claves o debo buscar el KEK en el servidor de aplicaciones? ¿Cuál es la práctica más segura?

[2] Ambos métodos tienen la falla de que si un atacante puede obtener acceso a cualquiera de estos servidores, conocerá tanto KEK como DEK. ¿Cómo podemos prevenir esto?

[3] Cuando hablamos de rotación de teclas, ¿cuál de las dos teclas (DEK y KEK) se gira?

    
pregunta Nalin Gupta 18.03.2013 - 18:43
fuente

1 respuesta

10
  

¿Debo enviar (en_dek + datos) al servidor de claves o debo buscar el KEK en el servidor de aplicaciones? ¿Cuál es la práctica más segura?

Al enviar la clave en_dek al servidor de claves que debe manejarse, existe bastante información acerca de cómo funciona un módulo de seguridad de hardware a un nivel alto. La ventaja de este enfoque es que el material clave nunca toca el servidor de aplicaciones. Por lo tanto, cualquier compromiso del servidor de aplicaciones solo puede descifrar las claves que se encuentran actualmente en la memoria, así como también enviar solicitudes de descifrado al servidor de claves. Sin embargo, el atacante no obtiene acceso automáticamente a la clave maestra, lo que es importante.

Dado que ya está hablando de enviar los datos a otro sistema para ser descifrados, me pregunto si no sería mejor simplemente enviar los datos, ocultando así la clave completamente del servidor de aplicaciones.

En cualquier esquema como este, la seguridad de la clave depende completamente de la seguridad del servidor o HSM en el que está almacenada. Por lo general, los HSM verdaderos son razonablemente buenos para proteger las claves a menos que sea muy hábil con la electrónica.

  

Ambos métodos tienen la falla de que si un atacante puede obtener acceso a cualquiera de estos servidores, conocerá tanto KEK como DEK. ¿Cómo podemos prevenir esto?

No puedes, excepto mediante el uso de un HSM dedicado, que es esencialmente lo que estás discutiendo sobre la construcción. Yo simplificaría el esquema y mantendría las claves en un servidor dedicado solo a operaciones criptográficas, y mantendría ese servidor bloqueado.

Para obtener más información sobre estos dos puntos, consulte la

  

Cuando hablamos de rotación de teclas, ¿cuál de las dos teclas (DEK y KEK) se gira?

Idealmente, ambos. Rotar el KEK debería ser más fácil, ya que los DEK son de tamaño fijo y no debería haber tantos. La rotación de los DEK puede ser más difícil si está cifrando gran cantidad de datos.

Desde la página OWASP, que lo dice mejor que yo:

  

Rekeying se refiere al proceso de descifrar datos y luego volver a cifrarlos con una nueva clave. La reescritura periódica de los datos ayuda a protegerlos de compromisos no detectados de claves antiguas. El período de cambio de clave adecuado depende de la seguridad de las claves. Es posible que los datos protegidos por claves asegurados en módulos de seguridad de hardware dedicados solo necesiten una nueva clave cada tres años. Los datos protegidos por claves que se dividen y almacenan en dos servidores de aplicaciones pueden necesitar una nueva clave cada año.

    
respondido por el user2213 18.03.2013 - 19:42
fuente

Lea otras preguntas en las etiquetas