2010.09.30 - Manual de Comandos Del DNIe - Tractis

DNI DNI ELECTRÓNICOELECTRÓNICO..

G GUÍAUÍA DEDE R REFERENCIAEFERENCIA T TÉCNICAÉ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

DIRECCIÓN GENERALDE LA POLICÍA Y

DE LA GUARDIA CIVIL

CUERPO NACIONAL DE POLICÍA

MINISTERIODEL INTERIOR

Índice de contenidoMarco legal básico................................................................................................................................................................3

Descripción.....................................................................................................................................................................3Actividad de validación de los certificados..........................................................................................................................5Seguridad lógica...................................................................................................................................................................6

Identificación de usuario mediante código CHV......................................................................................7Identificación de usuarios mediante datos biométricos............................................................................7Identificación de aplicación......................................................................................................................7Identificación mutua.................................................................................................................................7Desbloqueo y cambio de código CHV.....................................................................................................8Protección de mensajes............................................................................................................................8Funcionalidades criptográficas.................................................................................................................9Estados del sistema...................................................................................................................................9

Requisitos de seguridad. Asunciones de entorno..................................................................................................................9Servicio de Atención al Ciudadano.....................................................................................................................................11Glosario 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 EN-14890-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

http://www.dnielectronico.es/descargas/index.html

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 ISO-7816-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 Valor Significado CLA 0x00 INS 0x84 P1 0x00 P2 0x00 LC Vacío Data Vacío

0x08Longitud del desafío de 8 bytes, para establecimiento de canal seguro

Mensaje de respuesta

Significado Datos Datos del desafío SW1-SW2 Bytes de estado

Condiciones de estado

SW1 SW2 Significado0x67 0x00 Longitud incorrecta0x6A 0x86 Parámetros incorrectos P1-P2

Ejemplo:

Terminal Tarjeta00 84 00 00 08

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.


Byte Valor Significado CLA 0x90 INS 0xB8 P1 0x00 P2 0x00 LC Vacío Data Vacío LE 0x07 Número de serie


Datos Tamaño Significado0x07 Número de serie

SW1-SW2 Bytes de estado


SW1 SW2 Significado

0x67 0x00 Longitud incorrecta (el campo Lc no es correcto)

0x6A 0x86 Parámetros P1-P2 incorrectos

Ejemplo:

Terminal Tarjeta90 B8 00 00 07

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.


Byte Valor Significado CLA 0x00 INS 0xC0 P1 0x00 P2 0x00 LC Vacío Data Vacío

LELongitud de los datos esperados como respuesta


Significado

Datos Mensaje respuesta(o parte) de acuerdo a LE



SW1 SW2 Significado

0x61 0xXX Ejecución correcta. Quedan datos disponibles en la tarjeta.

0x69 0x85 Condiciones de uso no satisfechas

0x6C 0xXX Longitud incorrecta (XX indica el valor correcto)

0x90 0x00 Ejecución correcta.

Ejemplo:

Terminal Tarjeta00 C0 00 00 xx

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.


Byte Valor Significado CLA 0x00 INS 0x82 P1 0x00 P2 0x0X Key Id

LC Longitud de los datos, coincide Long Kpub de la tarjeta

Data Datos

LE Vacío

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 || KIFD || 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 Vacío SW1-SW2 Bytes de estado


SW1 SW2 Meaning

0x63 0xCX El código de autenticación no es válido. X expresa el número de intentos posibles.

0x65 0x81 Error de memoria0x67 0x00 Longitud incorrecta0x69 0x83 Método de autenticación bloqueado0x69 0x85 Condiciones de uso no satisfechas0x6A 0x80 Error en el campo de datos0x6A 0x86 Parámetros incorrectos P1-P20x6A 0x87 Lc inconsistente con P1-P20x6A 0x88 Datos referenciados no encontrados

Ejemplo:

Terminal Tarjeta00 82 00 00 P3 xx xx xx ..... xx xxP3: long clave pública de tarjetaxx 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


Byte Valor Significado CLA 0x00 INS 0x88

P1 0x00 Autenticación interna con establecimiento de canal

P2 0x00 Autenticación según EN-14890 LC 0x10

Data RND.IFD || SN.IFD Autenticación según EN-14890 ap. 8.4

LE Vacío


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


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


SW1 SW2 Significado

0x61 0xXX SW2 indica el número de bytes disponibles en la tarjeta como datos de respuesta.

0x62 0x83 El fichero seleccionado está invalidado

0x65 0x81 Error de memoria

0x69 0x82 Condiciones de seguridad no satisfechas

0x69 0x85 Condiciones de uso no satisfechas0x6A 0x80 Error en el campo de datos

0x6A 0x82 No se ha encontrado el EF criptográfico

0x6A 0x86 Parámetros incorrectos P1-P20x6A 0x88 Datos referenciados no encontrados

Ejemplo:

Terminal Tarjeta00 88 00 00 10 xx .. xx yy .. yyxx .. xx desafío del Terminalyy .. yy nº serie Terminal

61 LL00 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 Tamaño Formato DescripciónKRT_CRYPTO 2 bytes 0x01 ||

KeyIDReferencia una clave RSA privada almacenada en ICC.CRYPTO con el identificador KeyID

KRT_IDENT 2 bytes 0x02 || KeyID

Referencia una clave RSA (pública o privada) almacenada en ICC.ID con el identificador KeyID

KRT_MEMORY N bytes CHR del certificado

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 ParámetrosAutenticación (AT).

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

Firma (DST) •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


Byte Valor Significado CLA 0x00 INS 0x22 P1 0xX1 Tipo de operación. P2 0xXX Plantilla a modificar LC Vacío o longitud del campo de datos

Data ‘Data Objects’ a incluir en la plantilla

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.

b8

b7 B6 b5 b4 b3 b2 b1 Significado

---1

--1 -

-1--

1---

----

----

----

----

Asegurar el mensaje que aparece en campo de datos del comando Asegurar el mensaje que aparece en campo de datos de respuestaCá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 Significado‘A4’ Plantilla de autenticación‘A6’ Plantilla para intercambio de claves‘B6’ Plantilla para firmas


SignificadoDatos Vacío SW1-SW2 Bytes de estado


SW1 SW2 Significado0x62 0x83 Fichero invalidado0x6A 0x82 Fichero no encontrado0x6A 0x86 Parámetros incorrectos P1-P20x6A 0x87 Longitud de datos incorrecta0x6A 0x88 Datos referenciados no encontrados

27

Ejemplo:

Ejemplo 1: Selección de la clave Root CA

Terminal Tarjeta00 22 81 B6 04 83 02 02 0F

90 00

Ejemplo 2: Selección de la clave en memoria

Terminal Tarjeta00 22 81 B6 0A 83 08 xx .. xx

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 Tarjeta00 22 C1 A4 0A 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 Tarjeta00 22 41 B6 04 83 02 01 01

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 Tarjeta00 22 41 B6 04 84 02 01 02

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’

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.

‘5F 38’ ‘3D’ 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)

‘42’ ‘08’ CAR Se incluye también en claro para poder 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 01PK_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_part2Hash 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-2CPI = ‘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

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.

