Certificado y Firma digital

Certificado y Firma digital Fundamentos Informació general del document. Descripció. Títol: Certificado y Firma digital. Fundamentos Estat: Aprovat Versió: 1.0 Autor/s: Daniel Boerner Creat: 26/11/2013 Modificat 18/12/2013 Fitxer: firmaDigitalFBit.odt Històric de modificacions. Comentari: Font documental. Autor/s: Data: Contenido 1. Función Hash..............................................................................................................................................................................................5 2. Código de Autenticación.............................................................................................................................................................................5 2.1. HMAC................................................................................................................................................................................................6 3. Cifrado Simétrico.........................................................................................................................................................................................6 4. Cifrado Asimétrico.......................................................................................................................................................................................7 4.1. Generación de claves........................................................................................................................................................................7 5. Envoltorio Digital.......................................................................................................................................................................................10 6. Firma Digital..............................................................................................................................................................................................10 7. Sello de Tiempo........................................................................................................................................................................................12 8. Certificado Digital......................................................................................................................................................................................14 8.1. PKI X.509.........................................................................................................................................................................................14 Certificado digital X.509...................................................................................................................................................................15 Autoridades......................................................................................................................................................................................15 Usos.................................................................................................................................................................................................15 Políticas de certificación...................................................................................................................................................................16 Ejemplo de certificado digital X.509.................................................................................................................................................17 Creación de un certificado digital.....................................................................................................................................................19 Creación de un certificado digital autofirmado.................................................................................................................................20 Revocación.......................................................................................................................................................................................22 Validación.........................................................................................................................................................................................26 Subject Key Identifier.......................................................................................................................................................................27 Verificación.......................................................................................................................................................................................28 8.2. Archivos de certificados digitales....................................................................................................................................................30 Operaciones sobre archivos con certificados digitales....................................................................................................................31 8.3. Huella digital....................................................................................................................................................................................32 9. Marco legal................................................................................................................................................................................................32 10. Prácticas.................................................................................................................................................................................................34 10.1. PKI Simple.....................................................................................................................................................................................34 10.2. PKI Avanzado................................................................................................................................................................................35 10.3. PKI Experto....................................................................................................................................................................................35 10.4. SSL. Autenticación cliente/servidor...............................................................................................................................................36 11. Firma avanzada.......................................................................................................................................................................................37 12. CAdES.....................................................................................................................................................................................................38 12.1. Perfiles...........................................................................................................................................................................................38 CAdES-BES: básica.........................................................................................................................................................................39 CAdES-EPES: referencias a políticas de firma...............................................................................................................................40 CAdES-T: sello de tiempo................................................................................................................................................................40 CAdES-C: referencias a datos de validación...................................................................................................................................41 CAdES-X Long: datos de validación................................................................................................................................................41 CAdES-X Type 1: referencias a datos de validación y sello de tiempo sobre CAdES-C................................................................42 CAdES-X Type 2: referencias a datos de validación y sello de tiempo sobre referencias a datos de validación..........................42 CAdES-X Long Type 1: datos de validación y sello de tiempo sobre CadES-C.............................................................................43 CAdES-X Long Type 2: datos de validación y sello de tiempo sobre referencias a datos de validación.......................................43 CAdES-A: datos de validación y sello de tiempo sobre CAdES-C o sobre referencias a datos de validación, sellos de tiempo periódicos para validar la firma a largo plazo..................................................................................................................................44 13. XAdES.....................................................................................................................................................................................................44 13.1. Forma canónica.............................................................................................................................................................................45 13.2. Firma Digital XML..........................................................................................................................................................................45 Enveloping Signature.......................................................................................................................................................................46 Enveloped Signature........................................................................................................................................................................46 Detached Signature.........................................................................................................................................................................47 Validación de una firma XML...........................................................................................................................................................48 Ejemplo de una firma XML...............................................................................................................................................................48 13.3. Formas de firma digital XML avanzada.........................................................................................................................................50 XAdES: básica.................................................................................................................................................................................51 XAdES-T: sello de tiempo................................................................................................................................................................52 XAdES-C: referencias a datos de validación (cadenas de certificados y listas de revocación).....................................................53 XAdES-X: referencias a datos de validación y sello de tiempo sobre referencias a datos de validación y/o firma y otros sellos de tiempos.............................................................................................................................................................................................53 XAdES-X-L: datos de validación (cadenas de certificados y listas de revocación) y con referencias a datos de validación y sello de tiempo sobre referencias a datos de validación y/o firma y otros sellos de tiempos.................................................................55 XAdES-A: datos de validación (cadenas de certificados y listas de revocación), referencias a datos de validación, sellos de tiempo periódicos para validar la firma a largo plazo, sello de tiempo sobre referencias a datos de validación y/o firma y otros sellos de tiempos..............................................................................................................................................................................55 14. PAdES.....................................................................................................................................................................................................57 14.1. Perfiles PAdES..............................................................................................................................................................................57 PAdES Basic....................................................................................................................................................................................57 PAdES Enhanced.............................................................................................................................................................................59 PAdES Long Term............................................................................................................................................................................59 PAdES XML......................................................................................................................................................................................60 15. @Firma...................................................................................................................................................................................................60 1. Función Hash El valor de una función hash es un número calculado a partir de un mensaje o documento. Básicamente, una función hash exhibe tres propiedades interesantes: • no es posible recuperar el mensaje a partir del número • para dos mensajes diferentes no se obtiene el mismo número • la longitud de la representación del número calculado es independiente de la longitud del mensaje Debido a estas propiedades, una función hash se utiliza para: • indexar documentos • comprobar la integridad de un documento • almacenar contraseñas Para su utilidad práctica, el algoritmo que implementa una función hash debe ser eficiente en cuanto al consumo de recursos: tiempo de procesador y uso de memoria. Algoritmos que implementan una función hash son MD5 y SHA-1. Ejemplos: $ echo "hola mundo" | openssl dgst md5 (stdin)= 1e04bb3f9f396d3b71d93d326ebfc42d $ echo "hola mundo" | openssl dgst sha1 (stdin)= f66b87fef5bf79850e957497ef2d529ce607b7ad $ openssl dgst sha1 documento.txt SHA1(documento.txt)= 6d6aad4c5518695d6d6b9cb272aa14e18f2ca256 Una importante característica de las funciones hash es su calidad. Dado que el número de posibles valores de una función hash es finito y el número de mensajes es infinito, necesariamente se producen coincidencias entre los valores hash calculados para diferentes mensajes. Este hecho se conoce como colisión. Así, la calidad de una función hash se mide por la probabilidad de que se produzcan colisiones. 2. Código de Autenticación El código de autenticación de un mensaje (MAC) es un número obtenido al cifrar el valor resultante de aplicar una función hash a un mensaje. De esta forma el receptor del mensaje puede verificar la INTEGRIDAD (el mensaje no ha sido modificado durante su transmisión) y la AUTENTICIDAD del origen del mensaje (todas aquellas partes que posean la clave). No ofrece la propiedad de no repudio ya que cualquier parte (emisor o receptor) capaz de verificar un MAC puede también generar un MAC. Tampoco ofrece privacidad porque no se cifra el mensaje. El emisor calcula el MAC de un mensaje y lo adjunta al mensaje. El receptor calcula mediante el mismo algoritmo y con la misma clave utilizada por el emisor un nuevo MAC a partir del mensaje y lo compara con el MAC recibido. 5 de 61 2.1. HMAC Una implementación de un algoritmo MAC es HMAC (keyed-Hash Message Authentication Code) cuyo principio básico es: MAC = h(k | h(k | M)) donde: • h es una función hash • k es la clave • M es el mensaje • | representa la concatenación de cadenas de caracteres Ejemplos: $ echo 'mi pedido' | openssl dgst hmac 'mi clave' (stdin)= 03852bdcf9d499605472785694112cbe78ab616d $ echo 'mi pedido' | openssl dgst sha1 hmac 'mi clave' (stdin)= 03852bdcf9d499605472785694112cbe78ab616d $ echo n '' | openssl dgst hmac '' (stdin)= fbdb1d1b18aa6c08324b7d64b71fb76370690e1d $ perl MDigest::SHA e 'print Digest::SHA::hmac_sha1_hex("", ""), "\n";' fbdb1d1b18aa6c08324b7d64b71fb76370690e1d 3. Cifrado Simétrico En un sistema de cifrado simétrico se utiliza una única clave para cifrar y descifrar un mensaje o documento. El emisor utiliza una clave para cifrar un mensaje y el receptor del mensaje utiliza la misma clave para descifrar el mensaje. El cifrado simétrico requiere un intercambio inicial de la clave entre el emisor y el receptor. Para ello se debe utilizar un canal de comunicación de confianza para ambos. Mediante el cifrado simétrico se consigue INTEGRIDAD (el mensaje no ha sido modificado durante su transmisión), PRIVACIDAD (confidencialidad) y AUTENTICIDAD (se conoce el autor del mensaje). En cuanto a la gestión de claves, el cifrado simétrico precisa una clave para cada par emisor/receptor lo cual complica la distribución de las claves. Algoritmos de cifrado simétrico son: AES, Blowfish, DES, Triple-DES, etc... Ejemplo de cifrado utilizando el algoritmo Blowfish: $ openssl enc bf in document.in out document.bf k mypassword $ openssl enc bf d in document.bf out document.out k mypassword 6 de 61 4. Cifrado Asimétrico A diferencia del cifrado simétrico, el cifrado asimétrico utiliza dos claves relacionadas matemáticamente entre sí. Un emisor puede cifrar el mensaje con una de las claves manteniéndola privada y publicar la otra clave para que el receptor pueda descifrar con ella el mensaje. Este procedimiento es reversible: el emisor puede utilizar cualquiera de sus dos claves para cifrar, utilizando entonces el receptor la otra clave del emisor para descifrar. Alternativamente, el emisor puede utilizar una de las claves del receptor para cifrar, utilizando entonces el receptor su otra clave para descifrar el mensaje recibido. La utilización de una clave es complementaria a la utilización de la otra clave. Para conseguir la PRIVACIDAD en una comunicación, el emisor utiliza habitualmente la clave pública del destinatario para cifrar el mensaje. Actualmente, el algoritmo más popular que implementa el cifrado asimétrico es RSA: e d c = m mod n → m = c mod n donde: • m es una representación númerica del mensaje sin cifrar (0 ≤ m < n) • c es el mensaje cifrado (0 ≤ c < n) • n se denomina módulo y resulta de multiplicar dos números primos, aleatorios y grandes, p y q • e es un exponente que junto a n forman la clave pública. Típicamente e = 2 • d es la clave privada y se obtiene a partir de e y de la factorización p·q de n 16 +1 = 65537 En el contexto de RSA, la longitud de la clave es la longitud en bits del módulo. La seguridad del algoritmo RSA se basa en que actualmente no se sabe como obtener d en base al exponente e y sin conocer la factorización del módulo n. Y por supuesto, sin conocer d, tampoco se sabe como obtener la representación numérica m del mensaje original a partir del mensaje cifrado c. Teóricamente, el cifrado asimétrico resuelve el problema del intercambio inicial de claves. En la práctica, sin embargo, se requiere además de un servicio de directorio para una eficaz distribución de claves. La implementación del cifrado asimétrico consume mayor cantidad de recursos (tiempo de procesador y uso de memoria) con respecto a la implementación del cifrado simétrico. 4.1. Generación de claves Las claves son números grandes y aleatorios. A continuación se muestra un ejemplo de generación de un par de claves para un cifrado asimétrico. $ openssl genrsa out my.key 1024 Generating RSA private key, 1024 bit long modulus ..............++++++ ......++++++ e is 65537 (0x10001) Como resultado se obtiene: $ openssl pkey in my.key text noout PrivateKey: (1024 bit) modulus: 00:e1:8b:d9:44:dd:a2:41:4e:0d:8a:85:66:00:cb: 5d:8e:4d:e2:40:a7:a0:b7:41:5f:e3:93:72:f2:f3: 7 de 61 c3:6e:60:a5:b1:eb:87:53:1c:ba:bc:f9:fa:b7:d0: 14:0f:14:81:9c:5c:93:6f:36:ae:e6:0e:36:51:4f: a1:03:26:7a:17:2f:c9:0c:a7:a1:46:cb:2e:6a:d2: 9d:ff:20:20:19:79:de:52:97:0c:c5:ba:b8:cd:62: 2c:01:f1:3a:6a:a9:68:d5:31:eb:97:3c:3e:e0:d7: 8d:c9:8f:1d:6c:14:60:fc:e2:91:9c:a4:40:0a:24: a8:79:75:29:07:fc:7e:de:7f publicExponent: 65537 (0x10001) privateExponent: 32:98:da:de:d6:11:86:30:ea:5c:be:dc:49:25:56: 11:8c:6b:4b:31:cf:9e:0c:ae:64:31:39:c2:42:e8: fe:a3:f3:c7:dc:1c:79:8a:a2:61:ae:7a:8e:2d:c1: b2:38:59:73:28:59:72:c3:83:ac:dc:57:57:1a:53: f6:8e:f5:28:3e:9c:f1:ef:b5:24:f0:23:c0:c3:ed: bf:cb:bf:f3:eb:be:af:ef:76:8f:ac:40:40:55:af: fd:da:76:1c:9f:39:12:6f:36:e1:28:43:cb:23:c1: 2e:9c:75:1c:c0:e0:b1:bb:a1:7e:41:64:e8:1a:47: 41:c9:b7:22:aa:4d:24:41 prime1: 00:f5:19:14:9c:75:a5:ca:73:9b:f4:83:fe:b2:bf: 32:fc:e0:18:16:30:72:a7:1e:fc:85:93:ec:d2:6a: bc:5e:e6:e0:81:c8:8d:21:f3:62:4b:89:13:d4:f7: aa:62:c4:ce:54:35:d0:36:72:52:d5:d9:91:e0:ee: c1:1e:90:6d:11 prime2: 00:eb:94:22:4f:5f:c9:2b:34:55:0d:fa:2d:1d:e0: 81:6e:49:48:4a:a1:11:2c:53:fb:2c:e5:31:87:a2: bc:ca:37:8a:53:b0:1c:1f:4b:0d:4d:a4:10:47:67: 3d:e1:6f:48:13:c9:91:cd:7b:a4:4e:b7:03:6c:17: cb:12:ba:d2:8f exponent1: 08:dd:fe:6b:e6:a9:b7:d8:54:e5:14:bd:6b:34:15: a1:26:6e:58:a7:2a:0e:b7:c5:45:03:e4:06:7c:cc: 11:d6:e2:7a:6f:8a:03:97:6d:8f:f4:06:9e:a6:d3: 28:3d:9c:85:59:69:0d:ff:36:d5:fb:c8:16:4e:2c: f8:71:1b:31 exponent2: 00:b4:69:97:f5:0d:b8:34:5c:39:9f:20:af:18:a8: 6c:b7:17:6c:43:ab:22:49:be:6f:27:ac:c6:c7:c7: 3b:a9:e9:eb:07:b8:61:71:1d:bb:2c:70:ae:fe:df: f4:26:07:61:3d:b6:2a:f1:20:f5:6e:4a:fe:55:f3: ca:d3:a7:3b:c5 coefficient: 00:e8:36:9f:4b:ec:fc:04:13:68:e4:fa:24:aa:6e: 33:a9:7c:b4:ec:d0:6d:47:dd:39:9c:29:fb:da:1d: 54:0a:a7:b8:44:5b:69:fb:01:48:1b:a1:ee:c1:13: ac:0c:02:5a:4b:62:ea:31:bf:6f:1e:68:d9:9a:6e: 35:9b:2c:e8:96 Multiplicando los dos números prime1 y prime2: #!/usr/bin/perl w use strict; use Math::BigInt; (my $prime1 = <<'PRIME1') =~ s/[:\s\n]+//g; 0x 00:f5:19:14:9c:75:a5:ca:73:9b:f4:83:fe:b2:bf: 32:fc:e0:18:16:30:72:a7:1e:fc:85:93:ec:d2:6a: bc:5e:e6:e0:81:c8:8d:21:f3:62:4b:89:13:d4:f7: aa:62:c4:ce:54:35:d0:36:72:52:d5:d9:91:e0:ee: c1:1e:90:6d:11 PRIME1 8 de 61 (my $prime2 = <<'PRIME2') =~ s/[:\s\n]+//g; 0x 00:eb:94:22:4f:5f:c9:2b:34:55:0d:fa:2d:1d:e0: 81:6e:49:48:4a:a1:11:2c:53:fb:2c:e5:31:87:a2: bc:ca:37:8a:53:b0:1c:1f:4b:0d:4d:a4:10:47:67: 3d:e1:6f:48:13:c9:91:cd:7b:a4:4e:b7:03:6c:17: cb:12:ba:d2:8f PRIME2 my $a = Math::BigInt>new(qq($prime1)); my $b = Math::BigInt>new(qq($prime2)); my $modulus = $a>bmul($b)>as_hex(); # pretty print $modulus =~ s/0x/00/; $modulus =~ s/(\w\w)/$1:/g; $modulus =~ s/((\w\w:){15})/$1\n/g; $modulus =~ s/:$//; print $modulus, "\n"; se obtiene efectivamente el modulus cuya representación binaria contiene 1024 bits: 00:e1:8b:d9:44:dd:a2:41:4e:0d:8a:85:66:00:cb: 5d:8e:4d:e2:40:a7:a0:b7:41:5f:e3:93:72:f2:f3: c3:6e:60:a5:b1:eb:87:53:1c:ba:bc:f9:fa:b7:d0: 14:0f:14:81:9c:5c:93:6f:36:ae:e6:0e:36:51:4f: a1:03:26:7a:17:2f:c9:0c:a7:a1:46:cb:2e:6a:d2: 9d:ff:20:20:19:79:de:52:97:0c:c5:ba:b8:cd:62: 2c:01:f1:3a:6a:a9:68:d5:31:eb:97:3c:3e:e0:d7: 8d:c9:8f:1d:6c:14:60:fc:e2:91:9c:a4:40:0a:24: a8:79:75:29:07:fc:7e:de:7f Para obtener la clave privada: $ openssl pkey in my.key BEGIN PRIVATE KEY MIICeAIBADANBgkqhkiG9w0BAQEFAASCAmIwggJeAgEAAoGBAObJiSmXci/UmTtf EjiD0o0dw0CDNNITh1iwLDGWAtv1A+T2aAS3sY69dzd1yMJKFbe+Kqg6e2VzVuWO GAn2yyXsK/ibsxiZP9LP/a4oudpvpi0BT1FQAhpFw8SjjbuFaNQXhLfd7kmFiLRe JQxcp/B/2dVfYxcosdRXy34cf0nnAgMBAAECgYEAiDCR4pteZN9edWzLAdK4o1HW 8PD8cKPZkPqVecV+dnKGE81c4LvN6d/gxDebexvg6QctgQzR2LJRqzFI+khK5Dz1 EXJ5bQsXNISm1EPzQAXArDq6Diy3JV/xNujYkC757KWbKIotoFXE5EWnCbOxv5fl 9G01QZB7Jd97bUQMEqECQQD9VQ25VeUy4hp+yEmC1l4j1js5+nriE8R4wkw5wN5i 2NIUCtQ+Lbej3BN2gi1yIV3Jez8Y7zNUa8qJI7TQ/k5/AkEA6Te0RuTtyVaWOmOa niJDsX7UfCjCa55ikbEUDIyVEM75c33R9FxZJMzuXKH2KKICPSuucRIaQYQZi0mW OQ2gmQJAZ1cAyC+/1WfigwFU62hi8p97fYUuB3ck2FX6Hj0M+qmT2NUqC0s+9Drc PaWQwFPYHE6ISLWa7L8j2ZmVMwPqJQJBAMJSjt0PfW5ovk4yli+zHzJzGnvFvpHL bBg3MxxtuvtBaiqoKNvyYri+JNJ8hU5AB5uOnRBL5CK4/kvH6erqBukCQQDM/Omx /+6VbRYBBy1IsLJct1DIquuOGdP2mpz030vCsxll9T2vMF17TboZTsxyE4gcvMXd cM7cm0WQzs37md/a END PRIVATE KEY Esta sección PEM, contiene el modulus, el publicExponent, el privateExponent, el número prime1, el número prime2, el exponent1, el exponent2 y el coefficient. Para obtener la clave pública: $ openssl pkey in my.key pubout 9 de 61 BEGIN PUBLIC KEY MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDmyYkpl3Iv1Jk7XxI4g9KNHcNA gzTSE4dYsCwxlgLb9QPk9mgEt7GOvXc3dcjCShW3viqoOntlc1bljhgJ9ssl7Cv4 m7MYmT/Sz/2uKLnab6YtAU9RUAIaRcPEo427hWjUF4S33e5JhYi0XiUMXKfwf9nV X2MXKLHUV8t+HH9J5wIDAQAB END PUBLIC KEY Esta sección PEM, únicamente contiene el modulus y el publicExponent. 5. Envoltorio Digital Un envoltorio digital (digital envelope) es una técnica combinada de utilización de claves de cifrado simétrico y claves de cifrado asimétrico. El emisor cifra el mensaje mediante una clave simétrica y a su vez cifra esta clave mediante la clave pública de cada receptor. Cada receptor utiliza su clave privada para obtener la clave simétrica con la cual descifra el mensaje recibido. De esta forma la clave simétrica puede ser la misma para todos lo receptores. En consecuencia el emisor solo necesita calcular un único mensaje cifrado. Esta técnica explota la eficiencia del cifrado simétrico frente al cifrado asimétrico y delega el problema de distribución de claves a un sistema de claves públicas. 6. Firma Digital Una firma digital se obtiene al cifrar con la clave privada de un sistema de cifrado asimétrico el resultado de una función hash aplicada al documento o mensaje que se pretende firmar. La utilización de la clave privada del autor de la firma asegura su INTEGRIDAD, AUTENTICIDAD y la propiedad de NO REPUDIO: el emisor como único poseedor de la clave privada, no puede negar la generación de la firma. Tomando el algoritmo RSA que implementa el cifrado asimétrico, se tiene para la firma: d e s = h mod n → h = s mod n donde: • h es un valor hash del mensaje a firmar • s es la firma digital • n se denomina módulo y resulta de multiplicar dos números primos, aleatorios y grandes, p y q • e es un exponente que junto a n forman la clave pública. Típicamente e = 2 • d es la clave privada y se obtiene a partir de e y de la factorización p·q de n 16 +1 = 65537 10 de 61 El interesado en validar la firma, descifra el valor hash mediante la clave pública del autor de la firma y compara el resultado con un nuevo valor hash calculado sobre el documento o mensaje en cuestión. Así pues, para validar la firma es necesario conocer la clave pública del firmante del mensaje, el algoritmo utilizado para el cifrado del resultado de la función hash y el algoritmo utilizado para la generación del valor hash. Se podría prescindir de la función hash y cifrar directamente el mensaje con la clave privada. Sin embargo, el algoritmo RSA limita la longitud del mensaje a la longitud del módulo. Esta limitación se supera aplicando una función hash al mensaje y en lugar de cifrar el mensaje, se cifra el valor de la función hash. Independientemente de esta característica y como ventaja adicional, se obtiene una mayor eficiencia al cifrar el valor hash ya que, en general y comparado con la longitud del mensaje, el valor hash suele ser de menor longitud. La firma digital es un dato añadido al mensaje que se firma y NO garantiza la privacidad de la comunicación del mensaje. Ejemplo 1: Firmar: $ openssl genrsa out my.key 1024 $ openssl pkey in my.key pubout out pubkey.pem $ openssl dgst sha256 document.txt > hashA $ openssl rsautl sign in hashA inkey my.key out signature Verificar: $ openssl rsautl verify inkey pubkey.pem pubin in signature > hashB $ diff s hashA hashB Los archivos hashA y hashB son idénticos Ejemplo 2: Firmar: $ openssl genrsa out my.key 1024 $ openssl pkey in my.key pubout out pubkey.pem $ openssl dgst sha256 sign my.key out signature document.txt Verificar: 11 de 61 $ openssl dgst sha256 verify pubkey.pem signature signature document.txt Verified OK 7. Sello de Tiempo Mediante un sello de tiempo (time-stamp) se pretende demostrar la existencia anterior a una determinada fecha y hora de un mensaje o documento. El interesado calcula un hash del documento y lo envía como una petición a una tercera parte de confianza denominada Autoridad de Sellado de Tiempo (TSA). Esta obtiene un token de tiempo, adjunta el token al hash recibido, firma el resultado y lo envía como respuesta al interesado. El interesado, después de verificar la firma de la TSA, comprueba su conformidad con la fecha y hora emitida y que el dato sellado por la TSA coincida con el hash del documento. Este procedimiento presenta tres interesantes características: • No se requiere exponer el documento • El interesado no puede modificar el sello de tiempo • El interesado no puede modificar el documento después del momento representado por el sello de tiempo En base a la política que publica cada TSA para gestionar los sellos de tiempo, el interesado determinará la TSA que más le convenga. La respuesta que emite la TSA es un archivo con una estructura especificada por PKCS#7. Según RFC 3161, la TSA no está obligada a la identificación del interesado: las peticiones no incluyen información de identificación. Ejemplo 1: $ openssl ts query data documento.txt cert | tee documento.tsq | ./tsget h http://zeitstempel.dfn.de o documento.tsr 12 de 61 $ openssl ts query in documento.tsq text Version: 1 Hash Algorithm: sha1 Message data: 0000 a5 88 af 65 88 86 93 c7b8 08 6a 7f 40 41 3f 0d ...e......j.@A?. 0010 c8 a4 77 71 ..wq Policy OID: unspecified Nonce: 0xF113D01AD11BB96B Certificate required: yes Extensions: $ openssl ts reply in documento.tsr text Status info: Status: Granted. Status description: Operation Okay Failure info: unspecified TST info: Version: 1 Policy OID: 1.3.6.1.4.1.22177.300.22.1 Hash Algorithm: sha1 Message data: 0000 a5 88 af 65 88 86 93 c7b8 08 6a 7f 40 41 3f 0d ...e......j.@A?. 0010 c8 a4 77 71 ..wq Serial number: 0x014274EA4940 Time stamp: Nov 20 09:49:40 2013 GMT Accuracy: unspecified Ordering: no Nonce: 0xF113D01AD11BB96B TSA: unspecified Extensions: Ejemplo 2: (ver con ASN.1 Decoder http://lapo.it/asn1js) $ openssl pkcs7 inform DER in segell_acreditacio.tst text BEGIN PKCS7 MIIKLAYJKoZIhvcNAQcCoIIKHTCCChkCAQMxCzAJBgUrDgMCGgUAMHAGCyqGSIb3 DQEJEAEEoGEEXzBdAgEBBgtghVQBAwEBBAIBAjAhMAkGBSsOAwIaBQAEFKV2HugI xUd2cY5ML4MJFBNoUUnnAgQGTtEEGA8yMDEzMTExODEyMDQzNFowCQIBAYABAYEB AgIGAUJrGRIGoIIHWzCCB1cwggY/oAMCAQICAwUHnzANBgkqhkiG9w0BAQUFADBE MQswCQYDVQQGEwJFUzENMAsGA1UEChMETURFRjEMMAoGA1UECxMDUEtJMRgwFgYD VQQDEw9NSU5JU0RFRi1FQy1XUEcwHhcNMTEwODE3MDk1NDA1WhcNMjEwODE3MDk1 NDA1WjBlMQswCQYDVQQGEwJFUzENMAsGA1UECgwETURFRjEMMAoGA1UECwwDUEtJ MRIwEAYDVQQFEwlTMjgzMzAwMkUxJTAjBgNVBAMMHFNlbGxvIGRlIHRpZW1wbyBU U0AgLSBAZmlybWEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5qDUz Bp95YyOBNu35IdWJzQZEfQbX+LlF/NlUhy2mWllrZe7w2rITxd4MJR48XppnGdmV WkPpnSjGMfdX0+QzzS7h9hLPkFpOYU8wodp744jn3LbYi5j5Kzv4kLoJAQ9en/R/ Y6T09hoDGOTvIbgVh6cq93ABJZPrxUH9n80RziPQZq36zQnBlKL3NhgHOCpIcjPu NC4njBAULo2xUZt+5SVjG8FqSQ6Ca8CvG6gi3jPausTPbfmRBCkTnUmMp33a6hrb 4i2RwkCLnxL42/ACNVm+0fiKb5sNy92Fn4EaDMw3iMnqt6Yyrphsrmq2/IA38pV5 HlzPZp6mvCD5IbvTAgMBAAGjggQvMIIEKzCB5gYDVR0RBIHeMIHbgRZzb3BvcnRl LmFmaXJtYTVAbXB0LmVzpIHAMIG9MR4wHAYJYIVUAQMFAgIBDA9zZWxsbyBkZSB0 aWVtcG8xUDBOBglghVQBAwUCAgIMQU1pbmlzdGVyaW8gZGUgbGEgUG9sw610aWNh IFRlcnJpdG9yaWFsIHkgQWRtaW5pc3RyYWNpw7NuIFDDumJsaWNhMRgwFgYJYIVU AQMFAgIDDAlTMjgzMzAwMkUxLzAtBglghVQBAwUCAgUMIFRTQC0gQXV0b3JpZGFk IFNlbGxhZG8gZGUgdGllbXBvMIHEBgNVHRIEgbwwgbmBD2FncG1kQG9jLm1kZS5l c6SBpTCBojELMAkGA1UEBhMCRVMxDTALBgNVBAoMBE1ERUYxDDAKBgNVBAsMA1BL STEmMCQGA1UEBwwdQXJ0dXJvIFNvcmlhIDI4OSAyODA3MSBNYWRyaWQxEjAQBgNV BAUTCVMyODAwMjMxSTEpMCcGA1UECwwgTWluaXN0ZXJpbyBkZSBEZWZlbnNhIGRl 13 de 61 IEVzcGHDsWExDzANBgNVBAMMBlBLSURFRjAMBgNVHRMBAf8EAjAAMA4GA1UdDwEB /wQEAwIGwDAWBgNVHSUBAf8EDDAKBggrBgEFBQcDCDAdBgNVHQ4EFgQUex89Esdb bL4qPY4kdpqK84DTsyUwOAYIKwYBBQUHAQEELDAqMCgGCCsGAQUFBzABhhxodHRw Oi8vZXYwMS13cGcubWRlZi5lczo5MzA4MEQGA1UdIAQ9MDswOQYJYIVUAQEBAQME MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly9wa2kubWRlZi5lcy9jcHMvY3BzLmh0bTAf BgNVHSMEGDAWgBSr47khgFv6dg/HRtuwm4gLWrHKsjCCAYEGA1UdHwSCAXgwggF0 MIIBcKCCAWygggFohoG2bGRhcDovLy9DTj1NSU5JU0RFRi1FQy1XUEcsQ049RUMt V1BHLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNl cyxDTj1Db25maWd1cmF0aW9uLERDPWV0LERDPW1kZSxEQz1lcz9jZXJ0aWZpY2F0 ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Y2xhc3M9Y1JMRGlzdHJpYnV0aW9u UG9pbnSGfWxkYXA6Ly9sZGFwLm1kZWYuZXMvY249TUlOSVNERUYtQ1JMLUVDLVdQ RyxPVT1QS0ksTz1NREVGLEM9RVM/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9i YXNlP29iamVjdGNsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50hi5odHRwOi8vcGtp Lm1kZWYuZXMvY3JsL01JTklTREVGLUNSTC1FQy1XUEcuY3JsMA0GCSqGSIb3DQEB BQUAA4IBAQAYGURzOt6/O0UOvGakW1Y4iBFT84ZeNByR17e1VsML1ZmIzl8QHv4y yhwCDPiD8U7k7EZApdV8TzPp0hE1pqyxb7UwFj7kGncEcA2TMJ9rMikho27SPk8l vj1McxbPxBBbsfWbGXZvx9/W1yt2l/ZCVboPSJ3I/FBTS3qFFUglR00uxTxpARTN LOzVgHlLkCtzvS+C7QZn6TGk7ESWUTeKXLg7DPC0/Fue8Ya0Pa45VDPEaVq8ucTN O6KT7JgBgNFZdPdbdxMHAoL+cK/W5iesxtgRu3FY8EyWmuMbFGx57xKpRsqQ+Noi z4xg3FCVWPQnTScjg7wNeNEuvuhNPdhvMYICNDCCAjACAQEwSzBEMQswCQYDVQQG EwJFUzENMAsGA1UEChMETURFRjEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9NSU5J U0RFRi1FQy1XUEcCAwUHnzAJBgUrDgMCGgUAoIG/MBoGCSqGSIb3DQEJAzENBgsq hkiG9w0BCRABBDAjBgkqhkiG9w0BCQQxFgQUa4xjBSoFZEE+UuUEGtO0D3GZC6cw fAYLKoZIhvcNAQkQAgwxbTBrMGkwZwQU9l4z1pdybfofLjtzQaae/NavzNAwTzBI pEYwRDELMAkGA1UEBhMCRVMxDTALBgNVBAoTBE1ERUYxDDAKBgNVBAsTA1BLSTEY MBYGA1UEAxMPTUlOSVNERUYtRUMtV1BHAgMFB58wDQYJKoZIhvcNAQEBBQAEggEA Mto4CADUc2nGBKjKUm2fBXpBeQ9grWA+p3mDXQKroIQaPf4ve0tmLCtCpOuCEdaC veBnAHXetsvRxgnGChwXRs24J6Ll3FTBj5zYzo6cSxHu3mtEBcD42RH7uk4tzOJN cFqn5o7jjiUDSdAD63DnNiGskDEfJ2Tf3/SjYnW6e9uAdLzBdTzbUNa3vtFKhZ61 6v14quvefiuzUFKtsii5oY9x2r+sczNe+WhgrPo2YRsweZmVcr/Vhnt/HkzildjQ CnTSoFhhWyU2C1J4cDE76gtRdDSek3hHluQ3D1GzjYKovUQFMMtfW8NpMThmUGcu EGEgVcKUENI3qe7yg2tKog== END PKCS7 8. Certificado Digital Hasta aquí se han considerado las claves de un sistema de cifrado como monedas y billetes: el poseedor es el dueño legitimo de la clave. En un entorno globalmente interconectado no es posible conocer de una forma fiable la identidad de cada persona, entidad o sistema poseedor de una clave. Para demostrar la autenticidad de un mensaje y el norepudio de una firma digital es necesario asociar las claves a personas, entidades o sistemas de una forma eficaz, fiable y legalmente válida. Esto se consigue mediante un certificado digital. Un certificado digital relaciona una persona, entidad o sistema a una clave pública de un sistema de cifrado asimétrico. Al igual que cada estado respalda la identidad de cada uno de sus ciudadanos mediante documentos de identidad expedidos por organismos oficiales, la asociación entre una clave pública y una persona, entidad o sistema es respaldada por una tercera parte denominada autoridad certificadora. Se puede firmar con un certificado digital? 8.1. PKI X.509 Además de reconocer la legitimidad de las claves también se debe facilitar la interoperabilidad entre sistemas que utilizan certificados digitales. Todo ello requiere regular la administración y gestión de certificados digitales estableciendo normas, recomendaciones y especificaciones. El conjunto de normas, recomendaciones y especificaciones reconocido mundialmente se denomina X.509 que de 14 de 61 forma global, establece una infraestructura de clave pública (PKI). Certificado digital X.509 Básicamente, un certificado digital X.509 esta formado por un conjunto estructurado de atributos y valores: • Subject: Persona o entidad asociada a la clave pública (Nombre Distinguido) • Public Key: Clave pública • Valid-From: Inicio del período de validez del certificado (Not Before) • Valid-To: Fin del período de validez del certificado (Not After) • Serial Number: Número de serie del certificado • Issuer: Organismo o entidad que respalda el certificado (Nombre Distinguido) • Signature: Firma digital del organismo o de la entidad que respalda el certificado • Signature Algorithm: Algoritmo utilizado para crear la anterior firma digital • Key-Usage: Atributo que indica el propósito de utilización de la clave pública, como por ejemplo cifrado, firma digital, firma de otros certificados, … Autoridades • Autoridad Certificadora (CA) Organismo que crea, firma y registra certificados digitales. Los usuarios de la PKI reconocen este organismo como autoridad certificadora depositando su confianza en ella y aceptando sus reglas y procedimientos (políticas de certificación). • Autoridad Registradora (RA) Organismo subordinado a una CA que gestiona solicitudes de certificación y revocación. Puede aceptar o rechazar solicitudes. Comprueba la identidad y autenticación de usuarios solicitantes pero no firma certificados ni revocaciones de certificados. Usos En el momento de creación de un certificado digital X.509 se le asigna una serie de valores al atributo keyUsage según el propósito de utilización del certificado. De esta forma se limita el mal uso que pueda hacerse de él. Según la especificación X.509, los posibles valores que puede tomar el atributo obligatorio keyUsage son: • digitalSignature • nonRepudiation • keyEncipherment • dataEncipherment • keyAgreement 15 de 61 • keyCertSign • cRLSign • encipherOnly • decipherOnly Para ampliar los usos posibles de un certificado digital, en una posterior revisión de la especificación X.509 se añadió el atributo opcional extendedKeyUsage. Los valores de este atributo deben ser consistentes con los valores asignados al atributo keyUsage: • serverAuth (TLS WWW server authentication) Debe ser consistente con los usos: digitalSignature, keyEncipherment o keyAgreement. • clientAuth (TLS WWW client authentication) Debe ser consistente con los usos: digitalSignature y/o keyAgreement. • codeSigning (Signing of downloadable executable code) Debe ser consistente con los usos: digitalSignature. • emailProtection (Email protection) Debe ser consistente keyAgreement). • con los usos: digitalSignature, nonRepudiation, y/o (keyEncipherment o timeStamping (Binding the hash of an object to a time) Debe ser consistente con los usos: digitalSignature y/o nonRepudiation. • OCSPSigning (Signing OCSP responses) Debe ser consistente con los usos: digitalSignature y/o nonRepudiation. Políticas de certificación Una política de certificación determina un conjunto de reglas, procedimientos y condiciones al cual están sujetos los certificados emitidos por una determinada autoridad certificadora. Estas políticas pueden variar en función del uso o aplicación de cada certificado digital. Las políticas de certificación abarcan aspectos tales como: • procedimientos de renovación de certificados • realización de cambios en certificados • sistemas de archivo y copias de seguridad • realización de auditorías • medidas de seguridad implantadas • períodos de ejecución de revocaciones • publicación de listas de revocación 16 de 61 • algoritmos, parámetros y estándares utilizados • generación de claves (quien y como) • propiedad intelectual • términos de privacidad • responsabilidades y garantías • ámbitos jurídicos • tarifas y precios • etc... En la misma estructura de un certificado digital X.509 se encuentra un atributo denominado certificatePolicies cuyo valor hace referencia mediante un OID, a la política a la cual está sujeto el certificado. Ejemplo de certificado digital X.509 A continuación se muestra una representación de un certificado X.509 obtenida mediante $ openssl x509 in PLATAFORMA.pem text o bien $ openssl x509 in PLATAFORMA.cer inform der text Certificate: Data: Version: 3 (0x2) Serial Number: 37:93:8a:35:58:b4:2f:e9 Signature Algorithm: sha1WithRSAEncryption Issuer: C=ES, O=AC CAMERFIRMA S.A., L=MADRID (Ver en https://www.camerfirma.com/address), OU=AC CAMERFIRMA/serialNumber=A82743287, CN=AC CAMERFIRMA AAPP Validity Not Before: Nov 4 12:44:40 2010 GMT Not After : Nov 3 12:44:40 2013 GMT Subject: description=Qualified Certificate: AAPPSEPMSWKPSC, CN=PLATAFORMA INTEGRACION/serialNumber=G07896004, OU=sello electr\xF3nico, O=FUNDACI\xD3 IBIT, C=ES Subject Public Key Info: Public Key Algorithm: rsaEncryption PublicKey: (1024 bit) Modulus: 00:de:3b:fe:20:e6:1b:bc:b9:38:30:d3:2c:7b:ea: d4:d6:58:f7:73:6b:6e:e5:f0:4a:e8:f6:28:b4:a4: 7b:7f:53:f1:91:d6:41:90:dc:bf:5e:72:d2:b7:a3: 72:5b:bc:5e:06:a2:6b:65:a2:67:22:c4:38:1d:07: 13:10:43:76:1f:9d:03:ae:86:fe:f9:64:46:34:a5: 3b:9e:27:33:2d:6e:1b:64:8d:1d:27:58:56:f7:f6: db:1a:cc:4a:f3:c8:fb:61:09:00:33:71:de:13:79: 1b:9f:b3:fb:4c:66:f7:fc:80:c2:d8:39:88:7d:2f: 46:0e:ab:d7:b3:e2:f3:a9:c7 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: critical CA:FALSE 17 de 61 X509v3 Key Usage: critical Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment X509v3 Extended Key Usage: TLS Web Client Authentication, Email Protection X509v3 Subject Key Identifier: EA:41:E9:3B:F7:BC:6A:12:DD:A1:2A:5A:40:A5:8F:22:82:A7:A2:ED Authority Information Access: CA Issuers URI:http://www.camerfirma.com/certs/AC_CAMERFIRMA_AAPP.crt OCSP URI:http://ocsp.camerfirma.com X509v3 Authority Key Identifier: keyid:E5:46:50:E8:43:A0:B2:F7:1C:E4:B6:FF:D8:00:04:20:F7:1F:A4:0B DirName:/C=EU/O=AC Camerfirma SA CIF A82743287/OU=http://www.chambersign.org/CN=Chambers of Commerce Root serial:0D X509v3 CRL Distribution Points: Full Name: URI:http://crl.camerfirma.com/AC_CAMERFIRMA_AAPP.crl Full Name: URI:http://crl1.camerfirma.com/AC_CAMERFIRMA_AAPP.crl X509v3 Subject Alternative Name: DirName:/2.16.724.1.3.5.2.1.1=sello electr\xC3\xB3nico/2.16.724.1.3.5.2.1.2=FUNDACI\xC3\x93 IBIT/2.16.724.1.3.5.2.1.3=G07896004/2.16.724.1.3.5.2.1.5=PLATAFORMA INTEGRACION X509v3 Issuer Alternative Name: email:[email protected] X509v3 Certificate Policies: Policy: 1.3.6.1.4.1.17326.1.3.3.2 CPS: https://policy.camerfirma.com User Notice: Explicit Text: Certificado reconocido de sello electrónico de Administración, órgano o entidad de derecho público, nivel Medio. Consulte condiciones de uso en https://policy.camerfirma.com qcStatements: 0.0......F..0......F..... Signature Algorithm: sha1WithRSAEncryption be:99:d4:dc:ac:c1:95:9a:4f:8b:0c:2e:cf:dc:6c:20:d9:ad: 7f:8f:da:a9:7e:67:4e:d9:ac:90:14:db:25:0a:3b:d9:19:90: f7:83:c6:e0:75:bb:b4:a1:b1:fa:fb:87:f0:33:15:5e:b0:9a: 74:32:86:69:92:d3:ab:04:ad:4b:aa:39:09:59:3e:2b:78:bf: 9d:5a:95:e7:2d:03:05:db:bf:5d:1c:9c:52:84:b7:71:13:58: 50:f9:af:c4:0e:64:e5:19:5b:ba:eb:b7:aa:c4:6c:7e:42:eb: bc:20:43:da:5e:17:f1:51:f5:e4:b9:1b:0b:87:38:5d:d6:96: 34:d2:64:9b:03:7e:1e:bf:b5:c1:72:a3:ed:04:4d:5d:57:5d: 8e:f6:e5:25:29:d9:0a:54:36:a9:71:d3:fc:f7:5c:c8:68:97: 24:41:4c:a3:e3:8f:82:0f:94:d1:45:5f:ea:3e:f0:bc:80:84: b4:a3:34:db:9a:04:ec:04:7f:e6:fe:39:77:e2:0a:3b:29:aa: 84:19:da:88:9d:e6:c6:3d:7d:d5:f5:a7:87:5a:a3:99:24:10: fe:5d:cf:3e:1c:d0:f4:c3:7d:6f:15:28:71:13:c2:9f:6a:7c: e6:2a:37:65:d5:0f:52:1f:56:72:f5:9a:d0:ed:6c:8f:4a:e8: d1:21:78:71 BEGIN CERTIFICATE MIIHUjCCBjqgAwIBAgIIN5OKNVi0L+kwDQYJKoZIhvcNAQEFBQAwgbAxCzAJBgNV BAYTAkVTMRswGQYDVQQKExJBQyBDQU1FUkZJUk1BIFMuQS4xOzA5BgNVBAcTMk1B RFJJRCAoVmVyIGVuIGh0dHBzOi8vd3d3LmNhbWVyZmlybWEuY29tL2FkZHJlc3Mp MRYwFAYDVQQLEw1BQyBDQU1FUkZJUk1BMRIwEAYDVQQFEwlBODI3NDMyODcxGzAZ BgNVBAMTEkFDIENBTUVSRklSTUEgQUFQUDAeFw0xMDExMDQxMjQ0NDBaFw0xMzEx MDMxMjQ0NDBaMIGqMTIwMAYDVQQNEylRdWFsaWZpZWQgQ2VydGlmaWNhdGU6IEFB UFAtU0VQLU0tU1ctS1BTQzEfMB0GA1UEAxMWUExBVEFGT1JNQSBJTlRFR1JBQ0lP TjESMBAGA1UEBRMJRzA3ODk2MDA0MRowGAYDVQQLFBFzZWxsbyBlbGVjdHLzbmlj bzEWMBQGA1UEChQNRlVOREFDSdMgSUJJVDELMAkGA1UEBhMCRVMwgZ8wDQYJKoZI hvcNAQEBBQADgY0AMIGJAoGBAN47/iDmG7y5ODDTLHvq1NZY93NrbuXwSuj2KLSk e39T8ZHWQZDcv15y0rejclu8Xgaia2WiZyLEOB0HExBDdh+dA66G/vlkRjSlO54n My1uG2SNHSdYVvf22xrMSvPI+2EJADNx3hN5G5+z+0xm9/yAwtg5iH0vRg6r17Pi 86nHAgMBAAGjggP2MIID8jAMBgNVHRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIE8DAd 18 de 61 BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFOpB6Tv3vGoS 3aEqWkCljyKCp6LtMHoGCCsGAQUFBwEBBG4wbDBCBggrBgEFBQcwAoY2aHR0cDov L3d3dy5jYW1lcmZpcm1hLmNvbS9jZXJ0cy9BQ19DQU1FUkZJUk1BX0FBUFAuY3J0 MCYGCCsGAQUFBzABhhpodHRwOi8vb2NzcC5jYW1lcmZpcm1hLmNvbTCBqwYDVR0j BIGjMIGggBTlRlDoQ6Cy9xzktv/YAAQg9x+kC6GBhKSBgTB/MQswCQYDVQQGEwJF VTEnMCUGA1UEChMeQUMgQ2FtZXJmaXJtYSBTQSBDSUYgQTgyNzQzMjg3MSMwIQYD VQQLExpodHRwOi8vd3d3LmNoYW1iZXJzaWduLm9yZzEiMCAGA1UEAxMZQ2hhbWJl cnMgb2YgQ29tbWVyY2UgUm9vdIIBDTB6BgNVHR8EczBxMDagNKAyhjBodHRwOi8v Y3JsLmNhbWVyZmlybWEuY29tL0FDX0NBTUVSRklSTUFfQUFQUC5jcmwwN6A1oDOG MWh0dHA6Ly9jcmwxLmNhbWVyZmlybWEuY29tL0FDX0NBTUVSRklSTUFfQUFQUC5j cmwwgZQGA1UdEQSBjDCBiaSBhjCBgzEhMB8GCWCFVAEDBQIBAQwSc2VsbG8gZWxl Y3Ryw7NuaWNvMR0wGwYJYIVUAQMFAgECDA5GVU5EQUNJw5MgSUJJVDEYMBYGCWCF VAEDBQIBAwwJRzA3ODk2MDA0MSUwIwYJYIVUAQMFAgEFDBZQTEFUQUZPUk1BIElO VEVHUkFDSU9OMCEGA1UdEgQaMBiBFnNvcG9ydGVAY2FtZXJmaXJtYS5jb20wggEL BgNVHSAEggECMIH/MIH8BgwrBgEEAYGHLgEDAwIwgeswKQYIKwYBBQUHAgEWHWh0 dHBzOi8vcG9saWN5LmNhbWVyZmlybWEuY29tMIG9BggrBgEFBQcCAjCBsBqBrUNl cnRpZmljYWRvIHJlY29ub2NpZG8gZGUgc2VsbG8gZWxlY3Ry825pY28gZGUgQWRt aW5pc3RyYWNp824sIPNyZ2FubyBvIGVudGlkYWQgZGUgZGVyZWNobyBw+mJsaWNv LCBuaXZlbCBNZWRpby4gQ29uc3VsdGUgY29uZGljaW9uZXMgZGUgdXNvIGVuIGh0 dHBzOi8vcG9saWN5LmNhbWVyZmlybWEuY29tMCUGCCsGAQUFBwEDBBkwFzAIBgYE AI5GAQEwCwYGBACORgEDAgEPMA0GCSqGSIb3DQEBBQUAA4IBAQC+mdTcrMGVmk+L DC7P3Gwg2a1/j9qpfmdO2ayQFNslCjvZGZD3g8bgdbu0obH6+4fwMxVesJp0MoZp ktOrBK1LqjkJWT4reL+dWpXnLQMF279dHJxShLdxE1hQ+a/EDmTlGVu667eqxGx+ Quu8IEPaXhfxUfXkuRsLhzhd1pY00mSbA34ev7XBcqPtBE1dV12O9uUlKdkKVDap cdP891zIaJckQUyj44+CD5TRRV/qPvC8gIS0ozTbmgTsBH/m/jl34go7KaqEGdqI nebGPX3V9aeHWqOZJBD+Xc8+HND0w31vFShxE8KfanzmKjdl1Q9SH1Zy9ZrQ7WyP SujRIXhx END CERTIFICATE Creación de un certificado digital El punto de partida para la obtención de un certificado digital es la disposición de un par de claves de cifrado asimétrico: $ openssl genrsa out my.key 1024 Una vez obtenidas las claves, el interesado debe crear a partir de ellas una petición de firma de certificado CSR (Certificate Signing Request): $ openssl req out my.csr key my.key new $ openssl req in my.csr text verify noout verify OK Certificate Request: Data: Version: 0 (0x0) Subject: C=EU, ST=Balears, L=Palma, O=Internet Widgits Pty Ltd, OU=OTAE, CN=ADMINISTRACION ELECTRONICA/[email protected] Subject Public Key Info: Public Key Algorithm: rsaEncryption PublicKey: (1024 bit) Modulus: 00:9d:4b:3d:79:d2:d1:df:59:f7:24:9c:b9:92:0d: 46:ae:c0:69:53:46:1e:0b:20:1c:84:b3:5b:3c:7e: 96:fa:25:91:27:98:13:63:0a:53:95:c2:75:fd:6c: c4:7c:47:1f:d5:85:63:7e:33:72:16:ed:40:d7:35: a6:1e:c7:02:aa:77:c7:bf:27:ab:c4:19:f6:9b:fc: 2f:6c:6d:58:cf:5b:61:eb:a7:15:40:56:b7:4c:9e: 19 de 61 c3:01:7b:3b:34:fc:d2:aa:d8:16:b5:94:7f:da:49: dc:94:59:8e:c7:38:ae:0a:50:27:38:16:00:de:2a: a6:30:f3:b8:4d:a4:1f:9b:f3 Exponent: 65537 (0x10001) Attributes: a0:00 Signature Algorithm: sha1WithRSAEncryption 31:bc:8f:0e:f9:e7:5e:52:75:ad:22:dc:5c:8b:12:4f:65:44: fe:fc:a6:0e:d8:e8:b2:e9:5c:3a:68:98:7e:a0:83:65:8c:b6: 05:84:bc:8c:ce:bb:13:85:0b:c9:18:ac:30:78:79:a3:f3:9c: a5:e0:44:e7:03:1f:25:2a:0b:b2:72:e5:e3:ef:f9:5f:e7:0d: 83:db:d3:82:33:b3:b7:33:0e:94:dc:5b:47:2d:47:26:df:3a: 50:b2:2a:46:b8:bf:df:28:9d:d9:74:42:9b:ad:2e:84:65:a5: 0b:1d:0a:0c:39:8e:23:cf:81:de:a6:b2:36:64:fa:57:83:8b: d8:da Como se puede observar, se trata de una estructura de datos que contiene la clave pública generada por el interesado y la identidad en formato DN (Nombre Distinguido) del sujeto que se pretende asociar a la clave pública. Esta petición se firma con la clave privada asociada a la clave pública y se entrega a una autoridad certificadora (CA) o una autoridad de registro (RA). Porque se firma la CSR? Para emitir un certificado digital, la CA o RA necesita comprobar la identidad del sujeto (persona o entidad) que se pretende asociar a una clave pública. En el caso de una persona, esta comprobación se suele realizar de forma presencial y mediante un documento de identidad. Una vez comprobada la identidad del sujeto, la CA obtiene de la CSR la clave pública y el DN del sujeto en cuestión. Con estos datos, la CA creará una nueva estructura de datos incorporando un número de serie propio de la CA y otros atributos en función de las necesidades del interesado: validez temporal, usos, etc... Finalmente, la CA firma la estructura de datos resultante y la entrega como un certificado digital al interesado. Pueden existir diferentes certificados con la misma clave pública? Pueden existir diferentes certificados con la misma clave pública y con diferentes Subject? Pueden existir diferentes certificados con la misma clave pública y un mismo Subject? Pueden existir diferentes certificados con la misma clave pública y un mismo Issuer? Creación de un certificado digital autofirmado Un certificado digital para el cual el sujeto asociado a la clave pública coincide con el organismo o entidad que respalda el certificado se denomina certificado digital autofirmado. En este caso desaparece la función principal de una autoridad certificadora: certificar la asociación entre una clave pública y una persona o entidad. Así, en lugar de confiar en una CA, el usuario del certificado confía en el creador del certificado. Un certificado autofirmado ofrece PRIVACIDAD pero solo ofrece AUTENTICIDAD si se conoce el Subject del certificado o se confía en el creador del certificado. Por ello, la utilización de certificados autofirmados es apropiada en entornos de desarrollo, en conexiones SSL que solo requieren privacidad y en cadenas de certificación en cuyo caso actúan como certificados raíz. Con respecto a esto último, se puede pensar que un certificado raíz siempre es un certificado autofirmado. En cambio, un certificado autofirmado no tiene porque ser un certificado raíz: cuando no se utiliza para firmar otros certificados. Ejemplo: 20 de 61 $ openssl req x509 days 365 newkey rsa:2048 keyout private.key out certificado.crt nodes $ openssl x509 in certificado.crt text noout Certificate: Data: Version: 3 (0x2) Serial Number: 8a:a3:3c:a0:86:ab:b3:46 Signature Algorithm: sha1WithRSAEncryption Issuer: C=EU, ST=Balears, L=Palma, O=Internet Widgits Pty Ltd, OU=OTAE, CN=ADMINISTRACION ELECTRONICA/[email protected] Validity Not Before: Nov 28 07:11:45 2013 GMT Not After : Nov 28 07:11:45 2014 GMT Subject: C=EU, ST=Balears, L=Palma, O=Internet Widgits Pty Ltd, OU=OTAE, CN=ADMINISTRACION ELECTRONICA/[email protected] Subject Public Key Info: Public Key Algorithm: rsaEncryption PublicKey: (2048 bit) Modulus: 00:92:e0:5a:44:32:00:5b:a6:35:b1:a6:ca:0b:25: 06:94:94:f6:99:92:d5:e3:c1:52:2f:f2:17:e3:7e: c1:a8:1a:e7:c5:8a:19:29:2b:2c:40:7b:c8:4c:be: c9:74:33:a4:45:d4:3b:9c:73:ca:90:8f:20:34:4a: ec:0e:ff:ef:7f:c7:78:8c:92:e0:35:2d:b3:23:fe: c3:d1:5e:68:89:fd:3a:62:81:35:e1:4e:55:ec:d4: 51:f6:21:f3:ab:07:0a:86:40:37:f1:5e:22:67:05: 29:01:a2:9d:56:94:21:4e:c0:63:56:4d:85:70:40: 28:b5:6f:fb:be:a2:41:b6:ca:a4:e4:d1:66:da:06: ef:a0:8f:63:cc:83:c8:a8:26:6e:b2:fa:f1:a2:7e: cb:42:36:ab:fd:ef:e4:af:01:f7:b9:b7:b7:a8:80: b3:0f:8a:f1:dd:78:fc:c5:4a:37:60:2c:bb:71:83: 78:60:eb:2f:b1:d8:c0:d9:ee:d0:b1:20:3c:6a:e3: 0f:96:ff:9d:6b:16:e7:46:f6:06:96:cc:03:96:7b: bd:58:96:e5:9d:98:4c:88:60:b6:3d:d6:c8:db:44: 35:e5:35:bb:e1:39:9a:dd:91:c0:cd:22:cc:9f:cc: 01:90:2f:95:cd:11:7b:b4:ba:80:f2:a0:62:06:ce: c8:e5 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Subject Key Identifier: 46:83:16:FF:99:44:11:74:58:6A:0B:E6:48:8C:04:7B:A8:53:9F:E8 X509v3 Authority Key Identifier: keyid:46:83:16:FF:99:44:11:74:58:6A:0B:E6:48:8C:04:7B:A8:53:9F:E8 X509v3 Basic Constraints: CA:TRUE Signature Algorithm: sha1WithRSAEncryption 70:7f:05:8c:eb:0b:19:e4:30:fe:50:84:ba:82:10:45:be:d3: 26:11:c0:66:1d:be:c5:08:2b:7c:d5:e2:42:12:68:e7:d3:d2: a7:a9:5a:8b:39:23:76:b7:ae:3c:0c:3f:9c:7f:de:02:3c:03: a2:52:f0:1c:da:17:37:d5:a8:74:c7:b6:57:4e:1f:56:89:97: 27:ec:b4:12:2a:5a:ce:c6:c9:3b:9f:94:f0:15:84:34:23:b6: 3f:e7:c1:92:b3:71:de:c9:f6:fa:25:12:d3:8a:9b:91:7e:c2: f9:9d:fa:75:45:b5:7e:08:89:07:98:8c:11:b1:3e:99:1f:d3: d9:7c:2a:22:4b:95:ee:9b:2b:04:61:4a:46:9d:e5:09:d8:d9: 57:ec:d5:53:14:de:cb:8a:94:9f:4e:a6:e5:6f:bf:4b:61:fc: c9:72:74:60:82:dd:50:60:5b:a4:17:a3:45:cf:71:d5:02:6c: 34:5a:85:55:ae:9c:40:bc:36:57:07:6e:cc:ac:e0:24:ad:46: 4c:14:c6:f6:47:77:e2:1e:50:9a:19:49:20:5d:79:52:60:8c: 9b:5c:95:31:ca:cf:de:7b:a3:e6:f6:7e:00:54:ac:41:52:85: ce:f2:03:f5:8d:1f:17:7d:86:ba:d4:f8:ce:91:ed:bf:80:29: 7a:fd:af:43 21 de 61 Revocación Además de criterios basados en los mismos atributos del certificado (período de validez, usos, etc...) un certificado puede ser invalidado por otros motivos: el compromiso de la clave privada asociada al certificado, el cese de actividad del Subject del certificado, etc... Como ejemplo, un certificado puede estar revocado sin haber caducado o puede haber caducado sin estar revocado. Forma parte de la validación de un certificado digital la comprobación de su estado de revocación. Para comprobar el estado de revocación de un certificado se utilizan dos mecanismos: listas de revocación o un protocolo en línea. Lista de certificados revocados Una lista de certificados revocados (CRL) es una lista de certificados digitales que son considerados no válidos por la autoridad certificadora (CA) que emitió los certificados contenidos en esta lista. Esta lista la publica y firma periódicamente la misma CA que creó los certificados. Las listas de revocación se suelen distribuir según un modelo push (envío no solicitado por el cliente) o pull (envío solicitado por el cliente). Para sincronizar con posibles validaciones de certificados, cada CRL especifica su fecha de publicación y la fecha de su próxima publicación. Ejemplo: $ wget http://crl.camerfirma.com/AC_CAMERFIRMA_AAPP.crl $ openssl crl inform der text noout in AC_CAMERFIRMA_AAPP.crl Certificate Revocation List (CRL): Version 2 (0x1) Signature Algorithm: md5WithRSAEncryption Issuer: /C=ES/O=AC CAMERFIRMA S.A./L=MADRID (Ver en https://www.camerfirma.com/address)/OU=AC CAMERFIRMA/serialNumber=A82743287/CN=AC CAMERFIRMA AAPP Last Update: Nov 25 10:56:10 2013 GMT Next Update: Nov 27 10:56:10 2013 GMT CRL extensions: X509v3 Authority Key Identifier: keyid:E5:46:50:E8:43:A0:B2:F7:1C:E4:B6:FF:D8:00:04:20:F7:1F:A4:0B DirName:/C=EU/O=AC Camerfirma SA CIF A82743287/OU=http://www.chambersign.org/CN=Chambers of Commerce Root serial:0D X509v3 CRL Number: 3410 Revoked Certificates: Serial Number: A71D0D37DF454B Revocation Date: Jul 26 10:57:00 2011 GMT CRL entry extensions: X509v3 CRL Reason Code: Cessation Of Operation Serial Number: 0369E6EC8DC8A99F Revocation Date: Jan 23 08:41:08 2012 GMT CRL entry extensions: X509v3 CRL Reason Code: Affiliation Changed Serial Number: FFAFA22F155E5F2D Revocation Date: Sep 19 11:57:06 2011 GMT CRL entry extensions: X509v3 CRL Reason Code: Unspecified Serial Number: FFB8E24406495F69 Revocation Date: Sep 23 06:11:01 2013 GMT CRL entry extensions: X509v3 CRL Reason Code: 22 de 61 Superseded Signature Algorithm: md5WithRSAEncryption 7e:e1:5b:b0:6c:dd:45:a6:ab:03:f2:37:5b:1e:2d:5c:32:fa: b6:96:74:23:a4:1c:3e:ca:2d:18:05:56:6c:c0:99:ca:ca:cb: fa:1f:1b:2b:cb:62:ea:ed:ec:1a:08:8c:a8:c2:42:8e:bd:be: ac:e5:bb:6f:32:d3:d0:b3:a4:e5:71:39:57:d0:36:9f:d2:dd: 78:92:9a:b6:fa:45:57:ad:cb:6e:4d:dd:fd:82:66:66:24:8a: ab:ca:35:54:f7:cc:0d:b1:02:2e:25:01:81:64:34:37:df:42: 34:14:5b:19:d5:49:0b:99:bf:f9:5c:1a:b1:c3:63:f2:d1:b4: 38:86:6f:ee:7c:17:c3:c7:9c:a7:1a:36:7f:3d:56:d7:46:0f: 6d:ca:f1:d0:c1:d5:d7:b1:41:fe:ae:1e:04:0d:84:e7:4a:48: 1d:2c:6f:91:81:1b:dc:a0:18:58:9e:61:43:8e:dd:0a:7a:61: 24:64:b7:ce:16:9c:fc:15:02:05:bd:62:c4:87:20:d8:8f:a9: 0d:a5:72:cf:01:89:c7:7e:4d:15:8a:13:b1:f9:67:70:48:49: 65:a7:5e:a6:ba:c9:3c:97:2e:ec:9c:65:6a:5a:fc:df:0b:56: 11:71:e6:4a:ea:18:a8:b7:36:b6:19:7d:7a:0d:cc:0c:83:e1: a2:62:d9:00 Protocolo de estado de certificado en línea Una lista de certificados revocados presenta dos potenciales inconvenientes: la actualidad de la información y la cantidad de datos que contiene. Para mitigar estos inconvenientes se creó el protocolo OCSP (Online Certificate Status Protocol) que responde en tiempo real a peticiones puntuales sobre el estado de revocación de un determinado certificado digital. Los mensajes enviados mediante OCSP se transmiten típicamente sobre HTTP. Si la autoridad certificadora soporta OCSP, los certificados emitidos por ella pueden contener un atributo denominado authorityInfoAccess el cual especificará el punto de acceso (URL) al servidor (responder) que atiende a las peticiones de estado de revocación. Las respuestas de un responder están firmadas por la CA que emitió el certificado en cuestión o por un responder delegado por la CA. Obtener una respuesta OCSP requiere tiempo de conexión. Si se realizan o se validan firmas en modo batch y se precisa obtener datos de validación para cada firma, resulta más eficiente obtener una CRL en lugar de una respuesta OCSP por cada certificado. Tres son las posibles respuestas OCSP sobre el estado de un certificado digital: good, revoked o unknown. Las implementaciones de un responder OCSP suelen estar respaldadas por un proceso de generación de listas de revocación. Esto es, el responder genera las respuestas en base al contenido de una CRL. Así, una respuesta good no garantiza la existencia de un certificado digital (como requiere la legislación de algunos países para la validación de un certificado digital). Ejemplo: $ wget http://www.camerfirma.com/certs/AC_CAMERFIRMA_AAPP.crt $ openssl x509 inform der in AC_CAMERFIRMA_AAPP.crt out AC_CAMERFIRMA_AAPP.pem $ openssl ocsp issuer AC_CAMERFIRMA_AAPP.pem cert PLATAFORMA_INTEROPERABILIDAD.pem url http://ocsp.camerfirma.com/ noverify resp_text respout resp.der OCSP Response Data: OCSP Response Status: successful (0x0) Response Type: Basic OCSP Response Version: 1 (0x0) Responder Id: C = ES, O = AC Camerfirma SA, CN = OCSP Responder AC CAMERFIRMA AAPP, emailAddress = [email protected], serialNumber = A82743287 Produced At: Nov 25 11:43:17 2013 GMT Responses: Certificate ID: Hash Algorithm: sha1 Issuer Name Hash: E8200C085A817BCEEACCC11FB40223527C8E5411 Issuer Key Hash: E54650E843A0B2F71CE4B6FFD8000420F71FA40B Serial Number: 37938A3558B42FE9 Cert Status: good This Update: Nov 25 11:43:17 2013 GMT 23 de 61 Response Extensions: OCSP Nonce: 041092443D21613A5187F26BB728CB5B9ED1 Signature Algorithm: sha1WithRSAEncryption 4d:36:a6:72:4f:b8:20:9f:94:f6:d5:14:38:15:94:cf:ce:9a: d6:53:64:ca:d0:51:7b:d4:4d:44:ab:63:e5:f1:ed:ee:af:9a: 9e:2e:7d:ef:a4:78:fe:32:55:c3:f3:a8:7a:6e:4a:2a:e7:d1: 8e:39:e3:d5:33:df:3f:2a:c5:f5:7d:0e:28:8d:4a:58:ad:7f: 43:4e:f0:35:6c:29:6f:e0:d5:24:76:08:9f:e5:4e:c2:d9:6e: 9c:4d:10:5e:63:e4:95:bf:77:a4:0a:1b:7c:03:0d:d3:f0:f1: 82:e0:02:01:e3:64:d9:40:c1:47:ed:61:6d:07:9c:87:46:31: e0:1d:ba:58:48:ec:f8:e7:1a:2d:33:69:90:e0:d6:8b:21:6e: 1a:c4:ce:0c:3b:86:a8:e7:d5:97:d7:6c:71:38:a5:81:60:23: 64:4b:8a:30:7e:0c:ab:d3:31:83:43:e5:55:d5:76:6f:4a:c2: e3:8c:50:a3:00:2b:8c:6b:a6:d8:55:c5:55:dd:ce:96:10:4b: a0:49:45:a1:76:78:15:74:35:8b:e6:ab:13:16:ba:97:61:0b: 4b:1d:bd:39:5f:29:7c:38:ba:fb:4a:4f:64:0a:9d:3c:e8:b6: 4a:38:f8:b1:6a:2e:0b:f5:a2:30:3f:4e:21:d0:65:d3:f9:e5: eb:e4:17:d1 Certificate: Data: Version: 3 (0x2) Serial Number: 11:cc:bb:cc:bb:00:14:58 Signature Algorithm: sha1WithRSAEncryption Issuer: C=ES, O=AC CAMERFIRMA S.A., L=MADRID (Ver en https://www.camerfirma.com/address), OU=AC CAMERFIRMA/serialNumber=A82743287, CN=AC CAMERFIRMA AAPP Validity Not Before: Dec 5 10:07:14 2012 GMT Not After : Dec 5 10:07:14 2014 GMT Subject: C=ES, O=AC Camerfirma SA, CN=OCSP Responder AC CAMERFIRMA AAPP/[email protected]/serialNumber=A82743287 Subject Public Key Info: Public Key Algorithm: rsaEncryption PublicKey: (2048 bit) Modulus: 00:a8:39:b3:15:90:c0:9f:5b:c6:a2:6c:5b:0b:e0: 0f:e8:ef:e3:9a:e1:7e:9c:25:aa:83:e6:00:4e:76: ba:a0:0b:14:b4:56:9d:93:8d:8c:be:3f:3f:d3:36: 17:6d:d3:44:c5:b5:88:b1:85:05:8f:6d:45:8e:fc: 1c:cf:83:18:b1:d8:d8:75:c4:7d:db:c7:f1:a5:e6: df:1d:f7:f2:7f:e5:a5:35:23:18:1a:64:bf:6f:a5: c0:c8:28:ef:e5:c5:6d:dd:71:d2:f1:fa:41:7d:1b: 52:95:b5:2e:c8:2a:0c:36:67:c1:08:34:44:4f:76: e1:62:7c:65:70:e0:b8:d6:02:0f:6b:72:9d:90:77: 64:6d:a0:df:71:f2:cd:73:ba:61:ad:c0:be:b2:f7: 30:5a:ad:3f:b3:2b:ca:ff:d9:92:4e:71:c9:c5:4c: c0:bf:79:aa:af:70:87:b4:ef:f9:88:50:8d:f4:ba: 17:5a:81:3b:5b:a7:7b:f3:1c:ea:c8:4d:53:ae:80: cc:87:94:2b:76:95:b8:e9:0b:04:dc:c7:d4:c7:bb: 9b:dd:49:63:d9:f2:4a:d4:e4:f2:5b:ec:2c:46:8f: 17:b8:45:59:dd:3b:9a:ac:2a:37:06:70:26:d8:50: d4:79:a3:36:63:9e:d8:f1:0b:12:8d:6e:82:5c:bb: e9:cf Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: CA:FALSE X509v3 Key Usage: critical Digital Signature, Non Repudiation, Key Encipherment X509v3 Extended Key Usage: OCSP Signing X509v3 Subject Key Identifier: 55:BF:1D:62:97:B9:36:39:D0:75:B1:8E:DB:32:33:17:C9:C7:22:81 24 de 61 X509v3 Authority Key Identifier: keyid:E5:46:50:E8:43:A0:B2:F7:1C:E4:B6:FF:D8:00:04:20:F7:1F:A4:0B DirName:/C=EU/O=AC Camerfirma SA CIF A82743287/OU=http://www.chambersign.org/CN=Chambers of Commerce Root serial:0D Authority Information Access: CA Issuers URI:http://www.camerfirma.com/certs/AC_CAMERFIRMA_AAPP.crt X509v3 CRL Distribution Points: Full Name: URI:http://crl.camerfirma.com/AC_CAMERFIRMA_AAPP.crl Full Name: URI:http://crl1.camerfirma.com/AC_CAMERFIRMA_AAPP.crl X509v3 Certificate Policies: Policy: 1.3.6.1.4.1.17326.10.9.8 CPS: https://policy.camerfirma.com Signature Algorithm: sha1WithRSAEncryption 83:de:a9:ed:d3:96:14:9a:e9:18:84:c8:ac:d6:5b:b1:0f:34: 5d:ec:6a:2e:74:30:f2:c6:c4:fc:7e:fa:3c:1e:84:ff:90:25: 10:3c:24:ce:ce:70:38:0a:3d:ba:1d:78:e9:f6:5d:54:60:35: 1d:9d:6a:72:32:15:57:ea:6f:89:74:f4:6e:ff:a5:81:9e:42: 95:f4:f8:b2:b1:2a:ad:81:16:8d:47:0a:3e:87:91:af:64:e9: b4:9f:e8:f4:c7:29:b4:74:b6:af:31:28:93:cd:11:37:c6:ec: f1:45:55:f0:20:46:ae:a0:bf:bf:4c:9e:aa:d0:c3:29:10:37: 5f:8d:e5:09:f5:d5:b4:4e:e6:88:72:a8:d7:68:6f:a6:b9:df: 17:3e:cd:2e:a3:d4:a4:94:b2:6f:ef:08:cb:1b:24:fc:f7:e5: de:4c:c2:b9:8b:24:0c:73:e0:4c:e5:4d:e0:e4:b1:51:63:7d: 66:f0:cd:62:5d:c4:14:4d:f5:06:62:71:6a:7b:d8:22:3f:e5: 5e:41:f4:b3:a4:8b:e7:29:c0:cc:ee:73:e9:49:82:27:be:46: 1d:90:10:30:16:9a:b4:61:32:e8:28:84:4a:92:12:55:c9:6a: 20:d5:2c:60:3d:df:db:41:73:be:12:b3:10:1f:a3:0f:22:b3: bf:60:f1:c4 BEGIN CERTIFICATE MIIF3DCCBMSgAwIBAgIIEcy7zLsAFFgwDQYJKoZIhvcNAQEFBQAwgbAxCzAJBgNV BAYTAkVTMRswGQYDVQQKExJBQyBDQU1FUkZJUk1BIFMuQS4xOzA5BgNVBAcTMk1B RFJJRCAoVmVyIGVuIGh0dHBzOi8vd3d3LmNhbWVyZmlybWEuY29tL2FkZHJlc3Mp MRYwFAYDVQQLEw1BQyBDQU1FUkZJUk1BMRIwEAYDVQQFEwlBODI3NDMyODcxGzAZ BgNVBAMTEkFDIENBTUVSRklSTUEgQUFQUDAeFw0xMjEyMDUxMDA3MTRaFw0xNDEy MDUxMDA3MTRaMIGOMQswCQYDVQQGEwJFUzEZMBcGA1UEChMQQUMgQ2FtZXJmaXJt YSBTQTEsMCoGA1UEAxMjT0NTUCBSZXNwb25kZXIgLSBBQyBDQU1FUkZJUk1BIEFB UFAxIjAgBgkqhkiG9w0BCQEWE2luZm9AY2FtZXJmaXJtYS5jb20xEjAQBgNVBAUT CUE4Mjc0MzI4NzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKg5sxWQ wJ9bxqJsWwvgD+jv45rhfpwlqoPmAE52uqALFLRWnZONjL4/P9M2F23TRMW1iLGF BY9tRY78HM+DGLHY2HXEfdvH8aXm3x338n/lpTUjGBpkv2+lwMgo7+XFbd1x0vH6 QX0bUpW1LsgqDDZnwQg0RE924WJ8ZXDguNYCD2tynZB3ZG2g33HyzXO6Ya3AvrL3 MFqtP7Mryv/Zkk5xycVMwL95qq9wh7Tv+YhQjfS6F1qBO1une/Mc6shNU66AzIeU K3aVuOkLBNzH1Me7m91JY9nyStTk8lvsLEaPF7hFWd07mqwqNwZwJthQ1HmjNmOe 2PELEo1ugly76c8CAwEAAaOCAhgwggIUMAkGA1UdEwQCMAAwDgYDVR0PAQH/BAQD AgXgMBMGA1UdJQQMMAoGCCsGAQUFBwMJMB0GA1UdDgQWBBRVvx1il7k2OdB1sY7b MjMXyccigTCBqwYDVR0jBIGjMIGggBTlRlDoQ6Cy9xzktv/YAAQg9x+kC6GBhKSB gTB/MQswCQYDVQQGEwJFVTEnMCUGA1UEChMeQUMgQ2FtZXJmaXJtYSBTQSBDSUYg QTgyNzQzMjg3MSMwIQYDVQQLExpodHRwOi8vd3d3LmNoYW1iZXJzaWduLm9yZzEi MCAGA1UEAxMZQ2hhbWJlcnMgb2YgQ29tbWVyY2UgUm9vdIIBDTBSBggrBgEFBQcB AQRGMEQwQgYIKwYBBQUHMAKGNmh0dHA6Ly93d3cuY2FtZXJmaXJtYS5jb20vY2Vy dHMvQUNfQ0FNRVJGSVJNQV9BQVBQLmNydDB6BgNVHR8EczBxMDagNKAyhjBodHRw Oi8vY3JsLmNhbWVyZmlybWEuY29tL0FDX0NBTUVSRklSTUFfQUFQUC5jcmwwN6A1 oDOGMWh0dHA6Ly9jcmwxLmNhbWVyZmlybWEuY29tL0FDX0NBTUVSRklSTUFfQUFQ UC5jcmwwRQYDVR0gBD4wPDA6BgsrBgEEAYGHLgoJCDArMCkGCCsGAQUFBwIBFh1o dHRwczovL3BvbGljeS5jYW1lcmZpcm1hLmNvbTANBgkqhkiG9w0BAQUFAAOCAQEA 25 de 61 g96p7dOWFJrpGITIrNZbsQ80XexqLnQw8sbE/H76PB6E/5AlEDwkzs5wOAo9uh14 6fZdVGA1HZ1qcjIVV+pviXT0bv+lgZ5ClfT4srEqrYEWjUcKPoeRr2TptJ/o9Mcp tHS2rzEok80RN8bs8UVV8CBGrqC/v0yeqtDDKRA3X43lCfXVtE7miHKo12hvprnf Fz7NLqPUpJSyb+8Iyxsk/Pfl3kzCuYskDHPgTOVN4OSxUWN9ZvDNYl3EFE31BmJx anvYIj/lXkH0s6SL5ynAzO5z6UmCJ75GHZAQMBaatGEy6CiESpISVclqINUsYD3f 20FzvhKzEB+jDyKzv2DxxA== END CERTIFICATE PLATAFORMA_INTEROPERABILIDAD.pem: good This Update: Nov 25 11:43:17 2013 GMT Para volver a explorar la respuesta: $ openssl ocsp respin resp.der noverify text Validación La validación de un certificado digital depende de los requisitos de cada aplicación. En general, un certificado digital es considerado valido cuando es posible construir y validar un camino de certificación. • Camino de certificación En su forma más simple, un camino de certificación es una secuencia de n certificados donde: • – para todo x en {1 ... n-1}, el Subject del certificado x es el Issuer del certificado x+1 – para x=1 se tiene el certificado raíz (autofirmado) – para x=n se tiene el certificado del usuario o de la entidad Validación de un camino de certificación En su forma más básica, un procedimiento de validación realiza las siguientes tareas de comprobación para cada certificado de un camino de certificación: ◦ uso válido del certificado ◦ estado de revocación del certificado ◦ período de validez del certificado 26 de 61 ◦ el Issuer del certificado es el Subject del certificado anterior en el camino de certificación ◦ el certificado fue firmado con el certificado anterior en el camino de certificación Para el primer certificado (raíz), se omite esta última tarea o se comprueba que el certificado está autofirmado. El camino de validación puede acortarse en aquella entidad certificadora que resulte de confianza para ambas partes: la persona o entidad que presenta el certificado y la persona o entidad que comprueba el certificado. Subject Key Identifier Este atributo de un certificado X.509v3 se utiliza junto al atributo Authority Key Identifier para facilitar la construcción de caminos de certificación. El valor del atributo Subject Key Identifier se suele corresponder con el valor hash de la clave pública del mismo certificado. El valor del atributo Authority Key Identifier suele contener el valor hash de la clave pública del certificado anterior en el camino de certificación. Ejemplo: Utilizando pues como referencias los valores hash de las claves públicas, con tres certificados, tenemos el siguiente camino de certificación. Observar que el certificado raíz no contiene un valor para el atributo Authority Key Identifier o si lo contiene, este coincidirá con el valor del atributo Subject Key Identifier del mismo certificado (ver Creación de un certificado digital autofirmado). • • • Certificado Usuario ◦ Subject Key Identifier: EA41E93BF7BC6A12DDA12A5A40A58F2282A7A2ED ◦ Authority Key Identifier: E54650E843A0B2F71CE4B6FFD8000420F71FA40B Certificado CA ◦ Subject Key Identifier: E54650E843A0B2F71CE4B6FFD8000420F71FA40B ◦ Authority Key Identifier: E394F5B14DE9DBA1295B578B4D760676E1D1A28A Certificado raíz ◦ Subject Key Identifier: E394F5B14DE9DBA1295B578B4D760676E1D1A28A ◦ Authority Key Identifier: - Puede haber dos certificados diferentes con el mismo valor Authority Key Identifier? Puede haber dos certificados diferentes con el mismo valor Subject Key Identifier? 27 de 61 A continuación se muestra la obtención del valor hash para el atributo Subject Key Identifier a partir de la clave pública de un certificado. $ openssl rsa pubout in PLATAFORMA.pem writing RSA key BEGIN PUBLIC KEY MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDeO/4g5hu8uTgw0yx76tTWWPdz a27l8Ero9ii0pHt/U/GR1kGQ3L9ectK3o3JbvF4GomtlomcixDgdBxMQQ3YfnQOu hv75ZEY0pTueJzMtbhtkjR0nWFb39tsazErzyPthCQAzcd4TeRufs/tMZvf8gMLY OYh9L0YOq9ez4vOpxwIDAQAB END PUBLIC KEY $ openssl x509 inform der in PLATAFORMA.cer text | grep A 1 'Subject Key Identifier' X509v3 Subject Key Identifier: EA:41:E9:3B:F7:BC:6A:12:DD:A1:2A:5A:40:A5:8F:22:82:A7:A2:ED $ openssl rsa pubout in PLATAFORMA.pem | grep v e 'BEGIN' e 'END' | openssl asn1parse writing RSA key 0:d=0 hl=3 l= 159 cons: SEQUENCE 3:d=1 hl=2 l= 13 cons: SEQUENCE 5:d=2 hl=2 l= 9 prim: OBJECT :rsaEncryption 16:d=2 hl=2 l= 0 prim: NULL 18:d=1 hl=3 l= 141 prim: BIT STRING $ openssl rsa pubout in PLATAFORMA.pem | grep v e 'BEGIN' e 'END' | openssl asn1parse strparse 18 out key.der writing RSA key 0:d=0 hl=3 l= 137 cons: SEQUENCE 3:d=1 hl=3 l= 129 prim: INTEGER :DE3BFE20E61BBCB93830D32C7BEAD4D658F7736B6EE5F04AE8F628B4A47B7F53F191D64190DCBF5E72D2B7A3725BBC5E06A 26B65A26722C4381D07131043761F9D03AE86FEF9644634A53B9E27332D6E1B648D1D275856F7F6DB1ACC4AF3C8FB6109003 371DE13791B9FB3FB4C66F7FC80C2D839887D2F460EABD7B3E2F3A9C7 135:d=1 hl=2 l= 3 prim: INTEGER :010001 $ openssl sha1 key.der SHA1(key.der)= ea41e93bf7bc6a12dda12a5a40a58f2282a7a2ed Verificación Supongamos el siguiente camino de certificación compuesto por tres certificados (contenidos en dos archivos): Archivo PLATAFORMA_CA.pem BEGIN CERTIFICATE MIIEvTCCA6WgAwIBAgIBADANBgkqhkiG9w0BAQUFADB/MQswCQYDVQQGEwJFVTEn MCUGA1UEChMeQUMgQ2FtZXJmaXJtYSBTQSBDSUYgQTgyNzQzMjg3MSMwIQYDVQQL ExpodHRwOi8vd3d3LmNoYW1iZXJzaWduLm9yZzEiMCAGA1UEAxMZQ2hhbWJlcnMg b2YgQ29tbWVyY2UgUm9vdDAeFw0wMzA5MzAxNjEzNDNaFw0zNzA5MzAxNjEzNDRa MH8xCzAJBgNVBAYTAkVVMScwJQYDVQQKEx5BQyBDYW1lcmZpcm1hIFNBIENJRiBB ODI3NDMyODcxIzAhBgNVBAsTGmh0dHA6Ly93d3cuY2hhbWJlcnNpZ24ub3JnMSIw IAYDVQQDExlDaGFtYmVycyBvZiBDb21tZXJjZSBSb290MIIBIDANBgkqhkiG9w0B AQEFAAOCAQ0AMIIBCAKCAQEAtzZV5aVdGDDg2olUkfzIx1L4L1DZ77F1c2VHfRtb unXF/KGIJPov7coISjlUxFF6tdpg6jg8gbLL8bvZkSM/SAFwdakFKq0fcfPJVD0d BmpAPrMMhe5cG3nCYsS4No41XQEMIwRHNaqbYE6gZj3LJgqcQKH0XZi/caulAGgq 7YN6D6IUtdQis4CwPAxaUWktWBiP7Zme8a7ileb2R6jWDA+wWFjbw2Y3npuRVDM3 0pQcakjJyfKl2qUMI/cjDpwyVV5xnIQFUZot/eZOKjRa3spAN2cMVCFVd9oKDMyX roDclDZK9D7ONhMeU+SsTjoF7Nuucpw4i9A5O4kKPnf+dQIBA6OCAUQwggFAMBIG A1UdEwEB/wQIMAYBAf8CAQwwPAYDVR0fBDUwMzAxoC+gLYYraHR0cDovL2NybC5j 28 de 61 aGFtYmVyc2lnbi5vcmcvY2hhbWJlcnNyb290LmNybDAdBgNVHQ4EFgQU45T1sU3p 26EpW1eLTXYGduHRooowDgYDVR0PAQH/BAQDAgEGMBEGCWCGSAGG+EIBAQQEAwIA BzAnBgNVHREEIDAegRxjaGFtYmVyc3Jvb3RAY2hhbWJlcnNpZ24ub3JnMCcGA1Ud EgQgMB6BHGNoYW1iZXJzcm9vdEBjaGFtYmVyc2lnbi5vcmcwWAYDVR0gBFEwTzBN BgsrBgEEAYGHLgoDATA+MDwGCCsGAQUFBwIBFjBodHRwOi8vY3BzLmNoYW1iZXJz aWduLm9yZy9jcHMvY2hhbWJlcnNyb290Lmh0bWwwDQYJKoZIhvcNAQEFBQADggEB AAxBl8IahsAifJ/7kPMa0QOx7xP5IV8EnNrJpY0nbJaHkb5BkAFyk+cefV/2icZd p0AJPaxJRUXcLo0waLIJuvvDL8y6C98/d3tGfToSJI6WjzwFCm/SlCgdbQzALogi 1djPHRPH8EjX1wWnz8dHnjs8NMiAT9QUu/wNUPf6s+xCX6ndbcj0dc97wXImsQEc XCz9ek60AcUFV7nnPKoF2YjpB0ZBzu9Bga5Y34OirsrXdx/nADydb47kMgkdTXg0 eDQ8lJsm7U9xxhl6vSAiSFr+S30Dt+dYvsYyTnQeaN2oaFuzPu5ifdmA6Ap1erfu tGWaIZDgqtCYvDi1czyL+Nw= END CERTIFICATE BEGIN CERTIFICATE MIIGaTCCBVGgAwIBAgIBDTANBgkqhkiG9w0BAQUFADB/MQswCQYDVQQGEwJFVTEn MCUGA1UEChMeQUMgQ2FtZXJmaXJtYSBTQSBDSUYgQTgyNzQzMjg3MSMwIQYDVQQL ExpodHRwOi8vd3d3LmNoYW1iZXJzaWduLm9yZzEiMCAGA1UEAxMZQ2hhbWJlcnMg b2YgQ29tbWVyY2UgUm9vdDAeFw0xMDAyMjMwODQ2MzdaFw0yMjAyMjAwODQ2Mzda MIGwMQswCQYDVQQGEwJFUzEbMBkGA1UEChMSQUMgQ0FNRVJGSVJNQSBTLkEuMTsw OQYDVQQHEzJNQURSSUQgKFZlciBlbiBodHRwczovL3d3dy5jYW1lcmZpcm1hLmNv bS9hZGRyZXNzKTEWMBQGA1UECxMNQUMgQ0FNRVJGSVJNQTESMBAGA1UEBRMJQTgy NzQzMjg3MRswGQYDVQQDExJBQyBDQU1FUkZJUk1BIEFBUFAwggEgMA0GCSqGSIb3 DQEBAQUAA4IBDQAwggEIAoIBAQDcNq5DM3X0DUeai9Ks7lY6iimhIO3vifminrDd lCkoomMhFq7oE9Q6X5lko95+mpClRm/nD1XqBOTa04WAYyvcrGXRH0F6vEIp86ew 3I8CLUtWdeG255m2xcCcSKOreGDdcd/z+UsgdauerhvbJG1CmbAr1oWlmVCvr9zN 2Frn9NvkF/espf8TKkAAXH8za5yuC2i5mTXH6LWxTCm03kfrVJRpU329JdNRRIGj tgj+yTHqig50TDZ9Snu3yKn/s+KwqK9l+wUHIWqgOmEghrYTjzXCGEpPv2TyEAXO hszX3vzNwStgf8Slz9d4H1TfEsUh02bmXb7e8G5UuybNY0vNAgEDo4ICvjCCArow EgYDVR0TAQH/BAgwBgEB/wIBAjBuBgNVHR8EZzBlMDCgLqAshipodHRwOi8vY3Js LmNhbWVyZmlybWEuY29tL2NoYW1iZXJzcm9vdC5jcmwwMaAvoC2GK2h0dHA6Ly9j cmwxLmNhbWVyZmlybWEuY29tL2NoYW1iZXJzcm9vdC5jcmwwHQYDVR0OBBYEFOVG UOhDoLL3HOS2/9gABCD3H6QLMIGrBgNVHSMEgaMwgaCAFOOU9bFN6duhKVtXi012 Bnbh0aKKoYGEpIGBMH8xCzAJBgNVBAYTAkVVMScwJQYDVQQKEx5BQyBDYW1lcmZp cm1hIFNBIENJRiBBODI3NDMyODcxIzAhBgNVBAsTGmh0dHA6Ly93d3cuY2hhbWJl cnNpZ24ub3JnMSIwIAYDVQQDExlDaGFtYmVycyBvZiBDb21tZXJjZSBSb290ggEA MHUGCCsGAQUFBwEBBGkwZzA9BggrBgEFBQcwAoYxaHR0cDovL3d3dy5jYW1lcmZp cm1hLmNvbS9jZXJ0cy9ST09ULUNIQU1CRVJTLmNydDAmBggrBgEFBQcwAYYaaHR0 cDovL29jc3AuY2FtZXJmaXJtYS5jb20wDgYDVR0PAQH/BAQDAgEGMAkGA1UdEQQC MAAwJwYDVR0SBCAwHoEcY2hhbWJlcnNyb290QGNoYW1iZXJzaWduLm9yZzCBqwYD VR0gBIGjMIGgMIGdBgsrBgEEAYGHLgEDATCBjTApBggrBgEFBQcCARYdaHR0cHM6 Ly9wb2xpY3kuY2FtZXJmaXJtYS5jb20wYAYIKwYBBQUHAgIwVBpSQ2VydGlmaWNh ZG8gcmHtei4gQ29uc3VsdGUgbGFzIGNvbmRpY2lvbmVzIGRlIHVzbyBlbiBodHRw czovL3BvbGljeS5jYW1lcmZpcm1hLmNvbTANBgkqhkiG9w0BAQUFAAOCAQEADuar T/NOdigXhtxzdHZQOjpbY8s/ED8oeSGCil8vypvYJhGLQ+NDrlI4wXOm/gPJ+fU3 YUndDiL5Fli2Id4nch+b8pFes5MlXqSVPsEdi4jWYMh73x8bEDTGO+FnzxtgVW+/ g5V9sYIJ3Ir9CtRVBoCj1Z4DUb35hFoBAxHJkj2G5aPoDFNZUCbkTvQKaUFh920J NaDxvjS/Kx+ICG8dsUHofYLZ6ZdC4lxIAtOIgXw5zAkdv757VSq57OTMW3pjNXwH jaOVzuyZe8jNNlW4dpefTN+udKyeoZEEklGgVs2w72Dw4D7ji2xAvhNieH+uwl8X MLVICk48tHn5NpLFng== END CERTIFICATE Archivo PLATAFORMA_CER.pem BEGIN CERTIFICATE MIIHUjCCBjqgAwIBAgIIN5OKNVi0L+kwDQYJKoZIhvcNAQEFBQAwgbAxCzAJBgNV BAYTAkVTMRswGQYDVQQKExJBQyBDQU1FUkZJUk1BIFMuQS4xOzA5BgNVBAcTMk1B RFJJRCAoVmVyIGVuIGh0dHBzOi8vd3d3LmNhbWVyZmlybWEuY29tL2FkZHJlc3Mp MRYwFAYDVQQLEw1BQyBDQU1FUkZJUk1BMRIwEAYDVQQFEwlBODI3NDMyODcxGzAZ BgNVBAMTEkFDIENBTUVSRklSTUEgQUFQUDAeFw0xMDExMDQxMjQ0NDBaFw0xMzEx MDMxMjQ0NDBaMIGqMTIwMAYDVQQNEylRdWFsaWZpZWQgQ2VydGlmaWNhdGU6IEFB UFAtU0VQLU0tU1ctS1BTQzEfMB0GA1UEAxMWUExBVEFGT1JNQSBJTlRFR1JBQ0lP TjESMBAGA1UEBRMJRzA3ODk2MDA0MRowGAYDVQQLFBFzZWxsbyBlbGVjdHLzbmlj bzEWMBQGA1UEChQNRlVOREFDSdMgSUJJVDELMAkGA1UEBhMCRVMwgZ8wDQYJKoZI 29 de 61 hvcNAQEBBQADgY0AMIGJAoGBAN47/iDmG7y5ODDTLHvq1NZY93NrbuXwSuj2KLSk e39T8ZHWQZDcv15y0rejclu8Xgaia2WiZyLEOB0HExBDdh+dA66G/vlkRjSlO54n My1uG2SNHSdYVvf22xrMSvPI+2EJADNx3hN5G5+z+0xm9/yAwtg5iH0vRg6r17Pi 86nHAgMBAAGjggP2MIID8jAMBgNVHRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIE8DAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFOpB6Tv3vGoS 3aEqWkCljyKCp6LtMHoGCCsGAQUFBwEBBG4wbDBCBggrBgEFBQcwAoY2aHR0cDov L3d3dy5jYW1lcmZpcm1hLmNvbS9jZXJ0cy9BQ19DQU1FUkZJUk1BX0FBUFAuY3J0 MCYGCCsGAQUFBzABhhpodHRwOi8vb2NzcC5jYW1lcmZpcm1hLmNvbTCBqwYDVR0j BIGjMIGggBTlRlDoQ6Cy9xzktv/YAAQg9x+kC6GBhKSBgTB/MQswCQYDVQQGEwJF VTEnMCUGA1UEChMeQUMgQ2FtZXJmaXJtYSBTQSBDSUYgQTgyNzQzMjg3MSMwIQYD VQQLExpodHRwOi8vd3d3LmNoYW1iZXJzaWduLm9yZzEiMCAGA1UEAxMZQ2hhbWJl cnMgb2YgQ29tbWVyY2UgUm9vdIIBDTB6BgNVHR8EczBxMDagNKAyhjBodHRwOi8v Y3JsLmNhbWVyZmlybWEuY29tL0FDX0NBTUVSRklSTUFfQUFQUC5jcmwwN6A1oDOG MWh0dHA6Ly9jcmwxLmNhbWVyZmlybWEuY29tL0FDX0NBTUVSRklSTUFfQUFQUC5j cmwwgZQGA1UdEQSBjDCBiaSBhjCBgzEhMB8GCWCFVAEDBQIBAQwSc2VsbG8gZWxl Y3Ryw7NuaWNvMR0wGwYJYIVUAQMFAgECDA5GVU5EQUNJw5MgSUJJVDEYMBYGCWCF VAEDBQIBAwwJRzA3ODk2MDA0MSUwIwYJYIVUAQMFAgEFDBZQTEFUQUZPUk1BIElO VEVHUkFDSU9OMCEGA1UdEgQaMBiBFnNvcG9ydGVAY2FtZXJmaXJtYS5jb20wggEL BgNVHSAEggECMIH/MIH8BgwrBgEEAYGHLgEDAwIwgeswKQYIKwYBBQUHAgEWHWh0 dHBzOi8vcG9saWN5LmNhbWVyZmlybWEuY29tMIG9BggrBgEFBQcCAjCBsBqBrUNl cnRpZmljYWRvIHJlY29ub2NpZG8gZGUgc2VsbG8gZWxlY3Ry825pY28gZGUgQWRt aW5pc3RyYWNp824sIPNyZ2FubyBvIGVudGlkYWQgZGUgZGVyZWNobyBw+mJsaWNv LCBuaXZlbCBNZWRpby4gQ29uc3VsdGUgY29uZGljaW9uZXMgZGUgdXNvIGVuIGh0 dHBzOi8vcG9saWN5LmNhbWVyZmlybWEuY29tMCUGCCsGAQUFBwEDBBkwFzAIBgYE AI5GAQEwCwYGBACORgEDAgEPMA0GCSqGSIb3DQEBBQUAA4IBAQC+mdTcrMGVmk+L DC7P3Gwg2a1/j9qpfmdO2ayQFNslCjvZGZD3g8bgdbu0obH6+4fwMxVesJp0MoZp ktOrBK1LqjkJWT4reL+dWpXnLQMF279dHJxShLdxE1hQ+a/EDmTlGVu667eqxGx+ Quu8IEPaXhfxUfXkuRsLhzhd1pY00mSbA34ev7XBcqPtBE1dV12O9uUlKdkKVDap cdP891zIaJckQUyj44+CD5TRRV/qPvC8gIS0ozTbmgTsBH/m/jl34go7KaqEGdqI nebGPX3V9aeHWqOZJBD+Xc8+HND0w31vFShxE8KfanzmKjdl1Q9SH1Zy9ZrQ7WyP SujRIXhx END CERTIFICATE Se trata de verificar el certificado contenido en PLATAFORMA_CER.pem con los certificados contenidos en PLATAFORMA_CA.pem: $ openssl verify CAfile PLATAFORMA_CA.pem PLATAFORMA_CER.pem PLATAFORMA_CER.pem: description = Qualified Certificate: AAPPSEPMSWKPSC, CN = PLATAFORMA INTEGRACION, serialNumber = G07896004, OU = sello electr\C3\B3nico, O = FUNDACI\C3\93 IBIT, C = ES error 10 at 0 depth lookup:certificate has expired OK Como ejercicio se propone modificar un carácter del archivo PLATAFORMA_CER.pem y volver a ejecutar el comando anterior. 8.2. Archivos de certificados digitales La estructura de datos que define a un certificado digital suele estar contenida en archivos. Estos archivos están estructurados o codificados de alguna de las siguientes formas: • DER Codificación binaria de la notación ASN.1 de un certificado digital. • PEM Codificación en Base64 de la codificación DER de un certificado digital. • PKCS#12 Almacén de claves utilizado para contener claves privadas y certificados. 30 de 61 Operaciones sobre archivos con certificados digitales Conversión PEM (Base64) → DER (binario): $ openssl x509 outform der in certificado.crt out certificado.cer Conversión DER (binario) → PEM (Base64): $ openssl x509 inform der in certificado.cer out certificado.crt Importar PEM (Base64) → PKCS#12 (almacén de claves): $ openssl pkcs12 export out certificado.p12 inkey private.key in certificate.crt certfile CACert.crt Exportar PKCS#12 (almacén de claves) → PEM (Base64): $ openssl pkcs12 in certificado.p12 out certificado.crt Explorar certificados de usuario del almacén de claves: $ openssl pkcs12 in certificado.p12 nokeys clcerts | openssl x509 noout text Explorar certificados de CA del almacén de claves: $ openssl pkcs12 in certificado.p12 nokeys cacerts | openssl x509 noout text Exportar certificados (cadena) del almacén de claves: $ openssl pkcs12 in certificado.p12 out certificado.crt nokeys Exportar certificado (usuario) del almacén de claves: $ openssl pkcs12 in certificado.p12 out certificado.crt nokeys clcerts Exportar la clave privada del almacén de claves: $ openssl pkcs12 in certificado.p12 out private.key nocerts Cambiar la contraseña del almacén de claves: $ openssl pkcs12 in certificado.p12 out temp.pem passin pass:'uno 1' passout pass:temppassword $ openssl pkcs12 export in temp.pem out certificado.p12 passin pass:temppassword passout pass:'dos 2' $ rm temp.pem Generar un almacén de claves Java: $ keytool genkey alias foo keystore proves.jks $ keytool delete alias foo keystore proves.jks $ keytool list v keystore proves.jks Importar el contenido de un almacén PKCS#12 a un almacén Java: $ keytool importkeystore srckeystore proves.p12 destkeystore proves.jks srcstoretype pkcs12 srcstorepass '???' deststorepass '¿¿¿¿' $ keytool list v keystore proves.jks 31 de 61 Cambiar el alias de un certificado en un almacén Java: $ keytool changealias alias '1' destalias 'alias_nuevo' keypass '???' keystore proves.jks storepass '¿¿¿¿' $ keytool list v keystore proves.jks 8.3. Huella digital La huella digital, también denominada Thumbprint en Internet Explorer o Fingerprint en Mozilla Firefox, permite simplificar algunas tareas de gestión (automática) de certificados digitales. Una huella digital de un certificado digital es el valor obtenido mediante la aplicación de una función hash sobre el archivo que contiene el certificado digital. Se trata pues de una representación abreviada de un certificado digital. Con esta representación resulta más fácil indexar certificados digitales en un sistema de archivos o comprobar su autenticidad mediante determinados canales de comunicación como el teléfono. Al tratarse de un valor calculado sobre un archivo, no forma parte de la propia estructura ASN.1 de un certificado digital X.509. La huella digital se puede obtener de alguna de las siguientes formas: $ openssl x509 sha1 in PLATAFORMA.pem noout fingerprint SHA1 Fingerprint=59:E3:69:59:7E:9D:01:22:31:FE:6D:BE:29:5B:A6:33:11:95:D4:94 $ openssl x509 md5 in PLATAFORMA.pem noout fingerprint MD5 Fingerprint=DC:D0:9E:F5:FA:05:2F:46:5B:76:8F:24:4E:D9:D7:9F $ openssl sha1 PLATAFORMA.cer SHA1(PLATAFORMA.cer)= 59e369597e9d012231fe6dbe295ba6331195d494 Notar la relación entre este último ejemplo y el primero. En el primer ejemplo, el certificado está codificado en PEM (DER+Base64), mientras que en el último ejemplo está codificada en DER. Se concluye que la huella digital de un certificado coincide con el valor de una función hash (SHA1) aplicada al archivo que contiene la codificación DER del certificado. 9. Marco legal Además de una infraestructura de clave pública para facilitar la interoperabilidad, se requiere también un marco jurídico que regule legalmente los intereses, derechos, obligaciones y responsabilidades de las partes que intervienen en la creación y utilización de certificados y firmas digitales. En base a la Directiva 1999/93/CE sobre un marco comunitario para la firma electrónica, se promulgó la Ley 59/2003 de 19 de diciembre, de firma electrónica (BOE número 304, 20/12/2003) que establece las regulaciones jurídicas para el reconocimiento de certificados y firmas digitales. De forma resumida, la ley contempla aspectos tales como: • El reconocimiento del DNI electrónico como dispositivo para crear firmas reconocidas. • Obligaciones, responsabilidades y limitación de responsabilidades de los prestadores de servicios de certificación. • Las competencias del Ministerio de Ciencia y Tecnología para la supervisión y control de las actividades de los prestadores de servicio de certificación. • Criterios de extinción de la vigencia de los certificados. 32 de 61 • Procedimiento de cese de actividad de un prestador de servicios. • Establecimiento de infracciones y sanciones a prestadores de servicios de certificación. • Equivalencia internacional de certificados. • Protección de datos personales. Algunos detalles que la mencionada ley establece, son: • Establecimiento de un seguro de responsabilidad civil de un mínimo de 3.000.000 Euros a prestadores de servicios de certificación. • El periodo máximo de vigencia de un certificado digital es de cuatro años. • La conservación durante al menos 15 años, de la información y documentación relacionada a un certificado con el objetivo de permitir la verificación de las firmas realizadas con el mismo. • La obligatoriedad de informar en un certificado reconocido el DNI/CIF de la persona física/jurídica del certificado. Como reflexión sobre la generación de la clave privada (datos de creación de firma), la ley establece lo siguiente: Artículo 11. Concepto y contenido de los certificados reconocidos. 2. Los certificados reconocidos incluirán, al menos, los siguientes datos: f) Los datos de verificación de firma que correspondan a los datos de creación de firma que se encuentren bajo el control del firmante. Artículo 12. Obligaciones previas a la expedición de certificados reconocidos. c) Asegurarse de que el firmante está en posesión de los datos de creación de firma correspondientes a los de verificación que constan en el certificado. d) Garantizar la complementariedad de los datos de creación y verificación de firma, siempre que ambos sean generados por el prestador de servicios de certificación. Artículo 18. Obligaciones de los prestadores de servicios de certificación que expidan certificados electrónicos. a) No almacenar ni copiar los datos de creación de firma de la persona a la que hayan prestado sus servicios. Artículo 19. Declaración de prácticas de certificación. 1. Todos los prestadores de servicios de certificación formularán una declaración de prácticas de certificación en la que detallarán, en el marco de esta ley y de sus disposiciones de desarrollo, las obligaciones que se comprometen a cumplir en relación con la gestión de los datos de creación y verificación de firma... Artículo 20. Obligaciones de los prestadores de servicios de certificación que expidan certificados reconocidos. e) Tomar medidas contra la falsificación de certificados y, en el caso de que el prestador de servicios de certificación genere datos de creación de firma, garantizar su confidencialidad durante el proceso de generación y su entrega por un procedimiento seguro al firmante. 33 de 61 Artículo 24. Dispositivos de creación de firma electrónica. 1. Los datos de creación de firma son los datos únicos, como códigos o claves criptográficas privadas, que el firmante utiliza para crear la firma electrónica. Recordemos que la creación de un certificado digital se inicia con una CSR generada por el solicitante del certificado. PKI X.509 considera como una opción la generación de la clave privada por parte de una autoridad certificadora. En contraste, la legislación de algunos países prohíbe expresamente la generación de claves privadas por parte de autoridades de certificación. 10. Prácticas A continuación se proponen cuatro prácticas a realizar con la herramienta OpenSSL 1.0.1. 10.1. PKI Simple Esta PKI consiste de una CA raíz y una CA firmante: Se utilizará la CA firmante para firmar diferentes tipos de certificados de usuario. http://pki-tutorial.readthedocs.org/en/latest/simple/index.html 34 de 61 10.2. PKI Avanzado Esta PKI consiste de una CA raíz y tres CA's subordinadas: Se utilizará las tres CA's firmantes para firmar diferentes tipos de certificados de usuario. http://pki-tutorial.readthedocs.org/en/latest/advanced/index.html 10.3. PKI Experto Esta PKI consiste de una CA raíz, una CA intermedia y dos CA's firmantes: 35 de 61 Además de firmar diferentes tipos de certificado de usuario, se considerarán políticas de certificación y la configuración de un responder OCSP. http://pki-tutorial.readthedocs.org/en/latest/expert/index.html 10.4. SSL. Autenticación cliente/servidor Típicamente, una conexión SSL/TLS se implementa sobre el protocolo HTTP y pretende ofrecer AUTENTICIDAD de la identidad del servidor y/o del cliente, PRIVACIDAD de la sesión mediante la utilización combinada de cifrado asimétrico y simétrico, e INTEGRIDAD de cada transacción mediante la utilización de un MAC. El funcionamiento simplificado de SSL es: 1. El cliente inicia una sesión HTTPS 2. El servidor responde con un certificado autofirmado o bien con una cadena de certificados que incluye su certificado 3. El cliente comprueba el certificado recibido: ◦ el período de validez y el uso de cada certificado recibido ◦ que el dominio del servidor coincida con el dominio especificado en el certificado del servidor (Subject → DN → CN → FQDN) ◦ que el certificado raíz recibido es de confianza para el cliente ◦ etc... 4. El cliente genera una clave de cifrado simétrico y un MAC. Ambos son cifrados con la clave pública del servidor y enviados al servidor. 5. Para el resto de la sesión se utiliza la clave de cifrado simétrico para cifrar cada mensaje junto a su correspondiente MAC. Aunque la autenticación del servidor es típica, es posible realizar también la autenticación del cliente. Para ello, el cliente envía un certificado autofirmado o una cadena de certificados que incluya su certificado y el servidor realiza las mismas comprobaciones mencionadas en el punto 3. Opciones más avanzadas de SSL contemplan la generación de una nueva clave simétrica para cada transacción de una misma sesión, la negociación, durante el inicio de sesión, de procedimientos concretos de cifrado, etc... De forma obligatoria, SSL requiere autenticación del servidor. Para que el cliente pueda validar el certificado del servidor, el cliente debe disponer del certificado raíz de su confianza y que forme parte del camino de certificación del servidor. Alternativamente el servidor puede enviar su camino completo de certificación (hasta un certificado de común confianza) o simplemente un certificado autofirmado. De forma opcional, para la autenticación del cliente, para que el servidor pueda validar el certificado del cliente, el servidor debe disponer del certificado raíz de su confianza y que forme parte del camino de certificación del cliente. Alternativamente el cliente puede enviar su camino completo de certificación (hasta un certificado de común confianza) o un certificado autofirmado. La primera parte de esta práctica consiste en simular una conexión SSL/TLS sin autenticación de cliente: Se genera un par de claves: $ openssl req newkey rsa:1024 x509 nodes keyout srv_key.pem new out srv_cert.pem Se ejecuta un servidor SSL/TLS: $ openssl s_server cert srv_cert.pem key srv_key.pem state debug 36 de 61 Se ejecuta un cliente SSL/TLS que conecta al servidor: $ openssl s_client debug state En esta segunda parte, se simulará una conexión SSL/TLS con autenticación de cliente: Se genera un par de claves para el cliente: $ openssl req newkey rsa:1024 x509 nodes keyout cl_key.pem new out cl_cert.pem Se ejecuta un servidor SSL/TLS: $ openssl s_server cert srv_cert.pem key srv_key.pem state debug Verify 1 CAfile cl_cert.pem Se ejecuta un cliente SSL/TLS que conecta al servidor: $ openssl s_client key cl_key.pem cert cl_cert.pem debug state 11. Firma avanzada Lo visto hasta aquí son funciones criptográficas, procedimientos de firma digital y sellado de tiempo, certificados digitales y una infraestructura de clave pública. Son conceptos importantes pero conviene reflexionar si son suficientes para afrontar necesidades reales. Algunas cuestiones interesantes podrían ser: • Que sucede con la validez de una firma digital cuando el certificado con la cual fue realizada haya caducado o haya sido revocado? • Que sucede con la validez de una firma digital cuando los algoritmos o la longitud de claves criptográficas utilizadas para la firma hayan quedado obsoletas? • Como podemos enmarcar los conceptos de cofirma y contrafirma en todo lo visto hasta ahora? Aunque posiblemente puedan existir otras cuestiones que merezcan su atención, limitaremos este estudio a estas tres preguntas. Asumiendo que se pretende una validez indefinida o a muy largo plazo, se pueden ignorar aspectos relacionados con una extensión concreta del periodo de tiempo de validez de una firma digital. Así, la validación a muy largo plazo de una firma se puede conseguir aplicando de forma recurrente sellos de tiempo: el primero se aplicará sobre la firma y de forma sucesiva, se aplicará al último sello de tiempo un nuevo sello de tiempo basado en el más reciente estado de la criptografía. En cuanto a la aplicación de cofirmas y contrafirmas, se podría contemplar una determinada estructura de datos para poder registrar las relaciones entre las diferentes firmas y con respecto al objeto que se firma. Cofirma - firma paralela - los firmantes están al mismo nivel organizativo - NO existe un orden prefijado de las firmas - firman el mismo objeto 37 de 61 Contrafirma - firma secuencial - los firmantes NO están al mismo nivel organizativo - existe un orden prefijado de las firmas - NO firman el mismo objeto Resumiendo, se precisa una estructura para poder registrar sucesivos sellos de tiempo y un conjunto de firmas relacionadas de una u otra forma. La especificación de esta estructura de datos debe permitir la interoperabilidad entre sistemas heterogéneos debiéndose publicar como norma, estándar o recomendación. Así, tenemos CAdES, XAdES y PAdES. 12. CAdES Para prolongar la validez de una firma digital más allá del periodo de validez del certificado digital utilizado para la creación de la misma, CAdES (CMS Advanced Electronic Signatures) propone la utilización de los servicios ofrecidos por autoridades certificadoras, autoridades de sellos de tiempo, autoridades de registro, etc..., además de unos formatos de estructuras de datos necesarias para soportar la extensión del periodo de validez de las firmas digitales. Con ello también se pretende además evitar la invalidez de firmas digitales inherente a la obsolescencia de elementos criptográficos como las funciones hash y los algoritmos de cifrado. Para permitir un proceso de validación de firma digital coherente y técnicamente consistente, además de formatos de estructura de datos, CAdES también introduce el concepto de política de firma digital. Formalmente el formato de las estructuras de datos se especifican mediante ASN.1 y las políticas de firma se referencian mediante OIDs. Para la codificación de las estructuras de datos, CAdES recomienda su codificación en DER y para su transmisión, la codificación en Base64 del resultado de la codificación DER. Las especificaciones de CAdES procuran satisfacer la directiva de la Unión Europea 1999/93/EC acerca de la creación de un marco comunitario para el reconocimiento legal de la firma electrónica por parte de sus estados miembros y determinar también la coherencia técnica de diferentes especificaciones de Firma Electrónica. Así, el Instituto Europeo de Estándares de Telecomunicación (ETSI) formó un comité dedicado a la firma electrónica (ESI) el cual confecciona las especificaciones técnicas relacionadas con la firma electrónica avanzada. En este sentido, se ha publicado el documento ETSI TS 101 733 que la especifica a nivel Europeo y que en su versión V.1.7.4 equivale técnicamente a la especificación RFC 5126 publicada por la Internet Engineering Task Force (IETF). Básicamente, las estructuras de datos especificadas por CAdES denominadas perfiles, están formadas por determinados atributos agrupados e incluidos en un envoltorio digital basado en la especificación CMS. 12.1. Perfiles Actualmente, CAdES define dos perfiles básicos sin datos para la validación de la firma: • CAdES-BES: básica • CAdES-EPES: referencias a políticas de firma 38 de 61 y ocho perfiles extendidos con datos para la validación de la firma: • CAdES-T: sello de tiempo • CadES-C: referencias a datos de validación (cadenas de certificados y listas de revocación) • CAdES-X Long: datos de validación (cadenas de certificados y listas de revocación) • CAdES-X Type 1: referencias a datos de validación y sello de tiempo sobre CAdES-C • CAdES-X Type 2: referencias a datos de validación y sello de tiempo sobre referencias a datos de validación • CAdES-X Long Type 1: datos de validación y sello de tiempo sobre CAdES-C • CAdES-X Long Type 2: datos de validación y sello de tiempo sobre referencias a datos de validación • CAdES-A: datos de validación (cadenas de certificados y listas de revocación), sellos de tiempo periódicos para validar la firma a largo plazo y sello de tiempo sobre CAdES-C o sobre referencias a datos de validación Los dos perfiles básicos se han definido principalmente para satisfacer requisitos legales y como se muestra a continuación, se encapsulan en perfiles extendidos para ofrecer prestaciones avanzadas encaminadas a la validez de larga duración de la firma electrónica. Para que una firma electrónica sea reconocida conforme a la especificación CAdES, es suficiente que esta se ajuste a alguno de los perfiles CAdES-BES, CAdES-EPES, CAdES-T o CadES-C. CAdES-BES: básica El elemento Documento representa el documento o mensaje que se quiere firmar. Al igual que en CMS, puede ser de cualquier tipo pero se requiere que el formato de su presentación pueda ser especificado mediante MIME. Además del documento a firmar los siguientes atributos forman parte de CAdES-BES: • Atributos obligatorios abarcados por la firma: tipo del documento, valor hash del documento, etc... • Atributos opcionales abarcados por la firma: momento de la firma, lugar de la firma, sello de tiempo del documento a firmar, etc... • Atributos no abarcados por la firma: sello de tiempo de la firma, contrafirma, etc... La presencia de atributos opcionales viene determinada por la política de firma utilizada. CAdES-BES ofrece integridad y autenticación pero no incorpora referencias explicitas a políticas de firma y tampoco incorpora información suficiente para permitir la validación de la firma a largo plazo. 39 de 61 CAdES-EPES: referencias a políticas de firma CAdES-EPES es similar a CAdES-BES exceptuando un nuevo atributo abarcado por la firma. Este atributo identifica mediante un OID la política de firma que debe ser utilizada para la creación y validación de la firma. La política de firma referenciada debe ser accesible para cada validación de la firma. CAdES-T: sello de tiempo Si CAdES-EPES o CAdES-BES no contienen un atributo opcional correspondiente a un sello de tiempo, CAdES-T aporta un atributo no abarcado por la firma para incorporar un sello de tiempo. Este sello de tiempo hace referencia a la firma certificando su existencia anterior a un determinado momento. Para prevenir un posible repudio por parte del firmante, el sello de tiempo debe ser creado lo antes posible. 40 de 61 CAdES-C: referencias a datos de validación CAdES-C añade a CAdES-T un atributo con referencias (valores hash) a caminos de certificación y listas de revocación (o respuestas OCSP) necesarios para poder verificar la firma. Este atributo no está abarcado por la firma. El sello de tiempo presente en el perfil CAdES-T debe ser creado con anterioridad a la caducidad o revocación de los certificados referenciados. Disponer valores hash de determinados datos implica la posibilidad de acceder a los mismos para poder comprobar su integridad comparando tales valores hash. En otras palabras, para poder validar el valor hash, todos los elementos referenciados mediante este nuevo atributo deben ser accesibles en el momento de validar la firma. CAdES-X Long: datos de validación CAdES-X Long añade a CAdES-C un atributo con los datos de caminos de certificación y listas de revocación (o respuestas OCSP) necesarios para verificar la firma. 41 de 61 CAdES-X Type 1: referencias a datos de validación y sello de tiempo sobre CAdES-C CAdES-X Type 1 abarca un perfil CAdES-C sobre el cual se calcula un atributo de sello de tiempo. Este sello de tiempo garantiza que las referencias (valores hash) a caminos de certificación y listas de revocación (o respuestas OCSP) existieron con anterioridad al momento especificado por el sello de tiempo. Adicionalmente asegura la integridad (que no fueron modificados a posteriori) de los datos que representan estas referencias. CAdES-X Type 2: referencias a datos de validación y sello de tiempo sobre referencias a datos de validación El perfil CAdES-X Type 2 agrupa un perfil CAdES-C y un atributo de sello de tiempo. Este sello de tiempo se calcula sobre las referencias (valores hash) a caminos de certificación y listas de revocación (o respuestas OCSP) incluidos en el perfil CAdES-C. Al igual que con el perfil CAdES-X Type 1, con ello se consigue demostrar la existencia anterior al momento especificado por el sello de tiempo y asegurar la integridad de los datos que representan estas referencias en el caso de que las claves de la autoridad certificadora se hayan comprometidas. 42 de 61 CAdES-X Long Type 1: datos de validación y sello de tiempo sobre CadES-C CAdES-X Long Type 1 se asemeja a CAdES-X Type 1 pero incluye los datos de caminos de certificación y listas de revocación (o respuestas OCSP) necesarios para verificar la firma. De esta forma no es necesario recurrir a fuentes externas para poder validar la firma. CAdES-X Long Type 2: datos de validación y sello de tiempo sobre referencias a datos de validación 43 de 61 CAdES-X Long Type 2 se asemeja a CAdES-X Type 2 pero incluye los datos de caminos de certificación y listas de revocación (o respuestas OCSP) necesarios para verificar la firma. De esta forma no es necesario recurrir a fuentes externas para poder validar la firma. CAdES-A: datos de validación y sello de tiempo sobre CAdES-C o sobre referencias a datos de validación, sellos de tiempo periódicos para validar la firma a largo plazo Finalmente, CAdES-A ofrece la posibilidad de añadir periódicamente sellos de tiempo para conseguir conservar la validez a largo plazo un documento firmado. Actualizando sucesivamente los elementos criptográficos utilizados para procesar el sello de tiempo se consigue superar la obsolescencia de los mismos y mantener la validez de la firma del documento. En otras palabras, una vez validada la firma, esta seguirá siendo valida a pesar de la caducidad del certificado del firmante o del compromiso de sus claves. 13. XAdES XML, como especificación de datos estructurados ampliamente aceptada, también ofrece la posibilidad de firmas digitales avanzadas. Al igual que CAdES, intenta satisfacer los requisitos de la directiva de la Unión Europea 1999/93/EC ajustándose a las especificaciones recogidas en el documento ETSI TS 101 733. Como CAdES, XAdES extiende conceptualmente CMS pero basándose en XML y XMLDSIG. XAdES define dos tipos de propiedades que forman parte de la firma digital avanzada: aquellas que están incluidas en la propia firma y otras que no lo están pero que pueden estar firmadas por terceras partes (una propiedad contiene o referencia a un objeto representado mediante una estructura de datos). Para objetos incluidos en la firma, el firmante debe tener acceso a los mismos en el momento de realizar la firma. 44 de 61 Objetos no incluidos en la firma son añadidos por el firmante o por terceros después de realizar la firma. Estos pueden estar firmados o no. Ejemplos de objetos no incluidos y firmados son sellos de tiempo, certificados, CRL, etc... Antes de describir las diferentes formas de firma digital XML avanzada, se exponen dos conceptos importantes. La canonización como requisito fundamental para una firma digital XML y XMLDSIG como base de la firma digital XML avanzada. 13.1. Forma canónica Con respecto a los saltos de línea, espacios en blanco, orden de los elementos y atributos, codificación de caracteres, etc..., un documento XML permite una multitud de representaciones manteniendo un mismo significado lógico. Para poder aplicar funciones hash o algoritmos de cifrado sobre un documento XML, es imprescindible disponer de una representación normalizada o estandarizada del mismo. Cuando es posible representar de varias formas diferentes un conjunto (estructurado) de datos, puede resultar conveniente formatearlo de forma única, explícita y reproducible. El resultado de este proceso es una representación canónica del conjunto de datos, denominada también forma c14n (cANONICALIZATIOn). Ejemplo: Versión canónica: <doc xmlns="http://example.com/default" xmlns:x="http://example.com/x"> <a a1="1" a2="2">123</a> <b xmlns:y="http://example.com/y" a3=""3"" y:a1="1" y:a2="2"></b> </doc> de: <?xml version="1.0" encoding="UTF8"?> <doc xmlns:x="http://example.com/x" xmlns="http://example.com/default"> <a a2="2" a1="1" >123</a> <b y:a1='1' xmlns="http://example.com/default" a3='"3"' xmlns:y='http://example.com/y' y:a2='2'/> </doc> Existen diversos métodos o algoritmos de canonización. Algunos de ellos, Canonical XML Version 1.1 (2008) y Canonical XML Version 2.0 (2013), están publicados por el mismo organismo que especifica XML, el World Wide Web Consortium (W3C). 13.2. Firma Digital XML La firma digital XML es una representación XML de una firma digital cuya especificación denominada XMLDSIG, es regulada por el W3C. Así, una firma digital XML es un documento XML o un conjunto de elementos (fragmento) XML. XMLDSIG especifica la sintaxis y las reglas para procesar la creación y la representación de firmas digitales en una aplicación XML. Como CAdES, la especificación XMLDSIG permite la aplicación de una firma digital sobre cualquier contenido digital. Sin embargo, a diferencia de CAdES, en lugar utilizar ASN.1 para su descripción, XMLDSIG se describe de forma normalizada mediante un esquema XML o un DTD. Para referenciar elementos XML y objetos (algoritmos, funciones hash, etc...) que soportan a la firma digital, XMLDSIG utiliza espacios de nombre, URL, URN y URIs. XMLDSIG utiliza también elementos especificados mediante RFCs de la IETF. Por ello hay ciertos valores descritos mediante ASN.1 y codificados en DER y Base64. Estructura general de una firma XML: 45 de 61 <Signature ID?> <SignedInfo> <CanonicalizationMethod/> <SignatureMethod/> (<Reference URI? > <! referencia al objeto que se firma > (<Transforms>)? <DigestMethod> <DigestValue> <! valor de la función hash aplicada sobre el objeto a firmar > </Reference>)+ </SignedInfo> <SignatureValue> <! valor de la firma digital sobre el elemento SignedInfo > (<KeyInfo>)? <! objetos (certificado) necesario para validar la firma > (<Object ID?>)* </Signature> En función de la relación entre la firma digital XML y el objeto que se firma, se especifican tres tipos de firmas XML. El objeto que se firma puede estar incluido en el fragmento de la firma, el objeto puede incluir la firma XML o bien, ninguno de los dos casos anteriores: el objeto es externo a la firma y no la incluye. Enveloping Signature Se calcula un hash del contenido del elemento Object hijo del elemento Signature. El valor de este hash está contenido en el elemento DigestValue el cual es hijo de un elemento Reference. Este último contiene un atributo que hace referencia al objeto sobre el cual se ha calculado la función hash. El elemento SignedInfo, hijo también del elemento Signature, entre otros elementos contiene el elemento Reference. Finalmente, el elemento SignatureValue, hermano de SignedInfo, contiene la firma calculada sobre el elemento SignedInfo. <?xml version="1.0" encoding="UTF8"?> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/RECxmlc14n20010315"/> <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsasha1"/> <ds:Reference URI="#obj"> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <ds:DigestValue/> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue/> <ds:Object Id="obj">Hello, World!</ds:Object> </ds:Signature> Enveloped Signature En un elemento Reference se hace referencia al conjunto de elementos que forman el documento XML que contiene el elemento Signature. Mediante una transformación XPath especificada mediante un elemento Transform se calcula un subconjunto de elementos que excluye el elemento Signature. Sobre este subconjunto se aplica una función hash cuyo valor estará contenido en el elemento DigestValue el cual es hijo del elemento SignedInfo. Finalmente, el elemento SignatureValue, hermano de SignedInfo, contiene la firma calculada sobre el elemento SignedInfo. <!DOCTYPE Envelope [ <!ENTITY ds "http://www.w3.org/2000/09/xmldsig#"> <!ENTITY c14n "http://www.w3.org/TR/2001/RECxmlc14n20010315"> 46 de 61 <!ENTITY enveloped "http://www.w3.org/2000/09/xmldsig#envelopedsignature"> <!ENTITY xslt "http://www.w3.org/TR/1999/RECxslt19991116"> <!ENTITY digest "http://www.w3.org/2000/09/xmldsig#sha1"> ]> <Letter> <Returnaddress>address</Returnaddress> <To>You</To> <Message>msg body</Message> <From> <ds:Signature xmlns:ds="&ds;"> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm= "http://www.w3.org/TR/2001/RECxmlc14n20010315"/> <ds:SignatureMethod Algorithm= "http://www.w3.org/2000/09/xmldsig#rsasha1"/> <ds:Reference URI=""> <ds:Transforms> <ds:Transform Algorithm="&enveloped;"> </ds:Transform> </ds:Transforms> <ds:DigestMethod Algorithm="&digest;"/> <ds:DigestValue></ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue/> </ds:Signature> </From> <Attach>attachement</Attach> </Letter> Detached Signature Para los dos tipos de firmas anteriores, el elemento SignedInfo contiene uno o varios elementos Reference cuyos atributos URI pueden referenciar objetos de datos externos a la firma XML y que representan el contenido que se firma. El objeto a firmar puede estar contenido en el mismo documento XML en el que se encuentra la firma (internally detached), en cuyo caso será hermano de Signature, o bien encontrarse en un recurso físicamente externo al documento XML (externally detached). En cualquier caso, el objeto a firmar se referencia mediante un elemento Reference que es padre de un elemento DigestValue. Este elemento contiene el valor hash del objeto a firmar y al igual que los dos casos anteriores, la firma se calcula sobre el elemento SignedInfo. <?xml version="1.0" encoding="UTF8"?> <internallydetached> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/RECxmlc14n20010315"/> <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsasha1"/> <ds:Reference URI="#data"> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <ds:DigestValue/> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue/> </ds:Signature> <document Id="data"> <title>title</title> <author>writer</author> 47 de 61 <date>today</date> <content> <para>First paragraph</para> <para>Second paragraph</para> </content> </document> </internallydetached> En el siguiente ejemplo de firma externally detached, el objeto a firmar se encuentra en un servidor web y es referenciado mediante la URL http://www.w3.org/TR/xml-stylesheet <?xml version="1.0" encoding="UTF8"?> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/RECxmlc14n20010315"/> <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsasha1"/> <ds:Reference URI="http://www.w3.org/TR/xmlstylesheet"> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <ds:DigestValue/> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue/> </ds:Signature> Validación de una firma XML La validación de una firma XML se realiza en dos pasos: primero se validan (calcular y comparar los valores hash) las referencias contenidas en el elemento SignedInfo. Una vez validadas las referencias, se valida el valor de la propia firma, contenido en el elemento SignatureValue y calculada sobre el elemento SignedInfo. Para facilitar su verificación, el creador de la firma especifica el método utilizado para la canonización del elemento SignedInfo. De esta forma, el verificador podrá aplicar el mismo método antes de calcular y comparar los valores hash. Ejemplo de una firma XML <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <soapenv:Header> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/RECxmlc14n20010315" ></ds:CanonicalizationMethod> <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsasha1" ></ds:SignatureMethod> <ds:Reference URI="#MsgBody"> <ds:Transforms> <ds:Transform Algorithm="http://www.w3.org/TR/2001/RECxmlc14n20010315#WithComments" ></ds:Transform> </ds:Transforms> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" ></ds:DigestMethod> <ds:DigestValue>C16zUWdt5lnX1e+GRe6U4Y+Il94=</ds:DigestValue> </ds:Reference> </ds:SignedInfo> 48 de 61 <ds:SignatureValue> Pysy/UNRXSc0rZa02a8Uk1oNF/jVI9UMf2tRQ3v89ytDtZbRVn4h1DKzYxe0m/B8Mam+Pk0p3nc6 YBXEUX22NcTCuj5oeChHr/2L7vNjQxYYy9liV0H4kURRyUcRiyQ1wqUGMgWlO1rtDnP6xNiedPMu 89l86Q9TOzb3Tsi8Sng= </ds:SignatureValue> <ds:KeyInfo> <ds:X509Data> <ds:X509Certificate> MIIDwjCCAyugAwIBAgIEPN5pKTANBgkqhkiG9w0BAQUFADA2MQswCQYDVQQGEwJFUzENMAsGA1UE ChMERk5NVDEYMBYGA1UECxMPRk5NVCBDbGFzZSAyIENBMB4XDTEyMDMyMTA5MTc0NFoXDTE2MDMy MTA5MTc0NFowga0xCzAJBgNVBAYTAkVTMQ0wCwYDVQQKEwRGTk1UMRgwFgYDVQQLEw9GTk1UIENs YXNlIDIgQ0ExETAPBgNVBAsTCFB1YmxpY29zMRIwEAYDVQQLEwk1MDAwNzAwMTUxTjBMBgNVBAMT RURFU0NSSVBDSU9OIFNJU1RSQS1TQVJBIC0gRU5USURBRCBBSlVOVEFNRU5UIERFIFBBTE1BIC0g Q0lGIFAwNzA0MDAwSTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAm4aBZJKNxVCmCgd6eb51 ggGxIlrn3QZtUGuua2PyJdJ+W8Kljp2IAbO1y+0/SDvJZUqfCeoUqrD5wShxaNKoKKZzXdkH4Fry C5Is7z9Yt2QkMwO80JjgfNjfgW66Rc8rbG+rpccIG7Cke/Uj47/mf+w8U7kwLWe+4D8qmfMiHWkC AwEAAaOCAWMwggFfMGcGA1UdEQRgMF6kXDBaMRgwFgYJKwYBBAGsZgEPEwlQMDcwNDAwMEkxIjAg BgkrBgEEAaxmAQ4TE0FKVU5UQU1FTlQgREUgUEFMTUExGjAYBgkrBgEEAaxmAQgTC1NJU1RSQS1T QVJBMAkGA1UdEwQCMAAwKwYDVR0QBCQwIoAPMjAxMjAzMjEwOTE3NDRagQ8yMDE2MDMyMTA5MTc0 NFowCwYDVR0PBAQDAgWgMBEGCWCGSAGG+EIBAQQEAwIFoDAdBgNVHQ4EFgQUZpwux7NJR/YcYJV7 jNham6LNOwYwHwYDVR0jBBgwFoAUQJp2RJd0B8SsFMsejU86RXww12EwXAYDVR0fBFUwUzBRoE+g TaRLMEkxCzAJBgNVBAYTAkVTMQ0wCwYDVQQKEwRGTk1UMRgwFgYDVQQLEw9GTk1UIENsYXNlIDIg Q0ExETAPBgNVBAMTCENSTDEwMDU0MA0GCSqGSIb3DQEBBQUAA4GBAGvpGj8UdVj4BKgFry2LASAO ncDPHJQKWxC3k3vNCIgiGvCoTdEZhH9OFdTHsG+Z22yr7OrcCq1wmYm+oWJXi2cXcHxlS/PdgBie +YBjxcUwZdH1D1AsfkwN2Be20SI9q7XlV74I1+TbTobQqmMnoJ6XLK6fmqIwfCmoRxP9LyqQ </ds:X509Certificate> </ds:X509Data> <ds:KeyValue> <ds:RSAKeyValue> <ds:Modulus> m4aBZJKNxVCmCgd6eb51ggGxIlrn3QZtUGuua2PyJdJ+W8Kljp2IAbO1y+0/SDvJZUqfCeoUqrD5 wShxaNKoKKZzXdkH4FryC5Is7z9Yt2QkMwO80JjgfNjfgW66Rc8rbG+rpccIG7Cke/Uj47/mf+w8 U7kwLWe+4D8qmfMiHWk= </ds:Modulus> <ds:Exponent>AQAB</ds:Exponent> </ds:RSAKeyValue> </ds:KeyValue> </ds:KeyInfo> </ds:Signature> </soapenv:Header> <soapenv:Body Id="MsgBody"> <Respuesta xmlns="http://www.map.es/scsp/esquemas/V2/respuesta"> <Atributos> <IdPeticion>PINBAL0000001448</IdPeticion> <NumElementos>1</NumElementos> <TimeStamp>20130912T08:42:24.779+02:00</TimeStamp> <CodigoCertificado>SCDPPEAJU</CodigoCertificado> </Atributos> <Transmisiones> <TransmisionDatos> <DatosGenericos> <Emisor> <NifEmisor>S0711001H</NifEmisor> <NombreEmisor>CAIB</NombreEmisor> </Emisor> <Solicitante> <IdentificadorSolicitante>G07896004</IdentificadorSolicitante> <NombreSolicitante>Fundació BIT</NombreSolicitante> <Finalidad>CODSVDR_GBA_20121107#::##::#proves</Finalidad> <Consentimiento>Si</Consentimiento> <Funcionario> <NombreCompletoFuncionario>Javier Miguel</NombreCompletoFuncionario> <NifFuncionario>12345678Z</NifFuncionario> 49 de 61 </Funcionario> </Solicitante> <Titular> <TipoDocumentacion>DNI</TipoDocumentacion> <Documentacion>12345678Z</Documentacion> </Titular> <Transmision> <CodigoCertificado>SCDPPEAJU</CodigoCertificado> <IdSolicitud>PINBAL0000001448</IdSolicitud> <IdTransmision>PMI2013091209:15:49.128</IdTransmision> <FechaGeneracion>20130912T09:15:49.128</FechaGeneracion> </Transmision> </DatosGenericos> <DatosEspecificos xmlns="http://www.map.es/scsp/esquemas/datosespecificos"> <Estado> <CodigoEstado>0238</CodigoEstado> <LiteralError>Información no disponible.</LiteralError> </Estado> <Solicitud> <TipoSolicitud>LISTADOHABITANTES</TipoSolicitud> <Provincia> <Codigo>07</Codigo> </Provincia> <Municipio> <Codigo>040</Codigo> </Municipio> </Solicitud> </DatosEspecificos> </TransmisionDatos> </Transmisiones> </Respuesta> /soapenv:Body> </soapenv:Envelope> Si se guarda el contenido del elemento X509Certificate añadiendo en una línea aparte el prefijo -----BEGIN CERTIFICATE----- y en otra linea aparte, el sufijo -----END CERTIFICATE----- es posible, con el siguiente comando, ver el certificado utilizado para la firma del mensaje SOAP: $ openssl x509 in resposta.pem text 13.3. Formas de firma digital XML avanzada XAdES define seis formas de estructuras XML para la firma digital avanzada. • XAdES: básica • XAdES-T: sello de tiempo • XAdES-C: referencias a datos de validación (cadenas de certificados y listas de revocación) • XAdES-X: referencias a datos de validación y sello de tiempo sobre referencias a datos de validación y/o firma y otros sellos de tiempos • XAdES-X-L: datos de validación (cadenas de certificados y listas de revocación) y con referencias a datos de validación y sello de tiempo sobre referencias a datos de validación y/o firma y otros sellos de tiempos 50 de 61 • XAdES-A: datos de validación (cadenas de certificados y listas de revocación), referencias a datos de validación, sellos de tiempo periódicos para validar la firma a largo plazo, sello de tiempo sobre referencias a datos de validación y/o firma y otros sellos de tiempos XAdES: básica Partiendo de una estructura XMLDSIG, la especificación XAdES añade propiedades incluidas en la firma, SignedProperties y propiedades excluidas de la firma, UnsignedProperties. Estas propiedades se agrupan dentro del elemento Object de una estructura XMLDSIG. XMLDSIG | <ds:Signature ID?> + + <ds:SignedInfo> | | <ds:CanonicalizationMethod/> | | <ds:SignatureMethod/> | | (<ds:Reference URI? > | | (<ds:Transforms>)? | | <ds:DigestMethod> | | <ds:DigestValue> | | </ds:Reference>)+ | | </ds:SignedInfo> | | <ds:SignatureValue> | | (<ds:KeyInfo>)? + | | <ds:Object> | | <QualifyingProperties> | | <SignedProperties> | | <SignedSignatureProperties> | (SigningTime) | (SigningCertificate) | (SignaturePolicyIdentifier) | (SignatureProductionPlace)? | (SignerRole)? | </SignedSignatureProperties> | | <SignedDataObjectProperties> | (DataObjectFormat)* | (CommitmentTypeIndication)* | (AllDataObjectsTimeStamp)* | (IndividualDataObjectsTimeStamp)* | 51 de 61 </SignedDataObjectProperties> | | </SignedProperties> | | <UnsignedProperties> | | <UnsignedSignatureProperties> | (CounterSignature)* | </UnsignedSignatureProperties> | | </UnsignedProperties> | | </QualifyingProperties> | | </ds:Object> | | </ds:Signature> + | XAdES Especial mención se merece el elemento CounterSignature. Este elemento permite realizar cofirmas o contrafirmas. Un elemento CounterSignature contiene un elemento Signature. De esta forma, cada cofirma podrá referenciar al elemento SignatureValue del elemento Signature principal que referencia al objeto o documento que se firma. En cambio, una contrafirma referenciará al elemento SignatureValue del elemento Signature que representa a la firma anterior en la cadena de contrafirmas. XAdES-T: sello de tiempo XAdES-T añade a XAdES una propiedad para contener el valor de un sello de tiempo calculado sobre el elemento SignatureValue de la firma principal. Recordar que con ello se pretende probar que la firma se creó anterior a un determinado momento. Para minimizar una posibilidad de repudio, conviene minimizar la diferencia de tiempo entre la creación de la firma, registrado por el elemento SigningTime, y el sellado de la misma. </UnsignedSignatureProperties> (CounterSignature)* (SignatureTimeStamp)+ </UnsignedSignatureProperties> Como se puede ver, es posible incorporar más de un sello de tiempo, cada uno de los cuales pudiendo haber sido emitido por una TSA diferente. 52 de 61 XAdES-C: referencias a datos de validación (cadenas de certificados y listas de revocación) XAdES-C añade a XAdES-T propiedades para contener referencias (valores hash) a caminos de certificación y listas de revocación (o respuestas OCSP) necesarios para validar la firma. </UnsignedSignatureProperties> (CounterSignature)* (SignatureTimeStamp)+ (CompleteCertificateRefs) (CompleteRevocationRefs) </UnsignedSignatureProperties> Disponer valores hash de determinados datos implica la posibilidad de acceder a los mismos para poder comprobar su integridad comparando tales valores hash. En otras palabras, para poder validar el valor hash, todos los elementos referenciados mediante este nuevo atributo deben ser accesibles en el momento de validar la firma. XAdES-X: referencias a datos de validación y sello de tiempo sobre referencias a datos de validación y/o firma y otros sellos de tiempos XAdES-X extiende a XAdES-C añadiendo una propiedad para contener un sello de tiempo sobre la firma, el conjunto de sellos de tiempo sobre la firma y las referencias a caminos de certificación y listas de revocación (o respuestas OCSP) o bien, una propiedad para contener un sello de tiempo únicamente sobre las referencias a caminos de certificación y listas de revocación (o respuestas OCSP). El propósito de XAdES-X es mantener la validez de la firma en el caso de un compromiso de la clave utilizada para firmar algún certificado del camino de certificación, alguna lista de revocación o respuesta OCSP. Sellando en el tiempo certificados de CA o respuestas OCSP, se demuestra su validez anterior a la fecha en que la clave del correspondiente CA fue comprometida. 53 de 61 </UnsignedSignatureProperties> (CounterSignature) (SignatureTimeStamp) (CompleteCertificateRefs) (CompleteRevocationRefs) ((SigAndRefsTimeStamp)* | (RefsOnlyTimeStamp)*) </UnsignedSignatureProperties> El elemento SigAndRefsTimeStamp contiene referencias (valores hash) sobre los elementos SignatureValue, SignatureTimeStamp, CompleteCertificateRefs y CompleteRevocationRefs y el sello de tiempo se calcula sobre la concatenación de los mismos. El elemento RefsOnlyTimeStamp contiene referencias (valores hash) sobre los elementos CompleteCertificateRefs y CompleteRevocationRefs y el sello de tiempo se calcula sobre la concatenación de los mismos. 54 de 61 XAdES-X-L: datos de validación (cadenas de certificados y listas de revocación) y con referencias a datos de validación y sello de tiempo sobre referencias a datos de validación y/o firma y otros sellos de tiempos XAdES-X-L extiende XAdES-X incorporando los datos necesarios para realizar la validación: caminos de certificación, CRL's y respuestas OCSP. </UnsignedSignatureProperties> (CounterSignature)* (SignatureTimeStamp)+ (CompleteCertificateRefs) (CompleteRevocationRefs) ((SigAndRefsTimeStamp)* | (RefsOnlyTimeStamp)*) (CertificatesValues) (RevocationValues) </UnsignedSignatureProperties> XAdES-A: datos de validación (cadenas de certificados y listas de revocación), referencias a datos de validación, sellos de tiempo periódicos para validar la firma a largo plazo, sello de tiempo sobre referencias a datos de validación y/o firma y otros sellos de tiempos Para soportar la obsolescencia de los elementos criptográficos, XAdES-A añade la posibilidad de incorporar sucesivos sellos de tiempo calculados sobre XAdES-X-L. Cada nuevo sello de tiempo se realiza con el estado más reciente de las técnicas criptográficas conocidas. 55 de 61 XMLDSIG | <ds:Signature ID?> + ++++++ <ds:SignedInfo> | | | | | | | <ds:CanonicalizationMethod/> | | | | | | | <ds:SignatureMethod/> | | | | | | | (<ds:Reference (URI=)? > | | | | | | | (<ds:Transforms>)? | | | | | | | <ds:DigestMethod> | | | | | | | <ds:DigestValue> | | | | | | | </ds:Reference>)+ | | | | | | | </ds:SignedInfo> | | | | | | | <ds:SignatureValue> | | | | | | | (<ds:KeyInfo>)? + | | | | | | <ds:Object> | | | | | | | | | | | | <QualifyingProperties> | | | | | | | | | | | | <SignedProperties> | | | | | | | | | | | | <SignedSignatureProperties> | | | | | | (SigningTime) | | | | | | (SigningCertificate) | | | | | | (SignaturePolicyIdentifier) | | | | | | (SignatureProductionPlace)? | | | | | | (SignerRole)? | | | | | | </SignedSignatureProperties> | | | | | | | | | | | | <SignedDataObjectProperties> | | | | | | (DataObjectFormat)* | | | | | | (CommitmentTypeIndication)* | | | | | | (AllDataObjectsTimeStamp)* | | | | | | (IndividualDataObjectsTimeStamp)* | | | | | | </SignedDataObjectPropertiesSigned> | | | | | | | | | | | | </SignedProperties> | | | | | | | | | | | | <UnsignedProperties> | | | | | | | | | | | | </UnsignedSignatureProperties> | | | | | | (CounterSignature)* + | | | | | (SignatureTimeStamp)+ + | | | | (CompleteCertificateRefs) | | | | (CompleteRevocationRefs) + | | | ((SigAndRefsTimeStamp)* | | | | (RefsOnlyTimeStamp)*) + | | (CertificatesValues) | | (RevocationValues) + | (ArchiveTimeStamp)+ | </UnsignedSignatureProperties> +++++ | | | | | | | </UnsignedProperties> | | | | | | | | | | | | </QualifyingProperties> | | | | | | | | | | | | </ds:Object> | | | | | | | | | | | | </ds:Signature> ++++++ | | | | | | XAdES | | | | | | | | | | XAdEST | | | | | | | | XAdESC | | | 56 de 61 | | | XAdESX | | | | XAdESXL | | XAdESA 14. PAdES El estándar ISO-32000-1 (PDF 1.7) especifica un formato digital para representar documentos denominado PDF (Portable Document Format) que permite el intercambio y la visualización de documentos electrónicos independientemente del entorno en el cual fueron producidos o en el cual son impresos o visualizados. PAdES es un conjunto de restricciones y extensiones a ISO-32000-1 permitiendo capacidades de firma avanzada sobre documentos PDF. Las especificaciones de PAdES fueron publicadas en el año 2009 por el ETSI y se recogen en el documento ETSI TS 102 778. Se espera que estas especificaciones se incluyan en el nuevo estándar ISO-32000-2 (PDF 2.0). Tomando como referencia CAdES, PAdES también define una serie de perfiles para especificar los conjuntos de atributos y estructuras de datos que soportan diferentes tipos de firma avanzada. La especificación TS 102 778 de PAdES se estructura en cinco partes: • Parte 1. Introducción al soporte de la firma digital en documentos PDF e introducción de los diferentes perfiles presentados en las demás partes de la especificación. • Parte 2. Describe el perfil PAdES Basic el cual se basa en el estándar ISO-32000-1 para especificar la firma digital PDF. • Parte 3. Describe el perfil PAdES Enhanced el cual recoge los tipos de firma BES (Basic Electronic Signature) y EPES (Explicit Policy Electronic Signature). • Parte 4. Describe el perfil PAdES Long Term utilizado para validar firmas digitales a largo plazo. • Parte 5. Describe el perfil PAdES XML el cual permite incluir contenido XAdES en documentos PDF. 14.1. Perfiles PAdES A continuación se describen las principales características de los diferentes perfiles PAdES. PAdES Basic PAdES Basic define la firma PDF según la especificación ISO-32000-1. Un documento PDF contiene una serie de objetos uno de los cuales se denomina diccionario de firma. La firma está incluida en el diccionario de firma y contempla un rango de bytes sobre el mismo documento. Este rango cuya especificación forma parte del diccionario de firma cubre todo el documento excluyendo el valor mismo de la firma. El diccionario de firma también contiene los certificados necesarios para validar la firma y puede contener además un sello de tiempo. 57 de 61 La especificación ISO-32000-1 contempla dos tipos de firma: una única firma de autor y una o varias firmas de revisores. Los revisores firman anotaciones, comentarios o valores de campos de formularios PDF que ellos añaden en sucesivas versiones del documento. De esta forma se soportan las contrafirmas. Las cofirmas no son soportadas. Mediante una técnica denominada Modification Detection and Prevention (MDP), cada firmante puede especificar, en relación a su firma, que tipo de modificaciones (añadir comentarios o rellenar campos) se puede realizar sobre el documento (DocMDP) o que campos de formularios (FieldMDP) se pueden modificar después de aplicar su firma. 58 de 61 PAdES Enhanced Este perfil se basa en CadES-BES, CadES-EPES y opcionalmente en CAdES-T. De esta forma, se incluyen atributos que identifican mediante OIDs las políticas de firma que deben ser consideradas para la validación de la firma. No se deben confundir estas políticas con el seed value. El seed value es una entrada en el diccionario de firma PDF que especifica ciertas condiciones que se deben dar a la hora de realizarse la firma. En cambio, las políticas de firma son reglas que deben cumplir el firmante y el verificador de la firma. PAdES Long Term Para permitir Long Term Validation (LTV), la parte 4 de la especificación PAdES define una estructura de datos denominada Document Security Store (DSS). Esta estructura de datos se adjunta al documento PDF y contiene los certificados, CRL y respuestas OCSP asociados a la validación de cada firma del documento. Para verificar las firmas del documento PDF más allá de la fecha de caducidad o revocación de los certificados utilizados para las firmas, es necesario sellar las firmas y los datos de validación contenidos en el DSS. 59 de 61 Para permitir la verificación de las firmas a largo plazo se aplicarán sucesivos sellos de tiempo. Al estar firmado, cada sello de tiempo (TS_1) tendrá asociados unos datos de validación. Con anterioridad a su caducidad o revocación y mientras sean accesibles, hay que recolectar estos datos de validación, incorporarlos en un nuevo DSS y aplicar un nuevo sello de tiempo (TS_2). PAdES XML Un documento PDF puede contener documentos o elementos XML. Este perfil contempla la firma de elementos XML, o bien en forma de XAdES o XFA. De forma simple, XFA son campos de formularios PDF representados mediante XML. Cuando se realiza una firma de revisión sobre un documento se incluyen los posibles documentos XAdES. Por lo tanto hay que tener en cuenta, que la actualización posterior a la firma de revisión del documento XAdES para permitir la verificación de su firma a largo plazo, invalidaría la firma de revisión. Por otro lado, mediante DocMDP aplicado a la firma de autor, es posible permitir la actualización de un documento XML contenido en un documento PDF. 15. @Firma El Ministerio de Hacienda y Administraciones Públicas pone a disposición una plataforma de validación y firma que ofrece servicios avanzados de firma, validación y certificación electrónica facilitando a los sistemas de información la comprobación de la validez de los certificados electrónicos en las transacciones telemáticas llevadas a cabo por los ciudadanos con la Administración, así como para la realización de firma electrónica. Los principales servicios que ofrece son: • Validación de certificados • Validación de firmas • Generación de firmas • Sellado de tiempo • Gestión y administración 60 de 61 Los servicios de @firma están disponibles de forma gratuita para aquellas Administraciones Públicas que lo soliciten. El servicio se proporciona a través de la red SARA (Intranet Administrativa), por lo que para poder utilizarlo es necesario estar conectado a dicha red. Para más información: http://administracionelectronica.gob.es/pae_Home/pae_Estrategias/Racionaliza_y_Comparte/elementos_comunes/Ser vicios_Comunes_Firma_Electronica/FAQ-AFIRMA.html 61 de 61

Certificado y Firma digital

Documentos relacionados

Productos

Apoyo

Certificado y Firma digital

Documentos relacionados

Añadir este documento a la recogida (s)

Añadir a este documento guardado

Sugiéranos cómo mejorar StudyLib