Una infraestructura de clave pública ( PKI ) es un conjunto de roles, políticas, hardware, software y procedimientos necesarios para crear, gestionar, distribuir, utilizar, 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 validar la información que se transfiere.
En criptografía , una PKI es un acuerdo que vincula claves públicas con las respectivas identidades de entidades (como personas y organizaciones). [1] La vinculación se establece mediante un proceso de registro y emisión de certificados en y por una autoridad certificadora (CA). Dependiendo del nivel de seguridad de la vinculación, ésta podrá 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 administración de certificados, como CMP .
La función de PKI que una CA puede delegar para garantizar un registro válido y correcto se denomina autoridad de registro (RA). Una RA es responsable de aceptar solicitudes de certificados digitales y autenticar a la entidad que realiza la solicitud. [2] El RFC 3647 del 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 solicitudes de certificados, el inicio de revocaciones de certificados". o suspensiones 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)". [3] Si bien Microsoft puede haberse referido a una CA subordinada como RA, [4] esto es incorrecto según los estándares PKI X.509. Las RA no tienen la autoridad de firma de una CA y solo gestionan la verificación y el suministro de certificados. Entonces, en el caso de Microsoft PKI, la funcionalidad RA la proporciona el sitio web de Servicios de certificados de Microsoft o a través de los Servicios de certificados de Active Directory , 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 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 basándose en 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 . [5]
PKI proporciona "servicios de confianza": en términos sencillos, confía en las acciones o resultados de 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 pueda ver, de forma maliciosa o involuntaria, una carga útil en texto claro. Los datos se cifran para hacerlos secretos, de modo que incluso si se leyeran, parecerían un galimatías. Quizás el uso más común de PKI con fines de confidencialidad sea en el contexto de 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 de Internet ingresando una contraseña.
Integridad: Garantía de que si una entidad cambiara (manipulara) los datos transmitidos en lo más mínimo, sería obvio que así sucedió, ya que su integridad se habría visto comprometida. Muchas veces no es de suma importancia evitar que la integridad se vea comprometida (a prueba de manipulación), sin embargo, sí es de suma importancia que si la integridad se ve comprometida haya evidencia clara de que así fue (a prueba de manipulación).
Autenticidad: Garantía de que cada entidad tiene certeza de a qué se está conectando o puede evidenciar su legitimidad al conectarse a un servicio protegido. La primera se denomina autenticación del lado del servidor y normalmente se utiliza cuando se autentica en un servidor web mediante una contraseña. Esto último 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 manera confiable la identidad de una entidad mediante firmas digitales . [6]
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 determinada entidad. 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. [7] [8] [9]
Una PKI consta de: [8] [10] [11]
En términos generales, tradicionalmente ha habido tres enfoques para obtener esta confianza: autoridades de certificación (CA), red de confianza (WoT) e infraestructura de clave pública simple (SPKI). [ cita necesaria ]
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 independiente del usuario y del sistema, entonces se denomina Autoridad de Registro (RA), que puede o no estar separada de la CA. [12] La vinculación clave-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 se puede utilizar para autoridad de certificación (CA). Además, la PKI se utiliza a menudo como sinónimo de implementación de CA. [13]
Un certificado puede revocarse 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 emitido incorrectamente hasta que caduque. [14] Por lo tanto, la revocación es una parte importante de una infraestructura de clave pública. [15] La revocación la realiza la autoridad certificadora emisora , que produce una declaración de revocación autenticada criptográficamente . [dieciséis]
Para distribuir información de revocación a los clientes, la oportunidad 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. [17] 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 por completo y tratan un certificado como si estuviera revocado (y así degradan la disponibilidad ) o fallan por software y lo tratan como si estuviera revocado. no revocada (y permitir a los atacantes eludir la revocación). [18]
Debido al costo de las comprobaciones de revocación y al impacto en la disponibilidad de servicios remotos potencialmente poco confiables, los navegadores web limitan las comprobaciones de revocación que realizarán y fallarán cuando las realicen. [19] 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 latencia de conexión y privacidad. Se han propuesto otros esquemas, pero aún no se han implementado con éxito para permitir una verificación infalible. [15]
En este modelo de relaciones de confianza, una CA es un tercero confiable: en el que confía tanto el sujeto (propietario) del certificado como la parte que confía en el certificado.
Según el informe NetCraft de 2015, [20] 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 CA importantes: tres autoridades certificadoras ( 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 Symantec lo comprara) desde [nuestra] encuesta comenzó, 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 ocupados, 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 problemas importantes en la forma en que se gestionaba la emisión de certificados, todos los actores principales desconfiaron gradualmente de los certificados emitidos por Symantec, a partir de 2017 y finalizados en 2021. [21] [22] [23] [24]
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 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 . [25]
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 dichos certificados por parte de terceros. El término singular "red de confianza" no implica la existencia de una única red de confianza, o un punto de confianza común, sino más bien una de varias "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 red de confianza, como en PGP , es que puede interoperar con una CA 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 un presentador de confianza. Si se confía completamente en la "red de confianza", entonces, debido a la naturaleza de una red de confianza, confiar en un certificado equivale a 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. [26]
El concepto de red de confianza fue presentado por primera vez por el creador de PGP, Phil Zimmermann, en 1992 en el manual de PGP versión 2.0:
A medida que pasa el tiempo, acumulará claves de otras personas que quizás desee designar como presentadores de confianza. Todos los demás elegirán sus propios presentadores de confianza. Y cada uno acumulará y distribuirá 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 la red de confianza de X.509 y PGP . SPKI no asocia a los usuarios con personas, ya que la clave es aquello en lo que se confía, más que 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. [27] Este tipo de PKI es especialmente útil para realizar integraciones de PKI que no dependen de terceros para la autorización de certificados, información de certificados, etc.; un buen ejemplo de esto es una red aislada en una oficina.
Los identificadores descentralizados (DID) eliminan la dependencia de registros centralizados para 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 sea un libro mayor distribuido , cada entidad puede actuar como su propia autoridad raíz. Esta arquitectura se conoce como PKI descentralizada (DPKI). [28] [29]
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. [30] Debido a que los desarrollos en el GCHQ son altamente secretos, 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 tanto del intercambio seguro de claves como de 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 predecesoras), se hizo evidente la necesidad de encontrar formas en que los usuarios pudieran comunicarse entre sí de forma segura y, como consecuencia adicional de esto, de formas en que los usuarios pudieran comunicarse entre sí de manera segura. seguro con quién estaban interactuando realmente.
Se inventaron y analizaron diversos protocolos criptográficos dentro de los cuales se podían utilizar eficazmente las nuevas primitivas criptográficas . 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 las URL web ); incluía establecimiento de claves, autenticación del servidor (antes de v3, solo unidireccional), etc. Se creó así una estructura PKI para usuarios/sitios web que deseaban comunicaciones seguras.
Los vendedores y empresarios vieron la posibilidad de un gran mercado, fundaron empresas (o nuevos proyectos en empresas existentes) y comenzaron a hacer campaña por el reconocimiento legal y la protección contra la responsabilidad. Un proyecto tecnológico de la American Bar Association publicó un extenso análisis de algunos de los aspectos legales previsibles de las operaciones PKI (ver directrices de firma digital ABA ), y poco después, varios estados de EE.UU. ( siendo Utah 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 regulaciones promulgadas diferían, hubo problemas técnicos y operativos para convertir los esquemas PKI en una operación comercial exitosa y el progreso ha sido mucho más lento de lo que los pioneros habían imaginado.
En los primeros años del siglo XXI, la ingeniería criptográfica subyacente claramente no era fácil de implementar correctamente. Los procedimientos operativos (manuales o automáticos) no eran fáciles de diseñar correctamente (ni siquiera de ejecutarse perfectamente, como requería la ingeniería). Las normas 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 más lentamente y de maneras algo diferentes a las previstas. [31] Las PKI no han resuelto algunos de los problemas que se esperaba y varios proveedores importantes han cerrado o han sido adquiridos por otros. PKI ha tenido el mayor éxito en 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 Tarjetas de Acceso Común .
Las PKI de un tipo u otro, y de cualquiera de varios proveedores, tienen muchos usos, incluido el suministro de claves públicas y enlaces a identidades de usuario que se utilizan para:
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. [38] 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 claro que admitirían este protocolo sólo a través de una conexión TLS protegida por PKI. [39] La implementación de HTTP/2 en el navegador 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 certificadora, mediante claves públicas certificadas por los llamados certificados raíz . Esto significa que los navegadores deben tener una gran cantidad de proveedores de certificados diferentes, lo que aumenta el riesgo de que la clave se vea comprometida. [40]
Cuando se sabe que una clave está comprometida, se puede solucionar revocando el certificado, pero dicho compromiso no es fácilmente detectable y puede representar una enorme brecha de seguridad. Los navegadores deben emitir un parche de seguridad para revocar los certificados intermediarios emitidos por una autoridad certificadora raíz comprometida. [41]