‘5F 38’ ‘3C’ 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)

‘42’ ‘08’ CAR Se incluye también en claro para poder 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 01PK_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_part2Hash 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 Uso del certificado0010 0001 Puede utilizarse para la verificación de firma en una

cadena cruzada de certificados0010 0010 Puede utilizarse para la verificación de firma en una

cadena de certificados0000 0010 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.


Byte Valor Significado CLA 0x00 INS 0x2A

P1 0xXXTag indicando el tipo de datos de la respuesta

P2 0xXX Tag indicando el tipo de datos enviado

LC 0x14 Longitud de los datos Datos

Datos de entrada

LE Datos de salida

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

P1 P2 Operación‘00’ ‘AE’ Verificación de certificado. Los datos de entrada son

el certificado, y no se esperan datos de respuesta‘90’ ‘80’ 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

‘90’ ‘A0’ Calculo de hash. En la entrada se entregan los datos

32

con estructura, permitiendo realizar el hash parcialmente fuera de la tarjeta. La respuesta será el hash calculado

‘9E’ ‘9A’ 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


Significado

Datos Mensaje respuesta(o parte) de acuerdo a LE



SW1 SW2 Significado0x62 0x83 Fichero invalidado 0x65 0x81 Error de memoria


0x69 0x85 Condiciones de uso no satisfechas (secuencia de comandos incorrecta)

0x69 0x86 Tipo de fichero incorrecto0x6A 0x80 Campo de datos incorrecto0x6A 0x82 Fichero no encontrado0x6A 0x86 Parámetros incorrectos P1-P20x6A 0x87 Longitud de datos incorrecta0x6A 0x88 Datos referenciados no encontrados

Ejemplos:

Ejemplo 1: Verificar Certificado Autoverificable CA intermedia

Terminal Tarjeta00 2A 00 AE P3

xx .. xx 90 00

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

33

Ejemplo 2: Verificar Certificado Autoverificable Certificado Terminal

Terminal Tarjeta00 2A 00 AE P3

xx .. xx 90 00

xx .. xx Certificado autoverificable del Terminal (longitud P3)

Ejemplo 3: Cálculo de un hash en la tarjeta

Terminal Tarjeta00 2A 90 80 P3 xx .. xx datos sobre los que se calculará el hash. Longitud de los datos P3

61 140x14, hash disponible (longitud 20 bytes)

Ejemplo 4: Firma de un hash con formato PKCS#1

Terminal Tarjeta00 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

Datos = Digest Info + SHA1

61 xxFirma 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).


Byte Valor Significado CLA 0x00 INS 0xA4

P1 0x00

Selecciona DF o EF por Id (data field = id)

0x04 Selección directa de DF por nombre. P2 0x00 LC Longitud del campo de datos Data Datos de acuerdo a P1-P2 LE Vacio


Significado

Datos Plantilla FCI acorde con ISO 7816-4/9.


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

0x6F Long. Plantilla FCI acorde con ISO 7816-4/9. Longitud de los subsiguientes Objetos de Datos

T L Valor0x84 0xXX Nombre del DF name. (Solo para DFs)0x85 0xXX Información propietaria:

Long. Significado

0x01

File descriptor byte:•0x01 Elementary File (EF)•0x34 Dedicated File (DF)•0x15 EF propietario para claves. Linear variable

SIMPLE-TLV

0x02 Identificador de Fichero

0x02 Número de datos en el fichero, excluyendo la información de la estructura cabecera del fichero

0x05 Atributos de seguridad, información propietaria

35

0x6F Long. Plantilla FCI acorde con ISO 7816-4/9. Longitud de los subsiguientes Objetos de Datos

T L Valor0x84 0xXX Nombre del DF name. (Solo para DFs)0x85 0xXX Información propietaria:

Long. Significado

0x01

Control Flag for Security filesSecurity Efs (type 0x15)

---- 000-b CHV keys---- 001-b App Keys---- 010-b RFU---- 011-b RFU0000 100-b Empty RSA KEY file---- 101-b RFU---- 110-b Active RSA Key 1--- 1---b Key generated internally -10- 1---b RSA Key in CRT format-01- 1---b RSA Key without CRT ---1 1---b RFU---- 111-b Inactive RSA Key -100 111-b Inactive RSA Key Type 1-010 111-b Inactive RSA Key Type 2-001 111-b Inactive RSA Key Type 3

0x02

Control bytes for RSA cryptographic filesCryptographic Efs (type 0x15) RSA KEY in CRT format---- ----b XXXX XXXXb bit length of the key in 64 base0000 0000b ---- ----b empty key1--- ----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 present1111 1011b ---- ----b valid RSA with CRT key

Inactive RSA KEY ---- ----b XXXX XXXXb bit length of the key in 64 base0000 0000b ---- ----b empty key---- -1--b ---- ----b A8h-A9h-B8h present---- --1-b ---- ----b Aah-ABh-BAh present---- ---1b ---- ----b Ach-BCh Hash present0000 0111b ---- ----b valid inactive RSA key

RSA KEY without CRT ---- ----b XXXX XXXXb bit length of the key in 64 base0000 0000b ---- ----b empty key---- -1--b ---- ----b private present---- --1-b ---- ----b public exponent present---- ---1b ---- ----b modulus present0000 0111b ---- ----b valid RSA key

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


SW1 SW2 Significado

0x61 0xXX

Ejecución correcta. Se indica el número de bytes disponibles en respuesta al comando como una estructura FCI.

0x62 0x83 Fichero seleccionado invalidado0x65 0x81 Error de memoria (FCI erróneo)0x6A 0x82 Fichero no encontrado0x6A 0x86 Parámetros incorrectos P1-P20x6A 0x87 Lc inconsistente con P1-P2

36

Ejemplos:

Ejemplo 1: Selección del fichero elemental Id: 60 1F

Terminal Tarjeta00 A4 00 00 02 60 1F

61 0E

00 C0 00 00 0E

6F 0C 85 0A 01 60 1F 03 25 00 FF FF FF FF90 00

Ejemplo 2: Selección por nombre del fichero dedicado PKCS-15

Terminal Tarjeta00 A4 04 00 0C A0 00 00 00 63 50 4B 43 53 2D 31 35

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 FF90 00

37

Comando READ BINARY.

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


Byte Valor Significado CLA 0x0X INS 0xB0

P1-P2Offset del primer byte a leer desde el principio del fichero.

LC Vacío Data Vacío LE Número de bytes a leer

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


Significado DatOS Datos leidos (LE bytes) SW1-SW2 Bytes de estado


SW1 SW2 Meaning

0x62 0x83 El EF o DF seleccionados están invalidados



0x69 0x85 Condiciones de uso no satisfechas

0x69 0x86 Comando no permitido (no existe un EF seleccionado)

0x6A 0x82 Fichero no encontrado

0x6B 0x00 Parámetros incorrectos (el offset está fuera del EF)

0x6C 0xXX Longitud incorrecta (XX indica la longitud exacta)

38

Ejemplo: Lectura Binaria

Terminal Tarjeta00 B0 00 00 50

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

00 B0 00 50 40

yy .. yy 90 00yy .. 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.


