2010.09.30 - Manual de Comandos Del DNIe - Tractis

DIRECCIÓN GENERAL DE LA POLICÍA Y DE LA GUARDIA CIVIL

MINISTERIO DEL INTERIOR

CUERPO NACIONAL DE POLICÍA

DNI ELECTRÓNICO.

GUÍA

DE

REFERENCIA TÉCNICA.

Esta copia del Manual Técnico del DNIe ha sido firmada y emitida por la Oficina Técnica del DNIe a solicitud de David Blanco Giró 09340620K 1

Índice de contenido Marco legal básico................................................................................................................................................................3 Descripción.....................................................................................................................................................................3 Actividad de validación de los certificados..........................................................................................................................5 Seguridad lógica...................................................................................................................................................................6 Identificación de usuario mediante código CHV......................................................................................7 Identificación de usuarios mediante datos biométricos............................................................................7 Identificación de aplicación......................................................................................................................7 Identificación mutua.................................................................................................................................7 Desbloqueo y cambio de código CHV.....................................................................................................8 Protección de mensajes............................................................................................................................8 Funcionalidades criptográficas.................................................................................................................9 Estados del sistema...................................................................................................................................9 Requisitos de seguridad. Asunciones de entorno..................................................................................................................9 Servicio de Atención al Ciudadano.....................................................................................................................................11 Glosario de términos y expresiones habituales...................................................................................................................13 Anexo I. Desarrollo de la funcionalidad de seguridad. .....................................................................................................17 Anexo II. Comandos APDU. .............................................................................................................................................19 Anexo III. Elementos criptográficos. ................................................................................................................................41 Anexo IV. Ejemplo de firma electrónica. ..........................................................................................................................43

2

Marco legal básico. •Directiva 1999/93/CE del Parlamento Europeo y del Consejo, por la que se establece un marco comunitario para la firma electrónica. •Ley 59/2003 de 19 de diciembre, de Firma Electrónica. •Ley Orgánica 15/1999 de 13 de diciembre, de Protección de los Datos. •Real Decreto 1553/2005 de 23 de diciembre, por el que se regula el documento nacional de identidad y sus certificados de firma electrónica.

Descripción. En el resto del documento usaremos el término tarjeta para referirnos de forma indiferente al soporte plástico del DNIe y al microprocesador que incorpora. El contexto indicará si se está haciendo referencia a uno u otro elemento o a la suma de ambos.

El propósito del microprocesador que incorpora el DNI electrónico es contener y custodiar los datos de filiación del ciudadano, los datos biométricos (modelo dactilar, foto y firma manuscrita) y los dos pares de claves RSA con sus respectivos certificados. Podemos decir que el DNI electrónico está compuesto de dos elementos fundamentales: 1. La tarjeta. o Cumple con el estándar ISO-7816-1. o Está fabricada en policarbonato. Este es un material que permite su uso continuado y frecuente sin sufrir deterioro visible que altere sus prestaciones, durante el plazo máximo de vigencia del DNI, es decir, más de 10 años. o La personalización de la tarjeta se realiza mediante la grabación con láser de los datos de filiación, la fotografía y la firma manuscrita. Este sistema de personalización garantiza la imposibilidad de manipular los datos sin alterar el acabado de forma visible. o Cuenta con las más modernas medidas de seguridad ante la manipulación y falsificación del documento, muchas de ellas fácilmente identificables por cualquier persona sin ningún procedimiento especial. El conjunto de todas las medidas hace del DNI electrónico un documento altamente seguro, tanto desde el punto de vista físico como lógico. 2. El chip del DNI electrónico. o Nombre comercial: ST19WL34 o Sistema operativo: DNIe v1.1 o Capacidad de memoria: 32Kb.

3

La información en el chip está distribuida en tres zonas de seguridad con diferentes niveles y condiciones de acceso: –Zona pública: Accesible en lectura sin restricciones. –Certificado AC intermedia. –Claves Diffie-Hellman. –Certificado x509v3 de componente. –Zona privada: Accesible en lectura por el ciudadano, mediante la utilización de la clave personal de acceso o PIN; contiene: –Certificado de Firma. –Certificado de Identificación. –Zona de seguridad. Accesible en lectura por el titular en los Puestos de Actualización del DNIe (PAD). Incluye: –Datos de filiación del ciudadano, los mismos que están impresos en la tarjeta. –Imagen de la fotografía. –Imagen de la firma manuscrita. –En una zona lógica inaccesible desde el exterior se encuentran las claves RSA privadas y el modelo de la impresión dactilar. El acceso a estos datos es competencia exclusiva del sistema operativo que corre en cada chip. Datos criptográficos que incorporan los DNI electrónicos. Parejas de claves RSA de identificación y firma. Clave Pública de la AC raíz. Claves Diffie-Hellman.

Datos de gestión. Traza de fabricación. Número de serie del soporte. El chip almacena los siguientes certificados electrónicos:

•Certificado de componente. Su propósito es la identificación de la tarjeta del DNI electrónico durante el protocolo de autenticación mutua definido en EN-14890. oPermite el establecimiento de un canal cifrado e identificado entre la tarjeta y el middleware. oSu clave privada asociada no es externamente accesible.

4

•Certificado de identificación. Tiene como finalidad garantizar electrónicamente la identidad del ciudadano al realizar una transacción telemática. El certificado de identificación asegura que la comunicación electrónica se realiza con la persona que se identifica con el mismo. El titular podrá, a través de su certificado, acreditar su identidad frente a cualquiera ya que se encuentra en posesión del propio certificado y de la clave privada asociada al mismo. El uso de este certificado no está habilitado para operaciones que exijan no repudio de origen, por tanto los terceros aceptantes y los prestadores de servicios no tendrán garantía del compromiso del titular del DNI con el contenido firmado. Su uso principal será el de generar mensajes de identificación en el seno de determinados protocolos de establecimiento de canales cifrados. Para más información sobre el atributo KeyUsage de los certificados incorporados a los DNIe véase el apartado 6.7.1 de la DPC.

Este certificado puede ser utilizado también como medio de identificación para la realización de un registro que permita la expedición de certificados reconocidos por parte de entidades privadas, sin verse estas obligadas a realizar una fuerte inversión en el despliegue y mantenimiento de una infraestructura de registro.

•Certificado de firma. Destinado a la firma de documentos garantizando la integridad del documento y el no repudio de la autoría. Es un certificado X509.v3 estándar, que tiene activo en el atributo KeyUsage el bit ContentCommitment (compromiso con el contenido) y que esta asociado a una pareja de claves generada en el interior del chip del DNI electrónico. Es este certificado, expedido por una Autoridad de Certificación reconocida, el que convierte la firma electrónica avanzada en firma electrónica reconocida, permitiendo su equiparación legal con la firma manuscrita (Ley 59/2003 y Directiva 1999/93/CE).

Observación: Desde los orígenes del estándar X.509, descrito por primera vez en el documento RFC-2410 en 1998 tras su evolución desde el estándar X.500, se usa la expresión digitalSignature para referirse a un uso de la clave dirigido a la “autenticación”. Esta peculiaridad puede a veces inducir a error y causa sorpresa en los usuarios que tienen su primer contacto con esta tecnología. Parece lógico pensar que la expresión digitalSignature y su traducción al castellano, firmaDigital, haga referencia a un procedimiento de firma electrónica. Para aclarar este aparente error de concepto recordemos que el estándar describe convenciones; los autores del documento original usaron una etiqueta que resumía el hecho de que en el trasfondo de una operación de identificación lo que hay es un cifrado de un reto mediante la clave privada asociada al certificado, es decir, una firma electrónica avanzada. Para distinguir esta acción de la firma electrónica de documentos se aplicó la etiqueta nonRepudiation (no repudio) y en la actualidad contentCommitment (compromiso con el contenido) al uso de los certificados dirigidos a expresar precisamente el compromiso con el contenido de un documento electrónico.

Actividad de validación de los certificados.

La Autoridad de Validación es el componente de una PKI que tiene como tarea suministrar información sobre la vigencia de los certificados electrónicos que hayan sido expedidos por una Autoridad de Certificación. La información sobre los certificados electrónicos revocados (no vigentes) se almacena en las denominadas listas de revocación de certificados. Estas listas se

5

conocen más habitualmente por sus siglas en inglés, CRL. Recomendamos el examen detenido de la RFC-5280, y concretamente el apartado 5, para más información sobre las listas de revocación de certificados. En el esquema de infraestructura de clave pública adoptada para el DNI electrónico, se ha optado por asignar las funciones de Autoridad de Validación a entidades diferentes de la Autoridad de Certificación a fin de aislar la comprobación de la vigencia de un certificado electrónico de los datos de identidad de su titular; de esta forma la Autoridad de Certificación (Ministerio del Interior – Dirección General de la Policía y de la Guardia Civil) no tiene en modo alguno acceso a los datos de las transacciones que se realicen con los certificados que ella emite y las Autoridades de Validación no tienen acceso a la identidad de los titulares de los certificados electrónicos que valida, reforzando aún más si cabe la transparencia del sistema y garantizando la intimidad en el uso de los certificados DNIe.En la actualidad la PKI del DNI electrónico dispone de tres prestadores de servicios de validación: oFábrica Nacional de Moneda y Timbre – Real Casa de la Moneda, que presta sus servicios de validación con carácter universal: ciudadanos, empresas y Administraciones Públicas. oMinisterio de Administraciones Públicas, que presta los servicios de validación al conjunto de las Administraciones Públicas. oMinisterio de Industria, Turismo y Comercio, que presta servicio de validación a empresas. Adicionalmente, la entidad pública empresarial Red.es podría completar los servicios de validación en un futuro próximo. La prestación de estos servicios de validación se realiza en base a Online Certificate Status Protocol (OCSP), según se describe en el documento RFC-2560. En esencia supone que un cliente OCSP envía una petición a la Autoridad de Validación y ésta emite una respuesta firmada electrónicamente tras consultar su base de datos. En resumen, si el certificado no está en ninguna CRL se considera válido y si está en alguna CRL, la AV informará de que el estado es “revocado”. Si consta la razón de la revocación, también se incluye en la respuesta.

El servicio de validación está disponible de forma ininterrumpida todos los días del año.

Seguridad lógica. Mecanismos de identificación. El sistema operativo DNIe dispone de distintos métodos de identificación mediante los que una entidad externa demuestra legitimidad para el uso de los datos del chip. Usamos la expresión entidad externa para poder englobar cualquier tipo de implementación software o hardware. Dicha entidad puede ser una aplicación programada en un lenguaje de alto nivel corriendo sobre un determinado sistema operativo comercial o un programa en código máquina embebido en un periférico diseñado a medida para su ejecución.

La correcta realización de cada uno de estos métodos permite obtener unas condiciones de seguridad que podrán ser requeridas para el acceso a los distintos recursos de la tarjeta.

6

Identificación de usuario mediante código CHV.

La tarjeta DNIe soporta verificación de usuario (CHV-Card Holder Verification). Esta operación la realiza el sistema operativo cotejando el valor facilitado por la entidad externa con el valor almacenado en el chip. El código CHV tiene su propio contador de intentos. Tras una presentación válida el contador de intentos es automáticamente puesto a su valor inicial (típicamente = 3). El contador de intentos es decrementado cada vez que se realiza una presentación errónea, bloqueándose la posibilidad de identificación por este método si el contador llega a cero. El desbloqueo de un código CHV exige una identificación de nivel superior, concretamente de tipo biométrico. Esta operación se lleva a cabo en las instalaciones del Cuerpo Nacional de Policía mediante el uso de un PAD. A su vez estas presentaciones de huellas tienen su propio contador de intentos. Si el número de intentos de presentación de huella dactilar se agota, no será posible realizar la operación de desbloqueo. Es posible cambiar el código de CHV a un nuevo valor presentando el valor actual o presentando la huella dactilar.

Identificación de usuarios mediante datos biométricos.

El sistema operativo del DNI electrónico permite realizar una identificación biométrica del titular de la tarjeta. Está función sólo estará disponible en puntos de acceso controlados. En lineas generales, la aplicación que accede al DNIe decide qué huella va a proceder a verificar, solicitando al usuario que coloque el dedo adecuado. Tras la captura biométrica en el dispositivo lector de huellas, presenta la información al sistema operativo del chip a través del correspondiente comando. Mediante un algoritmo match-on-card se evalúa la correspondencia entre la huella presentada y la referencia almacenada en el propio chip. Si la evaluación supera el umbral, la verificación se considera correcta. En caso contrario, se anota una presentación errónea sobre esa huella devolviendo el número de intentos restantes.

Identificación de aplicación.

El propósito de este método es que la entidad externa demuestre tener conocimiento de una clave como condición de acceso a determinados recursos presentes en el chip. El método elegido es un protocolo de desafío-respuesta, con los siguientes pasos: oLa aplicación pide un desafío a la tarjeta. oSobre ese desafío, la entidad externa aplica un algoritmo en el que participa la clave privada de un certificado conocido por el sistema operativo del DNIe. El resultado lo transmite al chip. oEl sistema operativo del chip realiza las operaciones necesarias para determinar si la clave privada es congruente con el certificado confiable con el que cuenta. En caso de coincidir, considera correcta la presentación para posteriores operaciones.

7

Identificación mutua.

Este procedimiento permite que cada una de las partes (tarjeta y aplicación externa) confíe en la otra, mediante la presentación mutua de certificados y su verificación. Este proceso, similar al anterior en lineas generales, tiene como objetivo no sólo identificar los elementos participantes sino también un intercambio de claves de sesión, que deberán ser utilizadas para cifrar todos los mensajes que se intercambien posteriormente. Este servicio permite el uso de diferentes alternativas, que podrán seleccionarse implícitamente en función de la secuencia de comandos, o explícitamente, indicando su identificador de algoritmo en un comando de gestión de entorno de seguridad anterior (MSE). Las dos opciones disponibles están basadas en la especificación ‘EN-14890-1 Application Interface for smart cards used as Secured Signature Creation Devices – Part 1’, y son las siguientes: oAutenticación con intercambio de claves (capítulo 8.4 de EN-14890-1) oAutenticación de dispositivos con protección de la privacidad, (capítulo 8.5 de EN14890-1)

Desbloqueo y cambio de código CHV.

Se permite el cambio de código CHV mediante la presentación del valor antiguo o mediante identificación biométrica previa. Debido al carácter crítico de esta operación, el cambio de código CHV se ha de realizar siempre en condiciones de máxima confidencialidad y en terminales específicamente habilitados a tal efecto o con las debidas condiciones de seguridad, exigiéndose por tanto, el establecimiento de un canal seguro basado en certificados de componente. El desbloqueo del código CHV sólo es posible en los equipos denominados PAD, previa identificación biométrica del titular de la tarjeta. El cambio de código CHV es posible también mediante el producto denominado PAD_virtual. Se trata de un programa cliente desarrollado en lenguaje Java que accede a un servicio en el que se generan disposiciones aleatorias de caracteres. El programa representa en la pantalla del usuario un teclado sobre el que se seleccionan los caracteres que se desean que conformen el nuevo código CHV. Se envían al servidor las coordenadas ocupadas por dichos caracteres y el servidor compone la secuencia de comandos que el programa cliente debe enviar al chip para que éste acepte el cambio. Con este mecanismo se consigue que el nuevo código CHV no viaje en ningún momento entre cliente y servidor, imposibilitando así la interceptación de este dato tan sensible.

8

Protección de mensajes.

La sistema operativo DNIe incorpora la posibilidad de establecer un canal seguro entre el terminal y el chip que proteja los mensajes transmitidos, de hecho el sistema operativo rechazará la ejecución de determinados comandos si no se envían a la tarjeta a través de un canal seguro e identificado. Para el establecimiento es necesaria la autenticación previa del terminal y el chip mediante el uso de certificados. Durante la presencia del canal seguro cada mensajes se cifra y autentica de forma que se asegura una comunicación “una a uno” entre los extremos del canal. El canal seguro puede ser requerido por la aplicación o puede ser una restricción de acceso impuesta por algún recurso de la tarjeta. Para el establecimiento del canal seguro, en primer lugar se realiza un intercambio de las claves públicas de la tarjeta y el terminal mediante certificados que serán verificados por ambas partes. A continuación se ejecuta un protocolo dirigido al establecimiento de una clave de sesión. El procedimiento descrito es una variante del protocolo Diffie-Hellman. Una vez concluido el protocolo para el establecimiento de la clave de sesión todos los mensajes deben transmitirse cifrados con esta clave.

Funcionalidades criptográficas.

