En criptografía , X.509 es un estándar que define el formato de los certificados de clave pública . [1] Los certificados X.509 se utilizan en muchos protocolos de Internet, incluido TLS / SSL , que es la base de HTTPS , [2] el protocolo seguro para navegar por la web . También se utilizan en aplicaciones fuera de línea, como firmas electrónicas . Un certificado X.509 contiene una clave pública y una identidad (un nombre de host, una organización o un individuo) y está firmado por una autoridad de certificación.o autofirmado. Cuando un certificado está firmado por una autoridad certificadora confiable, o validado por otros medios, alguien que posea ese certificado puede confiar en la clave pública que contiene para establecer comunicaciones seguras con otra parte, o validar documentos firmados digitalmente por la clave privada correspondiente .
Tecnología de la información - Interconexión de sistemas abiertos - El directorio: marcos de certificados de atributos y claves públicas | |
Estado | Vigente (recomendación) |
---|---|
Publicado por primera vez | 1.0 al 25 de noviembre de 1988 |
Ultima versión | 9.0 14 de octubre de 2019 |
Organización | ITU-T |
Comité | Comisión de Estudio 17 del UIT-T |
Serie | X |
Estándares básicos | ASN.1 |
Estándares relacionados | ISO / IEC 9594-8: 2020, X.500 |
Dominio | Criptografía |
Sitio web | www |
X.509 también define listas de revocación de certificados , que son un medio para distribuir información sobre certificados que una autoridad firmante ha considerado inválidos, así como un algoritmo de validación de ruta de certificación , que permite que los certificados sean firmados por certificados de CA intermedios, que son, a su vez, firmados por otros certificados, que eventualmente alcanzan un ancla de confianza .
X.509 está definido por el "Sector de Normalización" de la Unión Internacional de Telecomunicaciones ( UIT-T ), en la Comisión de Estudio 17 del UIT-T y se basa en ASN.1 , otro estándar de UIT-T.
Historia y uso
X.509 se emitió inicialmente el 3 de julio de 1988 y se inició en asociación con el estándar X.500 . Asume un estricto sistema jerárquico de autoridades de certificación (CA) para emitir los certificados. Esto contrasta con los modelos de red de confianza , como PGP , donde cualquier persona (no solo CA especiales) puede firmar y, por lo tanto, dar fe de la validez de los certificados de claves de otros. La versión 3 de X.509 incluye la flexibilidad de admitir otras topologías como puentes y mallas . [2] Se puede usar en una red de confianza peer-to-peer, similar a OpenPGP , [ cita requerida ] pero rara vez se usó de esa manera a partir de 2004[actualizar]. El sistema X.500 solo ha sido implementado por naciones soberanas [ ¿cuál? ] para propósitos de cumplimiento de tratados de intercambio de información de identidad estatal, y el grupo de trabajo de Infraestructura de clave pública (X.509) (PKIX) del IETF ha adaptado el estándar a la organización más flexible de Internet. De hecho, el término certificado X.509 generalmente se refiere al certificado PKIX de IETF y al perfil CRL del estándar de certificado X.509 v3, como se especifica en RFC 5280 , comúnmente llamado PKIX para infraestructura de clave pública (X.509) . [3]
Certificados
En el sistema X.509, una organización que desea un certificado firmado solicita uno a través de una solicitud de firma de certificado (CSR).
Para hacer esto, primero genera un par de claves , manteniendo la clave privada en secreto y usándola para firmar el CSR. Contiene información que identifica al solicitante y la clave pública del solicitante que se utiliza para verificar la firma del CSR y el nombre distinguido (DN) para el que es el certificado. El CSR puede ir acompañado de otras credenciales o pruebas de identidad requeridas por la autoridad certificadora.
La autoridad de certificación emite un certificado que vincula una clave pública a un nombre distinguido particular .
Los certificados raíz de confianza de una organización se pueden distribuir a todos los empleados para que puedan utilizar el sistema PKI de la empresa. [ cita requerida ] Los navegadores como Internet Explorer , Firefox , Opera , Safari y Chrome vienen con un conjunto predeterminado de certificados raíz preinstalados, por lo que los certificados SSL de las principales autoridades de certificación funcionarán instantáneamente; en efecto, los desarrolladores de los navegadores determinan qué CA son terceros de confianza para los usuarios de los navegadores. [ cita requerida ] Por ejemplo, Firefox proporciona un archivo CSV y / o HTML que contiene una lista de CA incluidas. [4]
X.509 y RFC 5280 también incluye estándares para implementaciones de listas de revocación de certificados (CRL). Otra forma aprobada por IETF de verificar la validez de un certificado es el Protocolo de estado de certificado en línea (OCSP). Firefox 3.0 habilitó la verificación OCSP de forma predeterminada, al igual que las versiones de Windows de al menos Vista y posteriores. [5]
Estructura de un certificado
La estructura prevista por los estándares se expresa en un lenguaje formal, Abstract Syntax Notation One (ASN.1).
La estructura de un certificado digital X.509 v3 es la siguiente:
- Certificado
- Número de versión
- Número de serie
- ID de algoritmo de firma
- Nombre del emisor
- Período de validez
- No antes
- No después de
- Nombre del tema
- Información de clave pública del sujeto
- Algoritmo de clave pública
- Asunto Clave pública
- Identificador único del emisor (opcional)
- Identificador único del sujeto (opcional)
- Extensiones (opcional)
- ...
- Algoritmo de firma de certificado
- Firma del certificado
Cada extensión tiene su propia ID, expresada como identificador de objeto , que es un conjunto de valores, junto con una indicación crítica o no crítica. Un sistema que usa certificados debe rechazar el certificado si encuentra una extensión crítica que no reconoce o una extensión crítica que contiene información que no puede procesar. Una extensión no crítica puede ignorarse si no se reconoce, pero debe procesarse si se reconoce. [6]
La estructura de la versión 1 se da en RFC 1422 .
El UIT-T introdujo identificadores únicos de emisor y sujeto en la versión 2 para permitir la reutilización del nombre del emisor o del sujeto después de algún tiempo. Un ejemplo de reutilización será cuando una CA se declare en quiebra y su nombre se elimine de la lista pública del país. Después de algún tiempo, otra CA con el mismo nombre puede registrarse, aunque no esté relacionada con la primera. Sin embargo, IETF recomienda que no se reutilicen los nombres de emisores y sujetos. Por lo tanto, la versión 2 no se implementa ampliamente en Internet. [ cita requerida ]
Las extensiones se introdujeron en la versión 3. Una CA puede usar extensiones para emitir un certificado solo para un propósito específico (por ejemplo, solo para firmar objetos digitales ).
En todas las versiones, el número de serie debe ser único para cada certificado emitido por una CA específica (como se menciona en RFC 5280 ).
Extensiones que informan un uso específico de un certificado
RFC 5280 (y sus predecesores) define una serie de extensiones de certificado que indican cómo se debe utilizar el certificado. La mayoría de ellos son arcos del OID joint-iso-ccitt (2) ds (5) id-ce (29) . Algunas de las más comunes, definidas en la sección 4.2.1, son:
- Las restricciones básicas, {id-ce 19} , [7] se utilizan para indicar si el certificado pertenece a una CA.
- Key Usage, {id-ce 15} , [8] proporciona un mapa de bits que especifica las operaciones criptográficas que se pueden realizar utilizando la clave pública contenida en el certificado; por ejemplo, podría indicar que la clave debe usarse para firmas pero no para cifrado.
- El uso de clave extendido, {id-ce 37} , [9] se usa, generalmente en un certificado hoja, para indicar el propósito de la clave pública contenida en el certificado. Contiene una lista de OID, cada uno de los cuales indica un uso permitido. Por ejemplo, {id-pkix 3 1} indica que la clave puede usarse en el extremo del servidor de una conexión TLS o SSL; {id-pkix 3 4} indica que la clave se puede utilizar para proteger el correo electrónico.
En general, si un certificado tiene varias extensiones que restringen su uso, se deben cumplir todas las restricciones para que un uso determinado sea apropiado. RFC 5280 da el ejemplo específico de un certificado que contiene tanto keyUsage como extendedKeyUsage: en este caso, ambos deben procesarse y el certificado solo se puede usar si ambas extensiones son coherentes al especificar el uso de un certificado. Por ejemplo, NSS usa ambas extensiones para especificar el uso del certificado. [10]
Extensiones de nombre de archivo de certificado
Hay varias extensiones de nombre de archivo de uso común para los certificados X.509. Desafortunadamente, algunas de estas extensiones también se utilizan para otros datos, como claves privadas.
- .pem - ( Correo electrónico con privacidad mejorada ) Certificado DER codificado en Base64 , incluido entre "----- BEGIN CERTIFICATE -----" y "----- END CERTIFICATE -----"
- .cer , .crt , .der : generalmente en formato DER binario , pero los certificados codificados en Base64 también son comunes (ver .pem arriba)
- .p7b , .p7c - PKCS # 7 Estructura SignedData sin datos, solo certificado (s) o CRL (s)
- .p12 - PKCS # 12 , puede contener certificados (públicos) y claves privadas (protegidas con contraseña)
- .pfx - PFX, predecesor de PKCS # 12 (generalmente contiene datos en formato PKCS # 12, por ejemplo, con archivos PFX generados en IIS )
PKCS # 7 es un estándar para firmar o cifrar (oficialmente llamado "envolvente") de datos. Dado que el certificado es necesario para verificar los datos firmados, es posible incluirlos en la estructura SignedData. Un archivo .P7C es una estructura SignedData degenerada, sin ningún dato para firmar. [ cita requerida ]
PKCS # 12 evolucionó a partir del estándar de intercambio de información personal (PFX) y se utiliza para intercambiar objetos públicos y privados en un solo archivo. [ cita requerida ]
Cadenas de certificados y certificación cruzada
Una cadena de certificados (consulte el concepto equivalente de "ruta de certificación" definido por RFC 5280 sección 3.2) es una lista de certificados (generalmente comenzando con un certificado de entidad final) seguido de uno o más certificados de CA (generalmente el último es un certificado autofirmado), con las siguientes propiedades:
- El Emisor de cada certificado (excepto el último) coincide con el Asunto del siguiente certificado de la lista
- Cada certificado (excepto el último) está firmado por la clave secreta correspondiente al siguiente certificado de la cadena (es decir, la firma de un certificado se puede verificar utilizando la clave pública contenida en el siguiente certificado)
- El último certificado de la lista es un ancla de confianza : un certificado en el que confía porque le fue entregado mediante algún procedimiento confiable
Las cadenas de certificados se utilizan para comprobar que la clave pública (PK) contenida en un certificado de destino (el primer certificado de la cadena) y otros datos contenidos en él pertenecen efectivamente a su sujeto. Para ello, se verifica la firma en el certificado de destino utilizando el PK contenido en el siguiente certificado, cuya firma se verifica mediante el siguiente certificado, y así sucesivamente hasta llegar al último certificado de la cadena. Como el último certificado es un ancla de confianza, alcanzarlo con éxito demostrará que se puede confiar en el certificado de destino.
La descripción en el párrafo anterior es una vista simplificada del proceso de validación de la ruta de certificación según lo definido por RFC 5280 sección 6, que implica comprobaciones adicionales, como verificar las fechas de validez de los certificados, buscar CRL , etc.
Al examinar cómo se construyen y validan las cadenas de certificados, es importante tener en cuenta que un certificado concreto puede formar parte de cadenas de certificados muy diferentes (todas ellas válidas). Esto se debe a que se pueden generar varios certificados de CA para el mismo sujeto y clave pública, pero firmarse con diferentes claves privadas (de diferentes CA o diferentes claves privadas de la misma CA). Por lo tanto, aunque un solo certificado X.509 puede tener solo un emisor y una firma de CA, se puede vincular válidamente a más de un certificado, creando cadenas de certificados completamente diferentes. Esto es crucial para la certificación cruzada entre PKI y otras aplicaciones. [11] Vea los siguientes ejemplos:
Ejemplos de
En estos diagramas:
- Cada casilla representa un certificado, con su Asunto en negrita
- A → B significa "A está firmado por B" (o, más precisamente, "A está firmado por la clave secreta correspondiente a la clave pública contenida en B").
- Los certificados con el mismo color (que no son blancos / transparentes) contienen la misma clave pública
Ejemplo 1: Certificación cruzada en el nivel de la Autoridad de certificación (CA) raíz entre dos PKI
Para gestionar que los certificados de usuario existentes en PKI 2 (como "Usuario 2") sean de confianza para PKI 1, CA1 genera un certificado (cert2.1) que contiene la clave pública de CA2. [12] Ahora tanto "cert2 como cert2.1 (en verde) tienen el mismo asunto y clave pública, por lo que hay dos cadenas válidas para cert2.2 (Usuario 2):" cert2.2 → cert2 "y" cert2.2 → cert2.1 → cert1 ".
De manera similar, CA2 puede generar un certificado (cert1.1) que contiene la clave pública de CA1 para que los certificados de usuario existentes en PKI 1 (como "Usuario 1") sean de confianza para PKI 2.
Ejemplo 2: renovación del certificado de CA
Comprensión de la construcción de rutas de certificación (PDF) . Foro PKI. Septiembre de 2002. Para permitir una transición ordenada del par de claves de firma anterior al nuevo par de claves de firma, la CA debe emitir un certificado que contenga la clave pública anterior firmada por la nueva clave de firma privada y un certificado que contenga la nueva clave pública firmada. por la antigua clave de firma privada. Ambos de estos certificados son auto-emitida, pero tampoco es autofirmado . Tenga en cuenta que estos son adicionales a los dos certificados autofirmados (uno antiguo y otro nuevo).
Dado que tanto cert1 como cert3 contienen la misma clave pública (la anterior), existen dos cadenas de certificados válidas para cert5: "cert5 → cert1" y "cert5 → cert3 → cert2", y análogamente para cert6. Esto permite que los certificados de usuario antiguos (como cert5) y los certificados nuevos (como cert6) puedan ser confiables indistintamente por una parte que tenga el nuevo certificado de CA raíz o el anterior como ancla de confianza durante la transición a las nuevas claves de CA. [13]
Ejemplos de certificados X.509
Este es un ejemplo de un certificado X.509 decodificado que fue utilizado por wikipedia.org y varios otros sitios web de Wikipedia. Fue emitido por GlobalSign , como se indica en el campo Emisor. Su campo Asunto describe a Wikipedia como una organización, y su campo Nombre alternativo del sujeto describe los nombres de host para los que podría usarse. El campo Información de clave pública del sujeto contiene una clave pública ECDSA , mientras que la firma en la parte inferior fue generada por la clave privada RSA de GlobalSign .
Certificado de entidad final
Certificado: Datos: Versión: 3 (0x2) Número de serie: 10: e6: fc: 62: b7: 41: 8a: d5: 00: 5e: 45: b6 Algoritmo de firma: sha256WithRSAEncryption Emisor: C = BE, O = GlobalSign nv-sa, CN = GlobalSign Organization Validation CA - SHA256 - G2 Validez No antes: 21 de noviembre 08:00:00 2016 GMT No después: 22 de noviembre 07:59:59 2017 GMT Asunto: C = EE. UU., ST = California, L = San Francisco, O = Wikimedia Foundation, Inc., CN = *. Wikipedia.org Información de la clave pública del sujeto: Algoritmo de clave pública: id-ecPublicKey Clave pública: (256 bits) pub: 00: c9: 22: 69: 31: 8a: d6: 6c: ea: da: c3: 7f: 2c: ac: a5: af: c0: 02: ea: 81: cb: 65: b9: fd: 0c: 6d: 46: 5b: c9: 1e: 9d: 3b: ef ASN1 OID: prime256v1 CURVA NIST: P-256 Extensiones X509v3: Uso de la clave X509v3: crítico Firma digital, contrato clave Acceso a la información de la autoridad: Emisores de CA - URI: http: //secure.globalsign.com/cacert/gsorganizationvalsha2g2r1.crt OCSP - URI: http: //ocsp2.globalsign.com/gsorganizationvalsha2g2 Políticas de certificado X509v3: Política: 1.3.6.1.4.1.4146.1.20 CPS: https://www.globalsign.com/repository/ Política: 2.23.140.1.2.2 Restricciones básicas de X509v3: CA: FALSO Puntos de distribución de CRL X509v3: Nombre completo: URI: http: //crl.globalsign.com/gs/gsorganizationvalsha2g2.crl X509v3 Nombre alternativo del sujeto: DNS: *. Wikipedia.org, DNS: *. M.mediawiki.org, DNS: *. M.wikibooks.org, DNS: *. M.wikidata.org, DNS: *. M.wikimedia.org, DNS: * .m.wikimediafoundation.org, DNS: *. m.wikinews.org, DNS: *. m.wikipedia.org, DNS: *. m.wikiquote.org, DNS: *. m.wikisource.org, DNS: * .m.wikiversity.org, DNS: *. m.wikivoyage.org, DNS: *. m.wiktionary.org, DNS: *. mediawiki.org, DNS: *. planet.wikimedia.org, DNS: *. wikibooks.org, DNS: *. wikidata.org, DNS: *. wikimedia.org, DNS: *. wikimediafoundation.org, DNS: *. wikinews.org, DNS: *. wikiquote.org, DNS: *. wikisource. org, DNS: *. wikiversity.org, DNS: *. wikivoyage.org, DNS: *. wiktionary.org, DNS: *. wmfusercontent.org, DNS: *. zero.wikipedia.org, DNS: mediawiki.org, DNS: w.wiki, DNS: wikibooks.org, DNS: wikidata.org, DNS: wikimedia.org, DNS: wikimediafoundation.org, DNS: wikinews.org, DNS: wikiquote.org, DNS: wikisource.org, DNS: wikiversity.org, DNS: wikivoyage.org, DNS: wiktionary.org, DNS: wmfusercontent.org, DNS: wikipedia.org Uso extendido de la clave X509v3: Autenticación del servidor web TLS, autenticación del cliente web TLS Identificador de clave de asunto X509v3: 28: 2A: 26: 2A: 57: 8B: 3B: CE: B4: D6: AB: 54: EF: D7: 38: 21: 2C: 49: 5C: 36 Identificador de clave de autoridad X509v3: keyid: 96: DE: 61: F1: BD: 1C: 16: 29: 53: 1C: C0: CC: 7D: 3B: 83: 00: 40: E6: 1A: 7C Algoritmo de firma: sha256WithRSAEncryption 8b: c3: ed: d1: 9d: 39: 6f: af: 40: 72: bd: 1e: 18: 5e: 30: 54: 23: 35: ...
Para validar este certificado de entidad final, se necesita un certificado intermedio que coincida con su Emisor y su Identificador de clave de autoridad:
Editor | C = BE, O = GlobalSign nv-sa, CN = Validación de organización de GlobalSign CA - SHA256 - G2 |
Identificador de clave de autoridad | 96: DE: 61: F1: BD: 1C: 16: 29: 53: 1C: C0: CC: 7D: 3B: 83: 00: 40: E6: 1A: 7C |
En una conexión TLS, un servidor configurado correctamente proporcionaría el intermedio como parte del protocolo de enlace. Sin embargo, también es posible recuperar el certificado intermedio obteniendo la URL "Emisores de CA" del certificado de entidad final.
Certificado intermedio
Este es un ejemplo de un certificado intermedio que pertenece a una autoridad certificadora . Este certificado firmó el certificado de entidad final anterior y fue firmado por el certificado raíz a continuación. Tenga en cuenta que el campo de asunto de este certificado intermedio coincide con el campo del emisor del certificado de entidad final que firmó. Además, el campo "identificador de clave de asunto" en el intermedio coincide con el campo "identificador de clave de autoridad" en el certificado de entidad final.
Certificado: Datos: Versión: 3 (0x2) Número de serie: 04: 00: 00: 00: 00: 01: 44: 4e: f0: 42: 47 Algoritmo de firma: sha256WithRSAEncryption Emisor: C = BE, O = GlobalSign nv-sa, OU = CA raíz, CN = CA raíz de GlobalSign Validez No antes: 20 de febrero 10:00:00 2014 GMT No después: 20 de febrero 10:00:00 2024 GMT Asunto: C = BE, O = GlobalSign nv-sa, CN = Validación de organización de GlobalSign CA - SHA256 - G2 Información de la clave pública del sujeto: Algoritmo de clave pública: rsaEncryption Clave pública: (2048 bits) Módulo: 00: c7: 0e: 6c: 3f: 23: 93: 7f: cc: 70: a5: 9d: 20: c3: 0e: ... Exponente: 65537 (0x10001) Extensiones X509v3: Uso de la clave X509v3: crítico Signo de certificado, Signo CRL Restricciones básicas de X509v3: críticas CA: TRUE, pathlen: 0 Identificador de clave de asunto X509v3: 96: DE: 61: F1: BD: 1C: 16: 29: 53: 1C: C0: CC: 7D: 3B: 83: 00: 40: E6: 1A: 7C Políticas de certificado X509v3: Política: X509v3 Cualquier política CPS: https://www.globalsign.com/repository/ Puntos de distribución de CRL X509v3: Nombre completo: URI: http: //crl.globalsign.net/root.crl Acceso a la información de la autoridad: OCSP - URI: http: //ocsp.globalsign.com/rootr1 Identificador de clave de autoridad X509v3: keyid: 60: 7B: 66: 1A: 45: 0D: 97: CA: 89: 50: 2F: 7D: 04: CD: 34: A8: FF: FC: FD: 4B Algoritmo de firma: sha256WithRSAEncryption 46: 2a: ee: 5e: bd: ae: 01: 60: 37: 31: 11: 86: 71: 74: b6: 46: 49: c8: ...
Certificado raíz
Este es un ejemplo de un autofirmado certificado raíz que representa una autoridad de certificación . Sus campos de emisor y asunto son los mismos, y su firma se puede validar con su propia clave pública. La validación de la cadena de confianza tiene que terminar aquí. Si el programa de validación tiene este certificado raíz en su almacén de confianza , el certificado de entidad final se puede considerar de confianza para su uso en una conexión TLS. De lo contrario, el certificado de entidad final se considera que no es de confianza.
Certificado: [14] Datos: Versión: 3 (0x2) Número de serie: 04: 00: 00: 00: 00: 01: 15: 4b: 5a: c3: 94 Algoritmo de firma: sha1WithRSAEncryption Emisor: C = BE, O = GlobalSign nv-sa, OU = CA raíz, CN = CA raíz de GlobalSign Validez No antes: 1 de septiembre 12:00:00 1998 GMT No después: 28 de enero 12:00:00 2028 GMT Asunto: C = BE, O = GlobalSign nv-sa, OU = CA raíz, CN = CA raíz de GlobalSign Información de la clave pública del sujeto: Algoritmo de clave pública: rsaEncryption Clave pública: (2048 bits) Módulo: 00: da: 0e: e6: 99: 8d: ce: a3: e3: 4f: 8a: 7e: fb: f1: 8b: ... Exponente: 65537 (0x10001) Extensiones X509v3: Uso de la clave X509v3: crítico Signo de certificado, Signo CRL Restricciones básicas de X509v3: críticas CA: VERDADERO Identificador de clave de asunto X509v3: 60: 7B: 66: 1A: 45: 0D: 97: CA: 89: 50: 2F: 7D: 04: CD: 34: A8: FF: FC: FD: 4B Algoritmo de firma: sha1WithRSAEncryption d6: 73: e7: 7c: 4f: 76: d0: 8d: bf: ec: ba: a2: be: 34: c5: 28: 32: b5: ...
Seguridad
Hay varias publicaciones sobre problemas de PKI de Bruce Schneier , Peter Gutmann y otros expertos en seguridad. [15] [16] [17]
Debilidades arquitectónicas
- Uso de certificados no válidos de lista de bloqueo (usando CRL y OCSP ),
- Si el cliente solo confía en los certificados cuando las CRL están disponibles, perderá la capacidad sin conexión que hace atractiva la PKI. Por lo tanto, la mayoría de los clientes confían en los certificados cuando las CRL no están disponibles, pero en ese caso, un atacante que controla el canal de comunicación puede desactivar las CRL. Adam Langley de Google ha dicho que las verificaciones de CRL de falla suave son como un cinturón de seguridad que funciona excepto cuando tiene un accidente. [18]
- Las CRL son una mala elección debido a sus grandes tamaños y patrones de distribución intrincados,
- Semántica OCSP ambigua y falta de estado de revocación histórico,
- No se aborda la revocación de certificados raíz,
- Problema de agregación : los reclamos de identidad (autenticar con un identificador), los reclamos de atributos (enviar una bolsa de atributos examinados) y los reclamos de políticas se combinan en un solo contenedor. Esto plantea problemas de privacidad, asignación de políticas y mantenimiento. [ aclaración necesaria ]
- Problema de delegación : las CA no pueden restringir técnicamente que las CA subordinadas emitan certificados fuera de un conjunto de atributos o espacios de nombres limitados; esta función de X.509 no está en uso. Por tanto, existe una gran cantidad de CA en Internet, y clasificarlas y sus políticas es una tarea insuperable. La delegación de autoridad dentro de una organización no se puede manejar en absoluto, como en la práctica comercial común.
- Problema de federación : las cadenas de certificados que son el resultado de CA subordinadas, CA puente y firma cruzada hacen que la validación sea compleja y costosa en términos de tiempo de procesamiento. La semántica de validación de ruta puede ser ambigua. La jerarquía con un tercero de confianza es el único modelo. Esto es un inconveniente cuando ya existe una relación de confianza bilateral.
- La emisión de un certificado de validación extendida (EV) para un nombre de host no evita la emisión de un certificado de validación inferior válido para el mismo nombre de host, lo que significa que el nivel de validación más alto de EV no protege contra el intermediario ataques. [19]
Problemas con las autoridades de certificación
- El sujeto, no la parte que confía, compra certificados. El sujeto a menudo utilizará el emisor más barato, por lo que no se paga por la calidad en el mercado competidor. Esto se soluciona en parte con los certificados de validación extendida , pero el valor de la confianza a los ojos de los expertos en seguridad está disminuyendo [20]
- Las autoridades de certificación niegan casi todas las garantías al usuario (incluido el sujeto o incluso las partes que confían)
- "Los usuarios utilizan un protocolo de solicitud de certificación indefinido para obtener un certificado que se publica en una ubicación poco clara en un directorio inexistente sin medios reales para revocarlo" [17]
- Como todas las empresas, las CA están sujetas a las jurisdicciones legales en las que operan y pueden verse obligadas legalmente a comprometer los intereses de sus clientes y usuarios. Las agencias de inteligencia también han hecho uso de certificados falsos emitidos a través de compromisos extralegales de CA, como DigiNotar , para llevar a cabo ataques man-in-the-middle . [ cita requerida ] Otro ejemplo es una solicitud de revocación de la autoridad competente del gobierno holandés, debido a que una nueva ley holandesa se activa a partir del 1 de enero de 2018, otorgando nuevos poderes a los servicios de inteligencia y seguridad holandeses [21]
Problemas de implementación
Las implementaciones adolecen de fallas de diseño, errores, diferentes interpretaciones de estándares y falta de interoperabilidad de diferentes estándares. Algunos problemas son: [ cita requerida ]
- Muchas implementaciones desactivan la verificación de revocación:
- Visto como un obstáculo, las políticas no se hacen cumplir
- Si estuviera activado en todos los navegadores de forma predeterminada, incluida la firma de código, probablemente colapsaría la infraestructura [ cita requerida ]
- Los DN son complejos y poco entendidos (falta de canonicalización, problemas de internacionalización)
- rfc822Name tiene dos notaciones
- Restricciones de nombre y políticas apenas admitidas
- Se ignora el uso de la clave, se está utilizando el primer certificado de una lista
- La aplicación de OID personalizados es difícil
- Los atributos no deben ser críticos porque hace que los clientes se bloqueen [ cita requerida ]
- La longitud no especificada de los atributos conduce a límites específicos del producto
- Hay errores de implementación con X.509 que permiten, por ejemplo, nombres de sujetos falsificados utilizando cadenas terminadas en nulo [22] o ataques de inyección de código en certificados.
- Al usar subidentificadores ilegales [23] 0x80 rellenados de identificadores de objetos , implementaciones incorrectas o al usar desbordamientos enteros de los navegadores del cliente, un atacante puede incluir un atributo desconocido en el CSR, que la CA firmará, que el cliente interpreta erróneamente como "CN "(OID = 2.5.4.3). Dan Kaminsky en el 26º Congreso de Comunicación del Caos "Programas operativos negros de PKI" [24]
Debilidades criptográficas
Los sistemas de firma digital dependen de funciones hash criptográficas seguras para funcionar. Cuando una infraestructura de clave pública permite el uso de una función hash que ya no es segura, un atacante puede aprovechar las debilidades de la función hash para falsificar certificados. Específicamente, si un atacante puede producir una colisión de hash , puede convencer a una CA para que firme un certificado con contenido inocuo, donde el hash de esos contenidos es idéntico al hash de otro conjunto malicioso de contenido de certificado, creado por el atacante. con valores de su elección. Luego, el atacante puede agregar la firma proporcionada por la CA al contenido de su certificado malicioso, lo que da como resultado un certificado malicioso que parece estar firmado por la CA. Debido a que el contenido del certificado malicioso es elegido únicamente por el atacante, pueden tener fechas de validez o nombres de host diferentes a los del certificado inocuo. El certificado malicioso puede incluso contener un campo "CA: verdadero" que le permite emitir más certificados de confianza.
- Los certificados basados en MD2 se utilizaron durante mucho tiempo y eran vulnerables a los ataques de preimagen . Dado que el certificado raíz ya tenía una autofirma, los atacantes podrían usar esta firma y usarla para un certificado intermedio.
- En 2005, Arjen Lenstra y Benne de Weger demostraron "cómo utilizar las colisiones hash para construir dos certificados X.509 que contienen firmas idénticas y que difieren sólo en las claves públicas", logrado mediante un ataque de colisión en la función hash MD5 . [25]
- En 2008, Alexander Sotirov y Marc Stevens presentaron en el Chaos Communication Congress un ataque práctico que les permitió crear una Autoridad de Certificación falsa, aceptada por todos los navegadores comunes, aprovechando el hecho de que RapidSSL todavía estaba emitiendo certificados X.509 basados en MD5. [26]
- En abril de 2009, en la Conferencia Eurocrypt, [27] investigadores australianos de la Universidad de Macquarie presentaron "Búsqueda automática de ruta diferencial para SHA-1 ". [28] Los investigadores pudieron deducir un método que aumenta la probabilidad de una colisión en varios órdenes de magnitud. [29]
- En febrero de 2017, un grupo de investigadores dirigido por Marc Stevens produjo una colisión SHA-1, demostrando la debilidad de SHA-1. [30]
Mitigaciones para debilidades criptográficas
Aprovechar una colisión de hash para falsificar firmas X.509 requiere que el atacante pueda predecir los datos que firmará la autoridad de certificación. Esto puede ser mitigado de alguna manera por la CA generando un componente aleatorio en los certificados que firma, generalmente el número de serie. El CA / Browser Forum ha exigido la entropía del número de serie en su Sección 7.1 de requisitos básicos desde 2011. [31]
A partir del 1 de enero de 2016[actualizar], los requisitos básicos prohíben la emisión de certificados utilizando SHA-1. A principios de 2017[actualizar], Chrome [32] y Firefox [33] rechazan los certificados que utilizan SHA-1. En mayo de 2017[actualizar]tanto Edge [34] como Safari [35] también rechazan el certificado SHA-1. Los validadores X.509 que no son de navegador aún no rechazan los certificados SHA-1. [36]
Estándares PKI para X.509
- PKCS7 (Estándar de sintaxis de mensajes criptográficos: claves públicas con prueba de identidad para mensajes firmados y / o cifrados para PKI) [37]
- Transport Layer Security (TLS) y su predecesor SSL: protocolos criptográficos para comunicaciones seguras en Internet. [38]
- Protocolo de estado de certificados en línea (OCSP) [39] / lista de revocación de certificados (CRL) [40] : sirve para comprobar el estado de revocación de certificados
- PKCS12 (Estándar de sintaxis de intercambio de información personal): se utiliza para almacenar una clave privada con el certificado de clave pública adecuado [41]
Grupo de trabajo PKIX
En 1995, el Grupo de Trabajo de Ingeniería de Internet junto con el Instituto Nacional de Estándares y Tecnología [42] formó el grupo de trabajo Infraestructura de clave pública (X.509). El grupo de trabajo, concluido en junio de 2014, [43] se denomina comúnmente "PKIX". Produjo RFC y otra documentación de estándares sobre el uso e implementación de X.509 en la práctica. En particular produjo RFC 3280 y su sucesor RFC 5280, que definen cómo utilizar X.509 en protocolos de Internet.
Principales protocolos y estándares que utilizan certificados X.509
TLS / SSL y HTTPS utilizan el Perfil RFC 5280 de X.509, al igual que S / MIME (Extensiones seguras de correo de Internet multipropósito) y el método EAP-TLS para la autenticación WiFi. Cualquier protocolo que use TLS, como SMTP, POP, IMAP, LDAP, XMPP y muchos más, usa inherentemente X.509.
IPSec puede utilizar Perfil RFC 4945 para autenticar pares.
La especificación de seguridad de OpenCable define su propio perfil de X.509 para su uso en la industria del cable.
Los dispositivos como las tarjetas inteligentes y los TPM suelen llevar certificados para identificarse a sí mismos oa sus propietarios. Estos certificados están en formato X.509.
El estándar WS-Security define la autenticación mediante TLS o mediante su propio perfil de certificado. [14] Ambos métodos utilizan X.509.
El sistema de firma de código Microsoft Authenticode utiliza X.509 para identificar a los autores de programas informáticos.
El estándar de comunicación de automatización industrial OPC UA utiliza X.509.
SSH generalmente usa un modelo de seguridad Trust On First Use y no necesita certificados. Sin embargo, la popular implementación de OpenSSH admite un modelo de identidad firmado por una CA basado en su propio formato de certificado que no es X.509. [44]
Ver también
- Notación de sintaxis abstracta uno
- Política de certificados
- Seguridad de acceso al código
- Seguridad de las comunicaciones
- Seguridad de información
- ISO / IEC JTC 1
- Protocolo de consulta de recursos de PKI
- Criptografía de clave pública
- Protocolo de marca de tiempo
- Sellado de tiempo de confianza
- EdDSA
Referencias
- ^ "X.509: Tecnología de la información - Interconexión de sistemas abiertos - El directorio: marcos de certificados de atributo y clave pública" . ITU . Consultado el 6 de noviembre de 2019 .
- ^ a b RFC 4158
- ^ "Certificado de infraestructura de clave pública de Internet X.509 y perfil de lista de revocación de certificados (CRL)" . Mayo de 2008 . Consultado el 29 de mayo de 2020 .
A continuación se muestra una vista simplificada del modelo arquitectónico asumido por la infraestructura de clave pública utilizando especificaciones X.509 (PKIX).
- ^ "CA: incluidas las CA" . Wiki de Mozilla . Consultado el 17 de enero de 2017 .
- ^ "Error 110161 - (ocspdefault) habilita OCSP por defecto" . Mozilla . Consultado el 17 de marzo de 2016 .
- ^ "RFC 5280 sección 4.2" . Herramientas . IETF. Mayo de 2008 . Consultado el 12 de febrero de 2013 .
- ^ "RFC 5280, sección 'Restricciones básicas ' " .
- ^ " ' RFC 5280, sección' Uso de claves ' " .
- ^ "RFC 5280, sección 'Uso extendido de claves ' " .
- ^ Nelson B Boyard (9 de mayo de 2002). "Todo sobre las extensiones de certificados" . Mozilla . Consultado el 10 de septiembre de 2020 .
- ^ Lloyd, Steve (septiembre de 2002). Comprensión de la construcción de rutas de certificación (PDF) . Foro PKI.
- ^ "Certificación cruzada entre CA raíz". Escenarios de implementación de subordinación calificada . Microsoft. Agosto de 2009.
- ^ Nash; Duane; José; Brink (2001). "Ciclos de vida de claves y certificados. Renovación de certificados de CA". PKI: Implementación y gestión de seguridad electrónica . Prensa RSA - Osborne / McGraw-Hill. ISBN 0-07-213123-3.
- ^ a b "Web Services Security X.509 Token Profile Versión 1.1.1" . Oasis . Consultado el 14 de marzo de 2017 .
- ^ Carl Ellison y Bruce Schneier. "Los 10 principales riesgos de PKI" (PDF) . Computer Security Journal (Volumen XVI, Número 1, 2000).
- ^ Peter Gutmann. "PKI: no está muerta, solo descansa" (PDF) . Computadora IEEE (Volumen: 35, Edición: 8).
- ^ a b Gutmann, Peter. "Todo lo que nunca quiso saber sobre PKI pero se vio obligado a averiguarlo" (PDF) . Consultado el 14 de noviembre de 2011 .
- ^ Langley, Adam (5 de febrero de 2012). "Comprobación de revocación y CRL de Chrome" . Violeta imperial . Consultado el 2 de febrero de 2017 .
- ^ Michael Zusman; Alexander Sotirov (julio de 2009). "PKI subprime: atacar SSL de validación extendida" (PDF) . Blackhat . Consultado el 10 de septiembre de 2020 .
- ^ Caza, Troy. "Los certificados de validación extendida están muertos" . TroyHunt.com . Consultado el 26 de febrero de 2019 .
- ^ van Pelt, Cris. "Logius: problema de confianza de CA del gobierno holandés" . Bugzilla . Consultado el 31 de octubre de 2017 .
- ^ Moxie Marlinspike (2009). "Más trucos para defender SSL en la práctica" (PDF) . Instituto de Estudios Disruptivos. Blackhat . Consultado el 10 de septiembre de 2020 .
- ^ Rec. UIT-T X.690, cláusula 8.19.2
- ^ Dan Kaminsky (29 de diciembre de 2009). "26C3: Operaciones negras de PKI" . Blog de eventos CCC . Der Chaos Computer Club . Consultado el 29 de septiembre de 2013 .
- ^ Lenstra, Arjen; de Weger, Benne (19 de mayo de 2005). Sobre la posibilidad de construir colisiones hash significativas para claves públicas (PDF) (Informe técnico). Lucent Technologies, Bell Laboratories y Technische Universiteit Eindhoven. Archivado (PDF) desde el original el 14 de mayo de 2013 . Consultado el 28 de septiembre de 2013 .
- ^ "MD5 considerado nocivo en la actualidad" . Universidad Tecnológica de Eindhoven. 16 de junio de 2011 . Consultado el 29 de septiembre de 2013 .
- ^ "Eurocrypt 2009" . Asociación Internacional para la Investigación Criptológica.
- ^ Cameron McDonald; Philip Hawkes; Josef Pieprzyk (2009). "Colisiones SHA-1 ahora" (PDF) . Universidad Macquarie y Qualcomm . Consultado el 10 de septiembre de 2020 .
- ^ Dennis Dwyer (2 de junio de 2009). "Ataques de colisión SHA-1 ahora 252" . SecureWorks Insights . Consultado el 24 de febrero de 2016 .
- ^ Marc Stevens; Elie Bursztein; Pierre Karpman; Ange Albertini; Yarik Markov. "La primera colisión para SHA-1 completo" (PDF) . CWI Amsterdam y Google Research . Consultado el 10 de septiembre de 2020 , a través de Shattered.
- ^ "Documentos de requisitos básicos" . CA Browser Forum . Consultado el 19 de marzo de 2017 .
- ^ Andrew Whalley (16 de noviembre de 2016). "Certificados SHA-1 en Chrome" . Blog de seguridad en línea de Google . Consultado el 19 de marzo de 2017 .
- ^ "El fin de SHA-1 en la Web Pública" . Blog de seguridad de Mozilla . Consultado el 19 de marzo de 2017 .
- ^ "Aviso de seguridad de Microsoft 4010323" . Technet . Microsoft . Consultado el 16 de mayo de 2017 .
- ^ "Safari y WebKit no admiten certificados SHA-1" . Soporte de Apple . 16 de agosto de 2018 . Consultado el 10 de septiembre de 2020 .
- ^ Daniel Stenburg (10 de enero de 2017). "HTTPS menor para usuarios que no son navegadores" . Daniel Hax . Consultado el 19 de marzo de 2017 .
- ^ B Kaliski (marzo de 1998). "PKCS # 7: Sintaxis de mensajes criptográficos versión 1.5" . IETF . Consultado el 10 de septiembre de 2020 .
- ^ T Dierks (agosto de 2008). "La versión 1.2 del protocolo de seguridad de la capa de transporte (TLS)" . IETF . Consultado el 10 de septiembre de 2020 .
- ^ Stefan Santesson; Michael Myers; Rich Ankey; Slava Galperin; Carlisle Adams (junio de 2013). "Protocolo de estado de certificado en línea de infraestructura de clave pública de Internet X.509 - OCSP" . Herramientas . IETF . Consultado el 10 de septiembre de 2020 .
- ^ David Cooper; Stefan Santesson; Stephen Farrell; Sharon Boeyen; Russell Housley; Tim Polk (mayo de 2008). "Certificado de infraestructura de clave pública de Internet X.509 y perfil de lista de revocación de certificados (CRL)" . Herramientas . IETF . Consultado el 10 de septiembre de 2020 .
- ^ "PKCS 12: Estándar de sintaxis de intercambio de información personal" . EMC.com . Laboratorios RSA . Consultado el 19 de marzo de 2017 .[ enlace muerto ]
- ^ "Infraestructura de clave pública (X.509) (pkix) - Charter" . Rastreador de datos IETF . Grupo de trabajo de ingeniería de Internet . Consultado el 1 de octubre de 2013 .
- ^ "Páginas de estado de Pkix" . Herramientas IETF . Consultado el 10 de marzo de 2017 .
- ^ "Cómo crear una CA SSH para validar hosts y clientes con Ubuntu" . DigitalOcean . Consultado el 19 de marzo de 2017 .
enlaces externos
- Estándares X.509 de ITU-T
- Artículos de Peter Gutmann:
- Descripción general de PKI
- Notas de implementación y guía de estilo de X.509
- "Preguntas frecuentes sobre cripto de RSA Labs" . Laboratorios RSA. Archivado desde el original el 30 de diciembre de 2006.
- Directrices de código seguro Sun
- RFC 4158 - Infraestructura de clave pública de Internet X.509: creación de ruta de certificación
- Decodificador CSR y decodificador de certificados : se pueden utilizar para decodificar y examinar un certificado o CSR codificado
- phpseclib: Decodificador X.509 : decodifica a una matriz asociativa cuyas claves corresponden a la descripción ASN.1 de X.509
- SeSeLe , Asistente para certificados autofirmados SSL
- Comprensión de los certificados digitales Microsoft TechNet