¿Cómo manejar las CRL correctamente en firmas electrónicas a largo plazo?

Navega tus respuestas
3

¿Cuál es una forma recomendada de manejar CRL s en firmas electrónicas a largo plazo (específicamente el CAdES-A )?

El problema que veo es que CRL s no está protegido contra modificaciones (son texto sin formato, no está firmado) y ni siquiera es obligatorio en CAdES-T o CAdES-A .

Como tales, se pueden falsificar, y tal falsificación no se puede detectar fácilmente, si la autoridad de sellado de tiempo utilizada ( TSA ) ya no está activa. No puedo encontrar una manera de manejar CRL s de una manera que evite cualquier duda sobre la validez a largo plazo de un documento con marca de tiempo con CAdES-A .

El mismo problema que tengo con la verificación de confiabilidad de TSA s ellos mismos, si ya no existen.

Un escenario típico que me preocupa es este:

  1. Un atacante puede usar su propia autoridad de sellado de tiempo (= no confiable) para falsificar una marca de tiempo ( CAdES-T o CAdES-A ) de un documento. Nadie podrá ahora verificar si este% inalcanzable TSA era de confianza o no en el momento en que parece que se emite la marca de tiempo. Para crear una apariencia de credibilidad, el atacante puede actualizar la marca de tiempo con una marca de tiempo válida de un TSA de confianza, y esperar varios años. La actualización del sello de tiempo es posible debido al hecho de que los sellos de tiempo pueden emitirse automáticamente sin la verificación de la credibilidad de los sellos de tiempo anteriores.

  2. En un principio similar, un atacante puede usar un certificado revocado de una autoridad de marca de tiempo confiable. También puede adjuntar un CRL modificado desde el cual elimina la S / N del certificado de sello de tiempo usado (lo cual es posible ya que el CRL no está firmado). De esta manera, el atacante puede crear una serie de sellos de tiempo de diferentes TSA s. Es posible que después de 10 años, al menos uno de los TSA s no exista, y nadie podrá recibir su CRL no modificado correcto para verificar la validez de la marca de tiempo.

Desafortunadamente, las especificaciones de firmas a largo plazo no tratan estos problemas en detalle, o más bien no los mencionan en absoluto. Por ejemplo, en rfc5126 , especialmente las secciones C.4.1.1 y C.4.3.

Editar:

(Se ha movido otra subpregunta aquí .)

    
pregunta xarx 02.04.2014 - 19:20
fuente

1 respuesta

4

Una CRL es un objeto firmado, al igual que un certificado. Por esta razón, no es necesario que estén cubiertos por la firma del documento real. Sin embargo, para el archivado a largo plazo, deben estar marcados con la hora.

El trasfondo teórico es el siguiente:

  • En un momento dado T , puede validar certificados y verificar firmas utilizando el CRL recién descargado, lo que garantiza el estado de revocación de los certificados involucrados en la fecha actual ( T ).

  • Si, mientras la fecha actual es T , desea prepararse para una verificación de firma ulterior en la fecha T ' (más tarde que T ), luego ensamblas todos los objetos necesarios para realizar la verificación y los pones en una bolsa (algo de formato de archivo), para lo cual obtienes una marca de tiempo. La marca de tiempo indica que todos los contenidos de la bolsa existían en la fecha T.

  • En la fecha T ', verifica la marca de tiempo, que incluye la validación del certificado TSA y la descarga de CRL, y así sucesivamente; De manera crucial, usted valida la marca de tiempo en la fecha T ', que es la fecha actual. Una vez verificada la marca de tiempo, sabrá que todos los objetos en la bolsa ya existían en la fecha T , por lo que puede virtualmente proyectarse en el pasado y verificar la firma como si la fecha actual fuera T .

    La idea detrás de este viaje en el tiempo es que si en la fecha T hubiera validado la firma, todavía la recordaría y actuaría sobre el resultado. Por lo tanto, siempre que tenga una prueba (la marca de tiempo) de que todos los objetos usados (certificados y CRL) ya existían en la fecha T , entonces puede considerar que hizo la validación el certificado en la fecha T , y aún lo recuerda ahora.

  • Recurse. En la descripción anterior, usted valida la marca de tiempo en la fecha T ', luego la que tiene la marca de tiempo en la fecha T . La marca de tiempo en sí misma puede caducar (generalmente porque el certificado TSA caducará), por lo que si desea prepararse para la validación a largo plazo, debe obtener una marca de tiempo más nueva con una vida útil más larga. Esa marca de tiempo más reciente debe cubrir todo lo necesario para validar la primera marca de tiempo en la fecha T ', incluya la CRL.

    En última instancia, debe aplicar una nueva marca de tiempo cada dos o tres años aproximadamente, según la rapidez con que caduque la TSA. Cada nueva marca de tiempo se encuentra en una bolsa que contiene todos los objetos necesarios para validar la marca de tiempo anterior.

Todas las marcas de tiempo aquí son RFC 3161 , es decir, son CMS SignedData . Como tal, puede a posteriori incrustar certificados adicionales y CRL en una estructura de marca de tiempo. RFC 5126 declara como tal al final de sección-4.4.1 : 

  NOTE 2: Time-stamp tokens that may themselves include unsigned
  attributes required to validate the time-stamp token, such as the
  complete-certificate-references and complete-revocation-references
  attributes, as defined by the present document.

Además de los atributos sin signo específicos de CAdES, los certificados adicionales y CRL siempre se pueden insertar en los campos certificates y crls de la estructura SignedData , como se especifica en CMS . El efecto general es el mismo: la estructura SignedData es el formato de "bolsa" del que estoy hablando, y luego marca la hora de todo el lote.

Esta estructura de sellos de cadena de tiempo puede ser algo más fácil de entender en Sintaxis del registro de evidencia , un estándar de la competencia que se concentra en firmas a largo plazo y, en mi opinión, lo hace mejor que CAdES.

    
respondido por el Tom Leek 02.04.2014 - 19:44
fuente

Lea otras preguntas en las etiquetas

¿Cómo pueden los usuarios estar seguros de que la barra de URL del navegador no está falsificada? ¿La generación de claves gpg debería dar como resultado una clave idéntica a una clave más antigua?