Certificate Transparency

Certificate Transparency (CT) es un estándar abierto diseñado por Ben Laurie and Adam Langley y publicado inicialmente por la IETF ^[1]​ en 2013, además es un framework open source de monitorización y auditado de certificados digitales. Este ecosistema compuesto principalmente de logs, monitores y auditores, permite a cualquier interesado estar informado si se emite un nuevo certificado para un determinado dominio, ayudando así a mitigar el uso de certificados fraudulentos emitidos sin el conocimiento del propietario del dominio para el que se emiten. Además, esta tecnología permite realizar un seguimiento de la actividad de las autoridades certificadoras (CAs), de modo que puedan ser detectados rápidamente en el caso por ejemplo de que hayan podido ser comprometidas con el objetivo de emitir certificados fraudulentos.

Antecedentes

Los incidentes de seguridad registrados y problemas de privacidad relacionados con el uso de certificados fraudulentos, dejan patente la existencia de defectos en el sistema actual de certificados. Incidentes como el ocurrido con la CA holandesa DigiNotar en 2011, declarada en bancarrota tras conocerse que atacantes consiguieron emitir más de 500 certificados fraudulentos utilizando su infraestructura.^[2]​

Ventajas

Uno de los problemas del ecosistema actual de certificados digitales, es el tiempo que transcurre hasta que un certificado fraudulento es detectado, reportado y revocado por los navegadores. Certificate Transparency pretende mitigar este problema haciendo imposible la emisión de certificados para un dominio sin el conocimiento del propietario del mismo.

Una de las principales ventajas de Certificate Transparency es que no necesita un canal alternativo para validación de los certificados, como ocurre con otras tecnologías como por ejemplo Online Certificate Status Protocol (OCSP). Así mismo, Certificate Transparency tampoco requiere de la figura de terceras partes confiables para operar.

Logs en Certificate Transparency

Certificate Transparency se basa en la figura de los logs de certificados. El funcionamiento de los logs consiste en concatenar los nuevos certificados recibidos en un Árbol de Merkle.^[1]​^{:Section 3} de hashes de solo crecimiento, es decir, los certificados del log nunca se modifican ni se borran, las únicas operaciones aceptadas son las de adición de certificados y las operaciones criptográficas necesarias para mantener la integridad del árbol. Para operar correctamente, un log debe:

• Verificar que cada certificado o precertificado enviado, posee una cadena de certificación válida y terminada en un certificado asociado a una autoridad certificadora confiable.
• No aceptar certificados que no posean una cadena de certificación válida.
• Almacenar la totalidad de la cadena de certificación de los nuevos certificados recibidos, desde el propio certificado hasta la raíz de la cadena.
• Ofrecer esta cadena para monitorización y auditoría bajo petición.

Además, un log podría aceptar certificados que todavía no han sido completamente validados o incluso aquellos que han caducado.

Monitores en Certificate Transparency

Los monitores en Certificate Transparency, actúan como clientes de los servidores de log. Los monitores comprueban los logs en busca de certificados emitidos para un determinado dominio que se desea vigilar.

Auditores en Certificate Transparency auditors

Al igual que los monitores, los auditores actúan como clientes de los servidores de log, pero en este caso comprueban la actividad del log, verificando que su funcionamiento sea correcto. De este modo, si una inconsistencia es detectada, se usa como prueba de que el log no está funcionando adecuadamente, algo que puede ser validado estudiando las firmas de la estructura del log (Árbol de Merkle).^[1]​^{:Section 5.4}

Implementación por parte de las autoridades de certificación

Google fue el primero en lanzar un log de Certificate Transparency, que comenzó a operar en marzo de 2013.^[3]​ En septiembre de ese mismo año, DigiCert fue la primera autoridad de certificación en implementar Certificate Transparency.^[4]​

En 2015, Google Chrome estableció como requisito para ser aceptados por el navegador, la inclusión en Certificate Transparency para todo nuevo certificado de validación extendida emitido.^[5]​^[6]​ Además, aplicó esta restricción a los certificados (no solo de validación extendida) emitidos por la CA Symantec desde el 1 de junio de 2016, después de conocerse que 187 certificados habían sido emitidos por esta autoridad certificadora sin el consentimiento de los propietarios de los dominios a los que iban dirigidos.^[7]​^[8]​

Referencias

1. Laurie (June 2013). «RFC 6962 - Certificate Transparency». The Internet Engineering Task Force. Consultado el 20 de noviembre de 2013. 
2. Kim Zetter (11 de septiembre de 2011). «DigiNotar Files for Bankruptcy in Wake of Devastating Hack». Wired. Consultado el 14 de noviembre de 2014. 
3. «Known Logs - Certificate Transparency». certificate-transparency.org. Consultado el 31 de diciembre de 2015. 
4. . Dark Reading. Archivado desde el original el 10 de octubre de 2013. Consultado el 12 de noviembre de 2013. 
5. Woodfield, Meggie (5 de diciembre de 2014). «Certificate Transparency Required for EV Certificates to Show Green Address Bar in Chrome». DigiCert Blog. DigiCert. 
6. Laurie, Ben (4 de febrero de 2014), «Updated Certificate Transparency + Extended Validation plan», https://cabforum.org/pipermail/public/2014-February/002840.html. 
7. . Symantec Knowledge Center. Symantec. 9 de junio de 2016. Archivado desde el original el 5 de octubre de 2016. Consultado el 24 de abril de 2017. 
8. Sleevi, Ryan (28 de octubre de 2015). «Sustaining Digital Certificate Security». Google Security Blog. Google. 

Enlaces externos

• RFC 6962 - Internet Engineering Task Force
• Certificate-transparency.org, información general sobre el proyecto Certificate Transparency.
• crt.sh, un motor de consulta de certificados en los distintos logs de Certificate Tranparency.

•   Datos: Q17080777