¿Qué daño se podría hacer si un certificado malintencionado tuviera un “Identificador de clave del sujeto” idéntico?

Question

¿Qué daño se podría hacer si un certificado malintencionado tuviera un “Identificador de clave del sujeto” idéntico?

#1 de Thomas Pornin (16 votos)
#2 de Robert Siemer (0 votos)

11

Estoy viendo el Subject Key Identifier atributo de un Certificado de CA y estoy tratando de entender el rol que desempeña en la validación e inferir cómo la validación del software cliente podría hacer que no funcione correctamente.

¿Cuál es la función del identificador clave del sujeto en la validación de un certificado de CA o final?
Cualquier conocimiento de cómo se implementó los paquetes de software populares sería útil
¿Qué es lo peor que podría hacer un atacante si pudiera generar una clave pública que también contenga el mismo hash?

Al leer RFC3280 veo que el identificador clave del sujeto (SKI) es como el pegamento que se usa para construir y verificar la cadena PKI. El SKI también parece ser una versión más segura que el nombre y el número de serie del certificado que también se usó para unir dos certificados.

Con respecto a la validación de cliente del hash de certificado, los clientes simplemente hacen una "coincidencia de patrón" del SKI, o es el SKI de cadena realmente calculado como se describe a continuación:

Para los certificados de CA, los identificadores de clave de asunto DEBEN derivarse de
La clave pública o un método que genera valores únicos. Dos fotos comunes Los métodos para generar identificadores de clave a partir de la clave pública son:
  (1) The keyIdentifier is composed of the 160-bit SHA-1 hash of the
  value of the BIT STRING subjectPublicKey (excluding the tag,
  length, and number of unused bits).

  (2) The keyIdentifier is composed of a four bit type field with
  the value 0100 followed by the least significant 60 bits of the
  SHA-1 hash of the value of the BIT STRING subjectPublicKey
  (excluding the tag, length, and number of unused bit string bits).

Un ejemplo de riesgo que estoy tratando de mitigar es un certificado de CA con formato incorrecto con una clave pública que no tiene un hash correcto (hecho por la edición ASN.1 manual y que renuncia al certificado de la raíz del atacante)

public-key-infrastructure certificates certificate-authority threat-mitigation

pregunta random65537 10.01.2013 - 00:13

fuente

2 respuestas

0

Los identificadores clave de Rouge dificultarían la búsqueda de rutas no ambiguas.

En el peor de los casos, se deben verificar la validez de varias rutas potenciales. Pero ¿tendría un certificado con un identificador de colorete en su almacén de confianza de todos modos? Si no confías en él, no es necesario que revises esa ruta. Y si confía en él, entonces esa ruta no se validará.

respondido por el Robert Siemer 19.05.2016 - 22:58

fuente

Lea otras preguntas en las etiquetas public-key-infrastructure certificates certificate-authority threat-mitigation

¿Lista blanca o saneamiento de lista negra para comentarios internacionales? Mejores prácticas para la seguridad del correo electrónico

score 16 · Accepted Answer

El Subject Key Identifier no no desempeña un papel en la validación, al menos no en el algoritmo que compone la sección 6 de RFC 5280 . Se supone que es una ayuda para la creación de rutas , la actividad que se realiza antes de la validación: esto es cuando la entidad que quiere validar un certificado reúne posibles cadenas de certificados que luego se procesarán a través de la sección 6 algoritmo. La Sección 4.2.1.2 describe esta extensión e incluye este texto:

Para facilitar la construcción del camino de certificación, esta extensión DEBE aparecen en todos los certificados de CA conformes, es decir, todos los certificados incluida la extensión de restricciones básicas (Sección 4.2.1.9) donde la el valor de cA es VERDADERO. En los certificados de CA conformes, el valor de la el identificador de clave del sujeto DEBE ser el valor colocado en el identificador de clave campo de la extensión del identificador de clave de autoridad (Sección 4.2.1.1) de Certificados emitidos por el sujeto de este certificado. Aplicaciones no están obligados a verificar que los identificadores clave coincidan al realizar validación de la ruta de certificación.

Estos "DEBEN" son obligaciones de la CA: para cumplir con el perfil que describe RFC 5280, CA debe tener cuidado de hacer coincidir el Authority Key Identifier de los certificados que emite con su propio Subject Key Identifier . Tome nota de la última oración: esta coincidencia es no parte de lo que debe verificar la validación.

El RFC recomienda calcular el identificador de clave a través de hash, ya que minimizará las colisiones y, por lo tanto, garantizará la máxima eficiencia de esta extensión para la creación de rutas. Sin embargo, el hashing no es obligatorio. CA puede elegir el identificador de cualquier forma que crea conveniente; y los verificadores ciertamente no vuelven a calcular los identificadores. Esta es una prueba de igualdad de byte a byte puro. Además, sé que es un hecho que la implementación de la validación de rutas de Microsoft está lista para construir e intentar validar rutas donde los identificadores clave no coinciden.

Lo peor que podría hacer una CA deshonesta al reutilizar identificadores clave es dificultar la creación de rutas; esto podría desencadenar una especie de denegación de servicio para los verificadores que realizan la construcción de rutas a través de identificadores clave y son demasiado vagos para intentar lo contrario. En la práctica, los verificadores tienden a construir rutas al hacer coincidir el sujeto y el DN del emisor, no los identificadores clave, por lo que el impacto práctico debería ser casi nulo.