Byte Valor Significado CLA 0x00 INS 0x20 P1 0x00 P2 0x00 Datos de referencia (código CHV) LC Vacío o longitud del campo de datos Data Vacío o datos de verificación LE


Significado Datos Vacío SW1-SW2 Bytes de estado

39


SW1 SW2 Significado

0x63 0xCx Verificación fallida: ‘X’ indica el número de intentos disponibles.



0x69 0x83 Método de autenticación bloqueado0x69 0x863 Identificador de CHV no permitido0x6A 0x82 No se encuentra el fichero CHV0x6A 0x84 No hay memoria suficiente 0x6A 0x86 Parámetros incorrectos P1-P20x6A 0x88 Datos refrenciados no encontrados

Ejemplo: Presentación de PIN

Terminal Tarjeta00 20 00 00 08 xx .. xx xx .. xx PIN del usuariolongitud en este ejemplo = 8 bytes

90 00Verificació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 =EADEDA455332945039DAA404C8EBC4D3B7F5DC869283CDEA2F101E2AB54FB0D0B03D8F030DAF2458028288F54CE552F8FA57AB2FB103B112427E11131D1D27E10A5B500EAAE5D940301E30EB26C3E9066B257156ED639D70CCC090B863AFBB3BFED8C17BE7673034B9823E977ED657252927F9575B9FFF6691DB64F80B5E92CD

Exponente_público =010001

Certificado de la CA intermedia de Terminal verificable por la tarjeta :

C_CV_CA =7F2181CE5F3781803CBADC3684BEF32041AD155089258DFD20C69115D72F9C38AA99AD6C1AEDFAB2BFAC9092FC70CCC00CAF482A4BE31AFDBD3CBC8C8382CF06BC0719BAABB56B6EC80760A4A93FA2D7C347F34427F9FF5C8DE6D65DAC95F2F19DAC0053DF11A507FB625EEB8DA4C0299E4A2112AB7047588B8D6DA7592214F2DBA140C7D122579B5F383D2253C8B9CB5BC3543A55660BDA80946AFB0525E8E5586B4E63E89241497836D8D3AB088CD44C214D6AC856E2A007F44F83743337371ADD8E030001000142086573524449600006

Identificador de esta CA intermedia (CHR):

CHR =000000006573534449600006

Certificado de Terminal verificable por la tarjeta:

C_CV_IFD =7F2181CD5F3781802563FCF6714624C0C4F5D75F67305EBF8F3A6BB772996AFB6497BB466A238E731D08D378E9F4ECC04070E3717C138EA8D6D35A14ED1862B7F84E351B2DCE4CFB30F8C76B8AD1731E9AA84AB0B3BD30C3F00DA274E2005A51EB4213FD5523ABC97584A9FBD2576CB5DD9DD572AE49A597E14ECFFA91F76E04F6081292AE07CEF75F383C258B73CFB94A739CB5E97392E599E8FB45A60072CAA6FCD5F215C3C7E025EA3C9EB2CBE47DE9FEE8002BF2F6D4A24350AB3F5F15DB05A1270001000142086573534449600006

41

Identificador de este certificado (CHR):

CHR:000000002000000000000001

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

Módulo:DB2CB41E112BACFA2BD7C3D3D7967E84FB9434FC261F9D090A8983947DAF8488D3DF8FBDCC1F92493585E134A1B42DE519F463244D7ED384E26D516CC7A4FF7895B1992140043AACADFC12E856B202346AF8226B1A882137DC3C5A57F0D2815C1FCD4BB46FA9157FDFFD79EC3A10A824CCC1EB3CE0B6B4396AE236590016BA69

Exponente_público:010001

Exponente_privado:18B44A3D155C61EBF4E3261C8BB157E36F63FE30E9AF28892B59E2ADEB18CC8C8BAD284B9165819CA4DEC94AA06B69BCE81706D1C1B668EB128695E5F7FEDE18A908A3011A646A481D3EA71D8A387D474609BD57A882B182E047DE80E04B4221416BD39DFA1FAC0300641962ADB109E28CAF50061B68C9CABD9B00313C0F46ED

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 estadoprevio. 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

fadf3fa9775680300d06092a864886f70d0101050500308187310b300906035504061302455331283026060355040a0c1f444952454343494f4e2047454e4552414c204445204c4120504f4c49434941310d300b060355040b0c04444e4945311c301a060355040b0c134143205241495a20434f4d504f4e454e5445533121301f06035504030c18303030303030303036353733353234343439363030303036301e170d3036303232313039333730335a170d3331303232303137313331355a3072310b300906035504061302455331283026060355040a0c1f444952454343494f4e2047454e9000

00b000ffff 4552414c204445204c4120504f4c49434941310d300b0603

55040b0c04444e4945310d300b060355040b0c04464e4d54311b301906035504030c12414320434f4d504f4e454e5445532030303130819f300d06092a864886f70d010101050003818d0030818902818100de3cc30b668cb2353485fd42a1192125f4a82504197ebd3cb6abffb8e68f2e84293bb725fd618fd10fda1a409737d74bd1b97984685156ceff55f5e3525bc58bfd3799c2a7e300471d9303105ee8ec4c67d476dc48d1834670c27ebf4668779d7b855b44afa733da451bb954994a718910fde6313aab6266313fdbd1564fa57d0203010001a38201a7308201a330120603551d13019000

00b001feff 01ff040830060101ff020100301d0603551d0e041604143f

320e9794b8f9566ea3d721a61754fa923a12b1301f0603551d2304183016801445d76465f22504d8045e6627419d765005a2d158300e0603551d0f0101ff04040302010630370603551d200430302e302c0604551d20003024302206082b060105050702011616687474703a2f2f7777772e646e69652e65732f647063308201020603551d1f0481fa3081f73081f4a081f1a081ee8623687474703a2f2f63726c732e646e69652e65732f63726c732f41524c434f4d2e63726c8681c66c6461703a2f2f6c6461702e646e69652e65732f434e3d43524c2c434e3d3030303030303030363537339000

00b002fdff 3532343434393630303030362c4f553d4143253230524149

5a253230434f4d504f4e454e5445532c4f553d444e49452c4f3d444952454343494f4e25323047454e4552414c25323044452532304c41253230504f4c494349412c433d45533f617574686f726974795265766f636174696f6e4c6973743f626173653f6f626a656374636c6173733d63524c446973747269627574696f6e506f696e74300d06092a864886f70d0101050500038181008f837ad2f2a8c4ba6ab45e0d4b392d6ec0e66b9da3f97efb08da7dc3bbd3a6549be10471ff7f28209a17f0717af6f6d51e9f30dfd58fe804f02bf2b25820def595c2ed85e3b080380438d824702180469000

00b003fc30

44

2667f29d75b30cb9f2bb4a03dda58de2c150ed316ab9b29ca63210017dd70ffc21316f88f753904d743b70214523760a9000

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

ff47d829436117300d06092a864886f70d01010505003072310b300906035504061302455331283026060355040a0c1f444952454343494f4e2047454e4552414c204445204c4120504f4c49434941310d300b060355040b0c04444e4945310d300b060355040b0c04464e4d54311b301906035504030c12414320434f4d504f4e454e54455320303031301e170d3036303232343137353232345a170d3137303232343137353232345a3026310b3009060355040613024553311730150603550403130e303635413835434135383646333230819f300d06092a864886f70d010101050003818d9000