•Claves RSA La sistema operativo DNIe es capaz de generar y gestionar claves RSA. La generación de la pareja de claves RSA sigue el estándar PKCS#1 v1.5. Se usa el algoritmo Miller-Rabin como test de primalidad.

•Firmas electrónicas El DNIe tiene capacidad para la realización de firmas electrónicas de dos modos diferentes:

oModo raw. oModo relleno PKCS#1.

Estados del sistema.

Desde el punto de vista operativo, el chip del DNIe tiene tres estados de funcionamiento: •Operacional: estado habitual en el que el sistema ofrece todas las funcionalidades que incorpora. •Terminado: estado en el que se deshabilitan las funcionalidades, y deja de responder a comandos administrativos. •Borrado: estado en el que se destruye el contenido de la memoria EEPROM interna, y se deshabilitan las funcionalidades.

9

Las transiciones entre estados se invocan por reacción ante eventos que pudieran comprometer la seguridad. Las únicas transiciones posibles son de operacional a terminada y de operacional a borrada. Nótese que los eventos que motivan los cambios de estado son independientes de los códigos de respuesta y de la lógica del procesamiento de los comandos en modo operacional, que están diseñados para mantener constante el nivel de seguridad de la tarjeta. Los modos y transiciones indicados garantizan la confidencialidad del contenido del chip, comprometiendo si es necesario su disponibilidad; en determinadas circunstancias, ante actividad que pueda ser reconocida por el chip como algún tipo de ataque, el contenido quedará destruido o inaccesible.

Requisitos de seguridad. Asunciones de entorno.

Los requisitos de seguridad, tanto para el DNIe como para su entorno de operación están descritos en el Perfil de Protección EN-14169 y más específicamente en la Declaración de Seguridad del DNIe. De ésta última, obtenemos que para asegurar la confidencialidad y la integridad de los activos gestionados por el DNIe, su entorno de operación debe cumplir los siguientes requisitos •En relación con la aplicación de generación de certificados (CGA) FCS_CKM.2.1/CGA La tarjeta DNIe debe exportar las claves públicas a la aplicación de generación de certificados, para la posterior generación del certificado de integridad y no repudio. FCS_CKM.3.1/ CGA Una vez generado el certificado, la tarjeta DNIe debe realizar su importación a través de un canal seguro con confidencialidad, integridad y autenticación. FDP_UIT.1.1 / Importación de datos de verificación de firma (SVD) La tarjeta DNIe debe aplicar las políticas de seguridad en relación a la importación de datos de verificación de firma (SVD) para poder recibir datos de usuario de una manera protegida contra errores de modificación e inserción. FDP_UIT.1.2 / Importación de datos de verificación de firma (SVD) La tarjeta DNIe debe ser capaz de determinar, a la recepción de los datos de usuario, si ha ocurrido modificación e inserción. FTP_ITC.1.1 / Importación de datos de verificación de firma (SVD) La tarjeta DNIe debe proporcionar un canal de comunicación, entre sí misma y un producto de tecnología de la información (IT) confiable remoto, que sea distinto lógicamente de otros canales de comunicación y que proporcione la identificación segura de sus extremos y la protección de los datos del canal contra su modificación o pérdida de confidencialidad. FTP_ITC.1.2 / Importación de datos de verificación de firma (SVD) La tarjeta DNIe debe permitir al producto de tecnología de la información (IT) confiable remoto iniciar la comunicación a través del canal confiable. FTP_ITC.1.3 / Importación de datos de verificación de firma (SVD) La tarjeta DNIe debe iniciar la comunicación a través del canal confiable para la importación de datos de verificación de firma (SVD). La tarjeta incorpora funciones de seguridad para satisfacer los requisitos relacionados con la aplicación de generación de certificados. El DNIe no permite la

10

exportación de claves para la generación de certificados si no es a través de canales seguros establecidos con equipos del Cuerpo Nacional de Policía. Por otra parte, la funcionalidad de la tarjeta DNIe detecta cualquier alteración en las comunicaciones, invalidando, como resultado, la misma. Finalmente, la importación de certificados reconocidos, igualmente ha de ser realizada en equipos del Cuerpo Nacional de Policía. Estas medidas de seguridad garantizan la confidencialidad, integridad y autenticación de los datos en tránsito y los generados por cada una de las partes (DNIe y aplicación de generación de certificados). El usuario deberá realizar la solicitud de certificados en las dependencias del Cuerpo Nacional de Policía habilitadas a tal efecto. De este modo, el usuario tendrá todas las garantías del cumplimiento de los requisitos relacionados con el entorno al objeto de la generación de certificados reconocidos. •En relación con la aplicación de generación de firma electrónica (SGA) FCS_COP.1.1/ Hash de la aplicación de creación de firma (SCA) La tarjeta DNIe debe realizar el hash de los datos a ser firmados (DTBS) de acuerdo con el algoritmo criptográfico SHA1. FDP_UIT.1.1 / DTBS de la SCA La tarjeta DNIe debe aplicar las políticas de creación de firma para poder transmitir datos de usuario de una manera protegida contra errores de modificación, borrado e inserción. FDP_UIT.1.2 / DTBS de la SCA La tarjeta DNIe debe ser capaz de determinar, a la recepción de los datos de usuario, si ha ocurrido modificación, borrado e inserción. FTP_ITC.1.1 / DTBS de la SCA La tarjeta DNIe debe proporcionar un canal de comunicación, entre sí misma y un producto de tecnología de la información (IT) confiable remoto, que sea distinto lógicamente de otros canales de comunicación y que proporcione identificación segura de sus extremos y protección de los datos del canal contra la modificación o la pérdida de confidencialidad. FTP_ITC.1.2 / DTBS de la SCA La tarjeta DNIe debe permitir a la propia tarjeta iniciar la comunicación a través del canal confiable. FTP_ITC.1.3 / DTBS de la SCA La tarjeta DNIe debe iniciar la comunicación a través del canal confiable para firmar la representación de datos a ser firmados (DTBS) mediante el dispositivo seguro de creación de firma (SSCD). FTP_TRP.1.1 / SCA La tarjeta DNIe debe proporcionar una ruta de comunicación, entre sí misma y los usuarios locales, que sea lógicamente distinta de otras rutas de comunicación y proporcione identificación segura de sus extremos y protección de los datos comunicados contra la modificación o la pérdida de confidencialidad. FTP_TRP.1.2 / SCA La tarjeta DNIe debe permitir a los usuarios locales iniciar la comunicación a través de la ruta confiable. FTP_TRP.1.3 / SCA La tarjeta DNIe debe exigir el uso de la ruta confiable para la autenticación inicial del usuario. La tarjeta DNI tiene capacidad para realizar un hash o resumen según lo definido en el algoritmo SHA-1 al objeto de realizar firmas electrónicas. Por otra parte, la solicitud de una firma sólo puede ser realizada por el ciudadano previa autenticación del mismo, operación que realiza enviando el código PIN y bajo un canal de comunicaciones cifrado. La tarjeta DNIe sólo aceptará peticiones de firma en caso de que provengan de una SCA, identificada por un par de claves RSA que son utilizadas para establecer un canal seguro entre la tarjeta DNIe y la propia aplicación, dotando a los datos

11

intercambiados de confidencialidad, integridad y no repudio de autoría. Asimismo, ante cualquier perturbación detectada en las comunicaciones o en los propios datos, se generará el correspondiente error, invalidándose lo realizado hasta el momento. Para la correcta interacción de las aplicaciones con el chip DNIe se han de utilizar los módulos criptográficos CSP y PKCS#11 que se encuentran en el URI http://www.dnielectronico.es/descargas/index.html .

Servicio de Atención al Ciudadano. El DNI electrónico dispone de un servicio de atención al ciudadano con las siguientes características:

•

Es prestado de forma permanente, 24 horas al día, 7 días a la semana.

•

Es de ámbito universal, para todo tipo de usuarios.

•

Es gratuito.

•

Su cobertura es integral, atiende cualquier tipo de incidencia del DNI electrónico.

Servicio de Atención al Ciudadano para consultas de carácter administrativo 902.364.444 [email protected]

Consultas técnicas de ciudadanos, empresas y Administraciones [email protected]

12

Glosario de términos y expresiones habituales. Autenticación: el significado de esta palabra en castellano no se corresponde con el acto al que hace referencia en su uso habitual en criptografía. El error hay que buscarlo en la traducción que se ha hecho del verbo inglés “authenticate” que significa simultáneamente autenticar y probar. Esta última acepción, de la que carece la palabra en castellano, es la adecuada en el escenario del uso de certificados electrónicos cuya finalidad es servir de prueba de la identidad de una persona. Así pues, una conexión autenticada mediante certificados es aquella en la que las partes conectadas han probado su identidad (se han identificado mutuamente) mediante certificados. Certificado electrónico: es un documento electrónico firmado por un Prestador de Servicios de Certificación que vincula unos datos de verificación de firma a un firmante y confirma su identidad. Nótese que no se hace referencia a las características que hacen que un PSC tenga el atributo de reconocido; véase la entrada “certificado reconocido”. Esta es la definición de la Ley 59/2003 que en este documento se extiende a los casos en que la vinculación de los datos de verificación de firma se hace a un componente informático. Certificado reconocido: certificado expedido por un Prestador de Servicios de Certificación que cumple los requisitos establecidos en la Ley en cuanto a la comprobación de la identidad y demás circunstancias de los solicitantes y a la fiabilidad y las garantías de los servicios de certificación que presten, de conformidad con lo que dispone el capítulo II del Título II de la Ley 59/2003, de 19 de diciembre, de Firma Electrónica. Certificados de Identidad Pública: emitidos como certificados reconocidos vinculan una serie de datos personales del ciudadano a unas determinadas claves, para garantizar la autenticidad, integridad y no repudio de la autoría de actos de firma. Esta información está firmada electrónicamente por la Autoridad de Certificación creada al efecto. CGA: iniciales de la expresión inglesas Certificates Generation Application, aplicación de generación de certificados. CHV: siglas impropias de la expresión inglesa Cardholder Verification, verificación del titular. La expresión “código CHV” se refiere a una cadena de caracteres, no necesariamente numérica, cuya finalidad es la de demostrar la identidad del titular mediante la aplicación del principio del “secreto compartido”. Es un término más amplio y preciso que el de PIN (Personal Identification Number) pues este último, generalizado desde sus orígenes en la práctica bancaria de gestión de tarjetas de crédito y posteriormente en la de tarjetas GSM, hace referencia como su nombre indica a una cadena numérica. Ciudadano: en el ámbito de uso y aplicación del DNI, se refiere a los ciudadanos españoles.

13

Clave de Sesión: clave simétrica que se establece para cifrar una comunicación entre dos entidades. La clave se establece para cada sesión de comunicación, terminando su utilidad y desechándose una vez finalizada ésta. La sesión puede ser tan corta como para suponer la transmisión de un único comando o tan larga como para que se produzca el complejo intercambio de mensajes que exige una generación de firma electrónica. Clave Personal de Acceso (PIN): véase CHV. CRL: iniciales de la expresión inglesa Certificates Revocation List. Véase Lista de Revocación de Certificados. Datos de creación de Firma (Clave Privada): son datos únicos, como códigos o claves criptográficas privadas, que el suscriptor utiliza para crear la firma electrónica. Datos de verificación de Firma (Clave Pública): son los datos, como códigos o claves criptográficas públicas, que se utilizan para verificar la firma electrónica. Dispositivo seguro de creación de firma: instrumento que sirve para aplicar los datos de creación de firma cumpliendo con los requisitos que establece el artículo 24.3 de la Ley 59/2003, de 19 de diciembre, de Firma Electrónica. Documento electrónico: conjunto de datos almacenado en soporte susceptible de ser leído por equipos electrónicos de procesamiento de datos. Documento de seguridad: documento exigido por la Ley Orgánica 15/99 de Protección de Datos de Carácter Personal cuyo objetivo es establecer las medidas de seguridad implantadas, a los efectos de este documento, por la DGPGC como Prestador de Servicios de Certificación, para la protección de los datos de carácter personal contenidos en los ficheros de la actividad de certificación que contienen datos personales. DPC, Declaración de Políticas de Certificación: documento en el que la Autoridad de Certificación declara de forma detallada las prácticas que tiene previsto aplicar durante el ciclo de vida a los certificados que emita y los aspectos relativos a la seguridad en sentido amplio. DSCF: Véase Dispositivo seguro de creación de firma. Encargado del tratamiento: la persona física o jurídica, autoridad pública, servicio o cualquier otro organismo que trate datos personales por cuenta del responsable del tratamiento de los ficheros. Firma electrónica: es el conjunto de datos en forma electrónica, consignados junto a otros o asociados con ellos, que pueden ser utilizados como medio de identificación personal y para garantizar la integridad de un documento electrónico.

14

Firma electrónica avanzada: es aquella firma electrónica que permite establecer la identidad personal del suscriptor respecto de los datos firmados y comprobar la integridad de los mismos, por estar vinculada de manera exclusiva tanto al suscriptor, como a los datos a que se refiere, y por haber sido creada por medios que mantiene bajo su exclusivo control. Firma electrónica reconocida: es aquella firma electrónica avanzada basada en un certificado reconocido y generada mediante un dispositivo seguro de creación de firma. Función hash: esta expresión se refiere a una forma de correspondencia matemática en base a la cual se realiza una serie de operaciones algebraicas sobre un conjunto de datos de cualquier tamaño de forma que el resultado obtenido es otro conjunto de datos de tamaño fijo y habitualmente menor al original y que representa de forma bastante unívoca al conjunto original. Hash o huella digital: valor que se obtiene tras aplicar una función hash a un conjunto de datos. HSM: siglas de la expresión inglesa Hardware Security Module. Véase Módulo Hardware de Seguridad. Identificador de usuario: conjunto de caracteres que se utilizan para la identificación unívoca de un usuario en un sistema. Jerarquía de confianza: conjunto de autoridades de certificación que mantienen relaciones de confianza por las cuales una AC de nivel superior garantiza la confiabilidad de una o varias de nivel inferior. En el caso de DNIe, la jerarquía tiene dos niveles, la AC Raíz en el nivel superior es el origen de la confianza en sus AC subordinadas. Listas de Revocación de Certificados o Listas de Certificados Revocados: ficheros donde figuran exclusivamente aquellos certificados que han sido revocados o suspendidos (no los caducados). En el caso de la PKI del DNIe no existe el estado “suspendido”. Módulo Hardware de Seguridad: dispositivo utilizado para realizar funciones criptográficas (generación de claves y operaciones asociadas) y almacenar claves en un entorno seguro. Es más habitualmente conocido por sus siglas en inglés: HSM. Prestador de Servicios de Certificación: persona física o jurídica que expide certificados electrónicos o presta otros servicios en relación con la certificación y la firma electrónica. Punto de Actualización del DNIe: terminal ubicado en las Oficinas de Expedición que permite al ciudadano de forma guiada, sin la intervención de un funcionario, la realización de ciertas operaciones con el DNIe (comprobación de datos almacenados en la tarjeta, renovación de los certificados de identidad pública, cambio de clave personal de acceso y comprobación funcional de la tarjeta).

15

SCA: siglas de la expresión inglesa Signing Creation Aplication, Aplicación de generación de firma. SSCD: siglas de la expresión inglesa Secure Signature-Creation Device. Véase Dispositivo seguro de creación de firma. Tercero Aceptante: persona o entidad diferente del titular que decide confiar en un certificado emitido por un determinado Prestador de Servicios de Certificación.

16

ANEXO I Desarrollo de la funcionalidad de seguridad

Si bien las prestaciones electrónicas del DNIe pueden ser invocadas a través de las librerías CSP y PKCS#11 provistas, la tarjeta proporciona funciones accesibles a través de su interfaz de comandos para desarrollarla en los términos que desee el usuario. La invocación de estos comandos se rige por lo definido en el estándar ISO IEC 7816. En el resto del presente documento, la palabra comando hace siempre referencia a los comandos APDU definidos en esa norma, más concretamente en el documento ISO7816-4. Refiérase el lector a dicha norma para un estudio en profundidad de las características, prestaciones y sintaxis de cada comando y sus respuestas.

Identificación La tarjeta DNIe dispone de distintos métodos de identificación para que el usuario acceda a los recursos, pero sólo la identificación mediante código CHV está disponible para los usuarios. Una operación exitosa de identificación mediante código CHV conlleva la satisfacción de determinadas condiciones de seguridad, requisito indispensable para el acceso a los activos del DNIe. El comando que se ha de invocar para obtener esta funcionalidad es: -Verify Desbloqueo y cambio de PIN Se permite el cambio de PIN, mediante la presentación del valor antiguo. Es posible también el cambio de PIN bajo determinadas condiciones (canal seguro basado en certificado de componente en combinación con una clave de aplicación) tras la realización de una verificación biométrica. Esta operación se considera de administración de la seguridad del dispositivo por lo que el usuario deberá utilizar los mecanismos provistos por la Dirección General de la Policía y de la Guardia Civil.

