Validación de firmas en Tractis (1): Validación de certificados

Hoy Lunes 28 de Abril de 2008 marca un hito importante en el roadmap de Tractis. Tenemos el placer de anunciar oficialmente que Tractis supera la totalidad de tests PKITS del NIST.

El NIST o “National Institute of Standards and Technology” es la agencia del gobierno estadounidense dedicada a garantizar el cumplimiento de estándares y favorecer la interoperabilidad entre distintos fabricantes. Las pruebas diseñadas por la “NIST – Computer Security Division” y la NSA (Agencia de Seguridad Nacional) son utilizadas por las distintas administraciones del gobierno federal estadounidense como un método fiable para medir la calidad de los distintos despliegues PKI del gobierno. La semana pasada Tractis superó con éxito el 100% de la batería de tests PKITS del NIST, diseñados para garantizar un cumplimiento exquisito de las especificaciones X.509 y RFC3280.

Para celebrarlo, vamos a dedicar esta semana a una serie de tres posts cuyo objetivo es explicar (1) conceptos básicos de validación de certificados, (2) el desafío que supone la validación de firmas electrónicas y (3) algunas de las técnicas que utilizamos en Tractis para garantizar una validación perfecta y a prueba de fallos.

Introducción

En Tractis ofrecemos un servicio web que permite a particulares y empresas firmar contratos 100% online y con la misma eficacia jurídica que la firma manuscrita. Para ello empleamos tecnologías de firma digital que garantizan la integridad del documento, la identidad de las partes y la no repudiación futura de los compromisos adquiridos por los firmantes.

Nuestra plataforma no sólo permite un firmado de contratos sin más, sino que antes de añadir cualquier firma al contrato la validamos para evitar cualquier tipo de irregularidad en el proceso de firma. El responsable de realizar este proceso en nuestro back-end es un elemento al que denominamos “Autoridad de Validación Semántica” (SVA o Semantic Validation Authority). La SVA de Tractis valida desde aspectos criptográficos a temporales y, por supuesto, valida que el certificado empleado para realizar la firma es apto para ello.

Como el proceso completo de validación de la firma es demasiado complejo para explicar en un solo post (personalmente diría incluso que es demasiado complejo, a secas), en este primer post nos centraremos en el proceso de validar el certificado con el cual se ha realizado la firma.

Validación de certificados

Para que exista “firma electrónica reconocida” (equivalente a firma manuscrita), la legislación europea no requiere que se valide el certificado electrónico con el que se realiza la firma en el mismo momento de la firma. Sin embargo, en Tractis siempre lo hacemos. No es ninguna tontería. Imaginad una empresa que entrega un certificado electrónico a un empleado para que firme contratos electrónicos en representación de la compañía. Ahora imaginad que esa empresa despide al empleado y revoca su certificado. Si se utilizasen herramientas de contratación online que no validan online el estado del certificado, el ex-empleado podría engañar a terceros y utilizar el certificado para firmar en nombre de la empresa ¡incluso a pesar de estar despedido!. Las pérdidas podrían ser cuantiosas. No en Tractis. En Tractis no se realiza ninguna firma electrónica reconocida sin antes validar online en tiempo real el estado del certificado. Esto es así para todos los certificados que admitimos, sean del país que sean. Y, ni siquiera haciendo esto, hemos terminado nuestro trabajo.

Mucha gente piensa que validar un certificado consiste simplemente en lo que hemos comentado: consultar, en el momento de la firma, el estado del certificado a la Autoridad de Certificación que lo emitió y averiguar si el certificado es válido y no ha sido revocado. Nada más lejos de la realidad. Validar un certificado de una manera ortodoxa no es algo sencillo. Validar que el certificado no este “expirado” o mirando una CRL o consultando un OCSP para ver si está “revocado” es sólo una pequeña parte del trabajo.

El proceso de validar un certificado con garantías suficientes es bastante mas complejo, ya que hay que tener en cuenta la validación de todos los elementos relacionados con el certificado como certificados de Autoridades de Certificación, listas de revocación (CRL) o mensajes OCSP que deben ser a su vez validados de manera análoga.

El porque de tener que validar todos estos componentes deriva de que el encargado de validar el certificado no suele ser el mismo que el emisor de dicho certificado. Nos encontramos entonces con que el validador debe confiar en la información emitida por un tercero para poder emitir un veredicto respecto al certificado a validar. No obstante, antes de poder utilizar esta información para poder emitir un veredicto, ésta debe ser validada. Debemos comprobar que nos hayamos ante información confiable: que no ha sido alterada y que es adecuada para efectuar la validación del certificado en el instante de tiempo en el cual éste debe ser validado. Y es que el momento en el cual se valida el certificado es un punto clave a la hora de efectuar todo este proceso ya que el componente temporal afecta enormemente al proceso de validación. No es lo mismo validar un certificado en el momento actual, que hace 5 años o que de aquí a 5 años.

Por ello, y por poner un ejemplo sencillo, en el caso de una firma no podemos simplemente validar el certificado en la actualidad sino que debemos determinar de manera fidedigna cuando fue realizada la firma y validar el certificado en ese momento. Veamos un ejemplo: si firmé mi hipoteca y al año siguiente me robaron mi e-ID (sea el que sea: DNIe español, beID belga, Cartão de Cidadão portugués, Carta d’dentitá elettronica italiana, Bürgerkarte austriaco, FINEID finlandés, ID-Card estonio…) y lo anulé, no me gustaria que todas las firmas que hice antes de ese momento (incluyendo mi hipoteca) sean consideradas a partir de ese momento como invalidas, ¿no?.

