Infraestructura de clave pública

Una infraestructura de clave pública ( PKI ) es un conjunto de roles, políticas, hardware, software y procedimientos necesarios para crear, administrar, distribuir, usar, almacenar y revocar certificados digitales y administrar el cifrado de clave pública .

El objetivo de una PKI es facilitar la transferencia electrónica segura de información para una variedad de actividades en red, como el comercio electrónico, la banca por Internet y el correo electrónico confidencial. Es necesaria para actividades en las que las contraseñas simples son un método de autenticación inadecuado y se requieren pruebas más rigurosas para confirmar la identidad de las partes involucradas en la comunicación y validar la información que se transfiere.

En criptografía , una PKI es un mecanismo que vincula claves públicas con identidades respectivas de entidades (como personas y organizaciones). ^{[1] [2]} La vinculación se establece a través de un proceso de registro y emisión de certificados en y por una autoridad de certificación (CA). Dependiendo del nivel de seguridad de la vinculación, esto puede llevarse a cabo mediante un proceso automatizado o bajo supervisión humana. Cuando se realiza a través de una red, esto requiere el uso de un protocolo seguro de inscripción de certificados o de gestión de certificados como CMP .

La función de PKI que puede ser delegada por una CA para asegurar un registro válido y correcto se denomina autoridad de registro (RA). Una RA es responsable de aceptar solicitudes de certificados digitales y autenticar la entidad que realiza la solicitud. ^[3] La RFC 3647 del Grupo de trabajo de ingeniería de Internet define una RA como "Una entidad que es responsable de una o más de las siguientes funciones: la identificación y autenticación de los solicitantes de certificados, la aprobación o rechazo de solicitudes de certificados, iniciar revocaciones o suspensiones de certificados bajo ciertas circunstancias, procesar solicitudes de suscriptores para revocar o suspender sus certificados y aprobar o rechazar solicitudes de suscriptores para renovar o volver a codificar sus certificados. Las RA, sin embargo, no firman ni emiten certificados (es decir, a una RA se le delegan ciertas tareas en nombre de una CA)". ^[4] Si bien Microsoft puede haberse referido a una CA subordinada como una RA, ^[5] esto es incorrecto de acuerdo con los estándares de PKI X.509. Las RA no tienen la autoridad de firma de una CA y solo administran la verificación y el suministro de certificados. En el caso de Microsoft PKI, la funcionalidad de RA se proporciona a través del sitio web de Microsoft Certificate Services o a través de Active Directory Certificate Services, que aplica Microsoft Enterprise CA y la política de certificados a través de plantillas de certificados y administra la inscripción de certificados (inscripción manual o automática). En el caso de las CA independientes de Microsoft, la función de RA no existe, ya que todos los procedimientos que controlan la CA se basan en el procedimiento de administración y acceso asociado con el sistema que aloja la CA y la propia CA, en lugar de Active Directory. La mayoría de las soluciones de PKI comerciales que no son de Microsoft ofrecen un componente de RA independiente.

Una entidad debe ser identificable de forma única dentro de cada dominio de CA en función de la información sobre esa entidad. Una autoridad de validación (VA) externa puede proporcionar esta información de entidad en nombre de la CA.

El estándar X.509 define el formato más comúnmente utilizado para los certificados de clave pública . ^[6]

PKI proporciona "servicios de confianza"; en términos sencillos, confiar en las acciones o resultados de entidades, ya sean personas o computadoras. Los objetivos de los servicios de confianza respetan una o más de las siguientes capacidades: Confidencialidad, Integridad y Autenticidad (CIA).

Confidencialidad: garantía de que ninguna entidad puede ver de forma maliciosa o involuntaria una carga útil en texto claro. Los datos se cifran para que sean secretos, de modo que, incluso si se leyeran, aparecen como un galimatías. Quizás el uso más común de PKI con fines de confidencialidad se da en el contexto de la seguridad de la capa de transporte ( TLS ). TLS es una capacidad que sustenta la seguridad de los datos en tránsito, es decir, durante la transmisión. Un ejemplo clásico de TLS para la confidencialidad es cuando se utiliza un navegador de Internet para iniciar sesión en un servicio alojado en un sitio web basado en Internet mediante la introducción de una contraseña.

