Verificación de archivos firmados criptográficamente cuando la clave ha sido revocada

7

Esto es principalmente una pregunta por curiosidad ociosa. Si utilizo mi clave privada para firmar un archivo hoy, formando una firma y distribuyo esa firma con el documento a alguien, entonces puede usar mi clave pública (que obtuvieron fuera de banda de manera segura) y la Firma y verifica que el documento permanezca inalterado. Hasta ahora todo bien.

Pero si el paso de verificación solo ocurre algún tiempo después, y mientras tanto revoco mi clave, ¿cómo debería manejarse?

Por un lado, el archivo se firmó de buena fe en un momento determinado y si el archivo tiene una marca de fecha y hora anterior a la fecha de revocación y la revocación no se debe a una clave comprometida, entonces la revocación no debería No significa automáticamente la desconfianza de la firma.

Por otra parte, suponiendo que se revocó la clave porque estaba comprometida, otra persona podría haber usado mi clave privada comprometida para firmar un archivo con una marca de tiempo falsa dentro de la colocación dentro del período activo de la clave.

Según tengo entendido, mientras más tiempo una llave permanezca 'activa', menos segura se vuelve, porque cuanto más tiempo ha habido para forzarla y más ha firmado / cifrado, más información hay disponible para usar. En varios ataques. Ahora comprendo que, teóricamente, el hecho de forzar una clave debe tomar más tiempo del que se necesita para que el universo sufra la muerte por calor, pero siempre es posible que se encuentren atajos en el futuro. Así que imagino que uno querría revocar las claves regularmente.

¿Hay alguna manera de distinguir la diferencia entre las dos situaciones descritas anteriormente?

¿Hay alguna manera de distinguir las diferencias entre una revocación debido al ciclismo y una revocación debido a un compromiso?

Parece (de esta pregunta ) que la revocación de claves regulares Ya no es la mejor práctica, pero no estoy 100% seguro de que estoy leyendo bien. En su lugar, la confianza en el primer uso y la "fijación" se utilizan en la práctica actual. También las respuestas y los comentarios en dicha pregunta dejan claro que no hay un mecanismo para caducar una clave. Después de haber leído brevemente el TOFU y anclaje , y no parece influir en mi pregunta.

Para evitar que esto se cierre con una queja "XY", permítame ser más explícito. En la situación de una clave comprometida mencionada anteriormente, no se me ocurre una manera de verificar de manera confiable el documento a pesar de que esté firmado por una clave no comprometida en el momento. Esto podría muy fácilmente ser un vacío en mi conocimiento, y quiero saber si hay técnicas para hacerlo de manera confiable.

    
pregunta sirlark 01.07.2015 - 13:59
fuente

2 respuestas

2
  

¿Hay alguna manera de decir las diferencias entre una revocación debido a   ¿Ciclo y revocación por compromiso?

Certificados .
Los certificados suelen incluir tiempos de validez, durante los cuales la clave pública asociada es válida para su uso. La mayoría de los certificados se emiten por 1 a 3 años y luego necesita completar el ciclo del certificado (y quizás también la clave asociada). Con la mejor TOFU y de anclaje seguirán viendo y verificando el certificado y no confiarán únicamente en la clave anclada, para garantizar que la clave siga siendo válida y no caduque ni revocada (que se maneja a través de OCSP y CRL s).

  

Pero si el paso de verificación solo ocurre algún tiempo después, y en el   Mientras tanto, revoco mi llave, ¿cómo debería manejarse?

Este es realmente un problema difícil, que requiere algunos (2) cambios en la forma en que los documentos y los datos se firman y verifican.

Primero, necesitamos cambiar los respondedores de OCSP. En este momento, normalmente solo obtiene "bueno", "desconocido", "revocado" o "suspendido" de la CA como respuesta. Claramente, esto no es suficiente, ya que necesita saber cuándo el certificado fue revocado o suspendido. Dada esta información antes la clave se vio comprometida . Por supuesto, esto todavía deja el problema de que cualquiera podría usar una fecha previa a la revocación para firmar los datos.

Para solucionar este problema, necesita más forma confiable de datos de sellado de tiempo que dejar que el sello de tiempo sea creado por el firmante. Debe subcontratar la marca de tiempo, ya sea permitiendo que un servicio de confianza firme una combinación del hash y la hora actual, encadenando hábilmente los hashes como se hace con Certificate Transparency o inserte una entrada en la cadena de bloques.

Tan pronto como tenga una firma (de aspecto válido) con una marca de tiempo de confianza antes de la fecha de revocación, puede estar seguro de que la firma es válida, pero tenga en cuenta que el hash debe incluir su firma al momento Estampando el servicio para asegurar que nadie lo arrancó y lo reemplazó.

La posible solución alternativa es deshacerse de todo este sistema de revocación y solo (exclusivamente) utilizar certificados de corta duración en los que puede estar seguro de que, si se revocó, todos los datos en este breve período de tiempo podrían haberse firmado. maliciosamente.

    
respondido por el SEJPM 22.03.2016 - 15:28
fuente
0

Suponiendo que no hay un tiempo de retraso entre comprometer la clave privada y revocar la clave pública y que hay una manera de averiguar de manera confiable cuándo se ha revocado la clave, esto podría funcionar si marca la firma, no la fecha. expediente. De esta manera, se puede mostrar que la firma se realizó antes de que perdiera su clave privada.

Sin embargo, los protocolos de revocación de claves típicos no cubren esta aplicación. La base de datos de revocación necesitaría una marca de tiempo para recibir su revocación y tendría que firmar una declaración suya que indique hasta qué hora se puede confiar en las firmas, por ejemplo. la primera vez que su sistema pudo haber sido invadido.

    
respondido por el Joachim Wagner 27.07.2015 - 14:02
fuente

Lea otras preguntas en las etiquetas