X.

509

X.509
Certificado Digital X.509 ltima versin v3 / Mayo 2008

sistema operativo Todos Gnero Licencia Sitio Web Criptografa e infraestructura PKI estndar
[1]

En criptografa, X.509 es un estndar UIT-T para infraestructuras de claves pblicas (en ingls, Public Key Infrastructure o PKI). X.509 especfica, entre otras cosas, formatos estndar para certificados de claves pblicas y un algoritmo de validacin de la ruta de certificacin. Su sintaxis, se define empleando el lenguaje ASN.1 (Abstract Syntax Notation One), y los formatos de codificacin ms comunes son DER (Distinguish Encoding Rules) o PEM (Privacy Enhanced Mail).

Historia y uso
X.509 fue publicado oficialmente en 1988 y comenzado conjuntamente con el estndar X.500 y asume un sistema jerrquico estricto de autoridades certificantes (ACs) para emisin de certificados. Esto contrasta con modelos de redes de confianza, como PGP, donde cualquier nodo de la red (no solo las ACs) puede firmar claves pblicas, y por ende avalar la validez de certificados de claves de otros. La versin 3 de X.509 incluye la flexibilidad de soporte de otras tecnologas como bridges y mallas. Puede usarse en una web de confianza peer to peer de tipo OpenPGP, pero desde 2004 raramente se usa as. El sistema X.500 nunca se implement completamente, y el grupo de trabajo de la infraestructura de clave pblica de la IETF, comnmente conocido como PKIX para infraestructura de clave pblica (X.509) o PKIX, adapt el estndar a la estructura ms flexible de Internet. X.509 incluye tambin estndares para implementacin de listas de certificados en revocacin (CRLs), y con frecuencia aspectos de sistemas PKI. De hecho, el trmino certificado X.509 se refiere comnmente al Certificado PKIX y Perfil CRL del certificado estndar de X.509 v3 de la IETF, como se especifica en la RFC 3280. La forma aprobada por la IETF de chequear la validez de un certificado es el Online Certificate Status Protocol (OCSP).

Seguridad
En 2005, Arjen Lenstra y Benne de Weger demostraron "como usar colisiones de hash para construir certificados que contienen firmas idnticas y que solo difieren en la clave pblica", lo cual alcanzaron usando un ataque de colisiones en la funcin de hash MD5. [2] En 2007, Marc Stevens, Arjen Lenstra, y Benne de Weger demostraron "cmo usar colisiones de hash para aadir sufijos a dos ficheros diferentes obteniendo firmas idnticas" [3]

X.509

Autoridad de certificacin
Una autoridad de certificacin (AC) es una entidad que emite certificados digitales para su uso por terceros. Es un ejemplo de un tercero de confianza. Las ACs son caractersticas en muchos esquemas de infraestructuras de clave pblica (PKI). Los certificados raz de confianza de una organizacin pueden distribuirse a todos los empleados de manera que ellos puedan usar el sistema de infraestructura de clave pblica de la compaa. Navegadores web como Internet Explorer, Netscape/Mozilla y Opera vienen con certificados raz pre-instalados, 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 raz pueden borrarse o deshabilitarse, es muy raro que los usuarios lo hagan. Existen muchas ACs comerciales que cobran por sus servicios. Instituciones y gobiernos pueden tener sus propias ACs y tambin existen ACs gratuitas.

Certificados
En el sistema X.509, una autoridad certificadora (AC) emite un certificado asociando una clave pblica a un Nombre Distinguido particular en la tradicin de X.500 o a un Nombre Alternativo tal como una direccin de correo electrnico o una entrada de DNS.

Estructura de un certificado
La estructura de un certificado digital X.509 v3 es la siguiente: Certificado Versin Nmero de serie ID del algoritmo Emisor Validez