Integridad: Garantía de que si una entidad modifica (manipula) de la forma más mínima los datos transmitidos, será evidente que esto ocurrió, ya que su integridad se habrá visto comprometida. A menudo, no es de suma importancia evitar que se comprometa la integridad (a prueba de manipulaciones), sin embargo, es de suma importancia que, si se compromete la integridad, exista evidencia clara de que lo ha hecho (a prueba de manipulaciones).

Autenticidad: Garantía de que cada entidad tiene certeza de a qué se está conectando o puede demostrar su legitimidad al conectarse a un servicio protegido. La primera se denomina autenticación del lado del servidor y se utiliza normalmente cuando se autentica en un servidor web mediante una contraseña. La segunda se denomina autenticación del lado del cliente y a veces se utiliza cuando se autentica mediante una tarjeta inteligente (que aloja un certificado digital y una clave privada).

La criptografía de clave pública es una técnica criptográfica que permite a las entidades comunicarse de forma segura en una red pública insegura y verificar de forma confiable la identidad de una entidad a través de firmas digitales . ^[7]

Una infraestructura de clave pública (PKI) es un sistema para la creación, almacenamiento y distribución de certificados digitales que se utilizan para verificar que una clave pública particular pertenece a una entidad determinada. La PKI crea certificados digitales que asignan claves públicas a entidades, almacena de forma segura estos certificados en un repositorio central y los revoca si es necesario. ^{[8] [9] [10]}

Una PKI consta de: ^{[9] [11] [12]}

• Una autoridad de certificación (CA) que almacena, emite y firma los certificados digitales;
• Una autoridad de registro (RA) que verifica la identidad de las entidades que solicitan que sus certificados digitales se almacenen en la CA;
• Un directorio central , es decir, una ubicación segura en la que se almacenan e indexan las claves;
• Un sistema de gestión de certificados que gestiona cuestiones como el acceso a los certificados almacenados o la entrega de los certificados que se van a emitir;
• Una política de certificación que establece los requisitos de la PKI en relación con sus procedimientos. Su finalidad es permitir que terceros analicen la fiabilidad de la PKI.

La función principal de la CA es firmar digitalmente y publicar la clave pública vinculada a un usuario determinado. Esto se hace utilizando la clave privada de la propia CA, de modo que la confianza en la clave del usuario depende de la confianza que se tenga en la validez de la clave de la CA. Cuando la CA es un tercero independiente del usuario y del sistema, se denomina Autoridad de Registro (RA), que puede o no ser independiente de la CA. ^[13] La vinculación de la clave al usuario se establece, dependiendo del nivel de seguridad que tenga la vinculación, mediante software o bajo supervisión humana.

El término tercero de confianza (TTP) también puede utilizarse para referirse a una autoridad de certificación (CA). Además, la propia PKI se utiliza a menudo como sinónimo de una implementación de CA. ^[14]

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. ^[15] Por lo tanto, la revocación es una parte importante de una infraestructura de clave pública. ^[16] La revocación la realiza la autoridad de certificación emisora , que produce una declaración de revocación autenticada criptográficamente . ^[17]

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. ^[18] 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 total 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). ^[19]

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 forma suave. ^[20] 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 errores de forma estricta. ^[16]

En este modelo de relaciones de confianza, una CA es un tercero confiable, en el que confían tanto el sujeto (propietario) del certificado como la parte que confía en el certificado.

Según un informe de NetCraft de 2015, ^[21] el estándar de la industria para monitorear certificados de seguridad de la capa de transporte (TLS) activos, afirma que "Aunque el ecosistema global [TLS] es competitivo, está dominado por un puñado de CA importantes: tres autoridades de certificación ( Symantec , Sectigo , 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 fuera comprado por Symantec) 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".

A raíz de importantes problemas en la forma en que se gestionaba la emisión de certificados, todos los actores principales comenzaron a desconfiar gradualmente de los certificados emitidos por Symantec, a partir de 2017 y hasta 2021. ^{[22] [23] [24] [25]}

Este enfoque implica un servidor que actúa como una autoridad de certificación fuera de línea dentro de un sistema de inicio de sesión único . Un servidor de inicio de sesión único emitirá certificados digitales en el sistema del cliente, pero nunca los almacenará. Los usuarios pueden ejecutar programas, etc. con el certificado temporal. Es común encontrar esta variedad de solución con certificados basados ​​en X.509 . ^[26]

A partir de septiembre de 2020, la validez del certificado TLS se redujo a 13 meses.