Establecimiento de canal seguro. La tarjeta DNIe permite la posibilidad de establecer un canal seguro de usuario que cifre el tráfico de mensajes entre el terminal y la tarjeta. Para el establecimiento es necesaria la identificación previa del terminal y de la tarjeta mediante el uso de certificados. Durante la presencia del canal seguro los mensajes se cifran y se comprueba su autoría de tal forma que se asegura una comunicación “una a uno” entre los dos extremos del canal. El lector puede encontrar una descripción detallada de este protocolo en la norma EN-14890. Este canal seguro es un requisito obligatorio para la realización de firma electrónica y la autenticación del usuario. Los comandos APDU que hay que invocar para el establecimiento del este tipo de canal son, en este orden: •Get Chip Info, •Select File (6020) •Get Response •Read Binary (Lectura del Certificado de Autoridad intermedia para componentes)

17

•Select File (3F00) •Get Response •Select File (601F) •Get Response •Read Binary (Lectura del Certificado Componente) •Manage Security Environment (Seleccion Root CA), •Perform Security Operation (Verificar Certificado Autoverificable de la CA intermedia) •Manage Security Environment (Seleccion de clave en memoria y modo de uso), •Perform Security Operation (Verificar Certificado Autoverificable del terminal) •Manage Security Environment (Seleccion de claves para autenticación), •Internal Authenticate •Get Response •Get Challenge •External Authenticate Funcionalidades criptográficas. •Generación de claves RSA para la firma electrónica. El usuario puede realizar una generación de claves al objeto de obtener un certificado reconocido para la realización de firma electrónica pero debido a los requisitos de seguridad para las aplicaciones de generación de certificados reconocidos, el ciudadano sólo podrá realizar esta operación en las dependencias del Cuerpo Nacional de Policía habilitadas a este efecto. •Firmas electrónicas La tarjeta DNIe tiene capacidad para la realización de firmas electrónicas. Primero se establecerá canal seguro de usuario con los comandos descritos anteriormente. La aplicación de generación de firma, en el proceso de establecimiento del canal seguro, se deberá autenticar con los certificados del terminal y la clave RSA asociada. Esto es necesario para poder invocar la funcionalidad de firma. A continuación, se invocarán los siguientes comandos: 1)Verify (Para autenticación del usuario) 2)Manage Security Environment (Selección de clave y modo de uso), 3)Perform Security Operation (Cálculo de una firma) Las aplicaciones de generación de firma pueden ser construidas a partir de los módulos PKCS#11 y CSP que proporciona la Dirección General de la Policía y de la Guardia Civil. Estos módulos incluyen todos los datos, funciones y algoritmos necesarios para la comunicación con el DNIe y realizan todas las operaciones habituales que pueden ser requeridas por una aplicación de firma, un cliente de correo o un navegador web. No obstante, aquellos usuarios que decidan programar un módulo PKCS#11 o un CSP a medida necesitarán conocer las claves implicadas en el establecimiento de canal seguro. Estas claves se incluyen en el ANEXO III.

18

ANEXO II Comandos APDU necesarios para el desarrollo de la funcionalidad de seguridad de la tarjeta DNIe como dispositivo seguro de creación de firma.

NOTA: El presente anexo no pretende ser una transcripción, traducción o extracto de la norma ISO-IEC 7816-4. Si necesita información más precisa sobre el contenido de este anexo, por favor refiérase a dicha norma. Los ejemplos se proponen en su forma más genérica y no se basan en casos reales; no incorporan parámetros que puedan ser funcionales en algún escenario y su única finalidad es didáctica.

Comando GET CHALLENGE El comando Get Challenge genera la emisión de un desafío (p.e. un número aleatorio) que podrá formar parte de un procedimiento de seguridad.

Codificación del comando Byte CLA INS P1 P2 LC Data

Valor 0x00 0x84 0x00 0x00

Significado

Vacío Vacío Longitud del desafío de 8 bytes, para establecimiento de canal seguro

0x08

Mensaje de respuesta Datos SW1-SW2

Significado Datos del desafío Bytes de estado

Condiciones de estado SW1 0x67 0x6A

SW2 0x00 0x86

Significado Longitud incorrecta Parámetros incorrectos P1-P2

Ejemplo: Terminal 00 84 00 00 08

Tarjeta   xx xx xx xx xx xx xx xx 90 00 (Número aleatorio, 8 bytes)

19

Comando GET CHIP INFO Permite obtener información del chip relativa al número de serie.

Codificación del comando Byte CLA INS P1 P2 LC Data LE

Valor 0x90 0xB8 0x00 0x00

Significado

Vacío Vacío Número de serie

0x07

Mensaje de respuesta Datos

Tamaño Significado 0x07 Número de serie Bytes de estado

SW1-SW2

Condiciones de estado SW1 0x67 0x6A

SW2

Significado Longitud incorrecta (el campo Lc no 0x00 es correcto) 0x86 Parámetros P1-P2 incorrectos

Ejemplo: Terminal 90 B8 00 00 07

Tarjeta   xx xx xx xx xx xx xx 90 00 (Número de serie, 7 bytes)

20

Comando GET RESPONSE Este comando es usado para provocar que la tarjeta trasmita al dispositivo externo la respuesta APDU (o parte) que de otra manera no podría ser transmitida por el protocolo T=0.

Codificación del comando Byte CLA INS P1 P2 LC Data

Valor 0x00 0xC0 0x00 0x00

Significado

Vacío Vacío Longitud de los datos esperados como respuesta

LE

Mensaje de respuesta

Datos SW1-SW2

Significado Mensaje respuesta(o parte) de acuerdo a LE Bytes de estado

Condiciones de estado SW1

SW2

0x61

0xXX

0x69

0x85

0x6C

0xXX

0x90

0x00

Significado Ejecución correcta. Quedan datos disponibles en la tarjeta. Condiciones de uso no satisfechas Longitud incorrecta (XX indica el valor correcto) Ejecución correcta.

Ejemplo: Terminal 00 C0 00 00 xx

Tarjeta

xx Long de datos solicitados, en este ejemplo: 0A   xx xx xx xx xx xx xx xx xx xx 90 00 (Datos comando, 10 bytes)

21

Comando EXTERNAL AUTHENTICATION. Completa la ejecución de un protocolo de tipo desafío-respuesta con el fin de autenticar a una entidad externa. Se trata de una autenticación de la entidad externa, habitualmente un terminal, como parte un intercambio de claves para el establecimiento de canal seguro según EN-14890-1 apartado 8.4. Está basado en claves RSA de 1024 bits, y requiere que la clave pública del terminal sea cargada en la tarjeta mediante un certificado.

Codificación del comando Byte CLA INS P1 P2

Valor 0x00 0x82 0x00 0x0X

LC

Significado

Key Id Longitud de los datos, coincide Kpub de la tarjeta

Data

Datos

LE

Vacío

Long

Estructura del comando para autenticación según EN-14890 ap 8.4 E[PK.ICC.AUT](SIGMIN) Donde SIGMIN = min (SIG, N.IFD - SIG) y SIG= DS[SK.IFD.AUT] ( ‘6A’ = relleno según ISO 9796-2 (DS scheme 1) PRND2 =‘XX ... XX’ bytes de relleno aleatorios generados por el terminal. La longitud debe ser la necesaria para que la longitud desde ‘6A” hasta ‘BC” coincida con la longitud de la clave RSA KIFD = Semilla de 32 bytes, generada por el terminal, para la derivación de claves del canal seguro. h[PRND2 || KIFD || RND.ICC || SN.ICC ] = hash SHA1 que incluye

los datos aportados por la tarjeta y por el terminal ‘BC’ = relleno según ISO 9796-2 (option 1)

)

El bloque de datos ‘6A” || PRND2 || K IFD || h || ‘BC’ es firmado con la clave privada del terminal (SK.IFD.AUT). Al resultado de esta firma (SIG) se le aplica la función SIGMIN para luego poder encriptar el resultado con la clave pública de la tarjeta (PK.ICC.AUT). Para poder realizar esta operación, es necesario que el tamaño de las dos claves RSA implicadas (PK.ICC.AUT y SK.IFD.AUT) sea el mismo. La tarjeta descifrará el mensaje utilizando su clave privada, y verificará la firma utilizando la clave pública del terminal, que deberá haber sido cargada previamente mediante un certificado verificable en la tarjeta. Ambas claves deben estar seleccionadas previamente en la plantilla de autenticación.

22

Mensaje del comando Meaning Data field SW1-SW2

Vacío Bytes de estado

Condiciones de estado SW1

SW2

0x63

0xCX

0x65 0x67 0x69 0x69 0x6A 0x6A 0x6A 0x6A

0x81 0x00 0x83 0x85 0x80 0x86 0x87 0x88

Meaning El código de autenticación no es válido. X expresa el número de intentos posibles. Error de memoria Longitud incorrecta Método de autenticación bloqueado Condiciones de uso no satisfechas Error en el campo de datos Parámetros incorrectos P1-P2 Lc inconsistente con P1-P2 Datos referenciados no encontrados

Ejemplo: Terminal 00 82 00 00 P3

Tarjeta

xx xx xx ..... xx xx P3: long clave pública de tarjeta xx xx xx .... xx xx Datos para autenticación externa por parte del terminal   90 00

23

Comando INTERNAL AUTHENTICATION. Inicia el cálculo de una autenticación del origen de la tarjeta. El sistema de transmisión manda un desafío a la tarjeta que se firma con la clave privada RSA interna de identificación. Este comando forma parte del esquema de establecimiento de canal seguro de usuario. Este comando permitirá validar la autenticidad de la tarjeta e intercambiar de forma segura las semillas que luego se utilizarán para establecer un canal seguro con intercambio de claves según EN-14890-1 apartado 8.4. Se utilizan claves RSA de 1024, y una firma SHA1

Codificación del comando Byte CLA INS

Valor 0x00 0x88

P1

0x00

P2 LC

0x00 0x10

Significado

Autenticación interna con establecimiento de canal Autenticación según EN-14890 RND.IFD || SN.IFD Autenticación según EN-14890 ap. 8.4 Vacío

Data LE

Mensaje de respuesta Autenticación según EN-14890 ap. 8.4 E[PK.IFD.AUT] (SIGMIN) Donde SIGMIN = min (SIG, N.ICC - SIG) y SIG= DS[SK.ICC.AUT] ( ‘6A’ = relleno según ISO 9796-2 (DS scheme 1) PRND1 = ‘XX ... XX’ bytes de relleno aleatorios generados en la tarjeta. La longitud debe ser la necesaria para que la longitud desde ‘6A” hasta ‘BC” coincida con la longitud de la clave RSA KICC = Semilla de 32 bytes, generada por la tarjeta, para la derivación de claves del canal seguro. h[PRND1 || KICC || RND.IFD || SN.IFD2 ] = hash SHA1 que incluye

los datos aportados por la tarjeta y por el terminal ‘BC’ = relleno según ISO 9796-2 (option 1)

) El bloque de datos ‘6A” || PRND1 || KICC || h || ‘BC’ es firmado con la clave privada de la tarjeta (SK.ICC.AUT), que debe estar seleccionada en la plantilla de autenticación. Al resultado de esta firma (SIG) se le aplica la función SIGMIN para luego poder encriptar el resultado con la clave pública del terminal (PK.IFD.AUT), que previamente se deberá haber cargado (mediante certificados verificables en la tarjeta), y seleccionado en la plantilla de autenticación. Para poder realizar esta operación, es necesario que el tamaño de las dos claves RSA implicadas (PK.IFD.AUT y SK.ICC.AUT) sea el mismo.

24

Condiciones de estado SW1

SW2

0x61

0xXX

0x62

0x83

0x65

0x81

0x69

0x82

0x69 0x6A

0x85 0x80

0x6A

0x82

0x6A 0x6A

0x86 0x88

Significado SW2 indica el número de bytes disponibles en la tarjeta como datos de respuesta. El fichero seleccionado está invalidado Error de memoria Condiciones de seguridad no satisfechas Condiciones de uso no satisfechas Error en el campo de datos No se ha encontrado el EF criptográfico Parámetros incorrectos P1-P2 Datos referenciados no encontrados

Ejemplo: Terminal 00 88 00 00 10 xx .. xx yy .. yy xx .. xx desafío del Terminal yy .. yy nº serie Terminal

Tarjeta

  61 LL 00 C0 00 00 LL   xx xx xx ….. xx xx 90 00 (Datos de la tarjeta para la autenticación interna) P3 = longitud clave de la tarjeta

25

Comando MANAGE SECURITY ENVIRONMENT. Este comando permite la selección de las diferentes claves y algoritmos que serán utilizados en operaciones posteriores de los comandos Perform Security Operation, External Authentication, e Internal Autentication. Para ello se utiliza el concepto de ‘security environment’ (SE) definido en ISO 7816-4. Estos SE incluyen diferentes plantillas, cada una de ellas con una función determinada, en las que se pueden seleccionar distintos parámetros necesarios para operaciones criptográficas posteriores. Algunos de los parámetros incluidos en estas plantillas son referencias a distintas claves existentes en la tarjeta. Los formatos de estas referencias se describen en la siguiente tabla:

Tipo de referencia KRT_CRYPTO

Tamaño 2 bytes

Formato 0x01 || KeyID

KRT_IDENT

2 bytes

0x02 || KeyID

KRT_MEMORY

N bytes

CHR del certificado

Descripción Referencia una clave RSA privada almacenada en ICC.CRYPTO con el identificador KeyID Referencia una clave RSA (pública o privada) almacenada en ICC.ID con el identificador KeyID Referencia claves pública RSA en memoria. Su valor debe coincidir con el campo “Certificate Holder Refererence” (CHR) incluido en el certificado utilizado para cargar la clave.

A continuación se detallan las plantillas definidas, y los parámetros permitidos por cada una:

Plantilla Autenticación (AT).

Firma (DST)

Parámetros oReferencia a la clave privada de la tarjeta, para la autenticación. Tiene que estar en ICC.ID, y con un identificador entre 0x10 y 0x1f •Referencia a la clave pública del terminal, para la autenticación. Tiene que estar en memoria, y haber sido cargada mediante un certificado de terminal correctamente verificado. •Identificador de algoritmo, indicando el tipo de autenticación que se va a realizar •Referencia a la clave privada con la que se quiere realizar una operación de firma (con PSO:Sign). Tiene que estar en ICC.CRYPTO •Referencia a una clave pública que se quiere utilizar para verificar un certificado. Puede tratarse de una clave de CA raíz, alojada en ICC.ID (con identificador entre 0x00 y 0x0f), o de una clave en memoria, cargada mediante un certificado de autoridad certificadora correctamente verificado •Identificador de algoritmo, indicando el tipo de relleno que se debe utilizar en una operación de firma posterior 26

Codificación del comando Byte CLA INS P1 P2 LC

Valor 0x00 0x22 0xX1 0xXX

Significado

Tipo de operación. Plantilla a modificar Vacío o longitud del campo de datos ‘Data Objects’ a incluir en la plantilla

Data LE

El parámetro P1 indica qué tipo de operación se va a realizar, y qué elementos se están suministrando a la plantilla. Sólo se soporta la modificación del SE actual, por lo que el segundo nibble siempre deberá ser ‘0001’. La siguiente tabla muestra la codificación de este valor. b b7 8 - - - 1 1 - -

B6 1 -

b5 1 -

b4 -

b3 -

b2 -

b1 -

Significado Asegurar el mensaje que aparece en campo de datos del comando Asegurar el mensaje que aparece en campo de datos de respuesta Cálculo, descifrado, autenticación interna y acuerdo de claves Verificación, cifrado, autenticación externa y acuerdo de claves

-

-

0

0

0

1

SET

La siguiente tabla muestra los posibles valores de P2, que identifican la plantilla a utilizar.

Valor ‘A4’ ‘A6’ ‘B6’

Significado Plantilla de autenticación Plantilla para intercambio de claves Plantilla para firmas

Mensaje de respuesta Datos SW1-SW2

Significado Vacío Bytes de estado

Condiciones de estado SW1 0x62 0x6A 0x6A 0x6A 0x6A

SW2 0x83 0x82 0x86 0x87 0x88

Significado Fichero invalidado Fichero no encontrado Parámetros incorrectos P1-P2 Longitud de datos incorrecta Datos referenciados no encontrados

