Infraestructura de Clave Pública

Diagrama de una infraestructura 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 gestionar el cifrado de clave pública. El propósito de una PKI es facilitar la transferencia electrónica segura de información para una variedad de actividades de red, como el comercio electrónico, la banca por Internet y el correo electrónico confidencial. Se requiere para actividades donde 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 para validar la información que se transfiere.

En criptografía, una PKI es un arreglo que vincula claves públicas con las respectivas identidades de entidades (como personas y organizaciones). La vinculación se establece a través de un proceso de registro y emisión de certificados en y por una autoridad certificadora (CA). Según el 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 registro seguro de certificados o un protocolo de gestión de certificados como CMP.

La función de PKI que puede ser delegada por una CA para garantizar un registro válido y correcto se denomina autoridad de registro (RA). Básicamente, una RA se encarga de aceptar solicitudes de certificados digitales y autenticar a la entidad que realiza la solicitud. El RFC 3647 de Internet Engineering Task Force 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 las solicitudes de certificados, el inicio 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 cambiar la clave de sus certificados. Sin embargo, las RA no firman ni emiten certificados (es decir, a una RA se le delegan ciertas tareas en nombre de una CA)." Si bien es posible que Microsoft se haya referido a una CA subordinada como RA, 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 gestionan la verificación y el aprovisionamiento de certificados. Por lo tanto, en el caso de Microsoft PKI, la funcionalidad de RA la proporciona el sitio web de Servicios de certificados de Microsoft o a través de Servicios de certificados de Active Directory, que hace cumplir la política de certificados y CA de Microsoft Enterprise 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 PKI comerciales que no son de Microsoft ofrecen un componente RA independiente.

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

El estándar X.509 define el formato más utilizado para los certificados de clave pública.

Capacidades

PKI proporciona "servicios de confianza" - en términos simples, confiar en las acciones o resultados de las entidades, ya sean personas o computadoras. Los objetivos del servicio 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 maliciosamente o sin darse cuenta una carga útil en texto claro. Los datos se cifran para que sean secretos, de modo que incluso si se leyeron, aparecen como un galimatías. Quizás el uso más común de PKI con fines de confidencialidad se encuentra 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 usa un navegador de Internet para iniciar sesión en un servicio alojado en un sitio web basado en Internet ingresando una contraseña.

Integridad: Garantía de que si una entidad cambiara (manipulara) los datos transmitidos de la forma más mínima, sería obvio que sucedió, ya que su integridad se habría visto comprometida. A menudo, no es de suma importancia evitar que la integridad se vea comprometida (a prueba de manipulaciones), sin embargo, es de suma importancia que si la integridad se ve comprometida, haya evidencia clara de que lo ha hecho (a prueba de manipulaciones).

Autenticidad: Garantía de que toda entidad tiene certeza de a qué se está conectando, o puede evidenciar su legitimidad al conectarse a un servicio protegido. El primero se denomina autenticación del lado del servidor, que normalmente se usa cuando se autentica en un servidor web mediante una contraseña. Esta última se denomina autenticación del lado del cliente; a veces se usa cuando se autentica con una tarjeta inteligente (que aloja un certificado digital y una clave privada).

Diseño

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 fiable la identidad de una entidad mediante firmas digitales.

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 determinada clave pública pertenece a una determinada entidad. La PKI crea certificados digitales que asignan claves públicas a entidades, almacena de forma segura estos certificados en un depósito central y los revoca si es necesario.

Una PKI consta de:

• A certificado (CA) that stores, issues and signs the digital certificates;
• A autoridad de registro (RA) which verifies the identity of entities requesting their digital certificates to be stored at the CA;
• A directorio central—es decir, una ubicación segura en la que se almacenan y indexan las llaves;
• A Sistema de gestión de certificados gestionar cosas como el acceso a certificados almacenados o la entrega de los certificados a emitir;
• A Política de certificado indicando los requisitos del PKI sobre sus procedimientos. Su propósito es permitir que los forasteros analicen la confianza del PKI.

Métodos de certificación

En términos generales, tradicionalmente ha habido tres enfoques para obtener esta confianza: autoridades de certificación (CA), web de confianza (WoT) e infraestructura de clave pública simple (SPKI).