Un enfoque alternativo al problema de la autenticación pública de la información de clave pública es el esquema de red de confianza, que utiliza certificados autofirmados y certificaciones de terceros de esos certificados. El término singular "red de confianza" no implica la existencia de una única red de confianza o punto de confianza común, sino más bien una de varias "redes de confianza" potencialmente disjuntas. Ejemplos de implementaciones de este enfoque son PGP (Pretty Good Privacy) y GnuPG (una implementación de OpenPGP , la especificación estandarizada de PGP). Debido a que PGP y las implementaciones permiten el uso de firmas digitales de correo electrónico para la autopublicación de información de clave pública, es relativamente fácil implementar una red de confianza propia.

Una de las ventajas de la red de confianza, como en PGP , es que puede interoperar con una CA de PKI en la que confíen plenamente todas las partes de un dominio (como una CA interna de una empresa) que esté dispuesta a garantizar los certificados, como un introductor de confianza. Si la "red de confianza" es de total confianza, entonces, debido a la naturaleza de una red de confianza, confiar en un certificado es otorgar confianza a todos los certificados de esa red. Una PKI es tan valiosa como los estándares y prácticas que controlan la emisión de certificados, e incluir PGP o una red de confianza instituida personalmente podría degradar significativamente la confiabilidad de la implementación de PKI de esa empresa o dominio. ^[27]

El concepto de red de confianza fue propuesto por primera vez por el creador de PGP, Phil Zimmermann, en 1992 en el manual de la versión 2.0 de PGP:

A medida que pase el tiempo, acumulará claves de otras personas a las que desee designar como presentadores de confianza. Todos los demás elegirán sus propios presentadores de confianza. Y todos acumularán y distribuirán gradualmente con su clave una colección de firmas de certificación de otras personas, con la expectativa de que cualquiera que la reciba confíe en al menos una o dos de las firmas. Esto provocará el surgimiento de una red de confianza descentralizada y tolerante a fallas para todas las claves públicas.

Otra alternativa, que no se ocupa de la autenticación pública de la información de clave pública, es la infraestructura de clave pública simple (SPKI), que surgió de tres esfuerzos independientes para superar las complejidades de X.509 y la red de confianza de PGP . La SPKI no asocia a los usuarios con personas, ya que lo que se confía es la clave , no la persona. La SPKI no utiliza ninguna noción de confianza, ya que el verificador es también el emisor. Esto se denomina "bucle de autorización" en la terminología de la SPKI, donde la autorización es parte integral de su diseño. ^[28] Este tipo de PKI es especialmente útil para realizar integraciones de PKI que no dependen de terceros para la autorización de certificados, la información de certificados, etc.; un buen ejemplo de esto es una red con espacio de aire en una oficina.

Los identificadores descentralizados (DID) eliminan la dependencia de registros centralizados para los identificadores, así como de autoridades de certificación centralizadas para la gestión de claves, que es el estándar en PKI jerárquica. En los casos en que el registro DID es un libro de contabilidad distribuido , cada entidad puede actuar como su propia autoridad raíz. Esta arquitectura se conoce como PKI descentralizada (DPKI). ^{[29] [30]}

This section does not cite any sources. Please help improve this section by adding citations to reliable sources. Unsourced material may be challenged and removed. (January 2014) (Learn how and when to remove this message)

Los avances en PKI ocurrieron a principios de la década de 1970 en la agencia de inteligencia británica GCHQ , donde James Ellis , Clifford Cocks y otros hicieron importantes descubrimientos relacionados con algoritmos de cifrado y distribución de claves. ^[31] Debido a que los avances en GCHQ son altamente clasificados, los resultados de este trabajo se mantuvieron en secreto y no se reconocieron públicamente hasta mediados de la década de 1990.

La divulgación pública de los algoritmos de intercambio seguro de claves y de claves asimétricas en 1976 por parte de Diffie , Hellman , Rivest , Shamir y Adleman cambió por completo las comunicaciones seguras. Con el desarrollo posterior de las comunicaciones electrónicas digitales de alta velocidad ( Internet y sus predecesores), se hizo evidente la necesidad de encontrar formas en las que los usuarios pudieran comunicarse de forma segura entre sí y, como consecuencia adicional de ello, de encontrar formas en las que los usuarios pudieran estar seguros con quién estaban interactuando realmente.