00b000ffff 0030818902818100d1d60b95e4522a480b12b8bd565a6141

3c79279eab0e60d7d490199e6786d1c965a9cefe06a38edb9a5b89c47248fbd44932c8b908cf5111d9fb9635d1fcc94e3f0ef3e654f7c062686ba4c63ae7319899bd32b0e1b74ea2889e6b98def58ed17d4d0e55d9f12b6c61a5d2a535cbc25365513479458337b3f84556acb807511d0203010001a38201023081ff300c0603551d130101ff04023000300e0603551d0f0101ff040403020388301d0603551d0e04160414b20804697314e07b66f48b0140009a26ed41654a301f0603551d230418301680143f320e9794b8f9566ea3d721a61754fa923a12b1303f06082b06010505070101049000

00b001feff 333031302f06082b060105050730028623687474703a2f2f

7777772e646e69652e65732f63657274732f41435261697a2e637274305e0603551d1f045730553053a051a04f864d687474703a2f2f63726c732e666e6d742e646e69652e65732f63726c732f43524c383439313434323239324334334237334134454531314438443446354138463741324139443233342e63726c300d06092a864886f70d010105050003818100575c9b73f6dea428b98f6008cc6f66e03ed4a408f6247f2b36ee0450072297f29b749beb49cfb965d575a533eb342f4d3a4b25805dc0f98e0bcd02c56c13861eee635bb9760bde484059bd7caa77ed8274d4a405bccd4d8c9000

00b002fd28

45

55a441f4e0492fc7ff7fd6b0b76dfcb98972720fe3f8c1d858c3a96de551d4a0bb02131279d20a199000

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 =d1d60b95e4522a480b12b8bd565a61413c79279eab0e60d7d490199e6786d1c965a9cefe06a38edb9a5b89c47248fbd44932c8b908cf5111d9fb9635d1fcc94e3f0ef3e654f7c062686ba4c63ae7319899bd32b0e1b74ea2889e6b98def58ed17d4d0e55d9f12b6c61a5d2a535cbc25365513479458337b3f84556acb807511d

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’:

002a00aed27f2181ce5f3781803cbadc3684bef32041ad155089258dfd20c69115d72f9c38aa99ad6c1aedfab2bfac9092fc70ccc00caf482a4be31afdbd3cbc8c8382cf06bc0719baabb56b6ec80760a4a93fa2d7c347f34427f9ff5c8de6d65dac95f2f19dac0053df11a507fb625eeb8da4c0299e4a2112ab7047588b8d6da7592214f2dba140c7d122579b5f383d2253c8b9cb5bc3543a55660bda80946afb0525e8e5586b4e63e89241497836d8d3ab088cd44c214d6ac856e2a007f44f83743337371add8e030001000142086573524449600006

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’:

002a00aed17f2181cd5f378180825b69c6451e5f517074385f2f17d64dfe2e68567567094b57f3c578e830e425572de828faf4de1b01c394e345c2fb0629a393492f94f570b00b1d677729f755d107022bb0a116e1d7d7659db5c4ac0ddeab07ff045f37b5daf1732b54eab238a2ce17c9794187759cea9f92a17805a27c1015ec56cc7e471a488e6f1b91f7aa5f383cadfc12e856b202346af8226b1a882137dc3c5a57f0d2815c1fcd4bb46fa9157fdffd79ec3a10a824ccc1eb3ce0b6b4396ae236590016ba690001000142086573534449600006

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

d116074d33e60457f189b976235cab5762b64f896be8a9241a245dcac976fa2d0cac8719157e2927c61e0bcb48b51170ea0898381ef919398e46417899abe82708addd1b755c056f5f7b96ba69bd56fc576c809b27b8f8364fc4d559d1da8681fa04145ddd636eb79000

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


h[PRND1 || KICC || RND.IFD || SN.IFD ] = hash SHA1 que incluye los datos aportados por la tarjeta y por el terminal


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

Mensaje entregados por la tarjeta: 437393b30d1f0161455bb132e999de7bb8f7d82f91d507d6d116074d33e60457f189b976235cab5762b64f896be8a9241a245dcac976fa2d0cac8719157e2927c61e0bcb48b51170ea0898381ef919398e46417899abe82708addd1b755c056f5f7b96ba69bd56fc576c809b27b8f8364fc4d559d1da8681fa04145ddd636eb7

Mensaje descifrado con clave privada de Terminal:0b9b44777590ea6c4d1f1f724c235964c5ffed0109aab5d480b05b7a31c224a4d1c7effe147d454eaaf7d47c35f0dd01824023282bf8bb3cf1adecd576509672348a9eb196c8b8f1f49931ea73e634f681a7474480243992f177a92f386747a06f57ae0566b5557efc0217cc8be84f50dae24b0a35cd3df1f2429b96545464d5

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: 670f3942a1c15faed26cf22c0c87a8930dc3c1f73f772c82096fe5198ef3b03b72257a8bf8d5c26425faf638758072f3357ef10ee95f1284f8f277444fb0416ef092d8007abd245d46b12f3dcfbc303bb7f3e0134d53e542dcccc6f4269784b4affdb92cadd0494dcc58a142e901a8c940ed480554077ba1b2263e8b415e8461

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(..)c63ac71e6ec13fdbbdf3994b0a3707dc76793a9da163ab0353dfbe2435c4ad2493e1defff226498cef63b5483c581ed2c6f2a590dcd695d4e84da9605bac32dc0a845534be2f077073d272dbc700fca21815eb6c6193150f9726c269a68e47310df56050733bd5ed65a3bad8a9e373028a6ee96f0fb5f9c20602bb1663b2ec48

Descifrado con clave pública de tarjeta: 6ac6d2534290ca9938a5c69149d2b8ae2eb565a76b973455cb203484d893218df38454720dcdcc777460938bfcc888e113b3d7aa1f703e8ce1091ef1824c87df4e7c1be5da3a9c0521ba75886b2b015ce1c9529d9463695fabd1a4a4b85e0a1ccd4f55292c20e21e954d31624cca198a2463ec73f17bbc12461f182176a8ccbc

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

c6d2534290ca9938a5c69149d2b8ae2eb565a76b973455cb203484d893218df38454720dcdcc777460938bfcc888e113b3d7aa1f703e8ce1091ef1824c87df4e7c1be5da3a9c0521ba75


886b2b015ce1c9529d9463695fabd1a4a4b85e0a1ccd4f55292c20e21e954d31

h[PRND1 || KICC || RND.IFD || SN.IFD ] = hash SHA1 que incluye los datos aportados por la tarjeta y por el terminal

624cca198a2463ec73f17bbc12461f182176a8cc

‘BC’ = relleno según ISO 9796-2 (option 1) bc

Datos sobre los que calcular el hash: c6d2534290ca9938a5c69149d2b8ae2eb565a76b973455cb203484d893218df38454720dcdcc777460938bfcc888e113b3d7aa1f703e8ce1091ef1824c87df4e7c1be5da3a9c0521ba75

