Hay un principio general de que las claves se deben usar para un solo propósito. De acuerdo con las Pautas de uso clave de NIST (consulte la sección 5.2 en la página 42) / p>
En general, una sola clave debe usarse para un solo propósito (por ejemplo,
cifrado, autenticación, ajuste de clave, generación de números aleatorios, o
firmas digitales). Hay varias razones para esto:
- El uso de la misma clave para dos procesos criptográficos diferentes puede debilitar la seguridad proporcionada por uno o ambos procesos.
- Al limitar el uso de una clave, se limita el daño que se podría hacer si la clave está comprometida.
- Algunos usos de las teclas interfieren entre sí. Por ejemplo, considere un par de claves utilizadas tanto para el transporte de claves como para las firmas digitales. En esto
En este caso, la clave privada se utiliza como clave de transporte privada de clave para
descifrar las claves de cifrado de datos y una clave de firma privada para aplicar
firmas digitales. Puede ser necesario conservar la clave privada-clave de transporte
Más allá del criptoperiodo del público correspondiente.
clave de transporte clave para descifrar las claves de cifrado de datos necesarias
Para acceder a los datos encriptados. Por otro lado, la clave de firma privada.
será destruida a la expiración de su criptoperiodo para prevenir
su compromiso (ver Sección 5.3.6). En este ejemplo, la longevidad.
Requisitos para la clave privada de transporte clave y el privado
la clave de firma digital se contradice entre sí.
Las mismas razones por las que las claves comunes deben tener un solo propósito también se aplican a una clave de firma de CA o una clave de firma de CA subordinada (SCA).
No puedo pensar en una vulnerabilidad específica en los certificados que la razón # 1 pueda crear, pero hemos visto suficientes vulnerabilidades criptográficas que se producen cada vez que se violan los principios, por lo que no lo descartaría por completo.
Con respecto al # 2, obviamente desea limitar el daño que podría hacerse si un servidor de firmas está comprometido. Cuando comienza a ejecutar su propia PKI, se da cuenta de lo frágiles que pueden ser los sistemas y lo fácil que puede ser cometer errores sutiles.
La razón # 3 entra en la flexibilidad del sistema. Por ejemplo, alguien en administración de propiedades puede comprar una solución de seguridad preempaquetada para construir el control de acceso, y puede tener sus propios requisitos para emitir certificados de SCA que no coincidan con su jerarquía actual de certificados de SCA. En lugar de interrumpir sus otros procesos de emisión de certificados, puede aislar el cambio solo al dominio afectado.
Por supuesto, no puede simplemente apilar certificados de CA subordinados como bloques de construcción. Cada enlace de SCA en la cadena de confianza significa otro certificado que debe validarse, y hay límites prácticos a la cantidad de certificados que pueden validarse antes de que el proceso sea demasiado oneroso para los clientes. Por esa razón, verá que las CA raíz de confianza no delegan a los certificados SCA en sus servidores de trabajo, incluso si esto segrega mejor su infraestructura. Pero las CA raíz de confianza tienen mucha experiencia en el campo y han diseñado sus sistemas enfocados en la seguridad de su arquitectura; Todos confiamos en ellos para hacer bien su trabajo. (La realidad cínica es que cada vez que una entidad emisora raíz ha cometido un error y se ha comprometido en el pasado, la pérdida de confianza significa que la empresa tiende a salir del negocio rápidamente).