27

Ejemplo: Ejemplo 1: Selección de la clave Root CA Terminal 00 22 81 B6 04 83 02 02 0F

Tarjeta   90 00

Ejemplo 2: Selección de la clave en memoria Terminal 00 22 81 B6 0A 83 08 xx .. xx

Tarjeta

xx .. xx Identificador de la clave recuperada en memoria. CHR del certificado autoverificable (8 bytes)   90 00

Ejemplo 3: Selección de la clave en memoria para Autenticación interna Terminal 00 22 C1 A4 0A

Tarjeta 83 0C xx .. xx 84 02 02 1F

xx .. xx Número de serie del Terminal (12 bytes)   90 00

Ejemplo 4: Selección de la clave para autenticación Terminal 00 22 41 B6 04 83 02 01 01

Tarjeta

01 01 Identificador fichero de la clave para autenticación (2 bytes)   90 00

28

Ejemplo 5: Selección de la clave para firma Terminal 00 22 41 B6 04 84 02 01 02

Tarjeta

01 02 Identificador fichero de la clave para firma o no repudio (2 bytes)   90 00

Comando PERFORM SECURITY OPERATION. Este comando permite realizar las siguientes operaciones relacionadas con los procesos de autenticación y firma:

Validación de un certificado Este sub-comando permite la verificación de un certificado, utilizando la clave pública de la autoridad certificadora raíz almacenada en la tarjeta, o una clave pública de una autoridad certificadora intermedia, cargada anteriormente mediante otro certificado. El formato de los certificados en el definido en el documento EN-14890-1 capítulo 14. Se soportan los certificados de acuerdo a las plantillas con identificadores (CPI) 3 y 4 (únicos definidos hasta la fecha en el mencionado documento) Los certificados con CPI=3 son utilizados para la cargar la clave pública de una autoridad certificadora intermedia. Su formato es el siguiente: ‘7F 21’

‘81 CE’

C_CV certificate ‘5F 37’

‘81 80’

Longitud de la firma (ejemplo para claves de 1024 bits) ‘6A’ = Relleno según ISO 9796-2 CPI = ‘03’ CAR = Certification Authority Reference CHR = Card Holder Reference CHA = AID[1..6] || Role Identifier ‘a0 00 00 01 67 45’ || Role Identifier OID = ‘2B 24 03 04 02 02 01' PK_part1 = ‘XX ... XX’ (MSB..LSB) Hash = ‘XX ...XX’ ‘BC’

‘5F 38’

‘3D’

‘42’

‘08’

Los campos descritos no están en claro en el certificado, si no que son la entrada de la firma incluida en esta sección. PK_part2 = ‘XX ... XX’ (MSB..LSB) || ‘00 01 00 01’ Incluye el resto de la clave pública, que no se pudo poner en PK_part1 (resto del módulo y exponente público en 4 bytes) Se incluye también en claro para poder CAR identificar la autoridad que firma el certificado

29

La codificación de los campos es la siguiente: CPI es el identificador de la plantilla con que está construida el certificado (Certificate Profile Identifier). Este campo ocupa un solo byte. CAR es un campo de ocho bytes, que identifica la autoridad certificadora que emitió el certificado. (Certification Authority Reference) CHR es el identificador del propietario del certificado (Card Holder Reference), en este caso, corresponde a la autoridad certificadora intermedia cuya clave pública contiene este certificado. Este campo ocupa siempre doce bytes, compuesto por cuatro bytes de relleno a cero, y el identificador de la autoridad certificadora. CHA indica los niveles de autorización que se conceden al propietario del certificado (Certificate Holder Authorization). Es un campo de siete bytes, en los que los seis primeros son la parte más significativa del identificador de aplicación definido en EN-14890 (A0 00 00 01 67 45), y el último byte es el identificador de ‘rol’ del certificado. OID es un campo de siete bytes con el identificador de objeto definido en EN-14890. Su valor debe ser 2B 24 03 04 02 02 01 PK_part1 es la primera parte de la clave pública incluida en el certificado. La clave pública RSA está formada por el módulo, concatenado con el exponente público codificado en 4 bytes. En este campo se incluirá el máximo número de bytes posible (en función del tamaño de las claves) y el resto deberá ir en claro en el campo PK_part2 Hash es el resultado de aplicar la función SHA1 a la concatenación de los campos CPI, CAR, CHR, CHA, OID, y la clave pública completa. PK_part2 es el campo con la parte de la clave pública que no se pudo incluir en PK_part1 El bloque de datos ‘6A’ || CPI || CAR || CHR || CHA || OID || PK_part1 || Hash || ‘BC’ constituye la parte a firmar del certificado, y deberá tener el mismo tamaño que la clave RSA con la que está firmado el certificado. Los certificados con CPI=4 son utilizados para la cargar la clave pública de un terminal, que será utilizada a continuación en un proceso de autenticación. Su formato es el siguiente: ‘7F 21’

‘81 CD’

C_CV Certificate ‘5F 37’

‘81 80’

Longitud de la firma (ejemplo para claves de 1024 bits) ‘6A’ = Relleno según ISO 9796-2 CPI = ‘04’ CAR = Defined by Card Manufacturer CHR = Certificate Holder Reference CHA = AID[1..6] || Role Identifier OID = ‘2B 24 07 02 01 01’ PK_part1 = ‘xx..xx’ (MSB..LSB) Hash = ‘xx..xx’ ‘BC

‘5F 38’

‘3C’

‘42’

‘08’

Los campos descritos no están en claro en el certificado, si no que son la entrada de la firma incluida en esta sección. PK_part2 = ‘XX ... XX’ (MSB..LSB) || ‘00 01 00 01’ Incluye el resto de la clave pública, que no se pudo poner en PK_part1 (resto del módulo y exponente público en 4 bytes) Se incluye también en claro para poder CAR identificar la autoridad que firma el certificado

La codificación de los campos es la siguiente: CPI es el identificador de la plantilla con que está construida el certificado (Certificate Profile Identifier). Este campo ocupa un solo byte. CAR es un campo de ocho bytes, que identifica la autoridad certificadora que emitió el certificado. (Certification Authority Reference)

30

CHR es el identificador del propietario del certificado (Card Holder Reference), en este caso, corresponde al número de serie del terminal propietario del certificado. El campo ocupa siempre doce bytes. Si el número de serie es de menor longitud, se completará con ceros a la izquierda. Se considera que el número de serie es al menos de ocho bytes. CHA indica los niveles de autorización que se conceden al propietario del certificado (Certificate Holder Authorisation). Es un campo de siete bytes, en los que los seis primeros son la parte más significativa del identificador de aplicación definido en EN-14890 (A0 00 00 01 67 45), y el último byte es el identificador de ‘rol’ del certificado. OID es un campo de seis bytes con el identificador de objeto definido en EN-14890. Su valor debe ser 2B 24 07 02 01 01 PK_part1 es la primera parte de la clave pública incluida en el certificado. La clave pública RSA está formada por el módulo, concatenado con el exponente público codificado en 4 bytes. En este campo se incluirá el máximo número de bytes posible (en función del tamaño de las claves) y el resto deberá ir en claro en el campo PK_part2 Hash es el resultado de aplicar la función SHA1 a la concatenación de los campos CPI, CAR, CHR, CHA, OID, y la clave pública completa. PK_part2 es el campo con la parte de la clave pública que no se pudo incluir en PK_part1 El bloque de datos ‘6A’ || CPI || CAR || CHR || CHA || OID || PK_part1 || Hash || ‘BC’ constituye la parte a firmar del certificado, y deberá tener el mismo tamaño que la clave RSA con la que está firmado el certificado. Los identificadores de rol soportados son los siguientes:

Rol ID 0010 0001 0010 0010 0000 0010

Uso del certificado Puede utilizarse para la verificación de firma en una cadena cruzada de certificados Puede utilizarse para la verificación de firma en una cadena de certificados Puede utilizarse en el proceso de establecimiento de un canal seguro de usuario

31

Firma de un hash calculado externamente Este sub-comando permite firmar unos datos directamente enviados en el comando. La firma se realiza con una clave privada RSA ubicada en ICC.CRYPTO. El formato de rellenos de los datos sobre los que se realizará el hash viene indicado en la tabla siguiente: DSI PKCS#1 V2.x T

L

V (Ejemplo con módulo de 1024 bits)

-

-

‘00’ = Byte de inicio ‘01’ = Tipo de bloque ‘FF..FF’ = Cadena de relleno, PS (mínimo 8 bytes) ‘00’ = Separador DigestInfo = ASN.1- Secuencia de OID y resumen . { SHA1 : 30 21 30 09 06 05 2b 0e 03 02 1a 05 00 04 14 } ‘xx..xx’ = Hash

En caso de que los datos a firmar se incluyan directamente en el comando, la firma se realizará con formato PKCS#1, como indica EN-14890-2 apartado 6.3. Los datos no deberán exceder el 40% del tamaño de la clave RSA utilizada.

Codificación del comando Byte CLA INS

Valor 0x00 0x2A

P1

0xXX

P2

0xXX

LC Dato s LE

0x14

Significado

Tag indicando el tipo de datos de la respuesta Tag indicando el tipo de datos enviado Longitud de los datos Datos de entrada Datos de salida

La siguiente tabla indica las posibles combinaciones de P1-P2 soportadas

P1 ‘00’

P2 ‘AE’

‘90’

‘80’

‘90’

‘A0’

Operación Verificación de certificado. Los datos de entrada son el certificado, y no se esperan datos de respuesta Calculo de hash. En la entrada se entregan datos sin estructura, y la respuesta es el hash calculado por la tarjeta. Este hash quedará disponible para una firma realizada en el siguiente comando Calculo de hash. En la entrada se entregan los datos 32

‘9E’

‘9A’

con estructura, permitiendo realizar el hash parcialmente fuera de la tarjeta. La respuesta será el hash calculado Calculo de una firma. Si el tamaño de los datos de entrada es cero, se firmará el hash generado anteriormente, en caso contrario, se firmarán los datos enviados en el comando. La respuesta es la firma generada

Mensaje de respuesta

Datos SW1-SW2

Significado Mensaje respuesta(o parte) de acuerdo a LE Bytes de estado

Condiciones de estado SW1 0x62 0x65

SW2 0x83 0x81

0x69

0x82

0x69

0x85

0x69 0x6A 0x6A 0x6A 0x6A 0x6A

0x86 0x80 0x82 0x86 0x87 0x88

Significado Fichero invalidado Error de memoria Condiciones de seguridad no satisfechas Condiciones de uso no satisfechas (secuencia de comandos incorrecta) Tipo de fichero incorrecto Campo de datos incorrecto Fichero no encontrado Parámetros incorrectos P1-P2 Longitud de datos incorrecta Datos referenciados no encontrados

Ejemplos: Ejemplo 1: Verificar Certificado Autoverificable CA intermedia Terminal 00 2A 00 AE P3

Tarjeta 

 xx .. xx 90 00 xx .. xx Certificado autoverificable de la CA intermedia (longitud P3)

33

Ejemplo 2: Verificar Certificado Autoverificable Certificado Terminal Terminal 00 2A 00 AE P3

Tarjeta   xx .. xx 90 00 xx .. xx Certificado autoverificable del Terminal (longitud P3)

Ejemplo 3: Cálculo de un hash en la tarjeta Terminal 00 2A 90 80 P3 xx .. xx datos sobre los que se calculará el hash. Longitud de los datos P3

Tarjeta

  61 14 0x14, hash disponible (longitud 20 bytes)

Ejemplo 4: Firma de un hash con formato PKCS#1 Terminal 00 2A 9E 9A 23 00 2A 9e 9A 23 30 21 30 09 06 05 2b 0e 03 02 1A 05 00 04 14 83 9b 54 3f b0 9d 20 c8 03 b4 6e 6f 8f 07 47 24 49 51 82 2f

Tarjeta

Datos = Digest Info + SHA1   61 xx Firma disponible formato PKCS#1 (longitud xx bytes, long de la clave RSA que firma)

34

Comando SELECT. Este comando permite la selección de fichero dedicado (DF) o de un fichero elemental (EF).

Codificación del comando Byte CLA INS P1 P2 LC Data LE

Valor 0x00 0xA4

Significado

Selecciona DF o EF por Id (data field = id) Selección directa de DF por nombre.

0x00 0x04 0x00

Longitud del campo de datos Datos de acuerdo a P1-P2 Vacio

Mensaje de respuesta

Datos SW1-SW2

Significado Plantilla FCI acorde con ISO 78164/9. Bytes de estado

La información de control del fichero (FCI) es la cadena de datos que se recibe en respuesta a un comando SELECT FILE.

0x6F T 0x84 0x85

Plantilla FCI acorde con ISO 7816-4/9. Longitud de los subsiguientes Objetos de Datos L Valor 0xXX Nombre del DF name. (Solo para DFs) 0xXX Información propietaria: Long. Significado

Long.

0x01 0x02 0x02 0x05

File descriptor byte: •0x01 Elementary File (EF) •0x34 Dedicated File (DF) •0x15 EF propietario para claves. Linear variable SIMPLE-TLV Identificador de Fichero Número de datos en el fichero, excluyendo la información de la estructura cabecera del fichero Atributos de seguridad, información propietaria

35

0x6F T 0x84 0x85

Plantilla FCI acorde con ISO 7816-4/9. Longitud de los subsiguientes Objetos de Datos L Valor 0xXX Nombre del DF name. (Solo para DFs) 0xXX Información propietaria: Long. Significado

Long.

Control Flag for Security files Security Efs (type 0x15)

0x01

------------0000 ------1---10-01---1 ----100 -010 -001

000-b 001-b 010-b 011-b 100-b 101-b 110-b 1---b 1---b 1---b 1---b 111-b 111-b 111-b 111-b

CHV keys App Keys RFU RFU Empty RSA KEY file RFU Active RSA Key Key generated internally RSA Key in CRT format RSA Key without CRT RFU Inactive RSA Key Inactive RSA Key Type 1 Inactive RSA Key Type 2 Inactive RSA Key Type 3

Control bytes for RSA cryptographic files Cryptographic Efs (type 0x15)

0x02

RSA KEY in CRT format ---- ----b XXXX XXXXb bit length of the key in 64 base 0000 0000b ---- ----b empty key 1--- ----b ---- ----b q present -1-- ----b ---- ----b p present --1- ----b ---- ----b CRT present ---1 ----b ---- ----b d mod (p-1) present ---- 1---b ---- ----b d mod (q-1) present ---- --1-b ---- ----b public exponent present ---- ---1b ---- ----b modulus present 1111 1011b ---- ----b valid RSA with CRT key Inactive RSA KEY ---- ----b XXXX XXXXb bit length of the key in 64 base 0000 0000b ---- ----b empty key ---- -1--b ---- ----b A8h-A9h-B8h present ---- --1-b ---- ----b Aah-ABh-BAh present ---- ---1b ---- ----b Ach-BCh Hash present 0000 0111b ---- ----b valid inactive RSA key RSA KEY without CRT ---- ----b XXXX XXXXb bit length of the key in 64 base 0000 0000b ---- ----b empty key ---- -1--b ---- ----b private present ---- --1-b ---- ----b public exponent present ---- ---1b ---- ----b modulus present 0000 0111b ---- ----b valid RSA key

‘-‘ significa que el valor no tiene significado en el contexto ‘X’ significa cualquier valor

Condiciones de estado SW1

SW2

0x61

0xXX

0x62 0x65 0x6A 0x6A 0x6A

0x83 0x81 0x82 0x86 0x87

Significado Ejecución correcta. Se indica el número de bytes disponibles en respuesta al comando como una estructura FCI. Fichero seleccionado invalidado Error de memoria (FCI erróneo) Fichero no encontrado Parámetros incorrectos P1-P2 Lc inconsistente con P1-P2

36

Ejemplos: Ejemplo 1: Selección del fichero elemental Id: 60 1F Terminal 00 A4 00 00 02 60 1F

Tarjeta   61 0E

00 C0 00 00 0E   6F 0C 85 0A

01 60 1F 03 25 00 FF FF

FF FF 90 00

Ejemplo 2: Selección por nombre del fichero dedicado PKCS-15 Terminal 00 A4 04 00 0C A0 00 00 00 63 50 4B 43 53 2D 31 35

Tarjeta

  61 1C 00 C0 00 00 1C   6F 1A

84 0C A0 00 00 00 63 50 4B 43 53 2D 31 35 85 0A 38 50 15 00 0C FF FF FF

FF FF 90 00

37