886b2b015ce1c9529d9463695fabd1a4a4b85e0a1ccd4f55292c20e21e954d31

231dac737ba0fe6e

2000000000000001Hash 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


h[PRND2 || KIFD || RND.ICC || SN.ICC ] = hash SHA1 que incluye los datos aportados por la tarjeta y por el terminal


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

PRN2:2a5c7300d96df9190ec2ae1cef89bde15678a78b7f7d4df3d7d9bcfa313a0986efcc39695bd29812d2ce5931e1c2fc2d068a5caf3de5bafef621cd8ba7082659a307d9a45318d4798084

Kifd:cd97dbf2235760d8b3e9c4d7e9a691fb12cd207c42660df9c69357ba7b25d0fc

Calculamos el hash:

Datos sobre los que calcular el hash:2a5c7300d96df9190ec2ae1cef89bde15678a78b7f7d4df3d7d9bcfa313a0986efcc39695bd29812d2ce5931e1c2fc2d068a5caf3de5bafef621cd8ba7082659a307d9a45318d4798084

cd97dbf2235760d8b3e9c4d7e9a691fb12cd207c42660df9

50

c69357ba7b25d0fc

eaefa8fbd31ac8ec

00065a85ca586f32Hash calculado:

b82a94c0aea15d96eb0deb0a68828a1bef1b43fc

Construimos el mensaje en claro:

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

6a

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

2a5c7300d96df9190ec2ae1cef89bde15678a78b7f7d4df3d7d9bcfa313a0986efcc39695bd29812d2ce5931e1c2fc2d068a5caf3de5bafef621cd8ba7082659a307d9a45318d4798084


cd97dbf2235760d8b3e9c4d7e9a691fb12cd207c42660df9c69357ba7b25d0fc

h[PRND2 || KIFD || RND.ICC || SN.ICC ] = hash SHA1 que incluye los datos aportados por la tarjeta y por el Terminal

b82a94c0aea15d96eb0deb0a68828a1bef1b43fc

‘BC’ = relleno según ISO 9796-2 (option 1) bc

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

SIG:59d8b4c3cbe41cf96b60dadc845c53f7147a8269a75e24c3db06d974d59e3de1b7d913acfef9b83321b938740df1c8f1d7bfd4f6aa84507702b0437c24d19e617e2302a08ac9a7fc0a972317c8d63cbde35c519f22dee850c9f829b4f8e765ff47692ca26ce8da55b286bb2f09f18d6048e6c75ad0674380cd6c49b50274289c

Calculamos N.IFD-SIG para poder obtener SIGMIN, que en este ejemplo coincide con SIG:

N.IFD-SIG:8153ff5a45479000c076e8f7533a2a8de719b2927ec178452f82aa1fa81146a71c067c10cd25da1613cca8c093c264f342348e2da2fa830ddfbd0df0a2d36117178e9680b53a92b0a364efd08ddbc576879bd0cbf7a938e7124430a2f7eb1b5cd8641f1202c03b2a2d76bebd301f1ac483db23e2104f70b8

51

9d75eca3fda291cdSIGMIN:

59d8b4c3cbe41cf96b60dadc845c53f7147a8269a75e24c3db06d974d59e3de1b7d913acfef9b83321b938740df1c8f1d7bfd4f6aa84507702b0437c24d19e617e2302a08ac9a7fc0a972317c8d63cbde35c519f22dee850c9f829b4f8e765ff47692ca26ce8da55b286bb2f09f18d6048e6c75ad0674380cd6c49b50274289c

Por último cifraremos el mensaje con la clave pública de componente de la tarjeta, lo que nos da:

Datos autenticación externa:af7f20e622485f3700ab7473c201940dd855d36c68b5ebecddac383464f41cdea31d5b4045e7025d5f394a9e4c298747ae9300725bee8dfac5dab68df80ecb38e98109f2fe83effcfc74c7c850f6cd752f60ea9fcbd4acc4da3a453a08c937a088fe7580c1f0578892d945926c84f282c4ae00ebe2acbc548fc0ee396d2764c8

Enviamos el comando a la tarjeta, y si todo está bien calculado, deberá aceptarlo sin error (devolverá 9000):

0082000080af7f20e622485f3700ab7473c201940dd855d36c68b5ebecddac383464f41cdea31d5b4045e7025d5f394a9e4c298747ae9300725bee8dfac5dab68df80ecb38e98109f2fe83effcfc74c7c850f6cd752f60ea9fcbd4acc4da3a453a08c937a088fe7580c1f0578892d945926c84f282c4ae00ebe2acbc548fc0ee396d2764c8

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:cd97dbf2235760d8b3e9c4d7e9a691fb12cd207c42660df9c69357ba7b25d0fc

Kicc:886b2b015ce1c9529d9463695fabd1a4a4b85e0a1ccd4f55292c20e21e954d31

Kifdicc:45fcf0f37fb6a98a2e7da7beb60d405fb6757e765eab42acefbf775865b09dcd

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:45fcf0f37fb6a98a2e7da7beb60d405fb6757e765eab42acefbf775865b09dcd00000001

hash:598f26e36e11a8ec14b81e19bda223caebc69784

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:45fcf0f37fb6a98a2e7da7beb60d405fb6757e765eab42acefbf775865b09dcd00000002

hash:5de2939a1ea03a930b88206d8f73e8a7aefdaa4b

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:



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 8ac2bdCompletando de nuevo con relleno 7816:

0ca4040080000000 8711013e9ac315a8e855dd3722f29107 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:0ca40400198711013e9ac315a8e855dd3722f291078ac2bd8e04b6f56963

Enviamos este mensaje a la tarjeta:

0ca40400198711013e9ac315a8e855dd3722f291078ac2bd8e04b6f56963

612d 00c000002d 872101bb10c8915f0ddb630cf38ed799a202647ca47449d2

79139fc226d25c20765645990290008e049aa777079000

Para descifrar y comprobar la respuesta de la tarjeta, empezamos descomponiendo los TLV que lo forman:

TLV de datos:872101bb10c8915f0ddb630cf38ed799a202647ca47449d279139fc226d25c20765645

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

79139fc226d25c2076564599029000Con relleno 7861:

872101bb10c8915f0ddb630cf38ed799a202647ca47449d279139fc226d25c207656459902900080

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:872101bb10c8915f0ddb630cf38ed799a202647ca47449d279139fc226d25c20765645

Datos encriptados:bb10c8915f0ddb63 0cf38ed799a202647ca47449d279139f c226d25c20765645

Desencriptando con Kenc:6f19840b4d617374 65722e46696c65850a383f00000bffff ffffff8000000000

Eliminando relleno 7816:6f19840b4d617374 65722e46696c65850a383f00000bffff 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:



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 = KprivAutenticacionCKA_ID = A065A85CA586F3220060302120000Path = 3F110101

Segunda Clave:CKA_LABEL = KprivFirmaDigitalCKA_ID = F065A85CA586F3220060302000000Path = 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):

[002a9e9a233021300906052b0e03021a05000414839b543fb09d20c803b46e6f8f0747244951822f]