Autoridades certificadoras

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

El término tercero de confianza (TTP) también se puede utilizar para la autoridad de certificación (CA). Además, PKI se utiliza a menudo como sinónimo de implementación de CA.

Revocación de certificados

Se puede revocar un certificado antes de que caduque, lo que indica que ya no es válido. Sin la revocación, un atacante podría explotar dicho certificado comprometido o mal emitido hasta que caduque. Por lo tanto, la revocación es una parte importante de una infraestructura de clave pública. La revocación la realiza la autoridad emisora de certificados, que produce una declaración de revocación autenticada criptográficamente.

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 al consultar los estados de revocación y las preocupaciones de privacidad. Si la información de revocación no está disponible (ya sea debido a un accidente o un ataque), los clientes deben decidir si fallar fuertemente y tratar un certificado como si estuviera revocado (y, por lo tanto, degradar la disponibilidad) o fail-soft y trátelo como no revocado (y permita a los atacantes eludir la revocación).

Debido al costo de las comprobaciones de revocación y el impacto en la disponibilidad de los servicios remotos potencialmente poco fiables, los navegadores web limitan las comprobaciones de revocación que realizarán y fallarán levemente donde lo hagan. Las listas de revocación de certificados consumen demasiado ancho de banda para el uso rutinario, y el Protocolo de estado de certificados en línea presenta problemas de privacidad y latencia de conexión. Se han propuesto otros esquemas, pero aún no se han implementado con éxito para permitir la verificación a prueba de fallas.

Cuota de mercado del emisor

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

Según el informe de NetCraft de 2015, el estándar de la industria para monitorear certificados activos de seguridad de la capa de transporte (TLS), establece que "Aunque el ecosistema global [TLS] es competitivo, está dominado por un puñado de importantes CA: tres autoridades de certificación (Symantec, Sectigo, GoDaddy) representan las tres cuartas partes de todos los certificados [TLS] emitidos en servidores web públicos. Symantec (o VeriSign antes de que Symantec la comprara) ha ocupado el primer puesto 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 los millones de sitios más ocupados, Symantec emitió el 44 % de los certificados válidos y confiables en uso, significativamente más que su participación de mercado general."

Después de problemas importantes en la forma en que se administraba la emisión de certificados, todos los principales actores desconfiaron gradualmente de los certificados emitidos por Symantec a partir de 2017.

Certificados temporales e inicio de sesión único

Este enfoque involucra 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 soluciones con certificados basados en X.509.

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

Red de confianza

Un enfoque alternativo al problema de la autenticación pública de información de clave pública es el esquema de web 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 común de confianza, sino más bien una de cualquier número de "redes de confianza" potencialmente inconexas. 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 sus 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 su propia red de confianza.

Uno de los beneficios de la web de confianza, como en PGP, es que puede interoperar con una CA de PKI de plena confianza para todas las partes en un dominio (como una CA interna en una empresa) que está dispuesta a garantizar certificados, como presentador de confianza. Si la "red de confianza" es completamente confiable, debido a la naturaleza de una web de confianza, confiar en un certificado es otorgar confianza a todos los certificados en esa web. Una PKI es tan valiosa como los estándares y las 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 la PKI de esa empresa o dominio.

El creador de PGP Phil Zimmermann presentó por primera vez el concepto de red de confianza en 1992 en el manual para PGP versión 2.0:

A medida que siga el tiempo, acumularás claves de otras personas que quizás quieras designar como promotores de confianza. Todos los demás elegirán sus propios presentadores de confianza. Y todos gradualmente se acumularán y distribuirán con su llave una colección de firmas certificadoras de otras personas, con la expectativa de que cualquiera que la reciba confiará al menos una o dos firmas. Esto causará el surgimiento de una red de confianza descentralizada defectuosa de la culpa para todas las claves públicas.

Infraestructura de clave pública sencilla

Otra alternativa, que no se ocupa de la autenticación pública de 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 PGP de confianza. SPKI no asocia usuarios con personas, ya que la clave es en lo que se confía, y no en la persona. 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 SPKI, donde la autorización es parte integral de su diseño. Este tipo de PKI es especialmente útil para realizar integraciones de PKI que no dependan de terceros para autorización de certificados, información de certificados, etc.; un buen ejemplo de esto es una red con espacio de aire en una oficina.