Comando READ BINARY. El comando Read Binary devuelve en su mensaje de respuesta el contenido (o parte) de un fichero elemental transparente.

Codificación del comando Byte CLA INS P1-P2

Valor 0x0X 0xB0

Significado

Offset del primer byte a leer desde el principio del fichero.

LC Data LE

Vacío Vacío Número de bytes a leer

Si el campo Le=0 entonces el número de bytes a leer es 256.

Mensaje de respuesta

DatOS SW1-SW2

Significado Datos leidos (LE bytes) Bytes de estado

Condiciones de estado SW1

SW2

0x62

0x83

0x65

0x81

0x69

0x82

0x69

0x85

0x69

0x86

0x6A

0x82

0x6B

0x00

0x6C

0xXX

Meaning El EF o DF seleccionados están invalidados Error de memoria Condiciones de seguridad no satisfechas Condiciones de uso no satisfechas Comando no permitido (no existe un EF seleccionado) Fichero no encontrado Parámetros incorrectos (el offset está fuera del EF) Longitud incorrecta (XX indica la longitud exacta)

38

Ejemplo: Lectura Binaria Terminal 00 B0 00 00 50

Tarjeta   xx ..xx 90 00 xx .. xx Contenido del fichero (primeros 0x50 bytes) longitud = 80 bytes,

00 B0 00 50 40   yy .. yy 90 00 yy .. yy Contenido del fichero a partir del offset 0x50 (longitud = 64 bytes),

Comando VERIFY. El comando Verify inicia la comparación en la tarjeta de los datos de verificación de usuario enviados desde el dispositivo externo con los almacenados en la tarjeta. Esta operación se suele denominar verificación de PIN o CHV.

Codificación del comando Byte CLA INS P1 P2 LC Data LE

Valor 0x00 0x20 0x00 0x00

Significado

Datos de referencia (código CHV) Vacío o longitud del campo de datos Vacío o datos de verificación

Mensaje de respuesta Significado Datos SW1-SW2

Vacío Bytes de estado

39

Condiciones de estado SW1

SW2

0x63

0xCx

0x65

0x81

0x69

0x82

0x69 0x69 0x6A 0x6A 0x6A 0x6A

0x83 0x863 0x82 0x84 0x86 0x88

Significado Verificación fallida: ‘X’ indica el número de intentos disponibles. Error de memoria Condiciones de seguridad no satisfechas Método de autenticación bloqueado Identificador de CHV no permitido No se encuentra el fichero CHV No hay memoria suficiente Parámetros incorrectos P1-P2 Datos refrenciados no encontrados

Ejemplo: Presentación de PIN Terminal 00 20 00 00 08 xx .. xx xx .. xx PIN del usuario longitud en este ejemplo = 8 bytes

Tarjeta

  90 00 Verificación satisfactoria del PIN de usuario

40

ANEXO III Información necesaria para el establecimiento del canal seguro de usuario. Clave Pública ROOT CA para autenticación del componente. Sirve para verificar la cadena de certificado de componente (certificados de CA intermedia de componente – fichero 3F00/6020 - y certificado de componente – fichero 3F00/601F-)

Módulo = EADEDA455332945039DAA404C8EBC4D3B7F5DC869283CDEA 2F101E2AB54FB0D0B03D8F030DAF2458028288F54CE552F8 FA57AB2FB103B112427E11131D1D27E10A5B500EAAE5D940 301E30EB26C3E9066B257156ED639D70CCC090B863AFBB3B FED8C17BE7673034B9823E977ED657252927F9575B9FFF66 91DB64F80B5E92CD Exponente_público = 010001 Certificado de la CA intermedia de Terminal verificable por la tarjeta :

C_CV_CA = 7F2181CE5F3781803CBADC3684BEF32041AD155089258DFD 20C69115D72F9C38AA99AD6C1AEDFAB2BFAC9092FC70CCC0 0CAF482A4BE31AFDBD3CBC8C8382CF06BC0719BAABB56B6E C80760A4A93FA2D7C347F34427F9FF5C8DE6D65DAC95F2F1 9DAC0053DF11A507FB625EEB8DA4C0299E4A2112AB704758 8B8D6DA7592214F2DBA140C7D122579B5F383D2253C8B9CB 5BC3543A55660BDA80946AFB0525E8E5586B4E63E8924149 7836D8D3AB088CD44C214D6AC856E2A007F44F8374333737 1ADD8E030001000142086573524449600006 Identificador de esta CA intermedia (CHR):

CHR = 000000006573534449600006 Certificado de Terminal verificable por la tarjeta:

C_CV_IFD = 7F2181CD5F3781802563FCF6714624C0C4F5D75F67305EBF 8F3A6BB772996AFB6497BB466A238E731D08D378E9F4ECC0 4070E3717C138EA8D6D35A14ED1862B7F84E351B2DCE4CFB 30F8C76B8AD1731E9AA84AB0B3BD30C3F00DA274E2005A51 EB4213FD5523ABC97584A9FBD2576CB5DD9DD572AE49A597 E14ECFFA91F76E04F6081292AE07CEF75F383C258B73CFB9 4A739CB5E97392E599E8FB45A60072CAA6FCD5F215C3C7E0 25EA3C9EB2CBE47DE9FEE8002BF2F6D4A24350AB3F5F15DB 05A1270001000142086573534449600006 41

Identificador de este certificado (CHR):

CHR: 000000002000000000000001 Clave privada asociada para realizar la autenticación del Terminal:

Módulo: DB2CB41E112BACFA2BD7C3D3D7967E84FB9434FC261F9D09 0A8983947DAF8488D3DF8FBDCC1F92493585E134A1B42DE5 19F463244D7ED384E26D516CC7A4FF7895B1992140043AAC ADFC12E856B202346AF8226B1A882137DC3C5A57F0D2815C 1FCD4BB46FA9157FDFFD79EC3A10A824CCC1EB3CE0B6B439 6AE236590016BA69 Exponente_público: 010001 Exponente_privado: 18B44A3D155C61EBF4E3261C8BB157E36F63FE30E9AF2889 2B59E2ADEB18CC8C8BAD284B9165819CA4DEC94AA06B69BC E81706D1C1B668EB128695E5F7FEDE18A908A3011A646A48 1D3EA71D8A387D474609BD57A882B182E047DE80E04B4221 416BD39DFA1FAC0300641962ADB109E28CAF50061B68C9CA BD9B00313C0F46ED

42

ANEXO IV Ejemplo de firma electrónica para autenticación con establecimiento previo de canal seguro de usuario y presentación de PIN.

El presente anexo muestra un ejemplo de implementación con los comandos necesarios y el orden de estos comandos para el establecimiento del canal seguro de usuario, presentación de PIN, y realización de una firma con la clave de autenticación del usuario. Tenga en cuenta que se trata de un ejemplo con finalidad didáctica y que los valores utilizados y obtenidos son los aplicables a la tarjeta con la que se llevó a cabo el experimento.

1) Datos criptográficos necesarios para el establecimiento del canal seguro.

Véase el anexo III. 2) Establecimiento de canal seguro de usuario.

2.a) Reiniciar la tarjeta. En este primer paso, reiniciamos la tarjeta para que pierda cualquier estado previo. Se asume que la tarjeta acaba de ser alimentada y que se ha devuelto un ATR válido. 2.b) Petición del número de serie de la tarjeta: Para ello utilizamos el comando ‘Get Chip Info’:

 90b8000007  065a85ca586f329000 El número de serie de la tarjeta objeto de la prueba es: 065a85ca586f32 2.c) Selección y lectura de los certificados de componente, y de autoridad intermedia de componente: Empezamos seleccionado el fichero del certificado de la autoridad de certificación intermedia, que reside en el fichero 3F00/6020. Utilizamos los comandos ‘Select File’, y ‘Get Response’:

   

00a40000026020 610e 00c000000e 6f0c850a016020042c00ffffffff9000 En la respuesta al comando de selección del fichero, vemos que el tamaño del mismo es 0x042C bytes, así que lo leemos mediante varios comandos ‘Read Binary’:

43

 00b00000ff  3082042830820391a00302010202101aed357a7ba8c87b43 fadf3fa9775680300d06092a864886f70d01010505003081 87310b300906035504061302455331283026060355040a0c 1f444952454343494f4e2047454e4552414c204445204c41 20504f4c49434941310d300b060355040b0c04444e494531 1c301a060355040b0c134143205241495a20434f4d504f4e 454e5445533121301f06035504030c183030303030303030 36353733353234343439363030303036301e170d30363032 32313039333730335a170d3331303232303137313331355a 3072310b300906035504061302455331283026060355040a 0c1f444952454343494f4e2047454e9000  00b000ffff  4552414c204445204c4120504f4c49434941310d300b0603 55040b0c04444e4945310d300b060355040b0c04464e4d54 311b301906035504030c12414320434f4d504f4e454e5445 532030303130819f300d06092a864886f70d010101050003 818d0030818902818100de3cc30b668cb2353485fd42a119 2125f4a82504197ebd3cb6abffb8e68f2e84293bb725fd61 8fd10fda1a409737d74bd1b97984685156ceff55f5e3525b c58bfd3799c2a7e300471d9303105ee8ec4c67d476dc48d1 834670c27ebf4668779d7b855b44afa733da451bb954994a 718910fde6313aab6266313fdbd1564fa57d0203010001a3 8201a7308201a330120603551d13019000  00b001feff  01ff040830060101ff020100301d0603551d0e041604143f 320e9794b8f9566ea3d721a61754fa923a12b1301f060355 1d2304183016801445d76465f22504d8045e6627419d7650 05a2d158300e0603551d0f0101ff04040302010630370603 551d200430302e302c0604551d20003024302206082b0601 05050702011616687474703a2f2f7777772e646e69652e65 732f647063308201020603551d1f0481fa3081f73081f4a0 81f1a081ee8623687474703a2f2f63726c732e646e69652e 65732f63726c732f41524c434f4d2e63726c8681c66c6461 703a2f2f6c6461702e646e69652e65732f434e3d43524c2c 434e3d3030303030303030363537339000  00b002fdff  3532343434393630303030362c4f553d4143253230524149 5a253230434f4d504f4e454e5445532c4f553d444e49452c 4f3d444952454343494f4e25323047454e4552414c253230 44452532304c41253230504f4c494349412c433d45533f61 7574686f726974795265766f636174696f6e4c6973743f62 6173653f6f626a656374636c6173733d63524c4469737472 69627574696f6e506f696e74300d06092a864886f70d0101 050500038181008f837ad2f2a8c4ba6ab45e0d4b392d6ec0 e66b9da3f97efb08da7dc3bbd3a6549be10471ff7f28209a 17f0717af6f6d51e9f30dfd58fe804f02bf2b25820def595 c2ed85e3b080380438d824702180469000  00b003fc30 44

 2667f29d75b30cb9f2bb4a03dda58de2c150ed316ab9b29c a63210017dd70ffc21316f88f753904d743b70214523760a 9000 Realizamos la misma operación de selección y lectura con el certificado de componente, ubicado en el fichero 3F00/601F:      

 

 



00a4000002601f 610e 00c000000e 6f0c850a01601f032500ffffffff9000 00b00000ff 308203213082028aa003020102021031a75901575f510643 ff47d829436117300d06092a864886f70d01010505003072 310b300906035504061302455331283026060355040a0c1f 444952454343494f4e2047454e4552414c204445204c4120 504f4c49434941310d300b060355040b0c04444e4945310d 300b060355040b0c04464e4d54311b301906035504030c12 414320434f4d504f4e454e54455320303031301e170d3036 303232343137353232345a170d3137303232343137353232 345a3026310b300906035504061302455331173015060355 0403130e303635413835434135383646333230819f300d06 092a864886f70d010101050003818d9000 00b000ffff 0030818902818100d1d60b95e4522a480b12b8bd565a6141 3c79279eab0e60d7d490199e6786d1c965a9cefe06a38edb 9a5b89c47248fbd44932c8b908cf5111d9fb9635d1fcc94e 3f0ef3e654f7c062686ba4c63ae7319899bd32b0e1b74ea2 889e6b98def58ed17d4d0e55d9f12b6c61a5d2a535cbc253 65513479458337b3f84556acb807511d0203010001a38201 023081ff300c0603551d130101ff04023000300e0603551d 0f0101ff040403020388301d0603551d0e04160414b20804 697314e07b66f48b0140009a26ed41654a301f0603551d23 0418301680143f320e9794b8f9566ea3d721a61754fa923a 12b1303f06082b06010505070101049000 00b001feff 333031302f06082b060105050730028623687474703a2f2f 7777772e646e69652e65732f63657274732f41435261697a 2e637274305e0603551d1f045730553053a051a04f864d68 7474703a2f2f63726c732e666e6d742e646e69652e65732f 63726c732f43524c38343931343432323932433433423733 413445453131443844344635413846374132413944323334 2e63726c300d06092a864886f70d01010505000381810057 5c9b73f6dea428b98f6008cc6f66e03ed4a408f6247f2b36 ee0450072297f29b749beb49cfb965d575a533eb342f4d3a 4b25805dc0f98e0bcd02c56c13861eee635bb9760bde4840 59bd7caa77ed8274d4a405bccd4d8c9000 00b002fd28 45

 55a441f4e0492fc7ff7fd6b0b76dfcb98972720fe3f8c1d8 58c3a96de551d4a0bb02131279d20a199000 Una vez leídos ambos certificados, se deberá verificar la cadena de certificación de componente, utilizando la clave pública de la autoridad certificadora raíz. Del certificado de componente, extraemos la clave pública de componente, que luego tendremos que utilizar para completar las autenticaciones interna y externa. Clave pública de ICC:

Módulo = d1d60b95e4522a480b12b8bd565a61413c79279eab0e60d7 d490199e6786d1c965a9cefe06a38edb9a5b89c47248fbd4 4932c8b908cf5111d9fb9635d1fcc94e3f0ef3e654f7c062 686ba4c63ae7319899bd32b0e1b74ea2889e6b98def58ed1 7d4d0e55d9f12b6c61a5d2a535cbc25365513479458337b3 f84556acb807511d Exponente público = 010001 2.d) Selección y carga de la cadena de certificados verificables en la tarjeta. Seleccionamos en la tarjeta la clave pública de la autoridad certificadora raíz de la jerarquía de certificados verificables por la tarjeta. Para ello utilizamos el comando ‘Manage Security Environment’, utilizando la referencia del fichero donde reside la clave (020f):

 002281b6048302020f  9000 Enviamos el certificado de la autoridad intermedia verificable por la tarjeta (C_CV_CA). Para ello utilizamos el comando ‘Perform Security Operation’:

 002a00aed27f2181ce5f3781803cbadc3684bef32041ad15 5089258dfd20c69115d72f9c38aa99ad6c1aedfab2bfac90 92fc70ccc00caf482a4be31afdbd3cbc8c8382cf06bc0719 baabb56b6ec80760a4a93fa2d7c347f34427f9ff5c8de6d6 5dac95f2f19dac0053df11a507fb625eeb8da4c0299e4a21 12ab7047588b8d6da7592214f2dba140c7d122579b5f383d 2253c8b9cb5bc3543a55660bda80946afb0525e8e5586b4e 63e89241497836d8d3ab088cd44c214d6ac856e2a007f44f 83743337371add8e030001000142086573524449600006  9000 Al responder 9000, la tarjeta indica que el certificado ha sido correctamente verificado y que su clave pública ha quedado almacenada en memoria.

46

A continuación, seleccionamos la clave pública recién cargada con el comando ‘Manage Security Environment’, y utilizando la referencia del certificado anterior (CHR):

 002281b60a83086573534449600006  9000 Enviamos el certificado del Terminal, verificable por la tarjeta (C_CV_IFD), utilizando el comando ‘Perform Security Operation’:

 002a00aed17f2181cd5f378180825b69c6451e5f51707438 5f2f17d64dfe2e68567567094b57f3c578e830e425572de8 28faf4de1b01c394e345c2fb0629a393492f94f570b00b1d 677729f755d107022bb0a116e1d7d7659db5c4ac0ddeab07 ff045f37b5daf1732b54eab238a2ce17c9794187759cea9f 92a17805a27c1015ec56cc7e471a488e6f1b91f7aa5f383c adfc12e856b202346af8226b1a882137dc3c5a57f0d2815c 1fcd4bb46fa9157fdffd79ec3a10a824ccc1eb3ce0b6b439 6ae236590016ba690001000142086573534449600006  9000 Seleccionamos la clave pública recién cargada para autenticación. En el mismo comando ‘Manage Security Environment’ aprovechamos para seleccionar en la tarjeta la clave privada de componente (referencia 021F) que también se usará en los comandos de autenticación.

 0022c1a412830c0000000020000000000000018402021f  9000 2.e) Autenticación interna (de la tarjeta). Enviamos el comando ‘Internal Authentication’, mediante el que se le pide a la tarjeta que demuestre que posee la clave privada asociada a su certificado de componente. Para este comando, el Terminal deberá generar un valor aleatorio de 8 bytes. (en el ejemplo RND.IFD = 231dac737ba0fe6e):

   

