Autoridad certificadora

En criptografía , una autoridad de certificación ( CA ) es una entidad que almacena, firma y emite certificados digitales . Un certificado digital certifica la propiedad de una clave pública por parte del titular del certificado. Esto permite que otros (partes confiables) confíen en las firmas o en las afirmaciones realizadas sobre la clave privada que corresponde a la clave pública certificada. Una CA actúa como un tercero de confianza, tanto para el titular (propietario) del certificado como para la parte que confía en él. ^{[ 1 ]} El formato de estos certificados está especificado por el estándar X.509 o EMV .

Un uso particularmente común de las autoridades de certificación es la firma de certificados utilizados en HTTPS , el protocolo de navegación segura para la World Wide Web. Otro uso común es la emisión de tarjetas de identidad por parte de los gobiernos nacionales para su uso en la firma electrónica de documentos. ^{[ 2 ]}

Los certificados de confianza se pueden usar para crear conexiones seguras a un servidor a través de Internet. Un certificado es esencial para evitar que un tercero malicioso, que se encuentre en la ruta hacia un servidor objetivo, actúe como si fuera el objetivo. Este escenario se conoce comúnmente como ataque de intermediario (man-in-the-middle) . El cliente usa el certificado de la CA para autenticar la firma de la CA en el certificado del servidor, como parte de las autorizaciones antes de iniciar una conexión segura. ^{[ 3 ]} Por lo general, el software cliente, por ejemplo, los navegadores, incluye un conjunto de certificados de CA de confianza. Esto es lógico, ya que muchos usuarios necesitan confiar en su software cliente. Un cliente malicioso o comprometido puede omitir cualquier verificación de seguridad y aun así engañar a sus usuarios haciéndoles creer lo contrario.

Los clientes de una CA son administradores de servidores que solicitan un certificado que sus servidores otorgarán a los usuarios. Las CA comerciales cobran por emitir certificados, y sus clientes esperan que el certificado de la CA esté incluido en la mayoría de los navegadores web, de modo que las conexiones seguras a los servidores certificados funcionen de manera eficiente desde el primer momento. La cantidad de navegadores web, otros dispositivos y aplicaciones que confían en una autoridad de certificación en particular se denomina ubicuidad. Mozilla , que es una empresa sin fines de lucro, emite varios certificados de CA comerciales con sus productos. ^{[ 4 ]} Si bien Mozilla desarrolló su propia política, el CA/Browser Forum desarrolló directrices similares para la confianza en las CA. Un único certificado de CA puede ser compartido entre varias CA o sus revendedores . Un certificado raíz de CA puede ser la base para emitir varios certificados de CA intermedios con diferentes requisitos de validación.

Además de las autoridades de certificación comerciales, algunas organizaciones sin ánimo de lucro emiten certificados digitales de confianza pública sin coste alguno, como Let's Encrypt . Algunas grandes empresas de computación en la nube y alojamiento web también son autoridades de certificación de confianza pública y emiten certificados para los servicios alojados en su infraestructura, como IBM Cloud , Amazon Web Services , Cloudflare y Google Cloud Platform .

Las grandes organizaciones u organismos gubernamentales pueden tener sus propias infraestructuras de clave pública (PKI ), cada una con sus propias autoridades de certificación (CA). Cualquier sitio que utilice certificados autofirmados actúa como su propia CA.

Los bancos comerciales que emiten tarjetas de pago EMV están regidos por la Autoridad de Certificación EMV, ^{[ 5 ]} esquemas de pago que dirigen las transacciones de pago iniciadas en terminales de punto de venta ( TPV ) a un banco emisor de la tarjeta para transferir los fondos de la cuenta bancaria del titular de la tarjeta a la cuenta bancaria del destinatario del pago. Cada tarjeta de pago presenta, junto con sus datos, el Certificado del Emisor de la Tarjeta al TPV. El Certificado del Emisor está firmado por el Certificado de la CA EMV. El TPV recupera la clave pública de la CA EMV de su almacenamiento, valida el Certificado del Emisor y la autenticidad de la tarjeta de pago antes de enviar la solicitud de pago al esquema de pago.