0c2a9e9a31872901e2f39b27db5bc373dde1ea4de7c843711529a8f8ded8092fbc88ba9c2b6b7c18b9ffbf4f01def59a8e04ae86da97

6100 00c0000000 8782010901e4e9ca20eb996f14f219d086b13187d640a7f7

d9a93b74368870e7300ec5db202e683e8507ae871ff9fe6c10cd6b66e942affac1996a2048e0564d8edd8b0057eaa0576ec83e0b62eb07bea6f74a43a8d4a518f55daeba0bc6a87f0e30fb1a75d4472108ecb043dcd2f22f85db5640c86b500bf5a819ac7363d879f98b4295359d2f7c04f134fd28af07b7e5b327f3214a816fcda489b17e0a0f9b9c3af5b7ceaa4311c7a66eece210de9b471c78aef858cfeaeb11da40ba932d49900b73f6a14451c0cae04b085b62aa19037b62eaf7b97bf7e6df54cb8a4e3db5bc56818467ac756b53ba04b5db0f55c1db23f2289f9e2c359671ba174a9ecde26117

00c0000017 784dd3609f32f040dae1c1447e990290008e04999b1e4e9000 [632369fa040ccb9f298fdcc2a3e344d815be131e2a609792

9cf9d1fe35fd472580f56c67e040a2437d37f1320a7d802527e6eb2734f848315625f6bd14935ed72d1c1e42f5f41bc653d83fc180b98fff5b0f3ba5ef159d2de0737e9d4a86469a156ca7711ad7d9c2d10c797696062cac0b656c0b04b988c7e447fdf43add6e3a379f1f6e4e115916a49f1cf18ce4421e41ac044c5dca70a90e58b155212b7caa22bfd1e42ba60a0292d531943f2adf6bd0f238ecf931bbdfd98d085edc0050dcc799480415f0282e1f9e57b013ea3732330dffa6daba8957a55d34d004fd3259e6bdd9e568face8118d2e1eff13adeb23e1c58f5fafefe38e1374c631281a6689000]

Por lo tanto, la firma calculada es:

Firma del hash de los datos:632369fa040ccb9f298fdcc2a3e344d815be131e2a6097929cf9d1fe35fd472580f56c67e040a2437d37f1320a7d802527e6eb2734f848315625f6bd14935ed72d1c1e42f5f41bc653d83fc180b98fff5b0f3ba5ef159d2de0737e9d4a86469a156ca7711ad7d9c2d10c797696062cac0b656c0b04b988c7e447fdf43add6e3a379f1f6e4e115916a49f1cf18ce4421e

59

41ac044c5dca70a90e58b155212b7caa22bfd1e42ba60a0292d531943f2adf6bd0f238ecf931bbdfd98d085edc0050dcc799480415f0282e1f9e57b013ea3732330dffa6daba8957a55d34d004fd3259e6bdd9e568face8118d2e1eff13adeb23e1c58f5fafefe38e1374c631281a668

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 = CertAutenticacionCKA_ID = A065A85CA586F3220060302120000Path = 60817002

Segundo certificado:CKA_LABEL = CertFirmaDigitalCKA_ID = F065A85CA586F3220060302000000Path = 60817001

Tercer certificado:CKA_LABEL = CertCAIntermediaDGPCKA_ID = S065A85CA586F3220060302000000Path = 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

697f6b7bae797005d20adbafbba31fc2f8e9ceaeb90b79631a230e69e57c06fb7f58e3f2ef0e11211195d87572a2ee38ec91e8722bd660db01c718d6f0d8509de1e4b81cc169e18a128c638c705f4b5e5ebe0f02d9c5edf06908f472feda8953f04db368cd270baf5098fd8d38447df3d44952100510fc09a85b9055ce475867beb21f252e28e68bb0188abf70103d372c9ffba2270a6e13c393256ab44504f9021037d45a621e828307a14efdcd5796f39190632861ff195ffc9d2167a1879d0abc269354a76489cd574d2ea76e40ee7c3d04e0aeeb7dfdf917cbb3990290008e042d30f6009000

[e8050000b3040000789c3368627d62d0c4726601331323139300af5929b7e022f54617b62713652f1cbe6bc0cbc6a9d5e6d1f69d9791919595c120c690db80938d3994854d98c935d850c3400dc4e1e29177f10c727576f6f4f7537077f5730d72f451707155f0715408f0f7f174f67434e435e006a9e4e66171f1f3743514311002719979b81d9d1540220a0606860672e2bc066606c6064686464666a6e65140ae8581259c6b50866abb90810088c32acc69000646c621307b587858bc421dfd0c050df8415c2d1e0ed7e000c7c313fd7d0c0d0df421566bc08414600c1d059026050dc7d01057bf104f674767cf9000]

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

61

fa9c9259e12392e14ebfbe81549405a5038343e85b774eb02b7df7e57ece210bff119f5f9ecf3de16fbfe9e5516273b281ef0e21f40b9aa6e5ebcac0450a18784c3b3989c6c3b9b4e5aa20d95cb9e1333842696f154316055c408553cb47f7d5ffc4315d44fa4c851c16c55f5f06a897ecc0e6fbb67398dc9f414b771ebe0039c506e49e529ec757e2550ab85c38320ab1aa977a70e803d9f35da6bfb1e1e7ef5be4748d33234966c00840a733e05e67107a1234a9f41219ee92f0228504e8b71baf9affddc36093ead8705008b3fc62cba13cf7c9b02b7641b955cb990290008e04398d9f209000

[c393fd340d9a1895900382919581b989919f0128cec5d4c4c8c870e84ab9f987c4f4e3efda98f4d466fd75bd1a7d2469a7e81de1996bf8e79a374f7ca9707f6148c633d7aacf5e37e4265ca9c91311769733b1bb3a7d9bfbffd8779716cecbf55abaafff5ef8b2c88c98b0d07b7d6a063c9f9a67e90b862cf2cede90e9b8f4a8bbe3b9eb16ce13b98df8b6adb294fffdb14177c934f3042df179afe35ab5fe67346cac6b0e773f314b80e9b0cbf7290b647beb736b3a0c9cdc17c878f979685488bf9c715a607dc4ddc7524527aaa48e7f9b312dbde5bfc801ff6f4aa9ccde0bfee42707e87ae74418fc993aebe3cc9000]

[00b001deef] 0cb001de099701ef8e04537dd3e6 61fe 00c00000fe 8781f101c80473207556fd7f00d1c0a2ef0b156ec3d6901f

efc8ea9a5ad065b30ac38839b6242b4a5ac4f7af7c620917e022b35ac5c59b6918dead31cea1488aabd7c2b35a7c2e6ca4159a02c660f7674fd04aa31a013452b40bf36fe4a0c2fe53552b56a0f6814fcd4bbbd17b8d1974bb69067ead830a497109b513507b76a41df522641a965b0d087f32d3c101b88e446219ecf77727fa033c315f277a888d0492498d5f227f0e2e8a3c99f5631e5485a252ad43b42b1fa768bac9d54a5ac9796b32ce14c03b790cd4474ca7f1583e14b99ba26e30dc4097e3f61248b9b5d237dc53010b5ae8f34f647febf8a1d0b89844a15d990290008e04df3d0c1d9000

