En criptografía , un certificado de clave pública , también conocido como certificado digital o certificado de identidad , es un documento electrónico que se utiliza para demostrar la propiedad de una clave pública . [1] El certificado incluye información sobre la clave, información sobre la identidad de su propietario (llamado sujeto) y la firma digital de una entidad que ha verificado el contenido del certificado (llamado emisor). Si la firma es válida y el software que examina el certificado confía en el emisor, entonces puede usar esa clave para comunicarse de forma segura con el sujeto del certificado. En el cifrado de correo electrónico ,firma de código y sistemas de firma electrónica, el sujeto de un certificado suele ser una persona u organización. Sin embargo, en Transport Layer Security (TLS), el sujeto de un certificado suele ser una computadora u otro dispositivo, aunque los certificados TLS pueden identificar organizaciones o personas además de su función principal en la identificación de dispositivos. TLS, a veces llamado por su nombre anterior Secure Sockets Layer (SSL), se destaca por ser parte de HTTPS , un protocolo para navegar de forma segura en la web .
En un esquema típico de infraestructura de clave pública (PKI), el emisor del certificado es una autoridad de certificación (CA), generalmente una empresa que cobra a los clientes por emitir certificados para ellos. Por el contrario, en un esquema de red de confianza , los individuos firman las claves de los demás directamente, en un formato que realiza una función similar a un certificado de clave pública.
El formato más común para los certificados de clave pública está definido por X.509 . [2] Debido a que X.509 es muy general, el formato está aún más restringido por los perfiles definidos para ciertos casos de uso, como la Infraestructura de clave pública (X.509) como se define en RFC 5280 .
Tipos de certificado
Certificado de servidor TLS / SSL
En TLS (un reemplazo actualizado de SSL), se requiere que un servidor presente un certificado como parte de la configuración de conexión inicial. Un cliente que se conecte a ese servidor realizará el algoritmo de validación de la ruta de certificación :
- El asunto del certificado coincide con el nombre de host (es decir, el nombre de dominio) al que el cliente está intentando conectarse;
- El certificado está firmado por una autoridad certificadora de confianza.
El nombre de host principal ( nombre de dominio del sitio web) aparece como Nombre común en el campo Asunto del certificado. Un certificado puede ser válido para varios nombres de host (varios sitios web). Estos certificados se denominan comúnmente certificados de nombre alternativo del sujeto (SAN) o certificados de comunicaciones unificadas (UCC) . Estos certificados contienen el campo Nombre alternativo del sujeto , aunque muchas CA también los incluirán en el campo Nombre común del sujeto para compatibilidad con versiones anteriores. Si algunos de los nombres de host contienen un asterisco (*), un certificado también puede denominarse certificado comodín .
Un servidor TLS se puede configurar con un certificado autofirmado. Cuando ese es el caso, los clientes generalmente no podrán verificar el certificado y terminarán la conexión a menos que la verificación de certificados esté deshabilitada.
Según las aplicaciones, los certificados SSL se pueden clasificar en tres tipos: [3]
- SSL de validación de dominio;
- SSL de validación de la organización;
- SSL de validación extendida.
Certificado de cliente TLS / SSL
Los certificados de cliente son menos comunes que los certificados de servidor y se utilizan para autenticar al cliente que se conecta a un servicio TLS, por ejemplo, para proporcionar control de acceso. Debido a que la mayoría de los servicios brindan acceso a personas, en lugar de dispositivos, la mayoría de los certificados de cliente contienen una dirección de correo electrónico o un nombre personal en lugar de un nombre de host. Además, debido a que la autenticación generalmente la administra el proveedor de servicios, los certificados de cliente no suelen ser emitidos por una CA pública que proporciona certificados de servidor. En cambio, el operador de un servicio que requiere certificados de cliente generalmente operará su propia CA interna para emitirlos. Los certificados de cliente son compatibles con muchos navegadores web, pero la mayoría de los servicios utilizan contraseñas y cookies para autenticar a los usuarios, en lugar de certificados de cliente.
Los certificados de cliente son más comunes en los sistemas RPC , donde se utilizan para autenticar dispositivos para garantizar que solo los dispositivos autorizados puedan realizar determinadas llamadas RPC.
Certificado de correo electrónico
En el protocolo S / MIME para correo electrónico seguro, los remitentes deben descubrir qué clave pública usar para un destinatario determinado. Obtienen esta información de un certificado de correo electrónico. Algunas autoridades de certificación de confianza pública proporcionan certificados de correo electrónico, pero más comúnmente se usa S / MIME cuando se comunica dentro de una organización determinada, y esa organización ejecuta su propia CA, en la que los participantes de ese sistema de correo electrónico confían.
Certificado EMV
Las tarjetas de pago EMV están precargadas con un certificado del emisor de la tarjeta, firmado por la autoridad certificadora EMV [4] para validar la autenticidad de la tarjeta de pago durante la transacción de pago. El certificado EMV CA se carga en terminales de tarjetas ATM o POS y se utiliza para validar el certificado del emisor de la tarjeta.
Certificado de firma de código
Los certificados también se pueden utilizar para validar firmas en programas para garantizar que no se manipulen durante la entrega.
Certificado calificado
Un certificado que identifica a una persona, generalmente con fines de firma electrónica . Estos son los más utilizados en Europa, donde el reglamento eIDAS los estandariza y requiere su reconocimiento.
Certificado raíz
Un certificado autofirmado que se utiliza para firmar otros certificados. También a veces se le llama ancla de confianza .
Certificado intermedio
Un certificado que se utiliza para firmar otros certificados. Un certificado intermedio debe estar firmado por otro certificado intermedio o un certificado raíz.
Certificado de entidad final o hoja
Cualquier certificado que no se pueda utilizar para firmar otros certificados. Por ejemplo, los certificados de cliente y servidor TLS / SSL, los certificados de correo electrónico, los certificados de firma de código y los certificados calificados son todos certificados de entidad final.
Certificado basado en roles
Definidos en la Política de Certificados X.509 para la Autoridad de Certificación Puente Federal, los Certificados basados en roles "identifican un rol específico en nombre del cual el suscriptor está autorizado a actuar en lugar del nombre del suscriptor y se emiten en el interés de respaldar las prácticas comerciales aceptadas . " [5]
Certificado de grupo
Definido en la Política de Certificación X.509 para la Autoridad de Certificación de Puente Federal, para "casos en los que hay varias entidades actuando en una capacidad y donde no se desea el no repudio de las transacciones". [6]
Certificado autofirmado
Un certificado con un asunto que coincide con su emisor y una firma que puede ser verificada por su propia clave pública. La mayoría de los tipos de certificados se pueden autofirmar. Los certificados autofirmados también se denominan a menudo certificados de aceite de serpiente para enfatizar su falta de confiabilidad.
Campos comunes
Estos son algunos de los campos más comunes en los certificados. La mayoría de los certificados contienen varios campos que no se enumeran aquí. Tenga en cuenta que en términos de la representación X.509 de un certificado, un certificado no es "plano" pero contiene estos campos anidados en varias estructuras dentro del certificado.
- Número de serie : se utiliza para identificar de forma única el certificado dentro de los sistemas de una CA. En particular, esto se usa para rastrear la información de revocación.
- Asunto : Entidad a la que pertenece un certificado: una máquina, un individuo o una organización.
- Emisor : Entidad que verificó la información y firmó el certificado.
- No antes : la fecha y hora más tempranas en las que el certificado es válido. Por lo general, se establece unas horas o días antes del momento en que se emitió el certificado, para evitar problemas de desviación del reloj .
- Not After : La hora y fecha después de las cuales el certificado ya no es válido.
- Uso de clave : los usos criptográficos válidos de la clave pública del certificado. Los valores comunes incluyen la validación de firmas digitales, el cifrado de claves y la firma de certificados.
- Uso extendido de claves : las aplicaciones en las que se puede utilizar el certificado. Los valores comunes incluyen autenticación de servidor TLS, protección de correo electrónico y firma de código.
- Clave pública : una clave pública que pertenece al sujeto del certificado.
- Algoritmo de firma : el algoritmo utilizado para firmar el certificado de clave pública.
- Firma : una firma del organismo del certificado por la clave privada del emisor.
Certificado de muestra
Este es un ejemplo de un certificado SSL / TLS decodificado obtenido del sitio web SSL.com. El nombre común del emisor (CN) se muestra como SSL.com EV SSL Intermediate CA RSA R3
, identificándolo como un certificado de Validación Extendida (EV). La información validada sobre el propietario del sitio web (SSL Corp) se encuentra en el Subject
campo. El X509v3 Subject Alternative Name
campo contiene una lista de nombres de dominio cubiertos por el certificado. Los campos X509v3 Extended Key Usage
y X509v3 Key Usage
muestran todos los usos apropiados.
Certificado: Datos: Versión: 3 (0x2) Número de serie: 72: 14: 11: d3: d7: e0: fd: 02: aa: b0: 4e: 90: 09: d4: db: 31 Algoritmo de firma: sha256WithRSAEncryption Emisor: C = EE. UU., ST = Texas, L = Houston, O = SSL Corp, CN = SSL.com EV SSL Intermedio CA RSA R3 Validez No antes: 18 de abril 22:15:06 GMT de 2019 No después: 17 de abril 22:15:06 2021 GMT Asunto: C = EE. UU., ST = Texas, L = Houston, O = SSL Corp / serialNumber = NV20081614243, CN = www.ssl.com / postalCode = 77098 / businessCategory = Organización privada / calle = 3100 Richmond Ave / jurisdicciónST = Nevada / jurisdicciónC = EE. UU. Información de la clave pública del sujeto: Algoritmo de clave pública: rsaEncryption Clave pública RSA: (2048 bits) Módulo: 00: ad: 0f: ef: c1: 97: 5a: 9b: d8: 1e ... Exponente: 65537 (0x10001) Extensiones X509v3: Identificador de clave de autoridad X509v3: keyid: BF: C1: 5A: 87: FF: 28: FA: 41: 3D: FD: B7: 4F: E4: 1D: AF: A0: 61: 58: 29: BD Acceso a la información de la autoridad: Emisores de CA - URI: http: //www.ssl.com/repository/SSLcom-SubCA-EV-SSL-RSA-4096-R3.crt OCSP - URI: http: //ocsps.ssl.com X509v3 Nombre alternativo del sujeto: DNS: www.ssl.com, DNS: answers.ssl.com, DNS: faq.ssl.com, DNS: info.ssl.com, DNS: links.ssl.com, DNS: reseller.ssl.com, DNS: secure.ssl.com, DNS: ssl.com, DNS: support.ssl.com, DNS: sws.ssl.com, DNS: tools.ssl.com Políticas de certificado X509v3: Política: 2.23.140.1.1 Política: 1.2.616.1.113527.2.5.1.1 Política: 1.3.6.1.4.1.38064.1.1.1.5 CPS: https://www.ssl.com/repository Uso extendido de la clave X509v3: Autenticación de cliente web TLS, autenticación de servidor web TLS Puntos de distribución de CRL X509v3: Nombre completo: URI: http: //crls.ssl.com/SSLcom-SubCA-EV-SSL-RSA-4096-R3.crl Identificador de clave de asunto X509v3: E7: 37: 48: DE: 7D: C2: E1: 9D: D0: 11: 25: 21: B8: 00: 33: 63: 06: 27: C1: 5B Uso de la clave X509v3: crítico Firma digital, cifrado de claves SCT precertificados de CT: Marca de tiempo del certificado firmado: Versión: v1 (0x0) ID de registro: 87: 75: BF: E7: 59: 7C: F8: 8C: 43: 99 ... Marca de tiempo: 18 de abril 22: 25: 08.574 2019 GMT Extensiones: ninguna Firma: ecdsa-with-SHA256 30: 44: 02: 20: 40: 51: 53: 90: C6: A2 ... Marca de tiempo del certificado firmado: Versión: v1 (0x0) ID de registro: A4: B9: 09: 90: B4: 18: 58: 14: 87: BB ... Marca de tiempo: 18 de abril 22: 25: 08.461 2019 GMT Extensiones: ninguna Firma: ecdsa-with-SHA256 30: 45: 02: 20: 43: 80: 9E: 19: 90: FD ... Marca de tiempo del certificado firmado: Versión: v1 (0x0) ID de registro: 55: 81: D4: C2: 16: 90: 36: 01: 4A: EA ... Marca de tiempo: 18 de abril 22: 25: 08.769 2019 GMT Extensiones: ninguna Firma: ecdsa-with-SHA256 30: 45: 02: 21: 00: C1: 3E: 9F: F0: 40 ... Algoritmo de firma: sha256WithRSAEncryption 36: 07: e7: 3b: b7: 45: 97: ca: 4d: 6c ...
Uso en la Unión Europea
En la Unión Europea, las firmas electrónicas (avanzadas) en documentos legales se realizan comúnmente utilizando firmas digitales con certificados de identidad adjuntos. Sin embargo, solo las firmas electrónicas calificadas (que requieren el uso de un proveedor de servicios de confianza calificado y un dispositivo de creación de firmas) reciben el mismo poder que una firma física.
Autoridades de certificación
En el modelo de confianza X.509 , una autoridad de certificación (CA) es responsable de firmar los certificados. Estos certificados actúan como una introducción entre dos partes, lo que significa que una CA actúa como un tercero de confianza. Una CA procesa las solicitudes de personas u organizaciones que solicitan certificados (llamados suscriptores), verifica la información y, potencialmente, firma un certificado de entidad final basado en esa información. Para desempeñar esta función de manera eficaz, una CA debe tener uno o más certificados raíz o certificados intermedios de confianza general y las claves privadas correspondientes. Las CA pueden lograr esta amplia confianza al incluir sus certificados raíz en software popular o al obtener una firma cruzada de otra CA que delegue la confianza. Otras CA son confiables dentro de una comunidad relativamente pequeña, como una empresa, y se distribuyen mediante otros mecanismos como la Política de grupo de Windows .
Las autoridades de certificación también son responsables de mantener actualizada la información de revocación sobre los certificados que han emitido, lo que indica si los certificados siguen siendo válidos. Proporcionan esta información a través del Protocolo de estado de certificados en línea (OCSP) y / o Listas de revocación de certificados (CRL). Algunas de las autoridades de certificación más importantes del mercado incluyen IdenTrust , DigiCert y Sectigo . [7]
Programas raíz
Algunos programas importantes contienen una lista de autoridades de certificación en las que se confía de forma predeterminada. Esto hace que sea más fácil para los usuarios finales validar certificados y más fácil para las personas u organizaciones que solicitan certificados saber qué autoridades de certificación pueden emitir un certificado que será ampliamente confiable. Esto es particularmente importante en HTTPS, donde el operador de un sitio web generalmente desea obtener un certificado en el que casi todos los visitantes potenciales de su sitio web confíen.
Las políticas y procesos que utiliza un proveedor para decidir en qué autoridades de certificación debe confiar su software se denominan programas raíz. Los programas raíz más influyentes son:
- Programa raíz de Microsoft
- Programa de raíz de Apple
- Programa raíz de Mozilla
- Programa raíz de Oracle Java
- Adobe AATL Adobe Approved Trust List y programas raíz EUTL (utilizados para la firma de documentos)
Los navegadores distintos de Firefox generalmente utilizan las funciones del sistema operativo para decidir qué autoridades de certificación son confiables. Entonces, por ejemplo, Chrome en Windows confía en las autoridades de certificación incluidas en el Programa raíz de Microsoft, mientras que en macOS o iOS, Chrome confía en las autoridades de certificación en el Programa raíz de Apple. [8] Edge y Safari también utilizan sus respectivos almacenes de confianza del sistema operativo, pero cada uno solo está disponible en un único sistema operativo. Firefox utiliza el almacén de confianza del programa raíz de Mozilla en todas las plataformas.
El programa raíz de Mozilla se opera públicamente y su lista de certificados es parte del navegador web de código abierto Firefox, por lo que se usa ampliamente fuera de Firefox. Por ejemplo, aunque no existe un programa raíz común de Linux, muchas distribuciones de Linux, como Debian, [9] incluyen un paquete que copia periódicamente el contenido de la lista de confianza de Firefox, que luego es utilizado por las aplicaciones.
Los programas raíz generalmente proporcionan un conjunto de propósitos válidos con los certificados que incluyen. Por ejemplo, algunas CA pueden considerarse confiables para emitir certificados de servidor TLS, pero no para certificados de firma de código. Esto se indica con un conjunto de bits de confianza en un sistema de almacenamiento de certificados raíz.
Certificados y seguridad del sitio web
El uso más común de certificados es para sitios web basados en HTTPS . Un navegador web valida que un servidor web HTTPS es auténtico, de modo que el usuario puede sentirse seguro de que su interacción con el sitio web no tiene intrusos y que el sitio web es quien dice ser. Esta seguridad es importante para el comercio electrónico . En la práctica, el operador de un sitio web obtiene un certificado solicitándolo a una autoridad certificadora con una solicitud de firma de certificado . La solicitud de certificado es un documento electrónico que contiene el nombre del sitio web, la información de la empresa y la clave pública. El proveedor del certificado firma la solicitud, produciendo así un certificado público. Durante la navegación web, este certificado público se envía a cualquier navegador web que se conecte al sitio web y demuestre al navegador web que el proveedor cree que ha emitido un certificado al propietario del sitio web.
Por ejemplo, cuando un usuario se conecta https://www.example.com/
con su navegador, si el navegador no muestra ningún mensaje de advertencia de certificado, entonces el usuario puede estar teóricamente seguro de que interactuar con https://www.example.com/
es equivalente a interactuar con la entidad en contacto con la dirección de correo electrónico que aparece en el registrador público en "example.com", aunque es posible que esa dirección de correo electrónico no se muestre en ninguna parte del sitio web. No se implica ninguna otra garantía de ningún tipo. Además, la relación entre el comprador del certificado, el operador del sitio web y el generador del contenido del sitio web puede ser frágil y no está garantizada. En el mejor de los casos, el certificado garantiza la unicidad del sitio web, siempre que el sitio web en sí no haya sido comprometido (pirateado) o el proceso de emisión del certificado subvertido.
Un proveedor de certificados puede optar por emitir tres tipos de certificados, cada uno de los cuales requiere su propio grado de rigor de investigación. En orden de rigor creciente (y naturalmente, costo) son: Validación de dominio, Validación de organización y Validación extendida. Los participantes voluntarios en el CA / Browser Forum acuerdan libremente estos rigores .
Niveles de validación
Validación de dominio
Un proveedor de certificados emitirá un certificado de dominio validado (DV) a un comprador si el comprador puede demostrar un criterio de verificación: el derecho a administrar administrativamente los dominios DNS afectados.
Validación de la organización
Un proveedor de certificados emitirá un certificado de clase de validación de organización (OV) a un comprador si el comprador puede cumplir con dos criterios: el derecho a administrar administrativamente el nombre de dominio en cuestión y, quizás, la existencia real de la organización como entidad legal. Un proveedor de certificados publica sus criterios de verificación de VO a través de su política de certificados .
Validación extendida
Para adquirir un certificado de Validación Extendida (EV), el comprador debe persuadir al proveedor del certificado de su identidad legal, incluidas las comprobaciones de verificación manuales realizadas por un ser humano. Al igual que con los certificados OV, un proveedor de certificados publica sus criterios de verificación de EV a través de su política de certificados .
Hasta 2019, los principales navegadores como Chrome y Firefox generalmente ofrecían a los usuarios una indicación visual de la identidad legal cuando un sitio presentaba un certificado EV. Esto se hizo mostrando el nombre legal antes del dominio y un color verde brillante para resaltar el cambio. La mayoría de los navegadores desaprobaron esta característica [10] [11], lo que no proporciona ninguna diferencia visual para el usuario en el tipo de certificado utilizado. Este cambio siguió a las preocupaciones de seguridad planteadas por los expertos forenses y los intentos exitosos de comprar certificados EV para hacerse pasar por organizaciones famosas, lo que demuestra la ineficacia de estos indicadores visuales y resalta los abusos potenciales. [12]
Debilidades
Un navegador web no advertirá al usuario si un sitio web presenta repentinamente un certificado diferente, incluso si ese certificado tiene un número menor de bits de clave, incluso si tiene un proveedor diferente, e incluso si el certificado anterior tenía una fecha de vencimiento. lejano en el futuro. [ cita requerida ] Cuando los proveedores de certificados están bajo la jurisdicción de los gobiernos, esos gobiernos pueden tener la libertad de ordenar al proveedor que genere cualquier certificado, por ejemplo, para fines de aplicación de la ley. Los proveedores de certificados mayoristas subsidiarios también tienen la libertad de generar cualquier certificado.
Todos los navegadores web vienen con una extensa lista incorporada de certificados raíz de confianza , muchos de los cuales están controlados por organizaciones que pueden ser desconocidas para el usuario. [1] Cada una de estas organizaciones es libre de emitir cualquier certificado para cualquier sitio web y tiene la garantía de que los navegadores web que incluyen sus certificados raíz lo aceptarán como genuino. En este caso, los usuarios finales deben confiar en el desarrollador del software del navegador para administrar su lista incorporada de certificados y en los proveedores de certificados para comportarse correctamente e informar al desarrollador del navegador sobre los certificados problemáticos. Si bien es poco común, ha habido incidentes en los que se han emitido certificados fraudulentos: en algunos casos, los navegadores han detectado el fraude; en otros, pasó algún tiempo antes de que los desarrolladores de navegadores eliminaran estos certificados de su software. [13] [14]
La lista de certificados incorporados tampoco se limita a los proporcionados por el desarrollador del navegador: los usuarios (y hasta cierto punto las aplicaciones) son libres de ampliar la lista para fines especiales, como las intranets de la empresa. [15] Esto significa que si alguien obtiene acceso a una máquina y puede instalar un nuevo certificado raíz en el navegador, ese navegador reconocerá los sitios web que usan el certificado insertado como legítimos.
Para una seguridad demostrable , esta dependencia de algo externo al sistema tiene la consecuencia de que cualquier esquema de certificación de clave pública tiene que depender de algún supuesto de configuración especial, como la existencia de una autoridad de certificación . [dieciséis]
Utilidad frente a sitios web no seguros
A pesar de las limitaciones descritas anteriormente, todas las pautas de seguridad consideran obligatorio TLS autenticado por certificado siempre que un sitio web aloje información confidencial o realice transacciones importantes. Esto se debe a que, en la práctica, a pesar de las debilidades descritas anteriormente, los sitios web protegidos por certificados de clave pública siguen siendo más seguros que los sitios web http: // no protegidos . [17]
Estándares
La División de Seguridad Informática del Instituto Nacional de Estándares y Tecnología ( NIST ) [18] proporciona documentos de orientación para los certificados de clave pública:
- SP 800-32 Introducción a la tecnología de clave pública y la infraestructura PKI federal [19]
- SP 800-25 Uso de la tecnología de clave pública por parte de la agencia federal para firmas digitales y autenticación [20]
Ver también
- Certificado de autorización
- Privacidad bastante buena
Referencias
- ^ a b "Lista de certificados incluidos por Mozilla" . Mozilla.org . Consultado el 30 de julio de 2012 .
- ^ "Uso de autenticación basada en certificado de cliente con NGINX en Ubuntu - SSLTrust" . SSLTrust . Consultado el 26 de marzo de 2019 .
- ^ "Tipos de certificado SSL" . comparecheapssl.com . Consultado el 20 de noviembre de 2018 .
- ^ "EMV CA" . Autoridad de certificación EMV en todo el mundo. 2 de diciembre de 2010 . Consultado el 20 de enero de 2020 .
- ^ Política de certificado X.509 para la autoridad de certificación de puente federal (FBCA)
- ^ Política de certificado X.509 para la autoridad de certificación de puente federal (FBCA)
- ^ "Estadísticas de uso y cuota de mercado de las autoridades de certificación SSL para sitios web, mayo de 2020" . w3techs.com . Consultado el 1 de mayo de 2020 .
- ^ "Política de certificado raíz - Los proyectos de Chromium" . www.chromium.org . Consultado el 19 de marzo de 2017 .
- ^ "certificados ca en Launchpad" . launchpad.net . Consultado el 19 de marzo de 2017 .
- ^ "Grupo de Google de Firefox-dev - Intención de envío: Mueva la información de validación extendida fuera de la barra de URL" . groups.google.com . Consultado el 3 de agosto de 2020 .
- ^ "Grupo de Google Chrome Security-dev - Próximo cambio en los indicadores de identidad de Chrome" . groups.google.com . Consultado el 3 de agosto de 2020 .
- ^ "Los certificados de validación extendida están (realmente, realmente) muertos" . troyhunt.com . Consultado el 3 de agosto de 2020 .
- ^ "Eliminación de DigiNotar por Mozilla" . Mozilla.org . Consultado el 30 de julio de 2012 .
- ^ "Eliminación de DigitNotar por Google" . Consultado el 30 de julio de 2012 .
- ^ "Uso del artículo de certificados en Mozilla.org" . Mozilla.org . Consultado el 30 de julio de 2012 .
- ^ Ran Canetti: Firma, certificación y autenticación universalmente componibles. CSFW 2004, http://eprint.iacr.org/2003/239
- ^ Ben Laurie , Ian Goldberg (18 de enero de 2014). "Reemplazo de contraseñas en Internet, también conocido como cifrado oportunista posterior a Snowden" (PDF) . Parámetro desconocido
|conference=
ignorado ( ayuda );Cite journal requiere|journal=
( ayuda ) - ^ "Publicaciones de seguridad informática del NIST - Publicaciones especiales (SP) del NIST" . csrc.nist.gov . Consultado el 19 de junio de 2016 .
- ^ "SP 800-32 Introducción a la tecnología de clave pública y la infraestructura PKI federal" (PDF) . Instituto Nacional de Estándares y Tecnología.
- ^ "Uso de la Agencia Federal SP 800-25 de la tecnología de clave pública para firmas digitales y autenticación" (PDF) . Instituto Nacional de Estándares y Tecnología.