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 sujeto nombrado del certificado. Esto permite que otros (partes confiadas) 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, en el que confían tanto el sujeto (propietario) del certificado como la parte que confía en el certificado. [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 firmar 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 utilizar para crear conexiones seguras a un servidor a través de Internet. Un certificado es esencial para eludir a una parte maliciosa que se encuentra en la ruta a un servidor de destino que actúa como si fuera el objetivo. Este escenario se conoce comúnmente como un ataque de intermediario . El cliente utiliza el certificado de CA para autenticar la firma de 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 confiables. Esto tiene sentido, ya que muchos usuarios necesitan confiar en su software cliente. Un cliente malicioso o comprometido puede omitir cualquier control de seguridad y aún así engañar a sus usuarios para que crean lo contrario.
Los clientes de una CA son supervisores de servidores que solicitan un certificado que sus servidores otorgarán a los usuarios. Las CA comerciales cobran dinero por emitir certificados y sus clientes esperan que el certificado de la CA esté contenido 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 de Internet, otros dispositivos y aplicaciones que confían en una autoridad de certificación en particular se conoce como 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ó pautas similares para la confianza de las CA. Un solo certificado de CA puede compartirse entre varias CA o sus revendedores . Un certificado de CA raíz puede ser la base para emitir varios certificados de CA intermedios con diferentes requisitos de validación.
Además de las CA comerciales, algunas organizaciones sin fines de lucro emiten certificados digitales de confianza pública sin cargo, por ejemplo, Let's Encrypt . Algunas grandes empresas de computación en la nube y alojamiento web también son CA de confianza pública y emiten certificados para servicios alojados en su infraestructura, por ejemplo, IBM Cloud , Amazon Web Services , Cloudflare y Google Cloud Platform .
Las grandes organizaciones o los organismos gubernamentales pueden tener sus propias PKI ( infraestructura de clave pública ), cada una de las cuales contiene sus propias 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 enrutan las transacciones de pago iniciadas en Terminales de Punto de Venta ( POS ) a un Banco Emisor de Tarjetas para transferir los fondos desde la cuenta bancaria del titular de la tarjeta a la cuenta bancaria del receptor del pago. Cada tarjeta de pago presenta junto con sus datos de tarjeta también el Certificado de Emisor de Tarjeta al POS. El Certificado de Emisor está firmado por el Certificado de CA EMV. El POS recupera la clave pública de la CA EMV de su almacenamiento, valida el Certificado de Emisor y la autenticidad de la tarjeta de pago antes de enviar la solicitud de pago al esquema de pago.
Los navegadores y otros tipos de clientes suelen permitir a los usuarios añadir o eliminar certificados de CA a voluntad. Si bien los certificados de servidor suelen durar un período relativamente corto, los certificados de CA se extienden aún más, [6] por lo que, para los servidores visitados repetidamente, es menos propenso a errores importar y confiar en el certificado emitido por la CA, en lugar de confirmar una exención de seguridad cada vez que se renueva el certificado del servidor.
Con menor frecuencia, se utilizan certificados confiables para cifrar o firmar mensajes. Las CA también proporcionan certificados de usuario final, que se pueden utilizar con S/MIME . Sin embargo, el cifrado implica la clave pública del receptor y, dado que los autores y los receptores de mensajes cifrados, aparentemente, se conocen entre sí, la utilidad de un tercero confiable se limita a la verificación de la firma de los mensajes enviados a listas de correo públicas.
En todo el mundo, el negocio de las autoridades de certificación está fragmentado y los proveedores nacionales o regionales dominan su mercado local. Esto se debe a que muchos usos de los certificados digitales, como las firmas digitales legalmente vinculantes, están vinculados a leyes, regulaciones y esquemas de acreditación locales para las autoridades de certificación.
Sin embargo, el mercado de certificados de servidor TLS/SSL de confianza global está en manos de un pequeño número de empresas multinacionales. Este mercado tiene 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 América del Norte y ETSI en Europa [9] ) para que un navegador web o un sistema operativo los incluya como raíz de confianza.
Al 24 de agosto de 2020 [actualizar], 147 certificados raíz, que representan a 52 organizaciones, son confiables en el navegador web Mozilla Firefox , [10] 168 certificados raíz, que representan a 60 organizaciones, son confiables para macOS , [11] y 255 certificados raíz, que representan a 101 organizaciones, son confiables para 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 las que se incluyen 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 permitir la instalación y el mantenimiento de certificados. [14] Let's Encrypt es operado por el recientemente formado Internet Security Research Group , una organización sin fines de lucro de California reconocida como exenta de impuestos a nivel federal. [15]
Según Netcraft , el estándar de la industria para monitorear certificados TLS activos, en mayo de 2015, "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 públicos. El primer puesto lo ha ocupado Symantec (o VeriSign antes de que Symantec lo comprara) desde que comenzó [nuestra] encuesta, 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 activos, Symantec emitió el 44% de los certificados válidos y confiables en uso, significativamente más que su participación de mercado general". [16]
En 2020, según la empresa de encuestas independiente Netcraft , "DigiCert es la autoridad de certificación de alta seguridad más grande del mundo, con el 60% del mercado de certificados de validación extendida y el 96% de los certificados validados por organizaciones a nivel mundial. [17]
A partir de julio de 2024, [actualizar]la empresa de encuestas W3Techs, que recopila estadísticas sobre el uso de la autoridad de certificación entre los 10 millones de sitios web principales de Alexa y el millón de sitios web principales de Tranco, enumera las seis autoridades más grandes por participación de uso absoluto como se muestra a continuación. [18]
Las CA comerciales que emiten la mayor parte 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 utilizadas para la validación de dominio varían entre las CA, pero en general las técnicas de validación de dominio tienen como objetivo demostrar que el solicitante del certificado controla un nombre de dominio determinado , no información sobre la identidad del solicitante.
Muchas autoridades de certificación también ofrecen certificados de validación extendida (EV) como una alternativa más rigurosa a los certificados validados por dominio. La validación extendida tiene como objetivo verificar no solo el control de un nombre de dominio, sino también la información de identidad adicional que se incluirá en el certificado. Algunos navegadores muestran esta información de identidad adicional en un cuadro verde en la barra de URL. 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 validado por dominio para el dominio víctima y desplegarlo 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. Hay algunas dudas sobre si los usuarios 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 EV de IE7, sin embargo, el navegador actual de Microsoft, Edge , muestra una diferencia significativamente mayor entre los certificados EV y los validados por dominio, ya que los certificados validados por dominio tienen un candado hueco y gris.
La validación de dominios sufre ciertas limitaciones estructurales de seguridad. En particular, siempre es vulnerable a ataques que permiten a un adversario observar las sondas de validación de dominios que envían las CA. Estos 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. Estos ataques son posibles tanto en la red cercana a una CA como cerca del propio dominio de la víctima.
Una de las técnicas de validación de dominios más comunes implica enviar un correo electrónico que contenga 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 de contacto técnico que aparece en la entrada WHOIS del dominio o un correo electrónico administrativo como admin@ , administrator@ , webmaster@ , hostmaster@ o postmaster@ del dominio. [19] [20] Algunas autoridades de certificación pueden aceptar la confirmación utilizando root@ , [ cita requerida ] info@ o support@ en el dominio. [21] La teoría detrás de la validación de dominios 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 han sido a veces una fuente de vulnerabilidades de seguridad. En un caso, los investigadores de seguridad demostraron que los atacantes podían obtener certificados para sitios de correo web porque una CA estaba dispuesta a utilizar una dirección de correo electrónico como [email protected] 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. [22]
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 no estaba claro para los administradores de correo electrónico qué direcciones debían reservarse. La primera versión de los Requisitos básicos del CA/Browser Forum , adoptada en noviembre de 2011, especificaba una lista de dichas direcciones. Esto permitía a los servidores de correo reservar esas direcciones para uso administrativo, aunque estas 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 pudo obtener un certificado validado por dominio para live.fi, a pesar de no ser el propietario del nombre de dominio. [23]
Una CA emite certificados digitales que contienen una clave pública y la identidad del propietario. La clave privada correspondiente no se pone a disposición del público, sino que el usuario final que generó el par de claves la mantiene en secreto. El certificado es también una confirmación o validación por parte de la CA de que la clave pública contenida en el certificado pertenece a la persona, organización, servidor u otra entidad indicada en el certificado. La obligación de una CA en tales esquemas es verificar las credenciales de un solicitante, de modo que los usuarios y las partes que confían puedan confiar en la información contenida en el certificado emitido. Las CA utilizan una variedad de estándares y pruebas para hacerlo. En esencia, la autoridad de certificación es responsable de decir "sí, esta persona es quien dice ser, y nosotros, la CA, lo certificamos". [24]
Si el usuario confía en la CA y puede verificar su firma, entonces también puede asumir que una determinada clave pública pertenece efectivamente a quien está identificado en el certificado. [25]
La criptografía de clave pública se puede utilizar para cifrar datos comunicados entre dos partes. Esto suele ocurrir cuando un usuario inicia sesión en cualquier sitio que implemente el protocolo HTTP Secure . En este ejemplo, supongamos que el usuario inicia sesión en la página de inicio de su banco www.bank.example para realizar operaciones bancarias en línea. Cuando el usuario abre la página de inicio www.bank.example, recibe una clave pública junto con todos los datos que muestra su navegador web. La clave pública se puede utilizar para cifrar datos del cliente al servidor, pero el procedimiento seguro es utilizarla en un protocolo que determine una clave de cifrado simétrica compartida temporal; los mensajes en un protocolo de intercambio de claves de este tipo se pueden cifrar con la clave pública del banco de tal manera que solo el servidor del banco tenga la clave privada para leerlos. [26]
El resto de la comunicación se realiza utilizando la nueva clave simétrica (desechable), de modo que cuando el usuario introduce información en la página del banco y la envía (envía la información de vuelta al banco), los datos que el usuario ha introducido en la página quedan cifrados en su navegador web. Por lo tanto, incluso si alguien puede acceder a los datos (cifrados) que el usuario comunicó a www.bank.example, dicho espía no puede leerlos ni descifrarlos.
Este mecanismo sólo es seguro si el usuario puede estar seguro de que es el banco lo que ve en su navegador web. Si el usuario escribe www.bank.example, pero su comunicación es interceptada y un sitio web falso (que simula ser el sitio web del banco) envía la información de la página de vuelta al navegador del usuario, la página web falsa puede enviar una clave pública falsa al usuario (para la cual el sitio falso posee una clave privada correspondiente). El usuario completará el formulario con sus datos personales y enviará la página. La página web falsa obtendrá entonces acceso a los datos del usuario.
Esto es lo que pretende evitar el mecanismo de la autoridad de certificación. Una autoridad de certificación (CA) es una organización que almacena claves públicas y sus propietarios, y cada parte en una comunicación confía en esta organización (y conoce su clave pública). Cuando el navegador web del usuario recibe la clave pública de www.bank.example también recibe una firma digital de la clave (con algo más de información, en un llamado certificado X.509 ). El navegador ya posee la clave pública de la CA y, en consecuencia, puede verificar la firma, confiar en el certificado y la clave pública que contiene: dado que www.bank.example utiliza una clave pública que certifica la autoridad de certificación, un www.bank.example falso solo puede utilizar la misma clave pública. Dado que el www.bank.example falso no conoce la clave privada correspondiente, no puede crear la firma necesaria para verificar su autenticidad. [27]
Es difícil asegurar la exactitud de la correspondencia entre los datos y la entidad cuando los datos se presentan a la CA (quizás a través de una red electrónica), y cuando también se presentan las credenciales de la persona/empresa/programa que solicita un certificado. Por eso, las CA comerciales suelen utilizar una combinación de técnicas de autenticación que incluyen el aprovechamiento de las oficinas gubernamentales, la infraestructura de pago, las bases de datos y servicios de terceros y la heurística personalizada. En algunos sistemas empresariales, se pueden utilizar formas locales de autenticación, como Kerberos, para obtener un certificado que, a su vez, puede ser utilizado por terceros externos que confían en él. En algunos casos, se exige a los notarios que conozcan personalmente a la parte cuya firma se va a certificar; se trata de un estándar más alto que el que alcanzan muchas CA. Según el esquema de la Asociación Estadounidense de Abogados sobre la Gestión de Transacciones en Línea, los puntos principales de los estatutos federales y estatales de los EE. UU. promulgados con respecto a las firmas digitales han sido "prevenir una regulación local conflictiva y excesivamente onerosa y establecer que los escritos electrónicos satisfacen los requisitos tradicionales asociados con los documentos en papel". Además, el estatuto de firma electrónica de los EE. UU. y el código UETA sugerido [28] ayudan a garantizar que:
A pesar de las medidas de seguridad adoptadas para verificar correctamente la identidad de personas y empresas, existe el riesgo de que una única CA emita un certificado falso a un impostor. También es posible registrar personas y empresas con el mismo nombre o nombres muy similares, lo que puede dar lugar a confusión. Para minimizar este peligro, la iniciativa de transparencia de certificados propone auditar todos los certificados en un registro público infalsificable, lo que podría ayudar a prevenir el phishing . [29] [30]
En implementaciones a gran escala, es posible que Alice no esté familiarizada con la autoridad de certificación de Bob (quizás cada uno tenga un servidor CA diferente), por lo que el certificado de Bob también puede incluir la clave pública de su CA firmada por una CA 2 diferente , que presumiblemente Alice puede reconocer. Este proceso generalmente conduce a una jerarquía o malla de CA y certificados de CA.
Un certificado puede ser revocado antes de su vencimiento, lo que indica que ya no es válido. Sin la revocación, un atacante podría explotar un certificado comprometido o emitido incorrectamente hasta su vencimiento. [31] Por lo tanto, la revocación es una parte importante de una infraestructura de clave pública . [32] La revocación la realiza la CA emisora, que produce una declaración de revocación autenticada criptográficamente . [33]
Para distribuir información de revocación a los clientes, la puntualidad del descubrimiento de la revocación (y, por lo tanto, la ventana para que un atacante explote un certificado comprometido) se compensa con el uso de recursos en la consulta de estados de revocación y las preocupaciones de privacidad. [34] Si la información de revocación no está disponible (ya sea debido a un accidente o un ataque), los clientes deben decidir si fallan de manera severa y tratan un certificado como si estuviera revocado (y así degradan la disponibilidad ) o fallan de manera suave y lo tratan como si no estuviera revocado (y permiten a los atacantes eludir la revocación). [35]
Debido al costo de las comprobaciones de revocación y al impacto en la disponibilidad de servicios remotos potencialmente poco fiables, los navegadores web limitan las comprobaciones de revocación que realizan y, cuando lo hacen, fallan de manera suave. [36] Las listas de revocación de certificados consumen demasiado ancho de banda para su uso rutinario, y el Protocolo de estado de certificados en línea presenta problemas de latencia de conexión y privacidad. Se han propuesto otros esquemas, pero aún no se han implementado con éxito, para permitir la comprobación de fallas de manera estricta. [32]
El CA/Browser Forum publica los Requisitos básicos, [42] una lista de políticas y requisitos técnicos que deben seguir las CA. Estos son un requisito para la inclusión en los almacenes de certificados de Firefox [43] y Safari. [44]
Si la CA puede ser subvertida, entonces se pierde la seguridad de todo el sistema, subvirtiendo potencialmente todas las entidades que confían en la CA comprometida.
Por ejemplo, supongamos que un atacante, Eve, consigue que una CA le emita un certificado que dice representar a Alice. Es decir, el certificado declararía públicamente que representa a Alice y podría incluir otra información sobre Alice. Parte de la información sobre Alice, como el nombre de su empleador, podría ser verdadera, lo que aumentaría la credibilidad del certificado. Eve, sin embargo, tendría la importantísima clave privada asociada al certificado. Eve podría entonces utilizar el certificado para enviar un correo electrónico firmado digitalmente a Bob, engañándolo para que crea que el correo electrónico es de Alice. Bob podría incluso responder con un correo electrónico cifrado, creyendo que solo Alice podría leerlo, cuando Eve en realidad es capaz de descifrarlo utilizando la clave privada.
Un caso notable de subversión de CA como éste ocurrió en 2001, cuando la autoridad de certificación VeriSign emitió dos certificados a una persona que decía representar a Microsoft. Los certificados tienen el nombre "Microsoft Corporation", por lo que podrían usarse para engañar a alguien y hacerle 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 distribuidor 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] supuestamente por parte de piratas informáticos iraníes. Hay pruebas 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 (man-in-the-middle) que efectivamente permitía a una empresa rastrear el tráfico de red interna SSL utilizando el certificado subordinado. [51]
En 2012, el malware Flame (también conocido como SkyWiper) contenía módulos que tenían 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 roto. De esta forma, los autores pudieron llevar a cabo 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 y afiliada al registro de dominios central de China emitió certificados no autorizados para dominios de Google. [54] [55] Por lo tanto, Google eliminó tanto MCS como 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 CA, sin necesidad de acceso continuo a los sistemas de la CA. 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), que les permite firmar certificados con una clave, pero generalmente impiden la extracción de esa clave con controles físicos y de software. Las CA suelen tomar la precaución adicional de mantener la clave para sus certificados raíz de largo plazo en un HSM que se mantiene fuera de línea , excepto cuando es necesario para firmar certificados intermedios de vida más corta. 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.
Las CA a veces utilizan una ceremonia de clave al generar claves de firma, con el fin de garantizar que las claves no sean alteradas ni copiadas.
La debilidad crítica en la forma en que se implementa el esquema X.509 actual es que cualquier CA en la que confíe 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, ya 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 confiables es el protocolo HTTPS. Como todos los navegadores web principales se distribuyen a sus usuarios finales preconfigurados con una lista de CA confiables que se cuentan por docenas, esto significa que cualquiera de estas CA confiables preaprobadas puede emitir un certificado válido para cualquier dominio. [58] La respuesta de la industria a esto ha sido moderada. [59] Dado que el contenido de la lista de CA confiables preconfigurada de un navegador está 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.
Esta cuestión es el impulso que impulsa el desarrollo del protocolo de autenticación de entidades con nombre (DANE) basado en DNS . Si se adopta junto con las extensiones de seguridad del sistema de nombres de dominio (DNSSEC), DANE reducirá en gran medida, si no elimina, el papel de terceros de confianza en la infraestructura de clave pública (PKI) de un dominio.