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 la PKI de Microsoft, 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 la CA empresarial de Microsoft 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 es 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]
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 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). [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 manera 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 fallas de manera 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 todas las partes de un dominio confíen plenamente (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]
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 de claves seguras 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 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:
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]