Aparte de las consideraciones ya comentadas hay además multitud de detalles críticos como la comprobación de longitud de paths, espacios de nombres admitidos, extensiones críticas aceptadas o no, firmas de la información de revocación, etc… que deben ser tenidos en cuenta.

Para simplificar, abstrayéndonos un poco de toda esta ingente cantidad de procesos que deben llevarse a cabo, el proceso de validación de un certificado se divide en dos grandes partes: (1) la construcción del path de certificación y (2) la validación del mismo.

La necesidad de construir un path… y validarlo

Para validar un certificado, ya sea como parte una validación de firma o validándolo de manera aislada (por ejemplo para logearse en un portal mediante el uso de TLS), es necesario contruir todo su “certification path y validarlo.

El concepto de “path” viene determinado por el como las Autoridades de Certificación emiten sus certificados. Cada certificado de entidad final (el que emiten a personas o entidades ) contiene una serie de atributos tales como “nombre”, “organización”… que hacen referencia al sujeto que es objeto de la emisión del mismo. Además, cada certificado incluye una clave pública que será empleada en el proceso de validación criptográfica de toda firma realizada con la clave privada asociada a ese certificado.

Este certificado es una representación off-line de estos datos en la que un tercero (tu banco, tu gobierno…) nos garantiza la veracidad de estos atributos para este individuo. Por ejemplo con la emisión de un certificado donde figure mi nombre, apellidos, empresa y DNI, la autoridad que emite el certificado garantiza que esos atributos son constituyentes de mi identidad y además los asocia a una clave pública.

Como hemos comentado un certificado no es más que un mensaje codificado según una serie de reglas establecidas, pero como es un método de transmisión de información off-line debe haber alguna manera de garantizar la autenticidad de los datos que figuran en el mismo. De esta necesidad de preservar la integridad de los datos viene el requerimiento de que todo certificado debe estar firmado por la autoridad de certificación que lo emite. Así, deberemos validar criptograficamente el certificado de entidad final para garantizar su autenticidad y no alteración, utilizando para ello la clave pública del certificado de la Autoridad de Certificación (CA) emisora.

Este certificado de CA emisora puede estar emitido a su vez por una CA de grado superior y esta por otra hasta llegar hasta la llamada “CA raíz”, un certificado de CA que esta emitido por el mismo y como tal esta firmado con su propia clave privada.

Para que todo el proceso sea consistente estos “certificados raíz” deben ser conocidos por el validador por medios fuera de banda. ¿Os suena el repositorio de certificados que Windows lleva para que os podáis conectar a servidores vía https sin que salgan advertencias de seguridad?, pues es algo así.

Más aún, una vez construido el path, este debe ser validado teniendo en cuenta un gran número de consideraciones relativas a restricciones sobre el mismo o validar el estado del certificado de entidad final así como de las CAs involucradas (sin contar la raíz) contra CRLs, OCSPs u otros métodos de comprobación del estado de la revocación.

Y aún hay más, CRLs y OCSPs son objetos firmados con lo cual para poder emplearlos y ser confiables deben ser validados criptográfica y sintácticamente así como validar el certificado con el cual han sido firmados de manera similar a la comentada para los de entidad final: construyendo su path y validándolo.

Como veis, en la validación de un certificado intervienen una serie de actores adicionales como CAs e información de revocación que debe ser tenida en cuenta, procesada y validada haciendo que la complejidad y el coste de validar un certificado explote.

Afortunadamente las normas RFC 3280 especifican de manera detallada como debe llevarse a cabo el proceso de validación del path de certificados. Así, este procedimiento queda detallado en un documento y todos los validadores que, como Tractis, dispongan de una implementación que respete RFC3280 validarán siguiendo el mismo conjunto de reglas.

Conclusiones

El proceso de validar una firma electrónica es un proceso complejo que se puede dividir en diferentes procesos complementarios que validan las diferentes partes de la firma: la criptográfica, la relativa al tiempo de firma … y, como una de las destacadas, la relativa a la validación del certificado con el que se realiza la firma.

Hemos descrito este proceso a vista de pájaro y de forma resumida pero con el suficiente grado de detalle como para demostrar que conocer el estado de un certificado de manera diligente es mucho más complicado que consultar a un servicio OCSP de estado de certificados o bien mirar las entradas de una CRL.

También hemos visto que, por suerte para los que construimos infraestructuras de este tipo, existen especificaciones de lo que debe y no debe hacerse en dicho procesos. Estas especificaciones hacen posible que dispongamos de implementaciones de validación coherentes, respetuosas con estándares abiertos e interoperables entre los diferentes fabricantes.

Próximo post: Validación de firmas en Tractis (2): Validación de firmas

Por David García
Guardado en: Firma digital, Tecnología, Tractis | 2 comentarios » | 28 de Abril de 2008

2 Comentarios en “Validación de firmas en Tractis (1): Validación de certificados”

Gravatar de David Calavera

David Calavera
29 de Abril de 2008 a las 9:58 am    

que grande, felicidades!!

[...] Validación de firmas en Tractis (1): Validación de certificados. [...]

Más entradas en Negonation Blog