Los navegadores y otros clientes permiten habitualmente a los usuarios añadir o eliminar certificados CA a su antojo. Si bien los certificados de servidor suelen tener una vigencia relativamente corta, los certificados CA se extienden posteriormente, ^{[ 6 ]} por lo que, para servidores visitados repetidamente, es menos propenso a errores importar y confiar en el certificado CA emitido, en lugar de confirmar una exención de seguridad cada vez que se renueva el certificado del servidor.

Con menos frecuencia, se utilizan certificados de confianza para cifrar o firmar mensajes. Las autoridades de certificación también emiten certificados para usuarios finales, que pueden utilizarse con S/MIME . Sin embargo, el cifrado requiere la clave pública del receptor y, dado que los autores y receptores de mensajes cifrados, aparentemente, se conocen entre sí, la utilidad de un tercero de confianza se limita a la verificación de la firma de los mensajes enviados a listas de correo públicas.

A nivel mundial, el sector de las autoridades de certificación está fragmentado, con proveedores nacionales o regionales que dominan sus respectivos mercados. Esto se debe a que muchos usos de los certificados digitales, como las firmas digitales con validez legal, están vinculados a la legislación, las normativas y los sistemas de acreditación locales para las autoridades de certificación.

Sin embargo, el mercado de certificados de servidor TLS/SSL de confianza global está dominado en gran medida por un pequeño número de empresas multinacionales. Este mercado presenta importantes barreras de entrada debido a los requisitos técnicos. ^{[ 7 ]} Si bien no es un requisito legal, los nuevos proveedores pueden optar por someterse a auditorías de seguridad anuales (como WebTrust ^{[ 8 ]} para las autoridades de certificación en Norteamérica y ETSI en Europa ^{[ 9 ]} ) para ser incluidos como raíz de confianza por un navegador web o sistema operativo.

A fecha de 24 de agosto de 2020  , 147 certificados raíz, que representan a 52 organizaciones, son de confianza en el navegador web Mozilla Firefox , ^{[ 10 ]} 168 certificados raíz, que representan a 60 organizaciones, son de confianza en macOS , ^{[ 11 ]} y 255 certificados raíz, que representan a 101 organizaciones, son de confianza en Microsoft Windows . ^{[ 12 ]} A partir de Android 4.2 (Jelly Bean), Android contiene actualmente más de 100 CA que se actualizan con cada versión. ^{[ 13 ]}

El 18 de noviembre de 2014, un grupo de empresas y organizaciones sin fines de lucro, entre ellas la Electronic Frontier Foundation , Mozilla, Cisco y Akamai, anunciaron Let's Encrypt , una autoridad de certificación sin fines de lucro que proporciona certificados X.509 validados por dominio gratuitos , así como software para la instalación y el mantenimiento de certificados. ^{[ 14 ]} Let's Encrypt es operada por el recién formado Internet Security Research Group , una organización sin fines de lucro de California reconocida como exenta de impuestos federales. ^{[ 15 ]}

Según Netcraft en mayo de 2015, el estándar de la industria para monitorear certificados TLS activos, "Aunque el ecosistema global [TLS] es competitivo, está dominado por un puñado de CA importantes: tres autoridades de certificación (Symantec, Comodo, GoDaddy) representan tres cuartas partes de todos los certificados [TLS] emitidos en servidores web de acceso público. El primer puesto lo ha ocupado Symantec (o VeriSign antes de ser adquirida por Symantec) desde que comenzó [nuestro] estudio, y actualmente representa poco menos de un tercio de todos los certificados. Para ilustrar el efecto de las diferentes metodologías, entre el millón de sitios más visitados, Symantec emitió el 44 % de los certificados válidos y confiables en uso, significativamente más que su cuota de mercado general". ^{[ 16 ]}

A partir de julio de 2024 La empresa de encuestas W3Techs, que recopila estadísticas sobre el uso de autoridades de certificación entre los 10 millones de sitios web más visitados según Alexa y el millón de sitios web más visitados según Tranco, enumera las cinco autoridades más grandes por cuota de uso absoluta como se muestra a continuación. ^{[ 17 ]}

Las autoridades de certificación comerciales que emiten la mayoría de los certificados para servidores HTTPS suelen utilizar una técnica denominada " validación de dominio " para autenticar al destinatario del certificado. Las técnicas empleadas para la validación de dominio varían entre las distintas autoridades de certificación, pero en general, su objetivo es demostrar que el solicitante del certificado controla un nombre de dominio determinado , no obtener información sobre su identidad.