PKI descentralizada

Los identificadores descentralizados (DID) eliminan la dependencia de los registros centralizados para los identificadores, así como las autoridades de certificación centralizadas para la administración de claves, que es el estándar en PKI jerárquica. En los casos en que el registro DID sea un libro mayor distribuido, cada entidad puede servir como su propia autoridad raíz. Esta arquitectura se conoce como PKI descentralizada (DPKI).

Historia

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 los algoritmos de encriptación y la distribución de claves. Debido a que los desarrollos en GCHQ están 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 del intercambio seguro de claves y los algoritmos de claves asimétricas en 1976 por parte de Diffie, Hellman, Rivest, Shamir y Adleman cambió por completo las comunicaciones seguras. Con el mayor desarrollo de las comunicaciones electrónicas digitales de alta velocidad (Internet y sus predecesores), se hizo evidente la necesidad de formas en que los usuarios pudieran comunicarse entre sí de forma segura y, como consecuencia adicional de ello, de formas en que los usuarios pudieran comunicarse entre sí. seguro con quién estaban realmente interactuando.

Se inventaron y analizaron una variedad de protocolos criptográficos dentro de los cuales las nuevas primitivas criptográficas podrían usarse de manera efectiva. 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 hizo aún más aguda. Las razones comerciales por sí solas (por ejemplo, comercio electrónico, acceso en línea a bases de datos patentadas desde navegadores web) fueron suficientes. Taher Elgamal y otros en Netscape desarrollaron el protocolo SSL ('https' en URL web); incluía el establecimiento de claves, la autenticación del servidor (antes de v3, solo unidireccional), etc. Así se creó una estructura PKI para usuarios/sitios web que deseen comunicaciones seguras.

Los vendedores y empresarios vieron la posibilidad de un gran mercado, iniciaron empresas (o nuevos proyectos en empresas existentes) y comenzaron a hacer campaña por el reconocimiento legal y la protección de la responsabilidad. Un proyecto de tecnología de la American Bar Association publicó un análisis extenso de algunos de los aspectos legales previsibles de las operaciones de PKI (consulte las pautas de firma digital de ABA), y poco después, varios estados de EE. UU. (Utah fue el primero en 1995) y otras jurisdicciones en todo el mundo comenzaron promulgar leyes y adoptar reglamentos. Los grupos de consumidores plantearon preguntas sobre consideraciones de privacidad, acceso y responsabilidad, que se tuvieron más en cuenta en algunas jurisdicciones que en otras.

