¿Qué criptografía previene y detecta las CA "invisibles"? (por ejemplo, en X509v4)

3

Para esta pregunta, estoy llamando a una "CA invisible" que

  • está firmado por una raíz ca y existe como segundo o tercer nivel
  • Es válido, no caducado ni revocado
  • Tiene una clave pública diferente a la que actualmente es dominante y activa

Este escenario podría ocurrir en realidad cuando

  1. Se renueva una subCA normal (root0-1) *
  2. Un operador rootCA malicioso o infectado por virus firma una CA adicional (root0-2) en el lateral
  3. El operador luego firma / renueva el legítimo & CA raíz esperada (root0-1 se convierte en root0-3).

Mi objetivo es obtener información sobre una jerarquía PKI dada como consumidor, o alguien que confía en un certificado emitido, y no confiar en auditorías de terceros y HSM con conteo clave.

Preferiría tener una promesa criptográfica que me dirá cuántas veces se ha emitido una sub-CA, y si esas CA emitidas están activas / no son revocadas.

  

Un concepto similar pero diferente es la longitud del camino; Estoy centrado en la cantidad de CA activas para un valor de ruta dado.

Credenciales de presentación limitadas

He oído hablar de técnicas criptográficas que limitan el número de veces que se puede usar una clave (como ECash) y que expondría un "secreto". En este caso, tal vez el "secreto" sería un booleano "complies with stated agreements" o "does not comply with stated agreements" . Pero hay fallas con este enfoque, como la necesidad del cliente de monitorear cualquiera y todas las subCAs que se transmiten para detectar incluso un evento de este tipo.

Pregunta

¿Existe un enfoque más sensato (en teoría) para que los clientes verifiquen este aspecto de la integridad de PKI? (o cualquier red de confianza de "autoridades")

    
pregunta random65537 13.07.2014 - 04:10
fuente

1 respuesta

2

En este momento , en X.509, no existe el seguimiento de un número de usos de una clave determinada. Esto es parte de lo que significa "X.509 está libre de contexto": la validación se refiere a si la ruta del certificado que tiene delante es válida o no, independientemente de si se le mostró una ruta similar o algo diferente 5 Hace unos minutos, cuando hablaba con el "mismo" servidor para alguna noción de "igual".

Otro punto importante de X.509 es que las CA rogue están fuera de alcance . Esto parece paradójico, pero la idea es que cuando una CA queda bajo control hostil, entonces esa CA se "pierde" y lo único que se puede hacer con ella es cortar toda la rama del árbol, revocando los certificados correspondientes a los comprometidos. Clave CA (donde "compromiso" significa "la clave privada se usó con fines hostiles", no necesariamente "se robó una copia de la clave privada"). Para una CA raíz comprometida, la única corrección posible es eliminarla de los almacenes de confianza de todos los clientes, ya que la CA raíz, que es autoemitida, no puede ser revocada.

(Cuando Microsoft empuja un parche de Windows que elimina una CA raíz del almacén de confianza predeterminado, esto puede verse como una especie de revocación, en cuyo caso la CA raíz no es realmente "raíz", siendo la "raíz verdadera" Microsoft. Pero todo esto ocurre fuera de X.509.)

En el escenario que describe, lo que hizo el atacante con la clave privada de la raíz no se puede detectar mientras el atacante no usa el certificado fraudulento. Esto es inevitable, de una manera matemática sólida: si el atacante puede obtener acceso al estado completo de la CA raíz, puede "clonarlo" y usar la clave privada en sus propias máquinas; el estado de la CA raíz no se ve afectado. Lo que estás pidiendo es algo de magia criptográfica que mantendría un "contador de uso" que el atacante no podría alterar a voluntad incluso cuando puede ver el estado completo. Mientras las computadoras sean lo que son, esto no es factible. Para obtener un registro del número de firmas emitidas, a fin de detectar confiablemente firmas falsas, necesitará algo más, por ejemplo. almacenar la clave privada raíz en un dispositivo resistente a la manipulación indebida (un HSM) que mantendrá el contador y, por ejemplo, lo usará como parte del número de serie para todos los certificados emitidos (permitiendo la auditoría del lado del cliente). Realmente se trata de cambiar el modelo seleccionando un "núcleo de CA raíz" que el atacante no puede aprovechar.

Conceptualmente, podríamos imaginar un sistema de base de datos distribuida (similar al que se usa en Bitcoin) donde se insertan todas las firmas, en un formato que contiene un "contador de firmas". Esto supone lo siguiente:

  • El algoritmo de firma se modifica para que funcione sobre h (c || m) en lugar de h (m) ( c is el contador, m los datos firmados y h una función hash criptográfica).
  • Todos los valores de firma se almacenan, indexados por firmante y valor de contador, en la base de datos global (por lo tanto, se detectan duplicados).
  • Los verificadores (clientes) no aceptan una firma a menos que puedan encontrarla en la base de datos.
  • Los verificadores imponen un comportamiento de contador específico, que les permite darse cuenta cuando una CA ha hecho más firmas de las esperadas.
  • Los atacantes no pueden modificar la base de datos distribuida.

X.509 no admite nada de esto, ni ahora ni en el futuro previsible. No hay una base de datos global de valores de firma, y como se supone que X.509 se puede utilizar en contextos fuera de línea, no habrá una. Además, en X.509, los verificadores son sin estado: no hacen un seguimiento del historial de verificación, y se supone que es una característica deseable.

Los algoritmos criptográficos para detectar el doble gasto en los protocolos de efectivo electrónico realmente son una versión abreviada del concepto de "base de datos": se producen a nivel bancario, cuando el banco de hecho ve ambas transacciones. Por lo tanto, los protocolos de efectivo electrónico se realizan de modo que la identidad del gastador se revele en caso de doble gasto, durante esta fase de correlación .

    
respondido por el Thomas Pornin 13.07.2014 - 15:32
fuente