Muchas autoridades de certificación también ofrecen certificados de validación extendida (EV) como una alternativa más rigurosa a los certificados de validación de dominio. La validación extendida tiene como objetivo verificar no solo el control de un nombre de dominio, sino también información de identidad adicional que se incluirá en el certificado. Algunos navegadores muestran esta información de identidad adicional en un recuadro verde en la barra de direcciones. Una limitación de EV como solución a las debilidades de la validación de dominio es que los atacantes aún podrían obtener un certificado de validación de dominio para el dominio de la víctima e implementarlo durante un ataque; si eso ocurriera, la diferencia observable para el usuario víctima sería la ausencia de una barra verde con el nombre de la empresa. Existe cierta duda sobre si los usuarios probablemente reconocerían esta ausencia como indicativa de que se está produciendo un ataque: una prueba realizada con Internet Explorer 7 en 2009 mostró que los usuarios no notaron la ausencia de las advertencias de EV de IE7; sin embargo, el navegador más reciente de Microsoft, Edge Legacy , muestra una diferencia significativamente mayor entre los certificados EV y los certificados de validación de dominio, ya que estos últimos tienen un candado gris hueco.

La validación de dominios presenta ciertas limitaciones de seguridad estructurales. En particular, es vulnerable a ataques que permiten a un adversario observar las sondas de validación que envían las autoridades de certificación (CA). Estos ataques pueden incluir ataques contra los protocolos DNS, TCP o BGP (que carecen de las protecciones criptográficas de TLS/SSL), o la vulneración de enrutadores. Dichos ataques pueden ocurrir tanto en la red cercana a una CA como cerca del propio dominio víctima.

Una de las técnicas más comunes de validación de dominio consiste en enviar un correo electrónico que contiene un token de autenticación o un enlace a una dirección de correo electrónico que probablemente sea la responsable administrativa del dominio. Esta podría ser la dirección de correo electrónico del contacto técnico que figura en la entrada WHOIS del dominio , o un correo electrónico administrativo como admin@ , administrator@ , webmaster@ , hostmaster@ o postmaster@ del dominio. ^{[ 18 ] [ 19 ]} Algunas autoridades de certificación pueden aceptar la confirmación utilizando root@ , info@ o support@ en el dominio. ^{[ 20 ]} La teoría detrás de la validación de dominio es que solo el propietario legítimo de un dominio podría leer los correos electrónicos enviados a estas direcciones administrativas.

Las implementaciones de validación de dominios a veces han sido fuente de vulnerabilidades de seguridad. En un caso, investigadores de seguridad demostraron que los atacantes podían obtener certificados para sitios de correo web porque una CA estaba dispuesta a usar una dirección de correo electrónico como ssladmin@domain.com para domain.com, pero no todos los sistemas de correo web habían reservado el nombre de usuario "ssladmin" para evitar que los atacantes lo registraran. ^{[ 21 ]}

Antes de 2011, no existía una lista estándar de direcciones de correo electrónico que pudieran utilizarse para la validación de dominios, por lo que los administradores de correo electrónico no tenían claro qué direcciones debían reservarse. La primera versión de los Requisitos Básicos del Foro CA/Navegador , adoptada en noviembre de 2011, especificaba una lista de dichas direcciones. Esto permitió a los proveedores de correo reservar esas direcciones para uso administrativo, aunque tales precauciones aún no son universales. En enero de 2015, un finlandés registró el nombre de usuario "hostmaster" en la versión finlandesa de Microsoft Live y logró obtener un certificado de validación de dominio para live.fi, a pesar de no ser el propietario del nombre de dominio. ^{[ 22 ]}

Una CA emite certificados digitales que contienen una clave pública y la identidad del propietario. La clave privada correspondiente no se hace pública, sino que el usuario final que generó el par de claves la mantiene en secreto. El certificado también confirma o valida, por parte de la CA, que la clave pública que contiene pertenece a la persona, organización, servidor u otra entidad indicada en el certificado. La obligación de una CA en estos sistemas es verificar las credenciales del solicitante, de modo que los usuarios y las partes que confían en la información puedan confiar en el certificado emitido. Las CA utilizan diversos estándares y pruebas para ello. En esencia, la autoridad de certificación es responsable de afirmar: «Sí, esta persona es quien dice ser, y nosotros, la CA, lo certificamos». ^{[ 23 ]}

