JKS - Archivo de configuración y protección del almacén de claves

3

Parece que el servidor web utiliza a menudo Java Keystore mediante un archivo de configuración, con la contraseña que abre el JKS escrito y también la contraseña que protege la entrada específica.

¿Cómo podría eso ser considerado seguro? Con este esquema, el "problema secreto" se ha movido al archivo. Incluso si el archivo está protegido por derechos de usuario, debe estar cifrado, ¿no es así? ¿Pero eso significaría que cada vez que se inicia el servidor web, el administrador debe ingresar una contraseña para generar la clave simétrica (PBKDF2) y descifrar el archivo?

Me gustaría saber más sobre cómo se gestiona esto de manera segura.

    
pregunta crypto-learner 26.03.2015 - 10:52
fuente

2 respuestas

2

Como mencionó @whoami, simplemente mueve el problema a otro lugar. Como mencionó, le permite moverlo fuera del código (si lo ha codificado), protegerlo con contraseña (si originalmente era solo un PEM o cualquier otro elemento en el disco) y ACL a los permisos necesarios.

El problema es que necesitas conocer la clave para desbloquearla, y eso, por supuesto, requiere algún tipo de protección, y bueno, obtienes tortugas hasta el final.

Lo que básicamente estás haciendo es mover la barra de los atacantes para que tengan que hacer un mayor esfuerzo para romper la cosa. En algún punto, simplemente dicen que se atornillan y siguen adelante. Puede hacer que sea más difícil introduciendo la complejidad en la generación de claves, pero si los atacantes saben cómo funciona esto, pueden hacerlo ellos mismos con bastante facilidad o, lo que es peor, pueden robar el archivo e intentar el acceso forzado a la clave, ya que no es particularmente aleatorio. En algunos casos, el sistema operativo proporciona un mecanismo para proteger las claves aleatorias, pero en este caso necesitaría algo que esté expuesto a la JVM.

Las soluciones más prácticas implican mover la clave a áreas mejor protegidas, y eso generalmente significa hardware de algún tipo. En algunos casos, estamos hablando de TPM, HSM o simplemente tarjetas inteligentes (aunque en realidad son todas lo mismo, pero con diferentes características). El principio básico es que la llave nunca abandona el hardware, por lo que es imposible robarlo. Un efecto colateral de esto es que todo el cifrado suele ocurrir en el propio hardware, por lo que todo lo que está haciendo es empujar los datos y sacarlos, sin tener que preocuparse por el cifrado.

Esto significa que necesita proteger la interfaz del hardware para que solo los sistemas autorizados puedan hablar con él. ¿Ya viste a las tortugas?

    
respondido por el Steve 14.06.2015 - 22:03
fuente
0

Sí, tienes razón, todo lo que hace es mover el problema a otro lugar.

Hay varias formas de proteger la contraseña del Almacén de claves utilizando PBKDF2.

  1. Usar una contraseña que se necesita al iniciar el servidor de aplicaciones (como usted menciona).
  2. Componga la contraseña de PBKDF2 a partir de las "cosas" que sabe sobre su entorno de implementación; por ejemplo: concatenar el nombre de host, el nombre de usuario y la dirección MAC.

El número 2 tiene el beneficio de que ninguna persona tendrá que recordar (o anotar) la contraseña; También ayuda cuando un almacenista interno copia / roba su almacén de claves - > a menos que entiendan cómo se compone la contraseña.

La desventaja de usar 2. es que si, por ejemplo, su tarjeta de red falla y es reemplazada, no podrá obtener la clave necesaria para descifrar su contraseña del Almacén de claves.

Ambas formas mencionadas anteriormente son las formas en que personalmente lo he visto implementado.

    
respondido por el whoami 15.05.2015 - 13:55
fuente

Lea otras preguntas en las etiquetas