Las leyes y reglamentos promulgados diferían, hubo problemas técnicos y operativos para convertir los esquemas de PKI en una operación comercial exitosa, 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 claramente no era fácil de implementar correctamente. Los procedimientos de operación (manuales o automáticos) no eran fáciles de diseñar correctamente (ni aun así diseñados, de ejecutarse a la perfección, lo que requerí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 previsto a mediados de la década de 1990, y ha crecido de forma más lenta y algo diferente de lo previsto. Las PKI no han resuelto algunos de los problemas que se esperaba que resolvieran, y varios proveedores importantes han cerrado o han sido adquiridos por otros. PKI ha tenido el mayor éxito en implementaciones gubernamentales; la mayor implementación de PKI 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.

Usos

Las PKI de un tipo u otro, y de cualquiera de varios proveedores, tienen muchos usos, incluido proporcionar claves públicas y enlaces a las identidades de los usuarios que se utilizan para:

• Cifrado y/o autenticación de mensajes de correo electrónico (por ejemplo, usando OpenPGP o S/MIME);
• Cifrado y/o autenticación de documentos (por ejemplo, los estándares XML Signature o XML Encryption si los documentos son codificados como XML);
• Autenticación de usuarios a aplicaciones (por ejemplo, logotipo de tarjeta inteligente, autenticación del cliente con SSL/TLS). Hay uso experimental para autenticación HTTP firmada digitalmente en los proyectos Enigform y mod_openpgp;
• Crear protocolos de comunicación seguros, como el intercambio de claves en Internet (IKE) y SSL/TLS. En ambos, la configuración inicial de un canal seguro (una "asociación de seguridad") utiliza clave asimétrica, es decir, clave pública, metods, mientras que la comunicación real utiliza clave simétrica más rápida, es decir, clave secreta, metods;
• 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 ubicación;
• Internet de las cosas requiere una comunicación segura entre dispositivos de confianza mutua. Una infraestructura clave pública permite a los dispositivos obtener y renovar certificados X.509 que se utilizan para establecer confianza entre dispositivos y encriptar comunicaciones utilizando TLS.

Implementaciones de código abierto

• OpenSSL es la forma más simple de CA y herramienta para PKI. Es un kit de herramientas, desarrollado en C, que se incluye en todas las principales distribuciones de Linux, y se puede utilizar tanto para construir sus propias aplicaciones (simple) CA y PKI-enable. (Apache con licencia)
• EJBCA es una implementación de CA de grado completo y empresarial desarrollada en Java. Se puede utilizar para configurar una CA tanto para uso interno como para servicio. (LGPL con licencia)
• XiPKI, CA y OCSP. Con soporte SHA-3, implementado en Java. (Apache con licencia)
• XCA es una interfaz gráfica y una base de datos. XCA utiliza OpenSSL para las operaciones de PKI subyacentes.
• DogTag es un CA desarrollado y mantenido como parte del proyecto Fedora.
• Herramienta de código abierto CFSSL desarrollada por CloudFlare para firmar, verificar y acumular certificados TLS. (BSD 2-clause licensed)
• Herramienta Vault para la gestión segura de secretos (TLS certificados incluidos) desarrollado por HashiCorp. (Licencia Pública Mozilla 2.0 con licencia)
• Boulder, un CA de ACME escrito en Go. Boulder es el software que funciona Let's Encrypt.

Crítica

Algunos argumentan que comprar certificados para proteger sitios web mediante SSL/TLS y proteger software mediante firma de código es una empresa costosa para las pequeñas empresas. 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 en teoría conexiones no seguras; 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. La implementación del navegador web de HTTP/2, incluidos Chrome, Firefox, Opera y Edge, admite HTTP/2 solo sobre 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 envían con certificados intermedios preinstalados, emitidos y firmados por una autoridad certificadora, mediante claves públicas certificadas por los llamados certificados raíz. Esto significa que los navegadores deben llevar una gran cantidad de proveedores de certificados diferentes, lo que aumenta el riesgo de un compromiso clave.

Cuando se sabe que una clave está comprometida, se puede solucionar revocando el certificado, pero tal compromiso no es fácilmente detectable y puede ser una gran brecha de seguridad. Los navegadores deben emitir un parche de seguridad para revocar los certificados intermedios emitidos por una autoridad de certificación raíz comprometida.

Obras citadas

• Chung, Taejoong; Lok, Jay; Chandrasekaran, Balakrishnan; Choffnes, David; Levin, Dave; Maggs, Bruce M.; Mislove, Alan; Rula, John; Sullivan, Nick; Wilson, Christo (2018). "¿Está lista la Web para OCSP Must-Staple?" (PDF). Actas de la Conferencia de Medición de Internet 2018. pp. 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 impulsar todas las revocaciones TLS a todos los navegadores". 2017 Simposio IEEE sobre Seguridad y Privacidad (SP). pp. 539-556. doi:10.1109/sp.2017.17. ISBN 978-1-5090-5533-3. S2CID 3926509.
• Sheffer, Yaron; Saint-Andre, Pierre; Fossati, Thomas (noviembre 2022). Recomendaciones para el uso seguro de la seguridad de la capa de transporte (TLS) y seguridad de la capa de transporte de Datagram (DTLS). doi:10.17487/RFC9325RFC 9325.
• Smith, Trevor; Dickinson, Luke; Seamons, Kent (2020). "Revocamos: Revocación de Certificado Global escalable". Proceedings 2020 Network and Distributed System Security Symposium. doi:10.14722/nds.2020.24084. ISBN 978-1-891562-61-7. S2CID 211268930.