Siempre hay un problema con el huevo y la gallina cuando quieres almacenar las claves privadas de forma segura, pero la aplicación necesita acceso automático a ellas. Si busca en este sitio, encontrará muchas preguntas relacionadas, por ejemplo:
Pregúntese cuál es su modelo de amenaza ; Si solo está preocupado por los atacantes remotos, entonces centre sus esfuerzos en fortalecer el perímetro de su servidor. Si nadie puede acceder a su servidor, entonces el cifrado con AES ya podría ser excesivo.
Si su modelo de amenaza incluye usuarios maliciosos en ese sistema, los usuarios que introducen malware en el servidor, o si cualquier aplicación que esté ejecutando el servidor es lo suficientemente compleja como para que pueda verse comprometida, es una buena idea proteger las claves en reposo. Como dices, nada es 100% seguro; un enfoque basado en software siempre será rompible por alguien con acceso de root al servidor y tiempo suficiente para estudiar los volcados de memoria de su programa. Parece que lo que estás haciendo es razonable. Algunas posibles mejoras:
- En lugar de tener la clave AES incrustada en el código fuente, haga que un administrador ingrese una contraseña en el inicio del proceso que se usa para derivar la clave AES. De esa manera, un atacante realmente necesita estar en su servidor tomando volcados de memoria en lugar de poder extraerlo de su código binario o fuente, lo que supongo que es más fácil de adquirir que un volcado de memoria de un servidor prod.
- Tal vez podría cifrar cada clave privada con su propia clave AES solo para aumentar la barrera entre obtener una clave y obtener todas las claves.
- El siguiente gran paso sería generar las claves en un hardware criptográfico dedicado para que las claves privadas nunca estén en el servidor. Opción barata: un montón de Tarjetas inteligentes PKI que cuelgan del servidor con mochilas USB. Opción costosa: un HSM de la red .