Buena forma de proteger muchas claves privadas

Cómprese un HSM.

Entonces es tu elección:

1. Almacena las claves en el HSM; o
2. Cree una clave de cifrado en el HSM y cifre las claves almacenadas en la base de datos utilizando la clave almacenada en el HSM.

Una solución basada en HSM de alguna descripción es la única forma real de obtener una seguridad real contra ataques. Los HSM están diseñados de manera robusta para la seguridad y están diseñados explícitamente para que sea imposible obtener acceso a los datos clave almacenados en el HSM.

El uso de una frase de contraseña diferente para cada clave significa que luego tendrá el problema de averiguar dónde guardar las frases de contraseña. Es un poco mejor porque la frase de contraseña puede almacenarse por separado, y darse cuenta (comprometer?) El activo requiere que se comprometan tanto la frase de contraseña como la clave protegida.

La cantidad de entradas que describe implica que necesitará cierta automatización para reunir la clave y la contraseña (por ejemplo, una aplicación html5 que se conecte a 2 servicios diferentes con autenticación separada). Ese es el eslabón débil en la aplicación. Pero no nos ha dicho nada sobre la interfaz del sistema.

  

Estoy trabajando en un software que se ocupa de muchos (varios millones) de claves privadas RSA. ... aplicar la misma frase de contraseña a millones de claves privadas

Definitivamente estás haciendo algo fundamentalmente incorrecto, no hay una buena manera de proteger millones de claves en un solo servidor. Te sugiero que busques otro diseño donde no necesites millones de claves privadas. ¿Qué problema crees que puedes resolver con un millón de llaves? ¿Qué hay de malo en tener una sola clave RSA representándote?

  

que mejores opciones tengo

Simplemente use un cifrado de disco completo y no necesita cifrado por registro. Tendrá efectivamente el mismo nivel de seguridad y será mucho más fácil de administrar, lo que significa que es menos probable que cometa errores que puedan comprometer la seguridad.

Si desea una sugerencia que mejore la seguridad, tendrá que describir un poco más qué es lo que está construyendo, de lo contrario, cualquier consejo aquí no irá a ninguna parte.

Sin embargo, es probable que pueda hacer algo como el sistema de CA en el que solo tiene unas pocas claves de CA raíz con huecos de aire que solo se utilizan para emitir certificados de CA intermedios. Son los certificados de CA intermedios que se utilizan para la emisión diaria de certificados de acceso. No debe tener un solo servidor con millones de claves privadas, sino que, en cambio, su único servidor debe almacenar certificados (el certificado es una clave pública + atributos + fecha de caducidad + firma criptográfica realizada por la AC). Solo necesita una clave privada para cada persona, pero puede crear varios certificados a partir de una sola clave, afirmando varios atributos (reclamos) sobre el propietario de la clave privada. El propietario de la clave privada puede enviar estas reclamaciones a la parte que confía, lo que verifica si el propietario de la clave tiene permiso de acceso o no.

Tengo un esquema disponible que se puede usar para PKI, incluido depósito en garantía que podría ayudar. Es parte de un proyecto más grande que trata la complejidad de la vida útil de las claves de cifrado.

En el pasado hice algo similar y decidimos agregar un campo a la tabla que contiene las claves en un token. Ese token era la clave de otra tabla, que estaba en una base de datos diferente, que contiene las claves de la otra. Probablemente hay una forma mejor, pero esto fue suficiente para nosotros.

Primero: Sí, usa PKCS # 8. Es el estándar y ampliamente utilizado. Es probable que una implementación de cifrado personalizada sea defectuosa, menos conveniente y tenga menos herramientas.

Con respecto al intercambio de contraseñas en las claves:

Todo depende , pero al final, querrá restringir adecuadamente el acceso a las teclas para que una operación solo tenga acceso a las teclas que necesita.

Si todas estas claves son utilizadas por la misma persona / proceso simultáneamente, no tiene mucho sentido cifrarlas con contraseñas diferentes, ya que las contraseñas deberán ser accesadas todas juntas de todos modos.

Por otro lado, si almacena una clave por empleado (por ejemplo), cada empleado puede obtener la contraseña de su clave y solo su clave. De esa manera, una contraseña comprometida no pone en riesgo todas las claves privadas.

Por supuesto, puede ir entre las dos, agrupando claves, etc., dependiendo de lo que sea más apropiado para su situación.