Si el usuario confía en la CA y puede verificar la firma de la CA, entonces también puede asumir que una determinada clave pública pertenece efectivamente a quien se identifica en el certificado. ^{[ 24 ]}

• Consejo de Seguridad de Autoridades de Certificación (CASC) – En febrero de 2013, el CASC se fundó como una organización de defensa de la industria dedicada a abordar los problemas del sector y educar al público sobre la seguridad en Internet. Los miembros fundadores son las siete Autoridades de Certificación más grandes. ^{[ 36 ] [ 37 ]}
• Foro de Estándares Comunes de Seguridad Informática (CCSF) – En 2009, el CCSF se fundó para promover estándares de la industria que protejan a los usuarios finales. El director ejecutivo de Comodo Group, Melih Abdulhayoğlu, es considerado el fundador del CCSF. ^{[ 38 ]}
• Foro CA/Navegador – En 2005, se formó un nuevo consorcio de Autoridades de Certificación y proveedores de navegadores web para promover estándares de la industria y requisitos básicos para la seguridad en internet. El director ejecutivo de Comodo Group, Melih Abdulhayoğlu, organizó la primera reunión y es considerado el fundador del Foro CA/Navegador. ^{[ 39 ] [ 40 ]}

Si se logra vulnerar la autoridad de certificación (CA), se pierde la seguridad de todo el sistema, lo que podría comprometer a todas las entidades que confían en la CA comprometida.

Por ejemplo, supongamos que una atacante, Eve, logra que una autoridad de certificación le emita un certificado que supuestamente representa a Alice. Es decir, el certificado declararía públicamente que representa a Alice y podría incluir otra información sobre ella. Parte de esta información, como el nombre de su empleador, podría ser cierta, lo que aumentaría la credibilidad del certificado. Sin embargo, Eve tendría la clave privada, de vital importancia, asociada al certificado. Eve podría entonces usar el certificado para enviar un correo electrónico firmado digitalmente a Bob, engañándolo y haciéndole creer que el correo provenía de Alice. Bob incluso podría responder con un correo electrónico cifrado, creyendo que solo Alice podría leerlo, cuando en realidad Eve puede descifrarlo usando la clave privada.

Un caso notable de subversión de CA como este ocurrió en 2001, cuando la autoridad de certificación VeriSign emitió dos certificados a una persona que afirmaba representar a Microsoft. Los certificados tenían el nombre "Microsoft Corporation", por lo que podían usarse para engañar a alguien haciéndole creer que las actualizaciones del software de Microsoft provenían de Microsoft cuando en realidad no era así. El fraude se detectó a principios de 2001. Microsoft y VeriSign tomaron medidas para limitar el impacto del problema. ^{[ 45 ] [ 46 ]}

En 2008, el revendedor de Comodo, Certstar, vendió un certificado para mozilla.com a Eddy Nigg, quien no tenía autoridad para representar a Mozilla. ^{[ 47 ]}

En 2011 se obtuvieron certificados fraudulentos de Comodo y DigiNotar , ^{[ 48 ] [ 49 ]} presuntamente por piratas informáticos iraníes. Hay evidencia de que los certificados fraudulentos de DigiNotar se utilizaron en un ataque de intermediario en Irán. ^{[ 50 ]}

En 2012, se supo que Trustwave emitió un certificado raíz subordinado que se utilizó para la gestión transparente del tráfico (ataque de intermediario) que, en la práctica, permitía a una empresa interceptar el tráfico de la red interna SSL utilizando dicho certificado subordinado. ^{[ 51 ]}

En 2012, el malware Flame (también conocido como SkyWiper) contenía módulos que presentaban una colisión MD5 con un certificado válido emitido por un certificado de licencia de Microsoft Terminal Server que utilizaba el algoritmo hash MD5 vulnerado. De este modo, los autores pudieron realizar un ataque de colisión con el hash que figuraba en el certificado. ^{[ 52 ] [ 53 ]}

En 2015, una autoridad de certificación china llamada MCS Holdings, afiliada al registro central de dominios de China, emitió certificados no autorizados para dominios de Google. ^{[ 54 ] [ 55 ]} Google eliminó tanto a MCS como a la autoridad de certificación raíz de Chrome y revocó los certificados. ^{[ 56 ]}