[30a545b396093f69ea7aae5bb46d717c3acf85c31b0aeebc3eba2dce4be0ad466224c789231b565a356a3031edf48bd46060af093775f3fbcec4ccc8c0b8b889a9cda089a9c9800718bcb2c28c8cff59980c180cf8403c7e108f859989bdc14016c4e7631163117999fe5026f2d31df3cbda496d026bee30aeb9af9e62200f9256669130106b1091ea5c71f45d7f596c6861e7676bd3bdab5819a6e61b28b17168b301d3223b23338b98818801071b1b0b439f1b23239cc562900057c3c8126210043414ca37606c13ce282929b0d2d7cf4f2e2ed04bc9cb4cd54b2d06a6089802a63665a882f2f27298bc7e726a519000]

62

[00b002cdef] 0cb002cd099701ef8e048e11b7f4 61fe 00c00000fe 8781f101d18a6305065cc06862c9e6e1011528d61ccd546c

a61d59930bc697fbba768ed933d6fd8b79ef635449a94a519071ce33e9176b7968520c42f8c2f92a314062f35060e63c1d4246d540f2680b4f539b0c21b8ff94f699fd962b2283d9593246c289f200e75533819f95b7e172117b3b8cc2f7191f61c785905c500a69a362a9f82c95877f6aeec27236a48170c224ae7c96948a95e2858d5377ca208a0df25b74392a6eefc3a773e196193bdee3e42aa5c2da03c74a9fd886668c4e59e9482624d7abad231090f2f63d9c97738b4c4c5cafda92c5738a4ccc7f7377ab2f2650c98e69377d0faa1fe578092c0e4ada6869990290008e0486200d469000

[49b1bea373506266955e7251898135c8990a2c26064606066c1c09ad21c0ccc3c462a082701e13a398181693520a920d1a3fc0ddc7c4d2f8d8a0f181811113d003dc6c9c096d1e8ca9cc2c4c8c2c0aa1b67cacf60fd64bc7cc683388bfece376f4a1d2b33ba6191327cdbef5b850ff7936480f03a97aac80cac18e052aa7402f1ba97a3540e1c5c9a268200f4c0050cf73321a0a4af01b5a9a0173be91a9a111280b471938c182938591c5ccc004e44b2634db02abd2fa1e2e7aecb7dcf75ff89d4a815f6bc3c38d27a9ba7194fe7f97bd7a52ca12b4428b199445bd180515365cef3c1a1dbd5ecf6dddda7edd73319000]

[00b003bcef] 0cb003bc099701ef8e04dd235d61 61fe 00c00000fe 8781f101750c77ccaf5c18cdfe6c0cbd5a66772ca56995d8

1932677e0d3954f87010b02e070502dc3444023faa127a5a28cad4db3f1adcb0e0848c35fd418dbcfa0b9acf9bff811bac4d6ef1b0c5df7818539eb8ba1f3edc51874d6cfa8f2a1d93a245523755dabe07f44b364afc3265236ce3c55cb0217b00e6da7cd9afd861d1a0840086ef1aac2e1b842357ca44c1e918c877ce60edaac1b8529644b64baba80cc3c74867d5f9132f19cabe8094496a8ff6994963982a43ba41eb733f16ab83b3e7941fcc0ef9c0b5bb472c25b0227c0b9fe9c537a0b11ce03ec92fb82c2d10a47163194319a1a54a57da771a14ebc86f5d2a990290008e0413713a3f9000

[ca7107799d04152b4fbc522ffbd693ce71ecb3700d4f94327b36c39ca2d9499fddd6bb7f9512baca1ab9fa8de6c52d8f1497e50598e77e6b38ecfc96d9fbda84047f79d7f33396f7316d3511564daa3fd1adaa98fe9d7dc5d5f61533ffa807ecdbecaff7cce7f2c16d425646ec4eacc63f76711c79762ae85bc3df42f557738eaf13ba21788ad5e976df3bb9e90a3fd55a0bfb74e34ae6ed50bb9e7fdab2c349f3ee8ac7073e45e8

63

ce2ff25a6ada29f96285ef9aeb31f5acb7cc2cb6cc7a92603cc1904ff460b83b8364e5676d91d9520fd62bb71fe5edb62958ccc4ab9f719be123df963333bf046e4b75faf7f6a69000]