Se inventaron y analizaron diversos protocolos criptográficos dentro de los cuales se podían usar de manera efectiva los nuevos primitivos criptográficos . Con la invención de la World Wide Web y su rápida difusión, la necesidad de autenticación y comunicación segura se volvió aún más aguda. Las razones comerciales por sí solas (por ejemplo, comercio electrónico , acceso en línea a bases de datos propietarias desde navegadores web ) eran suficientes. Taher Elgamal y otros en Netscape desarrollaron el protocolo SSL (' https ' en URL web ); incluía el establecimiento de claves, autenticación de servidor (antes de v3, unidireccional solamente), etc. ^[32] De este modo, se creó una estructura PKI para los usuarios/sitios web que deseaban comunicaciones seguras.

Los vendedores y empresarios vieron la posibilidad de un gran mercado, crearon empresas (o nuevos proyectos en empresas existentes) y comenzaron a reclamar reconocimiento legal y protección frente a responsabilidades. Un proyecto tecnológico de la Asociación Estadounidense de Abogados publicó un análisis extenso de algunos de los aspectos legales previsibles de las operaciones de PKI (consulte las directrices de firma digital de la ABA ) y, poco después, varios estados de EE. UU. ( Utah fue el primero en 1995) y otras jurisdicciones de todo el mundo comenzaron a promulgar leyes y adoptar regulaciones. Los grupos de consumidores plantearon preguntas sobre la privacidad , el acceso y las consideraciones de responsabilidad, que se tomaron más en cuenta en algunas jurisdicciones que en otras. ^[33]

Las leyes y reglamentos promulgados diferían, hubo problemas técnicos y operativos para convertir los esquemas PKI en operaciones comerciales exitosas, y el progreso ha sido mucho más lento de lo que los pioneros habían imaginado que sería.

En los primeros años del siglo XXI, la ingeniería criptográfica subyacente no era fácil de implementar correctamente. Los procedimientos operativos (manuales o automáticos) no eran fáciles de diseñar correctamente (ni siquiera si se diseñaban, de ejecutar a la perfección, como exigía la ingeniería). Los estándares que existían eran insuficientes.

Los proveedores de PKI han encontrado un mercado, pero no es exactamente el mercado que se imaginaba a mediados de los años 1990, y ha crecido más lentamente y de maneras algo diferentes a las anticipadas. ^[34] Las PKI no han resuelto algunos de los problemas que se esperaban, y varios proveedores importantes han cerrado o han sido adquiridos por otros. La PKI ha tenido más éxito en las implementaciones gubernamentales; la implementación de PKI más grande hasta la fecha es la infraestructura PKI de la Agencia de Sistemas de Información de Defensa (DISA) para el programa de Tarjetas de Acceso Común .

Las PKI de un tipo u otro, y de varios proveedores, tienen muchos usos, incluido el suministro de claves públicas y enlaces a identidades de usuario que se utilizan para:

• Cifrado y/o autenticación del remitente de mensajes de correo electrónico (por ejemplo, utilizando OpenPGP o S/MIME );
• Cifrado y/o autenticación de documentos (por ejemplo, los estándares de Firma XML o Cifrado XML si los documentos están codificados como XML );
• Autenticación de usuarios en aplicaciones (por ejemplo, inicio de sesión con tarjeta inteligente , autenticación de clientes con SSL/TLS ). Existe un uso experimental de la autenticación HTTP firmada digitalmente en los proyectos Enigform y mod_openpgp ;
• Protocolos de comunicación seguros de arranque , como el intercambio de claves de Internet (IKE) y SSL/TLS . En ambos, la configuración inicial de un canal seguro (una " asociación de seguridad ") utiliza métodos de clave asimétrica (es decir, clave pública), mientras que la comunicación real utiliza métodos más rápidos de clave simétrica (es decir, clave secreta );
• Las firmas móviles son firmas electrónicas que se crean utilizando un dispositivo móvil y dependen de servicios de firma o certificación en un entorno de telecomunicaciones independiente de la ubicación; ^[35]
• La Internet de las cosas requiere una comunicación segura entre dispositivos que confíen mutuamente. Una infraestructura de clave pública permite que los dispositivos obtengan y renueven certificados X.509 que se utilizan para establecer la confianza entre dispositivos y cifrar las comunicaciones mediante TLS .