Un atacante que roba las claves privadas de una autoridad de certificación puede falsificar certificados como si fueran de la propia CA, sin necesidad de acceso continuo a sus sistemas. Por lo tanto, el robo de claves es uno de los principales riesgos contra los que se defienden las autoridades de certificación. Las CA de confianza pública casi siempre almacenan sus claves en un módulo de seguridad de hardware (HSM), lo que les permite firmar certificados con una clave, pero generalmente impiden la extracción de dicha clave mediante controles físicos y de software. Las CA suelen tomar la precaución adicional de mantener la clave de sus certificados raíz de larga duración en un HSM sin conexión , excepto cuando se necesita para firmar certificados intermedios de menor duración. Los certificados intermedios, almacenados en un HSM en línea, pueden realizar el trabajo diario de firmar certificados de entidad final y mantener actualizada la información de revocación.

En ocasiones, las autoridades de certificación utilizan una ceremonia de claves al generar las claves de firma, para garantizar que estas no sean manipuladas ni copiadas.

La debilidad crítica en la forma en que se implementa el esquema X.509 actual es que cualquier CA de confianza para una parte en particular puede emitir certificados para cualquier dominio que elija. Dichos certificados serán aceptados como válidos por la parte que confía en ellos, sean legítimos y autorizados o no. ^{[ 57 ]} Esta es una deficiencia grave dado que la tecnología más común que emplea X.509 y terceros de confianza es el protocolo HTTPS. Como todos los navegadores web principales se distribuyen a sus usuarios finales preconfigurados con una lista de CA de confianza que cuenta con decenas, esto significa que cualquiera de estas CA de confianza preaprobadas puede emitir un certificado válido para cualquier dominio. ^{[ 58 ]} La respuesta de la industria a esto ha sido tibia. ^{[ 59 ]} Dado que el contenido de la lista de CA de confianza preconfigurada de un navegador es determinado independientemente por la parte que distribuye o hace que se instale la aplicación del navegador, realmente no hay nada que las propias CA puedan hacer.

Este problema es el principal impulsor del desarrollo del protocolo de autenticación de entidades nombradas basado en DNS (DANE). Si se adopta junto con las extensiones de seguridad del sistema de nombres de dominio (DNSSEC), DANE reducirá considerablemente, si no elimina por completo, el papel de terceros de confianza en la infraestructura de clave pública (PKI) de un dominio.

• Autoridad de validación
• Página de contacto
• Personas por la Responsabilidad en Internet
• Red de confianza
• Cadena de confianza
• Firma digital
• Violación de la autoridad de certificación de DigiNotar
• Violación de la autoridad de certificación de Comodo

• Chung, Taejoong; Lok, Jay; Chandrasekaran, Balakrishnan; Choffnes, David; Levin, Dave; Maggs, Bruce M.; Mislove, Alan; Rula, John; Sullivan, Nick; Wilson, Christo (2018). "¿Está la web preparada para OCSP Must-Staple?" (PDF) . Actas de la Conferencia de Medición de Internet 2018. págs. 105–118 . doi : 10.1145/3278532.3278543 . ISBN  9781450356190. S2CID 53223350 . 
• Larisch, James; Choffnes, David; Levin, Dave; Maggs, Bruce M.; Mislove, Alan; Wilson, Christo (2017). «CRLite: Un sistema escalable para enviar todas las revocaciones TLS a todos los navegadores». Simposio IEEE de 2017 sobre seguridad y privacidad (SP) . págs. 539–556 . doi : 10.1109/sp.2017.17 . ISBN  978-1-5090-5533-3. S2CID 3926509 . 
• Sheffer, Yaron; Saint-Andre, Pierre; Fossati, Thomas (noviembre de 2022). Recomendaciones para el uso seguro de Transport Layer Security (TLS) y Datagram Transport Layer Security (DTLS) . IETF . doi : 10.17487/RFC9325 . RFC 9325 .
• Smith, Trevor; Dickinson, Luke; Seamons, Kent (2020). «Revoquemos: Revocación global escalable de certificados». Actas del Simposio de Seguridad de Redes y Sistemas Distribuidos de 2020. doi : 10.14722/ndss.2020.24084 . ISBN 978-1-891562-61-7. S2CID 211268930 . 

• ¿Qué tan seguro es HTTPS hoy en día? ¿Con qué frecuencia sufre ataques? , Electronic Frontier Foundation (25 de octubre de 2011)