0088000010231dac737ba0fe6e2000000000000001 6180 00c0000080 437393b30d1f0161455bb132e999de7bb8f7d82f91d507d6 d116074d33e60457f189b976235cab5762b64f896be8a924 1a245dcac976fa2d0cac8719157e2927c61e0bcb48b51170 ea0898381ef919398e46417899abe82708addd1b755c056f 5f7b96ba69bd56fc576c809b27b8f8364fc4d559d1da8681 fa04145ddd636eb79000 La respuesta de la tarjeta es un mensaje cifrado con la clave privada de componente de la tarjeta, a continuación se le ha aplicado la función SIGMIN, y por último se ha cifrado de nuevo con la clave pública del Terminal:

47

E[PK.IFD.AUT] (SIGMIN) Donde SIGMIN = min (SIG, N.ICC - SIG) y SIG= DS[SK.ICC.AUT] ( ‘6A’ = relleno según ISO 9796-2 (DS scheme 1) PRND1 = ‘XX ... XX’ bytes de relleno aleatorios generados en la tarjeta. La longitud debe ser la necesaria para que la longitud desde ‘6A” hasta ‘BC” coincida con la longitud de la clave RSA KICC = Semilla de 32 bytes, generada por la tarjeta, para la derivación de claves del canal seguro. h[PRND1 || KICC || RND.IFD || SN.IFD ] = hash SHA1 que incluye

los datos aportados por la tarjeta y por el terminal ‘BC’ = relleno según ISO 9796-2 (option 1)

) Por lo tanto, para verificarlo hay que empezar por descifrarlo con la clave privada del Terminal:

Mensaje entregados por la tarjeta: 437393b30d1f0161455bb132e999de7bb8f7d82f91d507d6 d116074d33e60457f189b976235cab5762b64f896be8a924 1a245dcac976fa2d0cac8719157e2927c61e0bcb48b51170 ea0898381ef919398e46417899abe82708addd1b755c056f 5f7b96ba69bd56fc576c809b27b8f8364fc4d559d1da8681 fa04145ddd636eb7 Mensaje descifrado con clave privada de Terminal: 0b9b44777590ea6c4d1f1f724c235964c5ffed0109aab5d4 80b05b7a31c224a4d1c7effe147d454eaaf7d47c35f0dd01 824023282bf8bb3cf1adecd576509672348a9eb196c8b8f1 f49931ea73e634f681a7474480243992f177a92f386747a0 6f57ae0566b5557efc0217cc8be84f50dae24b0a35cd3df1 f2429b96545464d5 Ahora lo que tenemos es el resultado de la función SIGMIN, que puede ser directamente SIG, o bien N.ICC-SIG. Probamos primero si es el primer caso, y por tanto lo desciframos directamente con la clave pública de componente de la tarjeta:

Descifrado con clave pública de tarjeta: 670f3942a1c15faed26cf22c0c87a8930dc3c1f73f772c82 096fe5198ef3b03b72257a8bf8d5c26425faf638758072f3 357ef10ee95f1284f8f277444fb0416ef092d8007abd245d 46b12f3dcfbc303bb7f3e0134d53e542dcccc6f4269784b4 affdb92cadd0494dcc58a142e901a8c940ed480554077ba1 b2263e8b415e8461 Sobre este mensaje descifrado hay que comprobar si se ajusta al formato esperado, y si coincide el hash. En este ejemplo no coincide el relleno (debería empezar por 0x6A, y acabar con 0xBC), así que pasamos a probar si el resultado de la función SIGMIN fue N.ICC-SIG. Calcularemos N.ICC-SIGMIN(..), y desciframos de nuevo con la clave pública de la tarjeta:

48

N.ICC-SIGMIN(..) c63ac71e6ec13fdbbdf3994b0a3707dc76793a9da163ab03 53dfbe2435c4ad2493e1defff226498cef63b5483c581ed2 c6f2a590dcd695d4e84da9605bac32dc0a845534be2f0770 73d272dbc700fca21815eb6c6193150f9726c269a68e4731 0df56050733bd5ed65a3bad8a9e373028a6ee96f0fb5f9c2 0602bb1663b2ec48 Descifrado con clave pública de tarjeta: 6ac6d2534290ca9938a5c69149d2b8ae2eb565a76b973455 cb203484d893218df38454720dcdcc777460938bfcc888e1 13b3d7aa1f703e8ce1091ef1824c87df4e7c1be5da3a9c05 21ba75886b2b015ce1c9529d9463695fabd1a4a4b85e0a1c cd4f55292c20e21e954d31624cca198a2463ec73f17bbc12 461f182176a8ccbc En este caso sí que obtenemos el relleno correcto, así que pasamos a descomponerlo de acuerdo a la estructura del mensaje, y comprobamos el hash:

‘6A’ = relleno según ISO 9796-2 (DS scheme 1)

6A

PRND1 = ‘XX ... XX’ bytes de relleno aleatorios generados en la tarjeta. La longitud debe ser la necesaria para que la longitud desde ‘6A” hasta ‘BC” coincida con la longitud de la clave RSA

c6d2534290ca9938a5c69149d2b8ae2e b565a76b973455cb203484d893218df3 8454720dcdcc777460938bfcc888e113 b3d7aa1f703e8ce1091ef1824c87df4e 7c1be5da3a9c0521ba75

KICC = Semilla de 32 bytes, generada por la tarjeta, para la derivación de claves del canal seguro. h[PRND1 || KICC || RND.IFD || SN.IFD ]

886b2b015ce1c9529d9463695fabd1a4 a4b85e0a1ccd4f55292c20e21e954d31 624cca198a2463ec73f17bbc12461f18 2176a8cc

= hash SHA1 que incluye los datos aportados por la tarjeta y por el terminal ‘BC’ = relleno según ISO 9796-2 (option 1)

bc

Datos sobre los que calcular el hash: c6d2534290ca9938a5c69149d2b8ae2eb565a76b973455cb 203484d893218df38454720dcdcc777460938bfcc888e113 b3d7aa1f703e8ce1091ef1824c87df4e7c1be5da3a9c0521 ba75 886b2b015ce1c9529d9463695fabd1a4a4b85e0a1ccd4f55 292c20e21e954d31 231dac737ba0fe6e 2000000000000001 Hash calculado: 624cca198a2463ec73f17bbc12461f182176a8cc Al coincidir el hash calculado con el recuperado en el mensaje descifrado la autenticación interna se considera correcta. El valor de Kicc debemos guardarlo, ya que se utilizará mas adelante para el cálculo de las claves de canal.

49

2.f) Autenticación externa (del terminal). El siguiente objetivo es realizar la autenticación externa, para lo cual hay que comenzar solicitando a la tarjeta un desafío de 8 bytes (RND.ICC):

 0084000008  eaefa8fbd31ac8ec9000 Ahora hay que construir el campo de datos para el comando ‘External authentication’ de acuerdo al siguiente formato: E[PK.ICC.AUT](SIGMIN) Donde SIGMIN = min (SIG, N.IFD - SIG) y SIG= DS[SK.IFD.AUT] ( ‘6A’ = relleno según ISO 9796-2 (DS scheme 1) PRND2 =‘XX ... XX’ bytes de relleno aleatorios generados por el terminal. La longitud debe ser la necesaria para que la longitud desde ‘6A” hasta ‘BC” coincida con la longitud de la clave RSA KIFD = Semilla de 32 bytes, generada por el terminal, para la derivación de claves del canal seguro. h[PRND2 || KIFD || RND.ICC || SN.ICC ] = hash SHA1 que incluye

los datos aportados por la tarjeta y por el terminal ‘BC’ = relleno según ISO 9796-2 (option 1)

)

Generamos PRN2 y Kifd como valores aleatorios de la longitud apropiada:

PRN2: 2a5c7300d96df9190ec2ae1cef89bde15678a78b7f7d4df3 d7d9bcfa313a0986efcc39695bd29812d2ce5931e1c2fc2d 068a5caf3de5bafef621cd8ba7082659a307d9a45318d479 8084 Kifd: cd97dbf2235760d8b3e9c4d7e9a691fb12cd207c42660df9 c69357ba7b25d0fc Calculamos el hash:

Datos sobre los que calcular el hash: 2a5c7300d96df9190ec2ae1cef89bde15678a78b7f7d4df3 d7d9bcfa313a0986efcc39695bd29812d2ce5931e1c2fc2d 068a5caf3de5bafef621cd8ba7082659a307d9a45318d479 8084 cd97dbf2235760d8b3e9c4d7e9a691fb12cd207c42660df9 50

c69357ba7b25d0fc eaefa8fbd31ac8ec 00065a85ca586f32 Hash calculado: b82a94c0aea15d96eb0deb0a68828a1bef1b43fc Construimos el mensaje en claro:

‘6A’ = relleno según ISO 9796-2 (DS scheme 1) PRND2 =‘XX ... XX’ bytes de relleno aleatorios generados por el terminal. La longitud debe ser la necesaria para que la longitud desde ‘6A” hasta ‘BC” coincida con la longitud de la clave RSA KIFD = Semilla de 32 bytes, generada por el terminal, para la derivación de claves del canal seguro. h[PRND2 || KIFD || RND.ICC || SN.ICC ] = hash SHA1 que incluye los datos aportados por la tarjeta y por el Terminal ‘BC’ = relleno según ISO 9796-2 (option 1)

6a 2a5c7300d96df9190ec2ae1cef89bde1 5678a78b7f7d4df3d7d9bcfa313a0986 efcc39695bd29812d2ce5931e1c2fc2d 068a5caf3de5bafef621cd8ba7082659 a307d9a45318d4798084

cd97dbf2235760d8b3e9c4d7e9a691fb 12cd207c42660df9c69357ba7b25d0fc b82a94c0aea15d96eb0deb0a68828a1b ef1b43fc

bc

Este mensaje lo cifraremos en primer lugar con la clave privada del Terminal:

SIG: 59d8b4c3cbe41cf96b60dadc845c53f7147a8269a75e24c3 db06d974d59e3de1b7d913acfef9b83321b938740df1c8f1 d7bfd4f6aa84507702b0437c24d19e617e2302a08ac9a7fc 0a972317c8d63cbde35c519f22dee850c9f829b4f8e765ff 47692ca26ce8da55b286bb2f09f18d6048e6c75ad0674380 cd6c49b50274289c Calculamos N.IFD-SIG para poder obtener SIGMIN, que en este ejemplo coincide con SIG:

N.IFD-SIG: 8153ff5a45479000c076e8f7533a2a8de719b2927ec17845 2f82aa1fa81146a71c067c10cd25da1613cca8c093c264f3 42348e2da2fa830ddfbd0df0a2d36117178e9680b53a92b0 a364efd08ddbc576879bd0cbf7a938e7124430a2f7eb1b5c d8641f1202c03b2a2d76bebd301f1ac483db23e2104f70b8 51

9d75eca3fda291cd SIGMIN: 59d8b4c3cbe41cf96b60dadc845c53f7147a8269a75e24c3 db06d974d59e3de1b7d913acfef9b83321b938740df1c8f1 d7bfd4f6aa84507702b0437c24d19e617e2302a08ac9a7fc 0a972317c8d63cbde35c519f22dee850c9f829b4f8e765ff 47692ca26ce8da55b286bb2f09f18d6048e6c75ad0674380 cd6c49b50274289c Por último cifraremos el mensaje con la clave pública de componente de la tarjeta, lo que nos da:

Datos autenticación externa: af7f20e622485f3700ab7473c201940dd855d36c68b5ebec ddac383464f41cdea31d5b4045e7025d5f394a9e4c298747 ae9300725bee8dfac5dab68df80ecb38e98109f2fe83effc fc74c7c850f6cd752f60ea9fcbd4acc4da3a453a08c937a0 88fe7580c1f0578892d945926c84f282c4ae00ebe2acbc54 8fc0ee396d2764c8 Enviamos el comando a la tarjeta, y si todo está bien calculado, deberá aceptarlo sin error (devolverá 9000):

 0082000080af7f20e622485f3700ab7473c201940dd855d3 6c68b5ebecddac383464f41cdea31d5b4045e7025d5f394a 9e4c298747ae9300725bee8dfac5dab68df80ecb38e98109 f2fe83effcfc74c7c850f6cd752f60ea9fcbd4acc4da3a45 3a08c937a088fe7580c1f0578892d945926c84f282c4ae00 ebe2acbc548fc0ee396d2764c8  9000 2.g) Cálculo de las claves de canal. El canal ya está establecido, sólo nos queda calcular las claves de canal. En primer lugar calculamos Kifdicc como el XOR de los valores de Kifd y Kicc obtenidos anteriormente:

Kifd: cd97dbf2235760d8b3e9c4d7e9a691fb 12cd207c42660df9c69357ba7b25d0fc Kicc: 886b2b015ce1c9529d9463695fabd1a4 a4b85e0a1ccd4f55292c20e21e954d31 Kifdicc: 45fcf0f37fb6a98a2e7da7beb60d405f b6757e765eab42acefbf775865b09dcd La clave de cifrado Kenc se obtiene como los primeros 16 bytes del hash de Kifdicc concatenado con el valor 00000001:

52

Datos para el hash: 45fcf0f37fb6a98a2e7da7beb60d405f b6757e765eab42acefbf775865b09dcd 00000001 hash: 598f26e36e11a8ec14b81e19bda223ca ebc69784 Kenc: 598f26e36e11a8ec14b81e19bda223ca De la misma forma, la clave para el cálculo del mac, Kmac se obtiene como los primeros 16 bytes del hash de Kifdicc concatenado con el valor 00000002:

Datos para el hash: 45fcf0f37fb6a98a2e7da7beb60d405f b6757e765eab42acefbf775865b09dcd 00000002 hash: 5de2939a1ea03a930b88206d8f73e8a7 aefdaa4b Kmac: 5de2939a1ea03a930b88206d8f73e8a7 Por último el contador de secuencia SSC se obtiene concatenando los 4 últimos bytes del desafío de la tarjeta (RND.ICC), con los cuatro últimos del desafío del Terminal (RND.IFD):

RND.ICC: eaefa8fbd31ac8ec RND.IFD: 231dac737ba0fe6e SSC: d31ac8ec7ba0fe6e

3) Construcción de un mensaje cifrado. Como ejemplo de construcción de un mensaje cifrado para su envío a la tarjeta una vez establecido el canal seguro, analizaremos un comando de selección por nombre del fichero maestro (‘Master.File’). El estado inicial del canal para este ejemplo es el siguiente:

Kenc: 598f26e36e11a8ec14b81e19bda223ca Kmac: 5de2939a1ea03a930b88206d8f73e8a7 SSC: d31ac8ec7ba0fe74

53

El mensaje en claro que queremos enviar es

Mensaje en claro: 00a404000b4d61737465722e46696c65 CLA: 00 INS: a4 P1 P2: 0400 P3: 0b Datos: 4d61737465722e46696c65 Como tenemos campo de datos, en primer lugar lo completamos con relleno (7816) hasta obtener una longitud múltiplo de 8 bytes. En este caso nos quedarán dos bloques de 8 bytes:

Datos con relleno 7816: 4d61737465722e46 696c658000000000 A continuación ciframos este mensaje, con la clave Kenc, utilizando triple DES (EDE), y encadenando bloques con CBC, y con un IV nulo:

Datos encriptados con DES_EDE CBC: 3e9ac315a8e855dd 3722f291078ac2bd Estos datos los completamos con un byte 0x01 delante, y los encapsulamos dentro del TLV de datos (tag=0x87):

TLV de datos: 8711013e9ac315a8e855dd3722f291078ac2bd Ahora tenemos que calcular el MAC. Los datos de entrada se construyen siguiendo estos pasos: •Al byte CLA, le añadimos los bits que indican que el comando está cifrado (CLA = CLA | 0x0c). •Tomamos los bytes de la cabecera CLA, INS, P1 y P2, y los completamos con relleno 7816 hasta 8 bytes. •Añadimos el TLV de datos. •Volvemos a completar con relleno 7816 hasta múltiplo de 8 bytes. En nuestro ejemplo:

