X.509
De Wikipedia, la enciclopedia libre
| Certificado Digital X.509 | |
|---|---|
| Última versión | 1.1 / 25 nov, 2005 |
| sistema_operativo | Todos |
| Género | Criptografía e infraestructura PKI |
| Licencia | estándar |
| Sitio Web | http://www.ietf.org/rfc/rfc3280.txt |
En criptografía, X.509 es un estándar UIT-T para infraestructuras de claves públicas (en inglés, Public Key Infrastructure o PKI). X.509 especifica, entre otras cosas, formatos estándar para certificados de claves públicas y un algoritmo de validación de la ruta de certificación.
Tabla de contenidos |
[editar] Historia y uso
X.509 fue publicado oficialmente en 1988 y comenzado conjuntamente con el estándar X.500 y asume un sistema jerárquico estricto de autoridades certificantes (ACs) para emisión de certificados. Esto contrasta con modelos de web de confianza, como PGP, donde cualquiera (no solo ACs) pueden firmar, y por ende avalar la validez de certificados de claves de otros. La versión 3 de X.509 incluye la flexibilidad de soporte de otras tecnologías como bridges y mallas. Puede usarse en una web de confianza de tipo OpenPGP peer to peer, pero a partir de 2004 raramente se usa así. El sistema X.500 nunca se implementó completamente, y el grupo de trabajo de la infraestructura de clave pública de la IETF (X.509), o PKIX, adaptó el estándar a la organización más flexible de Internet. De hecho, el término certificado X.509 se refiere comúnmente al Certificado PKIX y Perfil CRL del certificado estándar de X.509 v3 de la IETF, como se especifica en la RFC 3280, comúnmente conocido como PKIX para infraestructura de clave pública (X.509).
[editar] Certificados
En el sistema X.509, una autoridad certificadora (AC) emite un certificado asociando una clave pública a un Nombre Distinguido particular en la tradición de X.500 o a un Nombre Alternativo tal como una dirección de correo electrónico o una entrada de DNS.
Los certificados raíz de confianza de una organización pueden distribuirse a todos los empleados de manera que ellos puedan usar el sistema de infraestructura de clave pública de la compañía. Navegadores web como Internet Explorer, Netscape/Mozilla y Opera vienen pre-instalados con certificados raíz, de manera que certificados SSL de grandes vendedores que hayan pagado por el privilegio de ser pre-instalados funcionen al instante. En efecto, el propietario del navegador web determina qué ACs son terceros de confianza para los usuarios del navegador web. A pesar de que estos certificados raíz pueden borrarse o deshabilitarse, es muy raro que los usuarios lo hagan.
X.509 incluye también estándares para implementación de CRLs, y con frecuencia aspectos de sistemas PKI. La forma aprobada por la IETF de chequear la validez de un certificado es el Online Certificate Status Protocol (OCSP).
[editar] Estructura de un certificado
La estructura de un certificado digital X.509 v3 es la siguiente:
- Certificado
- Versión
- Número de serie
- ID del algoritmo
- Emisor
- Validez
- No antes de
- No después de
- Tema
- Tema información de clave pública
- Algoritmo de clave pública
- Tema clave pública
- Identificador único de emisor (opcional)
- Identificador único de tema (opcional)
- Extensiones (optional)
- ...
- Algoritmo de certificado de firma
- Certificado de firma
Los identificadores únicos de emisor y tema fueron introducidos en la versión 2, y las extensiones en la versión 3.
X.509 es la pieza central de la infraestructura de clave pública y es la estructura de datos que enlaza la clave pública con los datos que permiten identificar al titular. Su sintaxis se define empleando el lenguaje ASN.1 (Abstract Syntax Notation One) y los formatos de codificación más comunes son DER (Distinguished Encoding Rules) o PEM (Privacy-enhanced Electronic Mail). Siguiendo la notación de ASN.1, un certificado contiene diversos campos, agrupados en tres grandes grupos:
- El primer campo es el subject (tema), que contiene los datos que identifican al titular. Estos datos están expresados en notación DN (Distinguished Name), donde un DN se compone a su vez de diversos campos, siendo los más frecuentes los siguientes; CN (Common Name), OU (Organizational Unit), O (Organization) y C (Country). Un ejemplo para identificar un usuario mediante el DN, es el siguiente: CN=david.comin O=Safelayer, OU=development, C=ES. Además del nombre del titular (subject), el certificado, también contiene datos asociados al propio certificado digital, como la versión del certificado, su identificador (serialNumber), la CA firmante (issuer), el tiempo de validez (validity), etc. La versión X.509.v3 también permite utilizar campos opcionales (nombres alternativos, usos permitidos para la clave, ubicación de la CRL y de la CA,etc.).
- En segundo lugar, el certificado contiene la clave pública, que expresada en notación ASN.1, consta de dos campos, en primer lugar, el que muestra el algoritmo utilizado para crear la clave (ej. RSA), y en segundo lugar, la propia clave pública.
- Por último, la CA, ha añadido la secuencia de campos que identifican la firma de los campos previos. Esta secuencia contiene tres atributos, el algoritmo de firma utilizado, el hash de la firma, y la propia firma digital.
[editar] Extensiones de archivo de certificados
Las extensiones de archivo de certificados X.509 son:
- .CER - Certificado codificado en CER, algunas veces es una secuencia de certificados
- .DER - Certificado codificado en DER
- .PEM - Certificado codificado en Base64, encerrado entre "-----BEGIN CERTIFICATE-----" y "-----END CERTIFICATE-----"
- .P7B - Ver .p7c
- .P7C - Estructura PKCS#7 SignedData sin datos, solo certificado(s) o CRL(s)
- .PFX - Ver .p12
- .P12 - PKCS#12, puede contener certificado(s) (público) y claves privadas (protegido con clave)
PKCS #7 es un estándar para firmar o cifrar datos (ellos lo llaman "sobreado"). Dado que el certificado es necesario para verificar datos firmados, es posible incluírlos en la estructura SignedData. Un archivo .P7C es simplemente una estructura SignedData, sin datos para firmar.
PKCS #12 evolucionó del estándar PFX (Personal inFormation eXchange) y se usa para intercambiar objetos públicos y privados dentro de un archivo.
Un archivo .PEM puede contener certificados o claves privadas, encerrados entre las líneas BEGIN/END apropiadas.
[editar] Ejemplo de certificado X.509
Como ejemplo de un certificado X.509, se encuentra aquí una decodificación (generada con openssl) de uno de los certificados viejos de www.freesoft.org. El certificado real tiene un tamaño de alrededor de 1 KB. Fue emitido (firmado) por Thawte (desde que fue adquirido por Verisign), tal como se indica en el campo Emisor. El tema contiene bastante información personal, pero la parte más importante es el nombre común (CN) de www.freesoft.org - esta es la parque que debe coincidir con la terminal que se está autenticando. A continuación viene una clave pública RSA (módulo y exponente público), seguido de la firma, computada tomando un hash MD5 de ka primera parte del certificado y cifrándola con la clave privada RSA de Thawte.
Certificate:
Data:
Version: 1 (0x0)
Serial Number: 7829 (0x1e95)
Signature Algorithm: md5WithRSAEncryption
Issuer: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc,
OU=Certification Services Division,
CN=Thawte Server CA/Email=server-certs@thawte.com
Validity
Not Before: Jul 9 16:04:02 1998 GMT
Not After : Jul 9 16:04:02 1999 GMT
Subject: C=US, ST=Maryland, L=Pasadena, O=Brent Baccala,
OU=FreeSoft, CN=www.freesoft.org/Email=baccala@freesoft.org
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:b4:31:98:0a:c4:bc:62:c1:88:aa:dc:b0:c8:bb:
33:35:19:d5:0c:64:b9:3d:41:b2:96:fc:f3:31:e1:
66:36:d0:8e:56:12:44:ba:75:eb:e8:1c:9c:5b:66:
70:33:52:14:c9:ec:4f:91:51:70:39:de:53:85:17:
16:94:6e:ee:f4:d5:6f:d5:ca:b3:47:5e:1b:0c:7b:
c5:cc:2b:6b:c1:90:c3:16:31:0d:bf:7a:c7:47:77:
8f:a0:21:c7:4c:d0:16:65:00:c1:0f:d7:b8:80:e3:
d2:75:6b:c1:ea:9e:5c:5c:ea:7d:c1:a1:10:bc:b8:
e8:35:1c:9e:27:52:7e:41:8f
Exponent: 65537 (0x10001)
Signature Algorithm: md5WithRSAEncryption
93:5f:8f:5f:c5:af:bf:0a:ab:a5:6d:fb:24:5f:b6:59:5d:9d:
92:2e:4a:1b:8b:ac:7d:99:17:5d:cd:19:f6:ad:ef:63:2f:92:
ab:2f:4b:cf:0a:13:90:ee:2c:0e:43:03:be:f6:ea:8e:9c:67:
d0:a2:40:03:f7:ef:6a:15:09:79:a9:46:ed:b7:16:1b:41:72:
0d:19:aa:ad:dd:9a:df:ab:97:50:65:f5:5e:85:a6:ef:19:d1:
5a:de:9d:ea:63:cd:cb:cc:6d:5d:01:85:b5:6d:c8:f3:d9:f7:
8f:0e:fc:ba:1f:34:e9:96:6e:6c:cf:f2:ef:9b:bf:de:b5:22:
68:9f
Para validar este certificado, necesitamos otro certificado: uno que coincida con el Emisor (Thawte Server CA) en el primer certificado. Entonces se toma la clave pública RSA del segundo certificado (CA), se usa para decodificar la firma del primer certificado para obtener el hash MD5, el cual debe coincidir con el hash MD5 computado sobre el resto de los certificados. Éste es el certificado CA:
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1 (0x1)
Signature Algorithm: md5WithRSAEncryption
Issuer: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc,
OU=Certification Services Division,
CN=Thawte Server CA/Email=server-certs@thawte.com
Validity
Not Before: Aug 1 00:00:00 1996 GMT
Not After : Dec 31 23:59:59 2020 GMT
Subject: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc,
OU=Certification Services Division,
CN=Thawte Server CA/Email=server-certs@thawte.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:d3:a4:50:6e:c8:ff:56:6b:e6:cf:5d:b6:ea:0c:
68:75:47:a2:aa:c2:da:84:25:fc:a8:f4:47:51:da:
85:b5:20:74:94:86:1e:0f:75:c9:e9:08:61:f5:06:
6d:30:6e:15:19:02:e9:52:c0:62:db:4d:99:9e:e2:
6a:0c:44:38:cd:fe:be:e3:64:09:70:c5:fe:b1:6b:
29:b6:2f:49:c8:3b:d4:27:04:25:10:97:2f:e7:90:
6d:c0:28:42:99:d7:4c:43:de:c3:f5:21:6d:54:9f:
5d:c3:58:e1:c0:e4:d9:5b:b0:b8:dc:b4:7b:df:36:
3a:c2:b5:66:22:12:d6:87:0d
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:TRUE
Signature Algorithm: md5WithRSAEncryption
07:fa:4c:69:5c:fb:95:cc:46:ee:85:83:4d:21:30:8e:ca:d9:
a8:6f:49:1a:e6:da:51:e3:60:70:6c:84:61:11:a1:1a:c8:48:
3e:59:43:7d:4f:95:3d:a1:8b:b7:0b:62:98:7a:75:8a:dd:88:
4e:4e:9e:40:db:a8:cc:32:74:b9:6f:0d:c6:e3:b3:44:0b:d9:
8a:6f:9a:29:9b:99:18:28:3b:d1:e3:40:28:9a:5a:3c:d5:b5:
e7:20:1b:8b:ca:a4:ab:8d:e9:51:d9:e2:4c:2c:59:a9:da:b9:
b2:75:1b:f6:42:f2:ef:c7:f2:18:f9:89:bc:a3:ff:8a:23:2e:
70:47
Éste es un ejemplo de un certificado auto-firmado. Nótese que el emisor y el tema son iguales. No hay forma de verificar este certificado, salvo que se chequee contra sí mismo. Hemos alcanzado el fin de la cadena de certificados. Cómo es entonces que este certificado se hace confiable? Simple: se configura manualmente. Thawte es una de las autoridades certificantes raíz reconocida por Microsoft y Netscape. Este certificado ya viene con el navegador web (probablemente pueda encontrarse listado como "Thawte Server CA" en las opciones de seguridad) y es confiable por defecto. Como certificado confiado globalmente de larga vida (nótese la fecha de vencimiento) que puede firmar prácticamente cualquier cosa (nótese la falta de limitaciones), su clave privada correspondiente debe ser una de las más ocultas del mundo.
[editar] Seguridad
En 2005, Arjen Lenstra y Benne de Weger demostraron "como usar colisiones de hash para construir certificados que contienen firmas idénticas y que solo difieren en la clave pública", lo cual alcanzaron usando un ataque de colisiones en la función de hash MD5. [1]
[editar] Autoridad de certificación
Una autoridad de certificación o Autoridad certificante (AC) es una entidad que emite certificados digitales para su uso por terceros. Es un ejemplo de un tercero de confianza. Las ACs son características en muchos esquemas de infraestructuras de clave pública (PKI).
Existen muchos ACs comerciales que cobran por sus servicios. Instituciones y gobiernos pueden tener sus propias ACs y también existen ACs gratuitas.
[editar] Véase también
- Autoridad de certificación
- Certificado digital
- Firma digital
- Clave pública
- Infraestructura de clave pública (PKI)
- PGP
- CRL
[editar] Enlaces externos
- Integración corporativa de la confianza (Enterprise Trust Integration), estándares de Servicios Web y demos
- Safelayer (implementación comercial)
- Xcarecrows 4 X509 (implementación comercial)
[editar] Referencias
Fuente de: "Estudio y propuesta de una guía de sintonización de servicios web seguros basados en J2EE. David Comín Roig" UPC.