• OpenSSL es la forma más simple de CA y herramienta para PKI. Es un conjunto de herramientas, desarrollado en C, que se incluye en todas las principales distribuciones de Linux y se puede utilizar tanto para crear su propia CA (simple) como para habilitar aplicaciones para PKI. ( Licencia Apache )
• EJBCA es una implementación de CA de nivel empresarial con todas las funciones desarrollada en Java . Se puede utilizar para configurar una CA tanto para uso interno como para un servicio. ( Licencia LGPL )
• XiPKI, ^[36] CA y respondedor OCSP. Con soporte SHA-3 , implementado en Java . ( Licencia Apache )
• XCA ^[37] es una interfaz gráfica y una base de datos. XCA utiliza OpenSSL para las operaciones de PKI subyacentes.
• DogTag es una CA con todas las funciones desarrollada y mantenida como parte del Proyecto Fedora .
• CFSSL ^{[38] [39]} conjunto de herramientas de código abierto desarrollado por CloudFlare para firmar, verificar y agrupar certificados TLS. ( Licencia BSD de 2 cláusulas )
• Herramienta Vault ^[40] para la gestión segura de secretos (incluidos los certificados TLS) desarrollada por HashiCorp . ( Licencia pública de Mozilla 2.0 )
• Boulder, una CA basada en ACME escrita en Go . Boulder es el software que ejecuta Let's Encrypt .

Algunos sostienen que la compra de certificados para proteger sitios web mediante SSL/TLS y proteger software mediante firma de código es una operación costosa para las pequeñas empresas. ^[41] Sin embargo, la aparición de alternativas gratuitas, como Let's Encrypt , ha cambiado esto. HTTP/2 , la última versión del protocolo HTTP, permite conexiones no seguras en teoría; en la práctica, las principales empresas de navegadores han dejado en claro que admitirían este protocolo solo a través de una conexión TLS protegida por PKI . ^[42] La implementación de HTTP/2 en navegadores web, incluidos Chrome , Firefox , Opera y Edge , admite HTTP/2 solo a través de TLS mediante el uso de la extensión ALPN del protocolo TLS. Esto significaría que, para obtener los beneficios de velocidad de HTTP/2, los propietarios de sitios web se verían obligados a comprar certificados SSL/TLS controlados por corporaciones.

Actualmente, la mayoría de los navegadores web se entregan con certificados intermedios preinstalados emitidos y firmados por una autoridad de certificación, mediante claves públicas certificadas por los llamados certificados raíz . Esto significa que los navegadores deben contar con una gran cantidad de proveedores de certificados diferentes, lo que aumenta el riesgo de que se vulneren las claves. ^[43]

Cuando se sabe que una clave está comprometida, se puede solucionar revocando el certificado, pero ese tipo de compromiso no es fácil de detectar y puede suponer una grave violación de la seguridad. Los navegadores tienen que emitir un parche de seguridad para revocar los certificados intermediarios emitidos por una autoridad de certificación raíz comprometida. ^[44]

• Agilidad criptográfica (criptoagilidad)
• Protocolo de gestión de certificados (CMP)
• Gestión de certificados a través de CMS (CMC)
• Protocolo simple de inscripción de certificados (SCEP)
• Inscripción mediante transporte seguro (EST)
• Entorno de gestión automática de certificados (ACME)
• Infraestructura de clave pública de recursos (RPKI)

• 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 el imprescindible OCSP?" (PDF) . Actas de la Conferencia de medición de Internet de 2018. págs. 105–118. doi :10.1145/3278532.3278543. ISBN . 9781450356190. Número de identificación del sujeto  53223350.
• Larisch, James; Choffnes, David; Levin, Dave; Maggs, Bruce M.; Mislove, Alan; Wilson, Christo (2017). "CRLite: un sistema escalable para enviar todas las revocaciones de TLS a todos los navegadores". Simposio IEEE sobre seguridad y privacidad de 2017 (SP) . págs. 539–556. doi : 10.1109/sp.2017.17 . ISBN . 978-1-5090-5533-3. Número de identificación del sujeto  3926509.
• Sheffer, Yaron; Saint-Andre, Pierre; Fossati, Thomas (noviembre de 2022). Recomendaciones para el uso seguro de la seguridad de la capa de transporte (TLS) y la seguridad de la capa de transporte de datagramas (DTLS). doi : 10.17487/RFC9325 . RFC 9325.
• Smith, Trevor; Dickinson, Luke; Seamons, Kent (2020). "Let's Revoke: Scalable Global Certificate Revocation". Actas del Simposio sobre seguridad de redes y sistemas distribuidos de 2020. doi : 10.14722 /ndss.2020.24084 . ISBN . 978-1-891562-61-7.S2CID211268930  .​

• Tendencias de participación de mercado de las autoridades de certificación SSL (W3Techs)