No antes de No despus de Sujeto Informacin de clave pblica del sujeto Algoritmo de clave pblica Clave pblica del sujeto Identificador nico de emisor (opcional) Identificador nico de sujeto (opcional) Extensiones (opcional) ... Algoritmo usado para firmar el certificado Firma digital del certificado Los identificadores nicos de emisor y sujeto fueron introducidos en la versin 2, y las extensiones en la versin 3. Obsrvese que el nmero de serie debe ser nico para cada certificado emitido por una misma autoridad certificadora (tal como lo indica el RFC 2459). X.509 es la pieza central de la infraestructura de clave pblica y es la estructura de datos que enlaza la clave pblica 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 codificacin ms comunes son DER (Distinguished Encoding Rules) o PEM

X.509 (Privacy-enhanced Electronic Mail). Siguiendo la notacin de ASN.1, un certificado contiene diversos campos, agrupados en tres grandes grupos: El primer campo es el subject (sujeto), que contiene los datos que identifican al sujeto titular. Estos datos estn expresados en notacin DN (Distinguished Name), donde un DN se compone a su vez de diversos campos, siendo los ms 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. Adems del nombre del sujeto titular (subject), el certificado, tambin contiene datos asociados al propio certificado digital, como la versin del certificado, su identificador (serialNumber), la CA firmante (issuer), el tiempo de validez (validity), etc. La versin X.509.v3 tambin permite utilizar campos opcionales (nombres alternativos, usos permitidos para la clave, ubicacin de la CRL y de la CA,etc.). En segundo lugar, el certificado contiene la clave pblica, que expresada en notacin 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 pblica. Por ltimo, la CA, ha aadido 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.

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) (pblico) y claves privadas (protegido con clave) PKCS #7 es un estndar para firmar o cifrar datos (ellos lo llaman "sobreado"). Dado que el certificado es necesario para verificar datos firmados, es posible incluirlos en la estructura SignedData. Un archivo .P7C es simplemente una estructura SignedData, sin datos para firmar. PKCS #12 evolucion del estndar PFX (Personal inFormation eXchange) y se usa para intercambiar objetos pblicos y privados dentro de un archivo. Un archivo .PEM puede contener certificados o claves privadas, encerrados entre las lneas BEGIN/END apropiadas.

Ejemplo de certificado X.509 y del proceso de validacin

Como ejemplo de un certificado X.509, se encuentra aqu una decodificacin (generada con openssl) de uno de los certificados viejos de www.freesoft.org. El certificado real tiene un tamao de alrededor de 1KB. Fue emitido (firmado) por Thawte [4] (desde que fue adquirido por Verisign [5]), tal como se indica en el campo Emisor. El tema contiene bastante informacin personal, pero la parte ms importante es el nombre comn (CN) de www.freesoft.org - esta es la parte que debe coincidir con la terminal que se est autenticando. A continuacin viene una clave pblica RSA (mdulo y exponente pblico), seguido de la firma, computada tomando un hash MD5 de la primera parte del certificado y cifrndola con la clave privada RSA de Thawte. Certificate: Data: Version: 1 (0x0)

X.509 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 Obsrvese que al final del certificado se encuentra la firma de mismo. Para estampar esta firma, la autoridad certificadora calcula un hash MD5 de la primera parte del certificado (la seccin de Data: los datos del mismo ms la clave pblica) y cifra ese hash con su clave privada, que mantiene en secreto. Ahora supongamos que un cliente se conecta a www.freesoft.org y el sitio le devuelve el certificado anterior, con la intencin de probar su identidad. Para validar este certificado, necesitamos el certificado de la autoridad certificadora, que fue el emisor del primero (Thawte Server CA). Se toma la clave pblica del certificado de la autoridad certificadora para decodificar la firma del primer certificado, obtenindose un hash MD5. Este hash MD5 debe coincidir con el hash MD5 calculado sobre la primera parte del certificado. En ese caso el proceso de validacin termina con xito. Si no, la validacin no tiene xito, y no puede asegurarse que el certificado de www.freesoft.org est vinculado con esa clave pblica. Dicho de otro modo, es posible que www.freesoft.org no sea quien dice ser. A continuacin se muestra el certificado de la CA: Certificate: Data: Version: 3 (0x2)