CLA con los bits de mensaje cifrado: 0c Cabecera con relleno 7816: 0ca4040080000000 Añadiendo el TLV de datos: 0ca4040080000000 8711013e9ac315a8 54

e855dd3722f29107 8ac2bd Completando de nuevo con relleno 7816: 0ca4040080000000 8711013e9ac315a8 e855dd3722f29107 8ac2bd8000000000 Para calcular el MAC sobre estos datos deberemos realizar un cifrado DES con CBC de estos datos, y en el último bloque se utilizará triple DES. La clave para el cifrado DES son los ocho primeros bytes de Kmac, y para el triple DES será Kmac completa (con key3=key1). El valor inicial del IV para el encadenamiento CDB, será en contador de secuencia SSC incrementado antes de ser utilizado. La siguiente figura ilustra este proceso:

Los primeros cuatro bytes del último bloque cifrado será el MAC que incluiremos en el mensaje a la tarjeta. Con los datos de nuestro ejemplo:

SSC incrementado: d31ac8ec7ba0fe75 Cifrado DES: DES(d31ac8ec7ba0fe75) = 8818b3bff0cb40f5 XOR con bloque de datos: 8818b3bff0cb40f5 XOR 0ca4040080000000 = 84bcb7bf70cb40f5 Cifrado DES: DES(84bcb7bf70cb40f5) = dc6a4a7c11d0b384 55

XOR con bloque de datos: dc6a4a7c11d0b384 XOR 8711013e9ac315a8= 5b7b4b428b13a62c Cifrado DES: DES(5b7b4b428b13a62c) = 5a04399a0116a291 XOR con bloque de datos: 5a04399a0116a291 XOR e855dd3722f29107 = b251e4ad23e43396 Cifrado DES: DES(b251e4ad23e43396) = a398ffc834a23278 XOR con bloque de datos: a398ffc834a23278 XOR 8ac2bd8000000000 = 295a424834a23278 Cifrado triple DES: DES(295a424834a23278) = b6f56963ca2b8632 MAC: b6f56963 Construimos el TLV del MAC (tag = 0x8e), y construimos el mensaje completo, que incluirá la cabecera (con el CLA indicando mensaje cifrado), el TLV de datos, y el TLV con el MAC:

TLV del MAC: 8e04b6f56963 Mensaje cifrado: 0ca40400198711013e9ac315a8e855dd3722f291078ac2bd 8e04b6f56963 Enviamos este mensaje a la tarjeta:

 0ca40400198711013e9ac315a8e855dd3722f291078ac2bd 8e04b6f56963  612d  00c000002d  872101bb10c8915f0ddb630cf38ed799a202647ca47449d2 79139fc226d25c20765645990290008e049aa777079000 Para descifrar y comprobar la respuesta de la tarjeta, empezamos descomponiendo los TLV que lo forman:

TLV de datos: 872101bb10c8915f0ddb630cf38ed799a202647ca47449d2 79139fc226d25c20765645 TLV con respuesta del comando: 99029000 TLV con el MAC: 8e049aa77707 Para calcular el MAC utilizaremos como entrada todos los TLV devueltos por la tarjeta, excepto el propio TLV del MAC. El procedimiento es el descrito anteriormente:

Datos de entrada del MAC: 872101bb10c8915f0ddb630cf38ed799a202647ca47449d2 56

79139fc226d25c2076564599029000 Con relleno 7861: 872101bb10c8915f0ddb630cf38ed799a202647ca47449d2 79139fc226d25c207656459902900080 MAC calculado: 9aa77707 Como coincide con el enviado por la tarjeta, consideramos el mensaje correctamente cifrado. Los datos del TLV de datos deberemos descifrarlos, y eliminar el relleno 7816 para obtener los datos devueltos por el comando en claro:

TLV de datos: 872101bb10c8915f0ddb630cf38ed799a202647ca47449d2 79139fc226d25c20765645 Datos encriptados: bb10c8915f0ddb63 0cf38ed799a20264 7ca47449d279139f c226d25c20765645 Desencriptando con Kenc: 6f19840b4d617374 65722e46696c6585 0a383f00000bffff ffffff8000000000 Eliminando relleno 7816: 6f19840b4d617374 65722e46696c6585 0a383f00000bffff ffffff Por tanto, la respuesta equivalente de la tarjeta, puesta en claro sería:

Respuesta en claro: 6f19840b4d61737465722e46696c65850a383f00000bffff ffffff9000

3) Proceso de firma. El primer paso para realizar una operación de firma con una tarjeta DNIe será establecer un canal seguro de usuario, tal como se ha descrito anteriormente. En este ejemplo asumimos que el canal acaba de ser establecido, y las claves del canal son:

Kenc: 598f26e36e11a8ec14b81e19bda223ca Kmac: 5de2939a1ea03a930b88206d8f73e8a7 SSC: d31ac8ec7ba0fe6e El siguiente paso es la presentación del PIN del usuario, ya que es requerido para poder utilizar cualquiera de las claves privadas residentes en la tarjeta. El PIN de la tarjeta utilizada en este ejemplo es ‘CRYPTOKI’, con lo que los comandos de presentación de PIN serán:

57

 [002000000843525950544f4b49]  0c20000019871101ce1ab937c332f3faee43336d4311ef33 8e046908df4e  610a  00c000000a  990290008e04b4bbf3a69000 [9000] NOTA: Los símbolos  y  indican los comandos antes de cifrar, y los símbolos  y  indican los comandos cifrados que realmente se envían a la tarjeta. El siguiente paso es seleccionar la clave con la que queremos firmar. Para ello necesitamos conocer su identificador en la tarjeta, y la forma de obtenerlo es analizando la estructura PKCS15 de la tarjeta, y en el fichero PrKDF (en el path 3F00/5015/6001) encontraremos la información de las claves privadas almacenadas en la tarjeta. Los datos que nos interesan son su identificador de PKCS11 (CKA_ID), su etiqueta de PKCS11 (CKA_LABEL), y el path donde reside la clave. En nuestro ejemplo, en el PrKDF tendremos descritas dos claves:

Primera Clave: CKA_LABEL = KprivAutenticacion CKA_ID = A065A85CA586F3220060302120000 Path = 3F110101 Segunda Clave: CKA_LABEL = KprivFirmaDigital CKA_ID = F065A85CA586F3220060302000000 Path = 3F110102 Para simplificar este ejemplo no se incluye la secuencia de comandos para seleccionar, leer y analizar el PrKDF. Para ello únicamente es necesario utilizar los comandos de ‘Select File’ y de ‘Read Binary’. Su contenido se ajusta a la estructura ASN.1 descrita en el PKCS15 para este fichero. La clave que queremos utilizar es la de autenticación, que por la etiqueta vemos es la primera. El identificador de la clave en la tarjeta coincide con el último byte del path del fichero donde se encuentra, que en nuestro caso es el 01. Con todo esto, utilizaremos el comando ‘Manage Security Environment’ para seleccionar la clave 1 en la plantilla de firma:

     

[002241b60484020101] 0c2241b611870901faf40c655215987f8e043c3564db 610a 00c000000a 990290008e04c2a28ace9000 [9000]

Los datos que queremos firmar son:

Datos a firmar: 58

”Datos a firmar” Hash SHA1 de los datos a firmar: 839b543fb09d20c803b46e6f8f0747244951822f Por último utilizaremos el comando ‘Perform Security Operation’ para firmar el hash de los datos. En el comando, además del hash, también incluimos el DigestInfo del SHA1 para que sea incorporado a la firma (3021300906052b0e03021a05000414):

 [002a9e9a233021300906052b0e03021a05000414839b543f b09d20c803b46e6f8f0747244951822f]  0c2a9e9a31872901e2f39b27db5bc373dde1ea4de7c84371 1529a8f8ded8092fbc88ba9c2b6b7c18b9ffbf4f01def59a 8e04ae86da97  6100  00c0000000  8782010901e4e9ca20eb996f14f219d086b13187d640a7f7 d9a93b74368870e7300ec5db202e683e8507ae871ff9fe6c 10cd6b66e942affac1996a2048e0564d8edd8b0057eaa057 6ec83e0b62eb07bea6f74a43a8d4a518f55daeba0bc6a87f 0e30fb1a75d4472108ecb043dcd2f22f85db5640c86b500b f5a819ac7363d879f98b4295359d2f7c04f134fd28af07b7 e5b327f3214a816fcda489b17e0a0f9b9c3af5b7ceaa4311 c7a66eece210de9b471c78aef858cfeaeb11da40ba932d49 900b73f6a14451c0cae04b085b62aa19037b62eaf7b97bf7 e6df54cb8a4e3db5bc56818467ac756b53ba04b5db0f55c1 db23f2289f9e2c359671ba174a9ecde26117  00c0000017  784dd3609f32f040dae1c1447e990290008e04999b1e4e9000  [632369fa040ccb9f298fdcc2a3e344d815be131e2a609792 9cf9d1fe35fd472580f56c67e040a2437d37f1320a7d8025 27e6eb2734f848315625f6bd14935ed72d1c1e42f5f41bc6 53d83fc180b98fff5b0f3ba5ef159d2de0737e9d4a86469a 156ca7711ad7d9c2d10c797696062cac0b656c0b04b988c7 e447fdf43add6e3a379f1f6e4e115916a49f1cf18ce4421e 41ac044c5dca70a90e58b155212b7caa22bfd1e42ba60a02 92d531943f2adf6bd0f238ecf931bbdfd98d085edc0050dc c799480415f0282e1f9e57b013ea3732330dffa6daba8957 a55d34d004fd3259e6bdd9e568face8118d2e1eff13adeb2 3e1c58f5fafefe38e1374c631281a6689000] Por lo tanto, la firma calculada es:

Firma del hash de los datos: 632369fa040ccb9f298fdcc2a3e344d815be131e2a609792 9cf9d1fe35fd472580f56c67e040a2437d37f1320a7d8025 27e6eb2734f848315625f6bd14935ed72d1c1e42f5f41bc6 53d83fc180b98fff5b0f3ba5ef159d2de0737e9d4a86469a 156ca7711ad7d9c2d10c797696062cac0b656c0b04b988c7 e447fdf43add6e3a379f1f6e4e115916a49f1cf18ce4421e 59

41ac044c5dca70a90e58b155212b7caa22bfd1e42ba60a02 92d531943f2adf6bd0f238ecf931bbdfd98d085edc0050dc c799480415f0282e1f9e57b013ea3732330dffa6daba8957 a55d34d004fd3259e6bdd9e568face8118d2e1eff13adeb2 3e1c58f5fafefe38e1374c631281a668 Lectura del certificado de autenticación y verificación de la firma. Para obtener la lista de certificados disponibles en la tarjeta, en primer lugar será necesario seleccionar, leer y analizar el fichero CDF de la estructura PKCS15 de la tarjeta, que está ubicado en la ruta 3F00/5015/6004. La descripción de la estructura de este fichero puede encontrarse en la especificación del PKCS15. Los datos que nos interesan son su identificador de PKCS11 (CKA_ID), su etiqueta de PKCS11 (CKA_LABEL), y el path hasta donde reside el certificado:

Primer certificado: CKA_LABEL = CertAutenticacion CKA_ID = A065A85CA586F3220060302120000 Path = 60817002 Segundo certificado: CKA_LABEL = CertFirmaDigital CKA_ID = F065A85CA586F3220060302000000 Path = 60817001 Tercer certificado: CKA_LABEL = CertCAIntermediaDGP CKA_ID = S065A85CA586F3220060302000000 Path = 60617003 La relación entre un certificado y su clave privada es que ambos tienen el mismo CKA_ID. En nuestro caso, el certificado correspondiente a la clave que hemos utilizado es el primero (CKA_LABEL= CertAutenticacion), que está en la ruta 6081/7002. Seleccionamos el fichero del certificado (empezando por el fichero maestro), y lo leemos:

 [00a404000b4d61737465722e46696c65]  0ca40400198711013e9ac315a8e855dd3722f291078ac2bd 8e04b6f56963  612d  00c000002d  872101bb10c8915f0ddb630cf38ed799a202647ca47449d2 79139fc226d25c20765645990290008e049aa777079000  [6f19840b4d61737465722e46696c65850a383f00000bffff ffffff9000] [00a40000026081]  0ca4000011870901251c58d6b01d4e098e04fb732ce1 60

 612d  00c000002d  872101fad72ff5311c10b8a755837dd24460dcf522cfea3a 198b9ca5c5c2d09ef7dc19990290008e0457cd226d9000  [6f178409444e49652e50726976850a3860810009e0ffffff ff9000] [00a40000027002] 0ca40000118709012ca1509017522a6c8e04470c1fde 611d 00c000001d 8711012b9724c0ebbec01c697f4693b659d8aa990290008e 0460c777959000  [6f0c850a24700204f21120ffffff9000]     

[00b00000ef] 0cb00000099701ef8e0482fc8ba1 61fe 00c00000fe 8781f101711c55e3704a007ff352b1bcafcac96b43e11e87 697f6b7bae797005d20adbafbba31fc2f8e9ceaeb90b7963 1a230e69e57c06fb7f58e3f2ef0e11211195d87572a2ee38 ec91e8722bd660db01c718d6f0d8509de1e4b81cc169e18a 128c638c705f4b5e5ebe0f02d9c5edf06908f472feda8953 f04db368cd270baf5098fd8d38447df3d44952100510fc09 a85b9055ce475867beb21f252e28e68bb0188abf70103d37 2c9ffba2270a6e13c393256ab44504f9021037d45a621e82 8307a14efdcd5796f39190632861ff195ffc9d2167a1879d 0abc269354a76489cd574d2ea76e40ee7c3d04e0aeeb7dfd f917cbb3990290008e042d30f6009000  [e8050000b3040000789c3368627d62d0c472660133132313 9300af5929b7e022f54617b62713652f1cbe6bc0cbc6a9d5 e6d1f69d9791919595c120c690db80938d3994854d98c935 d850c3400dc4e1e29177f10c727576f6f4f7537077f5730d 72f451707155f0715408f0f7f174f67434e435e006a9e4e6 6171f1f3743514311002719979b81d9d1540220a06068606 72e2bc066606c6064686464666a6e65140ae8581259c6b50 866abb90810088c32acc69000646c621307b587858bc421d fd0c050df8415c2d1e0ed7e000c7c313fd7d0c0d0df42156 6bc08414600c1d059026050dc7d01057bf104f674767cf90 00]     

    

[00b000efef] 0cb000ef099701ef8e04b08c0cd5 61fe 00c00000fe 8781f1017490b8866e13cdcd7929262740e34d3e97d2c0e7 61

fa9c9259e12392e14ebfbe81549405a5038343e85b774eb0 2b7df7e57ece210bff119f5f9ecf3de16fbfe9e5516273b2 81ef0e21f40b9aa6e5ebcac0450a18784c3b3989c6c3b9b4 e5aa20d95cb9e1333842696f154316055c408553cb47f7d5 ffc4315d44fa4c851c16c55f5f06a897ecc0e6fbb67398dc 9f414b771ebe0039c506e49e529ec757e2550ab85c38320a b1aa977a70e803d9f35da6bfb1e1e7ef5be4748d33234966 c00840a733e05e67107a1234a9f41219ee92f0228504e8b7 1baf9affddc36093ead8705008b3fc62cba13cf7c9b02b76 41b955cb990290008e04398d9f209000  [c393fd340d9a1895900382919581b989919f0128cec5d4c4 c8c870e84ab9f987c4f4e3efda98f4d466fd75bd1a7d2469 a7e81de1996bf8e79a374f7ca9707f6148c633d7aacf5e37 e4265ca9c91311769733b1bb3a7d9bfbffd8779716cecbf5 5abaafff5ef8b2c88c98b0d07b7d6a063c9f9a67e90b862c f2cede90e9b8f4a8bbe3b9eb16ce13b98df8b6adb294fffd b14177c934f3042df179afe35ab5fe67346cac6b0e773f31 4b80e9b0cbf7290b647beb736b3a0c9cdc17c878f9796854 88bf9c715a607dc4ddc7524527aaa48e7f9b312dbde5bfc8 01ff6f4aa9ccde0bfee42707e87ae74418fc993aebe3cc90 00] [00b001deef] 0cb001de099701ef8e04537dd3e6 61fe 00c00000fe 8781f101c80473207556fd7f00d1c0a2ef0b156ec3d6901f efc8ea9a5ad065b30ac38839b6242b4a5ac4f7af7c620917 e022b35ac5c59b6918dead31cea1488aabd7c2b35a7c2e6c a4159a02c660f7674fd04aa31a013452b40bf36fe4a0c2fe 53552b56a0f6814fcd4bbbd17b8d1974bb69067ead830a49 7109b513507b76a41df522641a965b0d087f32d3c101b88e 446219ecf77727fa033c315f277a888d0492498d5f227f0e 2e8a3c99f5631e5485a252ad43b42b1fa768bac9d54a5ac9 796b32ce14c03b790cd4474ca7f1583e14b99ba26e30dc40 97e3f61248b9b5d237dc53010b5ae8f34f647febf8a1d0b8 9844a15d990290008e04df3d0c1d9000  [30a545b396093f69ea7aae5bb46d717c3acf85c31b0aeebc 3eba2dce4be0ad466224c789231b565a356a3031edf48bd4 6060af093775f3fbcec4ccc8c0b8b889a9cda089a9c98007 18bcb2c28c8cff59980c180cf8403c7e108f859989bdc140 16c4e7631163117999fe5026f2d31df3cbda496d026bee30 aeb9af9e62200f9256669130106b1091ea5c71f45d7f596c 6861e7676bd3bdab5819a6e61b28b17168b301d3223b2333 8b98818801071b1b0b439f1b23239cc562900057c3c81262 10043414ca37606c13ce282929b0d2d7cf4f2e2ed04bc9cb 4cd54b2d06a6089802a63665a882f2f27298bc7e726a5190 00]     