[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:789c3368627d62d0c4726601331323139300af5929b7e022f54617b62713652f1cbe6bc0cbc6a9d5e6d1f69d9791919595c120c690db80938d3994854d98c935d850c3400dc4e1e29177f10c727576f6f4f7537077f5730d72f451707155f0715408f0f7f174f67434e435e006a9e4e66171f1f3743514311002719979b81d9d1540220a0606860672e2bc066606c6064686464666a6e65140ae8581259c6b50866abb90810088c32acc69000646c621307b587858bc421dfd0c050df8415c2d1e0ed7e000c7c313fd7d0c0d0df421566bc08414600c1d059026050dc7d01057bf104f674767cfc393fd340d9a1895900382919581b989919f0128cec5d4c4c8c870e84ab9f987c4f4e3efda98f4d466fd75bd1a7d2469a7e81de1996bf8e79a374f7ca9707f6148c633d7aacf5e37e4265ca9c91311769733b1bb3a7d9bfbffd8779716cecbf55abaafff5ef8b2c88c98b0d07b7d6a063c9f9a67e90b862cf2cede90e9b8f4a8bbe3b9eb16ce13b98df8b6adb294fffdb14177c934f3042df179afe35ab5fe67346cac6b0e773f314b80e9b0cbf7290b647beb736b3a0c9cdc17c878f979685488bf9c715a607dc4ddc7524527aaa48e7f9b312dbde5bfc801ff6f4aa9ccde0bfee42707e87ae74418fc993aebe3cc30a545b396093f69ea7a

64

ae5bb46d717c3acf85c31b0aeebc3eba2dce4be0ad466224c789231b565a356a3031edf48bd46060af093775f3fbcec4ccc8c0b8b889a9cda089a9c9800718bcb2c28c8cff59980c180cf8403c7e108f859989bdc14016c4e7631163117999fe5026f2d31df3cbda496d026bee30aeb9af9e62200f9256669130106b1091ea5c71f45d7f596c6861e7676bd3bdab5819a6e61b28b17168b301d3223b23338b98818801071b1b0b439f1b23239cc562900057c3c8126210043414ca37606c13ce282929b0d2d7cf4f2e2ed04bc9cb4cd54b2d06a6089802a63665a882f2f27298bc7e726a5149b1bea373506266955e7251898135c8990a2c26064606066c1c09ad21c0ccc3c462a082701e13a398181693520a920d1a3fc0ddc7c4d2f8d8a0f181811113d003dc6c9c096d1e8ca9cc2c4c8c2c0aa1b67cacf60fd64bc7cc683388bfece376f4a1d2b33ba6191327cdbef5b850ff7936480f03a97aac80cac18e052aa7402f1ba97a3540e1c5c9a268200f4c0050cf73321a0a4af01b5a9a0173be91a9a111280b471938c182938591c5ccc004e44b2634db02abd2fa1e2e7aecb7dcf75ff89d4a815f6bc3c38d27a9ba7194fe7f97bd7a52ca12b4428b199445bd180515365cef3c1a1dbd5ecf6dddda7edd7331ca7107799d04152b4fbc522ffbd693ce71ecb3700d4f94327b36c39ca2d9499fddd6bb7f9512baca1ab9fa8de6c52d8f1497e50598e77e6b38ecfc96d9fbda84047f79d7f33396f7316d3511564daa3fd1adaa98fe9d7dc5d5f61533ffa807ecdbecaff7cce7f2c16d425646ec4eacc63f76711c79762ae85bc3df42f557738eaf13ba21788ad5e976df3bb9e90a3fd55a0bfb74e34ae6ed50bb9e7fdab2c349f3ee8ac7073e45e8ce2ff25a6ada29f96285ef9aeb31f5acb7cc2cb6cc7a92603cc1904ff460b83b8364e5676d91d9520fd62bb71fe5edb62958ccc4ab9f719be123df963333bf046e4b75faf7f6a6810bdff7e4830fe75e780e00c9adeabc

Si los datos comprimidos los expandimos con la librería zlib obtendremos el certificado X509 de autenticación del ciudadano:

Certificado X509:308205e4318204cca00302010202100d36750b11a227814406e4911dd0c3dd300d06092a864886f70d0101050500305c310b300906035504061302455331283026060355040a0c1f444952454343494f4e2047454e4552414c204445204c4120504f4c49434941310d301b060355040b0c04444e49453114301206035504030c0b414320444e494520303031301e170d3036303330323132323635375a170d3038303930323132323635375a3076310b30090603550406130245533112301006035504051309303030303030323354310d300b06035504040c044a55414e3111300b060355042a0c0845535041c3914f4c3131302f06035504030c2845535041c3914f4c2045535041c3914f4c2c204a55414e2028415554454e544943414349c3934e2930820122300d06092a864886f70d01010105000382010f003082010a0282010100c2d47737f06167c7ee86022e269afd45d55bc462b915dc1399ac0f9d378391e920dfa1

65

5468e6457af34ad81e90d47c6e1413471e343ed597b647ff5deed2a19e6d4aa5be8fde57a659685c5655de8e26300cf2839a2f1154a24b6bb06941a5c54741ced73843910b320eb6aa391ffbf1802da49637602a179eeb5e852aff6880b17e835747c89a1002c344f794a01d8d7f6d7c88304247a01c4a4e48287817e998cb10af58dde31a72c87a1ac7f698966784ff14c04ff62265034ba0fc6f63502d4b6c5830fc959af1995622a29aa613e4828ae72d72b6a35f670cd0c3b070dcebc5b65e4a10ed28615908c8c4b0a93a81280202b94e592800077c5735464ef70203010001a382028630820282300c0603551d130101ff04023000300e0603551d0f0101ff040403020780301d0603551d0e04160414e967e11c59f2dc37d32b628610acdc01acdf2764301f0603551d230418301680141a89a8c5ee8f765d557189f33b35bdaa0500956f302206082b06010505070103041630143008060604008e4601013008060604008e460104306006082b0601050507010104543052301f06082b060105050730018613687474703a2f2f6f6373702e646e69652e6573302f06082b060105050730028623687474703a2f2f7777772e646e69652e65732f63657274732f41435261697a2e637274303b0603551d20043430323030060860855401020202043024302206082b060105050702011616687474703a2f2f7777772e646e69652e65732f6470633081f006082b060105050701020481e33081e03032020101300b06096086480165030402010420553d0e053fe0af1b5c9886305fd34c46c5e122e6dc356891929bdae3712fe76b3032020100300b06096086480165030402010420553d0e053fe0af1b5c9886305fd34c46c5e122e6dc356891929bdae3712fe76b303a0609608554010202040201300b06096086480165030402010420553d0e053fe0af1b5c9886305fd34c46c5e122e6dc356891929bdae3712fe76b303a0609608554010202040206300b06096086480165030402010420553d0e053fe0af1b5c9886305fd34c46c5e122e6dc356891929bdae3712fe76b30280603551d090421301f301d06082b060105050709013111180f31393630313032353132303030305a304206086085540102020401043630343032020102300b06096086480165030402010420517a668ee1a2e34ea75dfe57dc7910faad5757339225460875ffee6bab9264a4300d06092a864886f70d010105050003820101004a011120b0d789c55b5baf2e46aead8f2dce5c235ec10d42112179c8ea2776f68c6708c6f3137c0c5a23076b009c729b62f346af47f51a12d50559abec29d1b4e221a66e50376df680c343ed034bd690604f1f45cf98a78e02b5341325627fc88b252167f707a8d587a899fc2750beb34f2ee64cd3c1b6123a3206420533f8ba08c4e6ca52f680fd7127ea9cc7ae12d811ca0542db8eee1e9720f92685718e2d5e749eb826d76fcb39884229dda8e3c0f2582d9f724aa5358919e8a84dacd75c7f05da3638b49ae4603390310e15c15747001979f32b149b1ae0af2387c50d8b3c70a3020d2f68db00f10eb4cc99f451b66542deedd930440ef763c1e19dd0e7

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 =2cd47737f06167c7ee86022e269afd45d55bc462b915dc1399ac0f9d378391e920dfa15468e6457af34ad81e90d47c6e1413471e343ed597b647ff5deed2a19e6d4aa5be8fde57a659685c5655de8e26300cf2839a2f1154a24b6bb06941a5c54741ced73843911c320eb6aa391ffbf1802da49637602a179eeb5e852aff6880b17e835747c89a1002c344f794a01d8d7f6d7c88304247a01c4a4e48287817e998cb10af58dde31a72c87a1ac7f698966784ff14c04ff62265034ba0fc6f63502d4b6c5830fc959af1995622a29aa613e4828ae72d72b6a35f670cd0c3b070dcebc5b65e4a21ed28615908c8c4b0a93a81280202b94e592800077c5735464ef7

Exponente público:010001

Desencriptando con esta clave pública la firma generada anteriormente:

Datos firmados con clave de autenticación:632369fa040ccb9f298fdcc2a3e344d815be131e2a6097929cf9d1fe35fd472580f56c67e040a2437d37f1320a7d802527e6eb2734f847315625f6bd14935ed72d1c1e42f5f41bc653d83fc180b98fff5b0f3ba5ef159d2de0737e9d4a86469a156ca7711ad7d9c2d10c797696062cac0b656c0b04b988c7e447fdf43add6e3a379f1f6e4e115916a49f1cf18ce4421e41ac044c5dca70a90e58b615212b7caa22bfd1e42ba60a0292d531943f2adf6bd0f238ecf931bbdfd98d085edc0050dcc799480415f0282e1f9e57b013ea3732330dffa6daba8957a55d34d004fd3259e6bdd9e568face8118d2e1eff13adeb23e1c58f5fafefe38e1347c631281a668

Firma desencriptada:0001ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff003021300906052b0e03021a05000414839b543fb09d20c803b46e6f8f0747244951822f

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

2010.09.30 - Manual de Comandos Del DNIe - Tractis

Documents

Transcript of 2010.09.30 - Manual de Comandos Del DNIe - Tractis