X.509 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 Este es un ejemplo de un certificado auto firmado. Ntese que el CN del Emisor y el CN del Sujeto son iguales. No hay forma de verificar este certificado, salvo que se comprueba contra s mismo. En este caso, hemos alcanzado el fin de la cadena de certificados. Cmo es entonces que este certificado se hace confiable? Simple: se configura manualmente. Thawte es una de las autoridades certificantes raz 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 (ntese la fecha de vencimiento) que puede firmar prcticamente cualquier cosa (ntese la falta de limitaciones), su clave privada correspondiente debe ser una de las ms ocultas del mundo.

X.509

Tipos de certificados
Hay distintos tipos de certificados, segn el criterio que utilicemos de clasificacin.[6]

Verificacin de datos
Certificados de Clase 1: corresponde a los certificados ms fciles de obtener e involucran pocas verificaciones de los datos que figuran en l: slo el nombre y la direccin de correo electrnico del titular. Certificados de Clase 2: en los que la Autoridad Certificadora comprueba adems el Documento de identidad o permiso de conducir que incluya fotografa, el nmero de la Seguridad Social y la fecha de nacimiento. Certificados de Clase 3: en la que se aaden a las comprobaciones de la Clase 2 la verificacin de crdito de la persona o empresa mediante un servicio del tipo Equifax, Datacredito. Certificados de Clase 4: que a todas las comprobaciones anteriores suma la verificacin del cargo o la posicin de una persona dentro de una organizacin.

Finalidad
Certificados SSL para cliente: mediante el protocolo Secure Socket Layer, dirigido a una persona fsica. Certificados SSL para servidor: usados para identificar a un servidor ante un cliente en comunicaciones mediante SSL. Certificados S/MIME : usados para servicios de correo electrnico firmado y cifrado, que se expiden generalmente a una persona fsica. Certificados para la firma de cdigo: usados para identificar al autor de ficheros o porciones de cdigo en cualquier lenguaje de programacin que se deba ejecutar en red (Java, JavaScript, CGI, etc). Certificados para AC (Autoridades Certificadoras): se usa por el software cliente para determinar si pueden confiar en un certificado cualquiera, accediendo al certificado de la AC y comprobando que sta es de confianza.

Enlaces externos
CAcert.org, Entidad Certificadora administrada por la comunidad Albalia Demo CA [7] Certificados de Prueba Integracin corporativa de la confianza (Enterprise Trust Integration), estndares de Servicios Web y demos [8] Safelayer (implementacin comercial) [9] Xcarecrows 4 X509 (implementacin comercial) [10] firma de documentos en lnea de forma fcil! [11]

Referencias
Estudio y propuesta de una gua de sintonizacin de servicios web seguros basados en J2EE. David Comn Roig UPC.

Notas al pie
[1] [2] [3] [4] [5] [6] [7] http:/ / tools. ietf. org/ rfc/ rfc5280. txt http:/ / www. win. tue. nl/ ~bdeweger/ CollidingCertificates/ ddl-full. pdf http:/ / www. win. tue. nl/ hashclash/ SoftIntCodeSign/ http:/ / www. thawte. com/ http:/ / www. verisign. com/ http:/ / www. eurologic. es/ conceptos/ certificados%20digitales. htm http:/ / ca. albalia. es:8080/ democa/

[8] http:/ / www. trustedwebservices. org [9] http:/ / www. safelayer. com [10] http:/ / www. xcarecrows. com/ xcarecrows4x509. php

X.509
[11] http:/ / www. ascertia. com/ Index. aspx

Fuentes y contribuyentes del artculo

Fuentes y contribuyentes del artculo

X.509 Fuente: http://es.wikipedia.org/w/index.php?oldid=70999116 Contribuyentes: Alexav8, Angeltoribio, Cobalttempest, DaveFX, Death Master, Diamondland, Digigalos, Er Komandante, GermanX, Hprmedina, Ignacioerrico, JRGL, Jarfil, Juanpebe, Lenho, LogC, Martini 001, Metrnomo, Osamanaseem, PabloCastellano, Reyesoft, Rsaralegui, Taichi, Technopat, Xandi, 47 ediciones annimas

Licencia
Creative Commons Attribution-Share Alike 3.0 //creativecommons.org/licenses/by-sa/3.0/