Generación de claves del dispositivo de seguridad

2

Para dispositivos como descifrar proxies HTTPS, a menudo hay un mecanismo incorporado para generar un par de claves y un CSR. A continuación, un administrador puede hacer que su autoridad interna firme el CSR con una plantilla de CA subordinada y vincule el certificado al CSR en el dispositivo. En este caso, la clave privada no abandona el dispositivo (y generalmente no se puede exportar).

Los mismos dispositivos a menudo ofrecen una opción para cargar una clave privada y un certificado cifrados. En este escenario, el administrador usaría (por ejemplo) OpenSSL para generar la clave y la CSR en una máquina separada, obtener el certificado y luego cargarlos. Las ventajas en ese caso son la capacidad de almacenar la clave privada para la copia de seguridad, posiblemente para especificar mayores longitudes de clave, y agregar información adicional a la CSR que puede no estar disponible en el asistente de generación en el dispositivo. Por supuesto, esto supone un proceso sólido de custodia / copia de seguridad de la clave.

Mi pregunta es: asumiendo que hay una máquina fuera de línea (o "bóveda") endurecida, dedicada para generar la clave y la CSR, ¿cuál es el método preferido? Desde la perspectiva de las mejores prácticas de seguridad, ¿debería generarse la clave en el dispositivo de destino utilizando el asistente o la máquina dedicada "OpenSSL"?

    
pregunta user185977 05.09.2018 - 19:21
fuente

2 respuestas

1

En general, debe generar pares de claves en el propio dispositivo. De esa manera, su clave permanece en la ubicación para la que se usa, minimizando la posibilidad de ataque. Además de eso, puede estar seguro de que el certificado es compatible con el protocolo. Los certificados siguen un protocolo estandarizado bien establecido (X509v3) pero sin duda todavía habrá diferencias en la implementación, solo por la complejidad de la estructura de datos.

Generalmente no hay necesidad de hacer una copia de seguridad. Si se pierde la clave, simplemente puede regenerar un nuevo conjunto de pares de claves - > CSR - > certificado. Esto se debe a que generalmente confía en un certificado de nivel superior al certificado raíz. Para una configuración profesional, no iría a pedir un certificado autofirmado (una cadena de certificados de longitud 1). Una de las razones para distribuir un certificado sería un clúster de equilibrio de carga en el que desea reutilizar la clave / certificado, que no se cuida automáticamente.

Si realmente requiere detalles de certificado especiales (un nombre específico, tamaño de clave, etc.), entonces puede importar la clave / certificado utilizando un almacén de claves PKCS # 12 o similar. Sin embargo, recuerde que muy pocas personas verán los certificados. Usted es la persona que asegura la infraestructura, después de todo.

Pasé la mayor parte del tiempo pensando en la accesibilidad de los certificados y, por supuesto, en el período de validez de sus certificados. Parece que intentas y sigues buenas prácticas de criptografía para esta parte de la configuración. Es hora de pensar en las otras partes. En general, el tiempo dedicado a dividir los pelos significa que se han olvidado otras partes del sistema.

    
respondido por el Maarten Bodewes 21.09.2018 - 13:12
fuente
1

Digo los comentarios de que el método que menos expone la clave debería ser preferido, es decir, generarlo en el dispositivo.

Si desea ser diligente, le preguntaría al fabricante cómo generan los números aleatorios y les pregunto por un medio para obtener un número de números aleatorios (por ejemplo, un par de 100,000) del dispositivo. Luego puedes someter esos números al azar a una prueba de aleatoriedad.

Otro punto a tener en cuenta es si el dispositivo implementa un cifrado y un amplificador de vanguardia; métodos hash, y si el fabricante proporciona actualizaciones de software. Si cualquiera de los dos puntos es negativo, es posible que prefiera generar certificados en un sistema diferente.

    
respondido por el c-alpha 20.12.2018 - 15:00
fuente