62

[00b002cdef] 0cb002cd099701ef8e048e11b7f4 61fe 00c00000fe 8781f101d18a6305065cc06862c9e6e1011528d61ccd546c a61d59930bc697fbba768ed933d6fd8b79ef635449a94a51 9071ce33e9176b7968520c42f8c2f92a314062f35060e63c 1d4246d540f2680b4f539b0c21b8ff94f699fd962b2283d9 593246c289f200e75533819f95b7e172117b3b8cc2f7191f 61c785905c500a69a362a9f82c95877f6aeec27236a48170 c224ae7c96948a95e2858d5377ca208a0df25b74392a6eef c3a773e196193bdee3e42aa5c2da03c74a9fd886668c4e59 e9482624d7abad231090f2f63d9c97738b4c4c5cafda92c5 738a4ccc7f7377ab2f2650c98e69377d0faa1fe578092c0e 4ada6869990290008e0486200d469000  [49b1bea373506266955e7251898135c8990a2c2606460606 6c1c09ad21c0ccc3c462a082701e13a398181693520a920d 1a3fc0ddc7c4d2f8d8a0f181811113d003dc6c9c096d1e8c a9cc2c4c8c2c0aa1b67cacf60fd64bc7cc683388bfece376 f4a1d2b33ba6191327cdbef5b850ff7936480f03a97aac80 cac18e052aa7402f1ba97a3540e1c5c9a268200f4c0050cf 73321a0a4af01b5a9a0173be91a9a111280b471938c18293 8591c5ccc004e44b2634db02abd2fa1e2e7aecb7dcf75ff8 9d4a815f6bc3c38d27a9ba7194fe7f97bd7a52ca12b4428b 199445bd180515365cef3c1a1dbd5ecf6dddda7edd733190 00]     

[00b003bcef] 0cb003bc099701ef8e04dd235d61 61fe 00c00000fe 8781f101750c77ccaf5c18cdfe6c0cbd5a66772ca56995d8 1932677e0d3954f87010b02e070502dc3444023faa127a5a 28cad4db3f1adcb0e0848c35fd418dbcfa0b9acf9bff811b ac4d6ef1b0c5df7818539eb8ba1f3edc51874d6cfa8f2a1d 93a245523755dabe07f44b364afc3265236ce3c55cb0217b 00e6da7cd9afd861d1a0840086ef1aac2e1b842357ca44c1 e918c877ce60edaac1b8529644b64baba80cc3c74867d5f9 132f19cabe8094496a8ff6994963982a43ba41eb733f16ab 83b3e7941fcc0ef9c0b5bb472c25b0227c0b9fe9c537a0b1 1ce03ec92fb82c2d10a47163194319a1a54a57da771a14eb c86f5d2a990290008e0413713a3f9000  [ca7107799d04152b4fbc522ffbd693ce71ecb3700d4f9432 7b36c39ca2d9499fddd6bb7f9512baca1ab9fa8de6c52d8f 1497e50598e77e6b38ecfc96d9fbda84047f79d7f33396f7 316d3511564daa3fd1adaa98fe9d7dc5d5f61533ffa807ec dbecaff7cce7f2c16d425646ec4eacc63f76711c79762ae8 5bc3df42f557738eaf13ba21788ad5e976df3bb9e90a3fd5 5a0bfb74e34ae6ed50bb9e7fdab2c349f3ee8ac7073e45e8     

63

ce2ff25a6ada29f96285ef9aeb31f5acb7cc2cb6cc7a9260 3cc1904ff460b83b8364e5676d91d9520fd62bb71fe5edb6 2958ccc4ab9f719be123df963333bf046e4b75faf7f6a690 00]      

[00b004ab47] 0cb004ab099701478e04960bfd2f 610a 00c000000a 99026c108e043190b8309000 [6c10]

[00b004ab10] 0cb004ab099701108e0462d211ad 6125 00c0000025 87190144fdab7ba445a1cb602b7e45138b561cbd4f6596d0 16bcb6990290008e047c5ed3c19000  [810bdff7e4830fe75e780e00c9adeabc9000]     

El contenido del fichero que acabamos de leer es el certificado comprimido con la librería zlib, con una pequeña cabecera que indica el tamaño de los datos comprimidos, y los datos comprimidos:

Tamaño de los datos descomprimidos: e8050000 Tamaño de los datos comprimidos: b3040000 Datos comprimidos: 789c3368627d62d0c4726601331323139300af5929b7e022 f54617b62713652f1cbe6bc0cbc6a9d5e6d1f69d97919195 95c120c690db80938d3994854d98c935d850c3400dc4e1e2 9177f10c727576f6f4f7537077f5730d72f451707155f071 5408f0f7f174f67434e435e006a9e4e66171f1f374351431 1002719979b81d9d1540220a0606860672e2bc066606c606 4686464666a6e65140ae8581259c6b50866abb90810088c3 2acc69000646c621307b587858bc421dfd0c050df8415c2d 1e0ed7e000c7c313fd7d0c0d0df421566bc08414600c1d05 9026050dc7d01057bf104f674767cfc393fd340d9a189590 0382919581b989919f0128cec5d4c4c8c870e84ab9f987c4 f4e3efda98f4d466fd75bd1a7d2469a7e81de1996bf8e79a 374f7ca9707f6148c633d7aacf5e37e4265ca9c913117697 33b1bb3a7d9bfbffd8779716cecbf55abaafff5ef8b2c88c 98b0d07b7d6a063c9f9a67e90b862cf2cede90e9b8f4a8bb e3b9eb16ce13b98df8b6adb294fffdb14177c934f3042df1 79afe35ab5fe67346cac6b0e773f314b80e9b0cbf7290b64 7beb736b3a0c9cdc17c878f979685488bf9c715a607dc4dd c7524527aaa48e7f9b312dbde5bfc801ff6f4aa9ccde0bfe e42707e87ae74418fc993aebe3cc30a545b396093f69ea7a 64

ae5bb46d717c3acf85c31b0aeebc3eba2dce4be0ad466224 c789231b565a356a3031edf48bd46060af093775f3fbcec4 ccc8c0b8b889a9cda089a9c9800718bcb2c28c8cff59980c 180cf8403c7e108f859989bdc14016c4e7631163117999fe 5026f2d31df3cbda496d026bee30aeb9af9e62200f925666 9130106b1091ea5c71f45d7f596c6861e7676bd3bdab5819 a6e61b28b17168b301d3223b23338b98818801071b1b0b43 9f1b23239cc562900057c3c8126210043414ca37606c13ce 282929b0d2d7cf4f2e2ed04bc9cb4cd54b2d06a6089802a6 3665a882f2f27298bc7e726a5149b1bea373506266955e72 51898135c8990a2c26064606066c1c09ad21c0ccc3c462a0 82701e13a398181693520a920d1a3fc0ddc7c4d2f8d8a0f1 81811113d003dc6c9c096d1e8ca9cc2c4c8c2c0aa1b67cac f60fd64bc7cc683388bfece376f4a1d2b33ba6191327cdbe f5b850ff7936480f03a97aac80cac18e052aa7402f1ba97a 3540e1c5c9a268200f4c0050cf73321a0a4af01b5a9a0173 be91a9a111280b471938c182938591c5ccc004e44b2634db 02abd2fa1e2e7aecb7dcf75ff89d4a815f6bc3c38d27a9ba 7194fe7f97bd7a52ca12b4428b199445bd180515365cef3c 1a1dbd5ecf6dddda7edd7331ca7107799d04152b4fbc522f fbd693ce71ecb3700d4f94327b36c39ca2d9499fddd6bb7f 9512baca1ab9fa8de6c52d8f1497e50598e77e6b38ecfc96 d9fbda84047f79d7f33396f7316d3511564daa3fd1adaa98 fe9d7dc5d5f61533ffa807ecdbecaff7cce7f2c16d425646 ec4eacc63f76711c79762ae85bc3df42f557738eaf13ba21 788ad5e976df3bb9e90a3fd55a0bfb74e34ae6ed50bb9e7f dab2c349f3ee8ac7073e45e8ce2ff25a6ada29f96285ef9a eb31f5acb7cc2cb6cc7a92603cc1904ff460b83b8364e567 6d91d9520fd62bb71fe5edb62958ccc4ab9f719be123df96 3333bf046e4b75faf7f6a6810bdff7e4830fe75e780e00c9 adeabc Si los datos comprimidos los expandimos con la librería zlib obtendremos el certificado X509 de autenticación del ciudadano:

Certificado X509: 308205e4318204cca00302010202100d36750b11a2278144 06e4911dd0c3dd300d06092a864886f70d0101050500305c 310b300906035504061302455331283026060355040a0c1f 444952454343494f4e2047454e4552414c204445204c4120 504f4c49434941310d301b060355040b0c04444e49453114 301206035504030c0b414320444e494520303031301e170d 3036303330323132323635375a170d303830393032313232 3635375a3076310b30090603550406130245533112301006 035504051309303030303030323354310d300b0603550404 0c044a55414e3111300b060355042a0c0845535041c3914f 4c3131302f06035504030c2845535041c3914f4c20455350 41c3914f4c2c204a55414e2028415554454e544943414349 c3934e2930820122300d06092a864886f70d010101050003 82010f003082010a0282010100c2d47737f06167c7ee8602 2e269afd45d55bc462b915dc1399ac0f9d378391e920dfa1 65

5468e6457af34ad81e90d47c6e1413471e343ed597b647ff 5deed2a19e6d4aa5be8fde57a659685c5655de8e26300cf2 839a2f1154a24b6bb06941a5c54741ced73843910b320eb6 aa391ffbf1802da49637602a179eeb5e852aff6880b17e83 5747c89a1002c344f794a01d8d7f6d7c88304247a01c4a4e 48287817e998cb10af58dde31a72c87a1ac7f698966784ff 14c04ff62265034ba0fc6f63502d4b6c5830fc959af19956 22a29aa613e4828ae72d72b6a35f670cd0c3b070dcebc5b6 5e4a10ed28615908c8c4b0a93a81280202b94e592800077c 5735464ef70203010001a382028630820282300c0603551d 130101ff04023000300e0603551d0f0101ff040403020780 301d0603551d0e04160414e967e11c59f2dc37d32b628610 acdc01acdf2764301f0603551d230418301680141a89a8c5 ee8f765d557189f33b35bdaa0500956f302206082b060105 05070103041630143008060604008e460101300806060400 8e460104306006082b0601050507010104543052301f0608 2b060105050730018613687474703a2f2f6f6373702e646e 69652e6573302f06082b060105050730028623687474703a 2f2f7777772e646e69652e65732f63657274732f41435261 697a2e637274303b0603551d200434303230300608608554 01020202043024302206082b060105050702011616687474 703a2f2f7777772e646e69652e65732f6470633081f00608 2b060105050701020481e33081e03032020101300b060960 86480165030402010420553d0e053fe0af1b5c9886305fd3 4c46c5e122e6dc356891929bdae3712fe76b303202010030 0b06096086480165030402010420553d0e053fe0af1b5c98 86305fd34c46c5e122e6dc356891929bdae3712fe76b303a 0609608554010202040201300b0609608648016503040201 0420553d0e053fe0af1b5c9886305fd34c46c5e122e6dc35 6891929bdae3712fe76b303a060960855401020204020630 0b06096086480165030402010420553d0e053fe0af1b5c98 86305fd34c46c5e122e6dc356891929bdae3712fe76b3028 0603551d090421301f301d06082b06010505070901311118 0f31393630313032353132303030305a3042060860855401 02020401043630343032020102300b060960864801650304 02010420517a668ee1a2e34ea75dfe57dc7910faad575733 9225460875ffee6bab9264a4300d06092a864886f70d0101 05050003820101004a011120b0d789c55b5baf2e46aead8f 2dce5c235ec10d42112179c8ea2776f68c6708c6f3137c0c 5a23076b009c729b62f346af47f51a12d50559abec29d1b4 e221a66e50376df680c343ed034bd690604f1f45cf98a78e 02b5341325627fc88b252167f707a8d587a899fc2750beb3 4f2ee64cd3c1b6123a3206420533f8ba08c4e6ca52f680fd 7127ea9cc7ae12d811ca0542db8eee1e9720f92685718e2d 5e749eb826d76fcb39884229dda8e3c0f2582d9f724aa535 8919e8a84dacd75c7f05da3638b49ae4603390310e15c157 47001979f32b149b1ae0af2387c50d8b3c70a3020d2f68db 00f10eb4cc99f451b66542deedd930440ef763c1e19dd0e7 Este certificado deberá ser verificado con la cadena de validación de certificados, comprobar caducidad, lista de revocados, etc...

66

De él podemos obtener la clave pública que nos servirá para comprobar la firma realizada anteriormente: Clave pública de autenticación:

Módulo = 2cd47737f06167c7ee86022e269afd45d55bc462b915dc13 99ac0f9d378391e920dfa15468e6457af34ad81e90d47c6e 1413471e343ed597b647ff5deed2a19e6d4aa5be8fde57a6 59685c5655de8e26300cf2839a2f1154a24b6bb06941a5c5 4741ced73843911c320eb6aa391ffbf1802da49637602a17 9eeb5e852aff6880b17e835747c89a1002c344f794a01d8d 7f6d7c88304247a01c4a4e48287817e998cb10af58dde31a 72c87a1ac7f698966784ff14c04ff62265034ba0fc6f6350 2d4b6c5830fc959af1995622a29aa613e4828ae72d72b6a3 5f670cd0c3b070dcebc5b65e4a21ed28615908c8c4b0a93a 81280202b94e592800077c5735464ef7 Exponente público: 010001 Desencriptando con esta clave pública la firma generada anteriormente:

Datos firmados con clave de autenticación: 632369fa040ccb9f298fdcc2a3e344d815be131e2a609792 9cf9d1fe35fd472580f56c67e040a2437d37f1320a7d8025 27e6eb2734f847315625f6bd14935ed72d1c1e42f5f41bc6 53d83fc180b98fff5b0f3ba5ef159d2de0737e9d4a86469a 156ca7711ad7d9c2d10c797696062cac0b656c0b04b988c7 e447fdf43add6e3a379f1f6e4e115916a49f1cf18ce4421e 41ac044c5dca70a90e58b615212b7caa22bfd1e42ba60a02 92d531943f2adf6bd0f238ecf931bbdfd98d085edc0050dc c799480415f0282e1f9e57b013ea3732330dffa6daba8957 a55d34d004fd3259e6bdd9e568face8118d2e1eff13adeb2 3e1c58f5fafefe38e1347c631281a668 Firma desencriptada: 0001ffffffffffffffffffffffffffffffffffffffffffff ffffffffffffffffffffffffffffffffffffffffffffffff ffffffffffffffffffffffffffffffffffffffffffffffff ffffffffffffffffffffffffffffffffffffffffffffffff ffffffffffffffffffffffffffffffffffffffffffffffff ffffffffffffffffffffffffffffffffffffffffffffffff ffffffffffffffffffffffffffffffffffffffffffffffff ffffffffffffffffffffffffffffffffffffffffffffffff ffffffffffffffffffffffffffffffffffffffffffffffff ffffffff003021300906052b0e03021a05000414839b543f b09d20c803b46e6f8f0747244951822f Donde podemos comprobar que está el hash que solicitamos firmar, y al que se le ha incluido el relleno PKCS1 hasta completar el tamaño de la clave.

67