2010.09.30 - Manual de Comandos Del DNIe - Tractis

MINISTERIO DEL INTERIOR
DIRECCIN GENERAL DE LA POLICA Y DE LA GUARDIA CIVIL
CUERPO NACIONAL DE POLICA
DNI ELECTRNICO.
GUA
DE
REFERENCIA TCNICA.
Esta copia del Manual Tcnico del DNIe ha sido firmada y emitida por la Oficina Tcnica del DNIe a solicitud de David Blanco Gir 09340620K
1
ndice de contenido
Marco legal bsico................................................................................................................................................................3 Descripcin.....................................................................................................................................................................3 Actividad de validacin de los certificados..........................................................................................................................5 Seguridad lgica...................................................................................................................................................................6 Identificacin de usuario mediante cdigo CHV......................................................................................7 Identificacin de usuarios mediante datos biomtricos............................................................................7 Identificacin de aplicacin......................................................................................................................7 Identificacin mutua.................................................................................................................................7 Desbloqueo y cambio de cdigo CHV.....................................................................................................8 Proteccin de mensajes............................................................................................................................8 Funcionalidades criptogrficas.................................................................................................................9 Estados del sistema...................................................................................................................................9 Requisitos de seguridad. Asunciones de entorno..................................................................................................................9 Servicio de Atencin al Ciudadano.....................................................................................................................................11 Glosario de trminos y expresiones habituales...................................................................................................................13 Anexo I. Desarrollo de la funcionalidad de seguridad. .....................................................................................................17 Anexo II. Comandos APDU. .............................................................................................................................................19 Anexo III. Elementos criptogrficos. ................................................................................................................................41 Anexo IV. Ejemplo de firma electrnica. ..........................................................................................................................43
Marco legal bsico.

Directiva 1999/93/CE del Parlamento Europeo y del Consejo, por la que se establece un marco comunitario para la firma electrnica. Ley 59/2003 de 19 de diciembre, de Firma Electrnica. Ley Orgnica 15/1999 de 13 de diciembre, de Proteccin 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 electrnica.
Descripcin.
En el resto del documento usaremos el trmino tarjeta para referirnos de forma indiferente al soporte plstico 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 propsito del microprocesador que incorpora el DNI electrnico es contener y custodiar los datos de filiacin del ciudadano, los datos biomtricos (modelo dactilar, foto y firma manuscrita) y los dos pares de claves RSA con sus respectivos certificados. Podemos decir que el DNI electrnico est compuesto de dos elementos fundamentales: 1. La tarjeta. o Cumple con el estndar 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 mximo de vigencia del DNI, es decir, ms de 10 aos. o La personalizacin de la tarjeta se realiza mediante la grabacin con lser de los datos de filiacin, la fotografa y la firma manuscrita. Este sistema de personalizacin garantiza la imposibilidad de manipular los datos sin alterar el acabado de forma visible. o Cuenta con las ms modernas medidas de seguridad ante la manipulacin y falsificacin del documento, muchas de ellas fcilmente identificables por cualquier persona sin ningn procedimiento especial. El conjunto de todas las medidas hace del DNI electrnico un documento altamente seguro, tanto desde el punto de vista fsico como lgico. 2. El chip del DNI electrnico. o Nombre comercial: ST19WL34 o Sistema operativo: DNIe v1.1 o Capacidad de memoria: 32Kb.
La informacin en el chip est distribuida en tres zonas de seguridad con diferentes niveles y condiciones de acceso: Zona pblica: 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 utilizacin de la clave personal de acceso o PIN; contiene: Certificado de Firma. Certificado de Identificacin. Zona de seguridad. Accesible en lectura por el titular en los Puestos de Actualizacin del DNIe (PAD). Incluye: Datos de filiacin del ciudadano, los mismos que estn impresos en la tarjeta. Imagen de la fotografa. Imagen de la firma manuscrita. En una zona lgica inaccesible desde el exterior se encuentran las claves RSA privadas y el modelo de la impresin dactilar. El acceso a estos datos es competencia exclusiva del sistema operativo que corre en cada chip. Datos criptogrficos que incorporan los DNI electrnicos. Parejas de claves RSA de identificacin y firma. Clave Pblica de la AC raz. Claves Diffie-Hellman.
Datos de gestin. Traza de fabricacin. Nmero de serie del soporte. El chip almacena los siguientes certificados electrnicos:
Certificado de componente. Su propsito es la identificacin de la tarjeta del DNI

electrnico durante el protocolo de autenticacin 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.
Certificado de identificacin. Tiene como finalidad garantizar electrnicamente la identidad del ciudadano al realizar una transaccin telemtica. El certificado de identificacin asegura que la comunicacin electrnica se realiza con la persona que se identifica con el mismo. El titular podr, a travs de su certificado, acreditar su identidad frente a cualquiera ya que se encuentra en posesin 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 tendrn garanta del compromiso del titular del DNI con el contenido firmado. Su uso principal ser el de generar mensajes de identificacin en el seno de determinados protocolos de establecimiento de canales cifrados.
Para ms informacin sobre el atributo KeyUsage de los certificados incorporados a los DNIe vase el apartado 6.7.1 de la DPC.
Este certificado puede ser utilizado tambin como medio de identificacin para la realizacin de un registro que permita la expedicin de certificados reconocidos por parte de entidades privadas, sin verse estas obligadas a realizar una fuerte inversin 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 autora. Es un certificado X509.v3 estndar, 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 electrnico. Es este certificado, expedido por una Autoridad de Certificacin reconocida, el que convierte la firma electrnica avanzada en firma electrnica reconocida, permitiendo su equiparacin legal con la firma manuscrita (Ley 59/2003 y Directiva 1999/93/CE).
Observacin: Desde los orgenes del estndar X.509, descrito por primera vez en el documento RFC-2410 en 1998 tras su evolucin desde el estndar X.500, se usa la expresin digitalSignature para referirse a un uso de la clave dirigido a la autenticacin. Esta peculiaridad puede a veces inducir a error y causa sorpresa en los usuarios que tienen su primer contacto con esta tecnologa. Parece lgico pensar que la expresin digitalSignature y su traduccin al castellano, firmaDigital, haga referencia a un procedimiento de firma electrnica. Para aclarar este aparente error de concepto recordemos que el estndar describe convenciones; los autores del documento original usaron una etiqueta que resuma el hecho de que en el trasfondo de una operacin de identificacin lo que hay es un cifrado de un reto mediante la clave privada asociada al certificado, es decir, una firma electrnica avanzada. Para distinguir esta accin de la firma electrnica 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 electrnico.
Actividad de validacin de los certificados.
La Autoridad de Validacin es el componente de una PKI que tiene como tarea suministrar informacin sobre la vigencia de los certificados electrnicos que hayan sido expedidos por una Autoridad de Certificacin. La informacin sobre los certificados electrnicos revocados (no vigentes) se almacena en las denominadas listas de revocacin de certificados. Estas listas se
conocen ms habitualmente por sus siglas en ingls, CRL. Recomendamos el examen detenido de la RFC-5280, y concretamente el apartado 5, para ms informacin sobre las listas de revocacin de certificados. En el esquema de infraestructura de clave pblica adoptada para el DNI electrnico, se ha optado por asignar las funciones de Autoridad de Validacin a entidades diferentes de la Autoridad de Certificacin a fin de aislar la comprobacin de la vigencia de un certificado electrnico de los datos de identidad de su titular; de esta forma la Autoridad de Certificacin (Ministerio del Interior Direccin General de la Polica 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 Validacin no tienen acceso a la identidad de los titulares de los certificados electrnicos que valida, reforzando an ms si cabe la transparencia del sistema y garantizando la intimidad en el uso de los certificados DNIe.En la actualidad la PKI del DNI electrnico dispone de tres prestadores de servicios de validacin: oFbrica Nacional de Moneda y Timbre Real Casa de la Moneda, que presta sus servicios de validacin con carcter universal: ciudadanos, empresas y Administraciones Pblicas. oMinisterio de Administraciones Pblicas, que presta los servicios de validacin al conjunto de las Administraciones Pblicas. oMinisterio de Industria, Turismo y Comercio, que presta servicio de validacin a empresas. Adicionalmente, la entidad pblica empresarial Red.es podra completar los servicios de validacin en un futuro prximo. La prestacin de estos servicios de validacin se realiza en base a Online Certificate Status Protocol (OCSP), segn se describe en el documento RFC-2560. En esencia supone que un cliente OCSP enva una peticin a la Autoridad de Validacin y sta emite una respuesta firmada electrnicamente tras consultar su base de datos. En resumen, si el certificado no est en ninguna CRL se considera vlido y si est en alguna CRL, la AV informar de que el estado es revocado. Si consta la razn de la revocacin, tambin se incluye en la respuesta.
El servicio de validacin est disponible de forma ininterrumpida todos los das del ao.
Seguridad lgica.
Mecanismos de identificacin. El sistema operativo DNIe dispone de distintos mtodos de identificacin mediante los que una entidad externa demuestra legitimidad para el uso de los datos del chip.
Usamos la expresin entidad externa para poder englobar cualquier tipo de implementacin software o hardware. Dicha entidad puede ser una aplicacin programada en un lenguaje de alto nivel corriendo sobre un determinado sistema operativo comercial o un programa en cdigo mquina embebido en un perifrico diseado a medida para su ejecucin.
La correcta realizacin de cada uno de estos mtodos permite obtener unas condiciones de seguridad que podrn ser requeridas para el acceso a los distintos recursos de la tarjeta.
Identificacin de usuario mediante cdigo CHV.
La tarjeta DNIe soporta verificacin de usuario (CHV-Card Holder Verification). Esta operacin la realiza el sistema operativo cotejando el valor facilitado por la entidad externa con el valor almacenado en el chip. El cdigo CHV tiene su propio contador de intentos. Tras una presentacin vlida el contador de intentos es automticamente puesto a su valor inicial (tpicamente = 3). El contador de intentos es decrementado cada vez que se realiza una presentacin errnea, bloquendose la posibilidad de identificacin por este mtodo si el contador llega a cero. El desbloqueo de un cdigo CHV exige una identificacin de nivel superior, concretamente de tipo biomtrico. Esta operacin se lleva a cabo en las instalaciones del Cuerpo Nacional de Polica mediante el uso de un PAD. A su vez estas presentaciones de huellas tienen su propio contador de intentos. Si el nmero de intentos de presentacin de huella dactilar se agota, no ser posible realizar la operacin de desbloqueo. Es posible cambiar el cdigo de CHV a un nuevo valor presentando el valor actual o presentando la huella dactilar.
Identificacin de usuarios mediante datos biomtricos.
El sistema operativo del DNI electrnico permite realizar una identificacin biomtrica del titular de la tarjeta. Est funcin slo estar disponible en puntos de acceso controlados. En lineas generales, la aplicacin que accede al DNIe decide qu huella va a proceder a verificar, solicitando al usuario que coloque el dedo adecuado. Tras la captura biomtrica en el dispositivo lector de huellas, presenta la informacin al sistema operativo del chip a travs del correspondiente comando. Mediante un algoritmo match-on-card se evala la correspondencia entre la huella presentada y la referencia almacenada en el propio chip. Si la evaluacin supera el umbral, la verificacin se considera correcta. En caso contrario, se anota una presentacin errnea sobre esa huella devolviendo el nmero de intentos restantes.
Identificacin de aplicacin.
El propsito de este mtodo es que la entidad externa demuestre tener conocimiento de una clave como condicin de acceso a determinados recursos presentes en el chip. El mtodo elegido es un protocolo de desafo-respuesta, con los siguientes pasos: oLa aplicacin pide un desafo a la tarjeta. oSobre ese desafo, 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 presentacin para posteriores operaciones.
Identificacin mutua.
Este procedimiento permite que cada una de las partes (tarjeta y aplicacin externa) confe en la otra, mediante la presentacin mutua de certificados y su verificacin. Este proceso, similar al anterior en lineas generales, tiene como objetivo no slo identificar los elementos participantes sino tambin un intercambio de claves de sesin, que debern ser utilizadas para cifrar todos los mensajes que se intercambien posteriormente. Este servicio permite el uso de diferentes alternativas, que podrn seleccionarse implcitamente en funcin de la secuencia de comandos, o explcitamente, indicando su identificador de algoritmo en un comando de gestin de entorno de seguridad anterior (MSE). Las dos opciones disponibles estn basadas en la especificacin EN-14890-1 Application Interface for smart cards used as Secured Signature Creation Devices Part 1, y son las siguientes: oAutenticacin con intercambio de claves (captulo 8.4 de EN-14890-1) oAutenticacin de dispositivos con proteccin de la privacidad, (captulo 8.5 de EN14890-1)
Desbloqueo y cambio de cdigo CHV.
Se permite el cambio de cdigo CHV mediante la presentacin del valor antiguo o mediante identificacin biomtrica previa. Debido al carcter crtico de esta operacin, el cambio de cdigo CHV se ha de realizar siempre en condiciones de mxima confidencialidad y en terminales especficamente habilitados a tal efecto o con las debidas condiciones de seguridad, exigindose por tanto, el establecimiento de un canal seguro basado en certificados de componente. El desbloqueo del cdigo CHV slo es posible en los equipos denominados PAD, previa identificacin biomtrica del titular de la tarjeta. El cambio de cdigo CHV es posible tambin 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 cdigo CHV. Se envan 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 cdigo CHV no viaje en ningn momento entre cliente y servidor, imposibilitando as la interceptacin de este dato tan sensible.
Proteccin 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 ejecucin de determinados comandos si no se envan a la tarjeta a travs de un canal seguro e identificado. Para el establecimiento es necesaria la autenticacin 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 comunicacin una a uno entre los extremos del canal. El canal seguro puede ser requerido por la aplicacin o puede ser una restriccin de acceso impuesta por algn recurso de la tarjeta. Para el establecimiento del canal seguro, en primer lugar se realiza un intercambio de las claves pblicas de la tarjeta y el terminal mediante certificados que sern verificados por ambas partes. A continuacin se ejecuta un protocolo dirigido al establecimiento de una clave de sesin. El procedimiento descrito es una variante del protocolo Diffie-Hellman. Una vez concluido el protocolo para el establecimiento de la clave de sesin todos los mensajes deben transmitirse cifrados con esta clave.
Funcionalidades criptogrficas.
Claves RSA
La sistema operativo DNIe es capaz de generar y gestionar claves RSA. La generacin de la pareja de claves RSA sigue el estndar PKCS#1 v1.5. Se usa el algoritmo Miller-Rabin como test de primalidad.
Firmas electrnicas
El DNIe tiene capacidad para la realizacin de firmas electrnicas 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.
Las transiciones entre estados se invocan por reaccin ante eventos que pudieran comprometer la seguridad. Las nicas transiciones posibles son de operacional a terminada y de operacional a borrada.
Ntese que los eventos que motivan los cambios de estado son independientes de los cdigos de respuesta y de la lgica del procesamiento de los comandos en modo operacional, que estn diseados 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 algn 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 operacin estn descritos en el Perfil de Proteccin EN-14169 y ms especficamente en la Declaracin 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 operacin debe cumplir los siguientes requisitos En relacin con la aplicacin de generacin de certificados (CGA) FCS_CKM.2.1/CGA La tarjeta DNIe debe exportar las claves pblicas a la aplicacin de generacin de certificados, para la posterior generacin del certificado de integridad y no repudio. FCS_CKM.3.1/ CGA Una vez generado el certificado, la tarjeta DNIe debe realizar su importacin a travs de un canal seguro con confidencialidad, integridad y autenticacin. FDP_UIT.1.1 / Importacin de datos de verificacin de firma (SVD) La tarjeta DNIe debe aplicar las polticas de seguridad en relacin a la importacin de datos de verificacin de firma (SVD) para poder recibir datos de usuario de una manera protegida contra errores de modificacin e insercin. FDP_UIT.1.2 / Importacin de datos de verificacin de firma (SVD) La tarjeta DNIe debe ser capaz de determinar, a la recepcin de los datos de usuario, si ha ocurrido modificacin e insercin. FTP_ITC.1.1 / Importacin de datos de verificacin de firma (SVD) La tarjeta DNIe debe proporcionar un canal de comunicacin, entre s misma y un producto de tecnologa de la informacin (IT) confiable remoto, que sea distinto lgicamente de otros canales de comunicacin y que proporcione la identificacin segura de sus extremos y la proteccin de los datos del canal contra su modificacin o prdida de confidencialidad. FTP_ITC.1.2 / Importacin de datos de verificacin de firma (SVD) La tarjeta DNIe debe permitir al producto de tecnologa de la informacin (IT) confiable remoto iniciar la comunicacin a travs del canal confiable. FTP_ITC.1.3 / Importacin de datos de verificacin de firma (SVD) La tarjeta DNIe debe iniciar la comunicacin a travs del canal confiable para la importacin de datos de verificacin de firma (SVD). La tarjeta incorpora funciones de seguridad para satisfacer los requisitos relacionados con la aplicacin de generacin de certificados. El DNIe no permite la
10
exportacin de claves para la generacin de certificados si no es a travs de canales seguros establecidos con equipos del Cuerpo Nacional de Polica. Por otra parte, la funcionalidad de la tarjeta DNIe detecta cualquier alteracin en las comunicaciones, invalidando, como resultado, la misma. Finalmente, la importacin de certificados reconocidos, igualmente ha de ser realizada en equipos del Cuerpo Nacional de Polica. Estas medidas de seguridad garantizan la confidencialidad, integridad y autenticacin de los datos en trnsito y los generados por cada una de las partes (DNIe y aplicacin de generacin de certificados). El usuario deber realizar la solicitud de certificados en las dependencias del Cuerpo Nacional de Polica habilitadas a tal efecto. De este modo, el usuario tendr todas las garantas del cumplimiento de los requisitos relacionados con el entorno al objeto de la generacin de certificados reconocidos. En relacin con la aplicacin de generacin de firma electrnica (SGA) FCS_COP.1.1/ Hash de la aplicacin de creacin de firma (SCA) La tarjeta DNIe debe realizar el hash de los datos a ser firmados (DTBS) de acuerdo con el algoritmo criptogrfico SHA1. FDP_UIT.1.1 / DTBS de la SCA La tarjeta DNIe debe aplicar las polticas de creacin de firma para poder transmitir datos de usuario de una manera protegida contra errores de modificacin, borrado e insercin. FDP_UIT.1.2 / DTBS de la SCA La tarjeta DNIe debe ser capaz de determinar, a la recepcin de los datos de usuario, si ha ocurrido modificacin, borrado e insercin. FTP_ITC.1.1 / DTBS de la SCA La tarjeta DNIe debe proporcionar un canal de comunicacin, entre s misma y un producto de tecnologa de la informacin (IT) confiable remoto, que sea distinto lgicamente de otros canales de comunicacin y que proporcione identificacin segura de sus extremos y proteccin de los datos del canal contra la modificacin o la prdida de confidencialidad. FTP_ITC.1.2 / DTBS de la SCA La tarjeta DNIe debe permitir a la propia tarjeta iniciar la comunicacin a travs del canal confiable. FTP_ITC.1.3 / DTBS de la SCA La tarjeta DNIe debe iniciar la comunicacin a travs del canal confiable para firmar la representacin de datos a ser firmados (DTBS) mediante el dispositivo seguro de creacin de firma (SSCD). FTP_TRP.1.1 / SCA La tarjeta DNIe debe proporcionar una ruta de comunicacin, entre s misma y los usuarios locales, que sea lgicamente distinta de otras rutas de comunicacin y proporcione identificacin segura de sus extremos y proteccin de los datos comunicados contra la modificacin o la prdida de confidencialidad. FTP_TRP.1.2 / SCA La tarjeta DNIe debe permitir a los usuarios locales iniciar la comunicacin a travs de la ruta confiable. FTP_TRP.1.3 / SCA La tarjeta DNIe debe exigir el uso de la ruta confiable para la autenticacin inicial del usuario. La tarjeta DNI tiene capacidad para realizar un hash o resumen segn lo definido en el algoritmo SHA-1 al objeto de realizar firmas electrnicas. Por otra parte, la solicitud de una firma slo puede ser realizada por el ciudadano previa autenticacin del mismo, operacin que realiza enviando el cdigo PIN y bajo un canal de comunicaciones cifrado. La tarjeta DNIe slo 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 aplicacin, dotando a los datos
11
intercambiados de confidencialidad, integridad y no repudio de autora. Asimismo, ante cualquier perturbacin detectada en las comunicaciones o en los propios datos, se generar el correspondiente error, invalidndose lo realizado hasta el momento. Para la correcta interaccin de las aplicaciones con el chip DNIe se han de utilizar los mdulos criptogrficos CSP y PKCS#11 que se encuentran en el URI http://www.dnielectronico.es/descargas/index.html .
Servicio de Atencin al Ciudadano.

El DNI electrnico dispone de un servicio de atencin al ciudadano con las siguientes caractersticas:
Es prestado de forma permanente, 24 horas al da, 7 das 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 electrnico.
Servicio de Atencin al Ciudadano para consultas de carcter administrativo 902.364.444 sac@dnielectronico.es
Consultas tcnicas de ciudadanos, empresas y Administraciones oficinatecnica@dnielectronico.es
12
Glosario de trminos y expresiones habituales.

Autenticacin: el significado de esta palabra en castellano no se corresponde con el acto al que hace referencia en su uso habitual en criptografa. El error hay que buscarlo en la traduccin que se ha hecho del verbo ingls authenticate que significa simultneamente autenticar y probar. Esta ltima acepcin, de la que carece la palabra en castellano, es la adecuada en el escenario del uso de certificados electrnicos cuya finalidad es servir de prueba de la identidad de una persona. As pues, una conexin autenticada mediante certificados es aquella en la que las partes conectadas han probado su identidad (se han identificado mutuamente) mediante certificados. Certificado electrnico: es un documento electrnico firmado por un Prestador de Servicios de Certificacin que vincula unos datos de verificacin de firma a un firmante y confirma su identidad. Ntese que no se hace referencia a las caractersticas que hacen que un PSC tenga el atributo de reconocido; vase la entrada certificado reconocido. Esta es la definicin de la Ley 59/2003 que en este documento se extiende a los casos en que la vinculacin de los datos de verificacin de firma se hace a un componente informtico. Certificado reconocido: certificado expedido por un Prestador de Servicios de Certificacin que cumple los requisitos establecidos en la Ley en cuanto a la comprobacin de la identidad y dems circunstancias de los solicitantes y a la fiabilidad y las garantas de los servicios de certificacin que presten, de conformidad con lo que dispone el captulo II del Ttulo II de la Ley 59/2003, de 19 de diciembre, de Firma Electrnica. Certificados de Identidad Pblica: 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 autora de actos de firma. Esta informacin est firmada electrnicamente por la Autoridad de Certificacin creada al efecto. CGA: iniciales de la expresin inglesas Certificates Generation Application, aplicacin de generacin de certificados. CHV: siglas impropias de la expresin inglesa Cardholder Verification, verificacin del titular. La expresin cdigo CHV se refiere a una cadena de caracteres, no necesariamente numrica, cuya finalidad es la de demostrar la identidad del titular mediante la aplicacin del principio del secreto compartido. Es un trmino ms amplio y preciso que el de PIN (Personal Identification Number) pues este ltimo, generalizado desde sus orgenes en la prctica bancaria de gestin de tarjetas de crdito y posteriormente en la de tarjetas GSM, hace referencia como su nombre indica a una cadena numrica. Ciudadano: en el mbito de uso y aplicacin del DNI, se refiere a los ciudadanos espaoles.
13
Clave de Sesin: clave simtrica que se establece para cifrar una comunicacin entre dos entidades. La clave se establece para cada sesin de comunicacin, terminando su utilidad y desechndose una vez finalizada sta. La sesin puede ser tan corta como para suponer la transmisin de un nico comando o tan larga como para que se produzca el complejo intercambio de mensajes que exige una generacin de firma electrnica. Clave Personal de Acceso (PIN): vase CHV. CRL: iniciales de la expresin inglesa Certificates Revocation List. Vase Lista de Revocacin de Certificados. Datos de creacin de Firma (Clave Privada): son datos nicos, como cdigos o claves criptogrficas privadas, que el suscriptor utiliza para crear la firma electrnica. Datos de verificacin de Firma (Clave Pblica): son los datos, como cdigos o claves criptogrficas pblicas, que se utilizan para verificar la firma electrnica. Dispositivo seguro de creacin de firma: instrumento que sirve para aplicar los datos de creacin de firma cumpliendo con los requisitos que establece el artculo 24.3 de la Ley 59/2003, de 19 de diciembre, de Firma Electrnica. Documento electrnico: conjunto de datos almacenado en soporte susceptible de ser ledo por equipos electrnicos de procesamiento de datos. Documento de seguridad: documento exigido por la Ley Orgnica 15/99 de Proteccin de Datos de Carcter Personal cuyo objetivo es establecer las medidas de seguridad implantadas, a los efectos de este documento, por la DGPGC como Prestador de Servicios de Certificacin, para la proteccin de los datos de carcter personal contenidos en los ficheros de la actividad de certificacin que contienen datos personales. DPC, Declaracin de Polticas de Certificacin: documento en el que la Autoridad de Certificacin declara de forma detallada las prcticas 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: Vase Dispositivo seguro de creacin de firma. Encargado del tratamiento: la persona fsica o jurdica, autoridad pblica, servicio o cualquier otro organismo que trate datos personales por cuenta del responsable del tratamiento de los ficheros. Firma electrnica: es el conjunto de datos en forma electrnica, consignados junto a otros o asociados con ellos, que pueden ser utilizados como medio de identificacin personal y para garantizar la integridad de un documento electrnico.
14
Firma electrnica avanzada: es aquella firma electrnica 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 electrnica reconocida: es aquella firma electrnica avanzada basada en un certificado reconocido y generada mediante un dispositivo seguro de creacin de firma. Funcin hash: esta expresin se refiere a una forma de correspondencia matemtica en base a la cual se realiza una serie de operaciones algebraicas sobre un conjunto de datos de cualquier tamao de forma que el resultado obtenido es otro conjunto de datos de tamao fijo y habitualmente menor al original y que representa de forma bastante unvoca al conjunto original. Hash o huella digital: valor que se obtiene tras aplicar una funcin hash a un conjunto de datos. HSM: siglas de la expresin inglesa Hardware Security Module. Vase Mdulo Hardware de Seguridad. Identificador de usuario: conjunto de caracteres que se utilizan para la identificacin unvoca de un usuario en un sistema. Jerarqua de confianza: conjunto de autoridades de certificacin 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 jerarqua tiene dos niveles, la AC Raz en el nivel superior es el origen de la confianza en sus AC subordinadas. Listas de Revocacin 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. Mdulo Hardware de Seguridad: dispositivo utilizado para realizar funciones criptogrficas (generacin de claves y operaciones asociadas) y almacenar claves en un entorno seguro. Es ms habitualmente conocido por sus siglas en ingls: HSM. Prestador de Servicios de Certificacin: persona fsica o jurdica que expide certificados electrnicos o presta otros servicios en relacin con la certificacin y la firma electrnica. Punto de Actualizacin del DNIe: terminal ubicado en las Oficinas de Expedicin que permite al ciudadano de forma guiada, sin la intervencin de un funcionario, la realizacin de ciertas operaciones con el DNIe (comprobacin de datos almacenados en la tarjeta, renovacin de los certificados de identidad pblica, cambio de clave personal de acceso y comprobacin funcional de la tarjeta).
15
SCA: siglas de la expresin inglesa Signing Creation Aplication, Aplicacin de generacin de firma. SSCD: siglas de la expresin inglesa Secure Signature-Creation Device. Vase Dispositivo seguro de creacin de firma. Tercero Aceptante: persona o entidad diferente del titular que decide confiar en un certificado emitido por un determinado Prestador de Servicios de Certificacin.
16
ANEXO I Desarrollo de la funcionalidad de seguridad
Si bien las prestaciones electrnicas del DNIe pueden ser invocadas a travs de las libreras CSP y PKCS#11 provistas, la tarjeta proporciona funciones accesibles a travs de su interfaz de comandos para desarrollarla en los trminos que desee el usuario. La invocacin de estos comandos se rige por lo definido en el estndar ISO IEC 7816.
En el resto del presente documento, la palabra comando hace siempre referencia a los comandos APDU definidos en esa norma, ms concretamente en el documento ISO7816-4. Refirase el lector a dicha norma para un estudio en profundidad de las caractersticas, prestaciones y sintaxis de cada comando y sus respuestas.
Identificacin La tarjeta DNIe dispone de distintos mtodos de identificacin para que el usuario acceda a los recursos, pero slo la identificacin mediante cdigo CHV est disponible para los usuarios. Una operacin exitosa de identificacin mediante cdigo CHV conlleva la satisfaccin 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 presentacin del valor antiguo. Es posible tambin el cambio de PIN bajo determinadas condiciones (canal seguro basado en certificado de componente en combinacin con una clave de aplicacin) tras la realizacin de una verificacin biomtrica.
Esta operacin se considera de administracin de la seguridad del dispositivo por lo que el usuario deber utilizar los mecanismos provistos por la Direccin General de la Polica 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 trfico de mensajes entre el terminal y la tarjeta. Para el establecimiento es necesaria la identificacin 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 autora de tal forma que se asegura una comunicacin una a uno entre los dos extremos del canal. El lector puede encontrar una descripcin detallada de este protocolo en la norma EN-14890. Este canal seguro es un requisito obligatorio para la realizacin de firma electrnica y la autenticacin 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 autenticacin), Internal Authenticate Get Response Get Challenge External Authenticate Funcionalidades criptogrficas. Generacin de claves RSA para la firma electrnica. El usuario puede realizar una generacin de claves al objeto de obtener un certificado reconocido para la realizacin de firma electrnica pero debido a los requisitos de seguridad para las aplicaciones de generacin de certificados reconocidos, el ciudadano slo podr realizar esta operacin en las dependencias del Cuerpo Nacional de Polica habilitadas a este efecto. Firmas electrnicas La tarjeta DNIe tiene capacidad para la realizacin de firmas electrnicas. Primero se establecer canal seguro de usuario con los comandos descritos anteriormente. La aplicacin de generacin 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 continuacin, se invocarn los siguientes comandos: 1)Verify (Para autenticacin del usuario) 2)Manage Security Environment (Seleccin de clave y modo de uso), 3)Perform Security Operation (Clculo de una firma) Las aplicaciones de generacin de firma pueden ser construidas a partir de los mdulos PKCS#11 y CSP que proporciona la Direccin General de la Polica y de la Guardia Civil. Estos mdulos incluyen todos los datos, funciones y algoritmos necesarios para la comunicacin con el DNIe y realizan todas las operaciones habituales que pueden ser requeridas por una aplicacin de firma, un cliente de correo o un navegador web. No obstante, aquellos usuarios que decidan programar un mdulo PKCS#11 o un CSP a medida necesitarn 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 creacin de firma.
NOTA: El presente anexo no pretende ser una transcripcin, traduccin o extracto de la norma ISO-IEC 7816-4. Si necesita informacin ms precisa sobre el contenido de este anexo, por favor refirase a dicha norma. Los ejemplos se proponen en su forma ms genrica y no se basan en casos reales; no incorporan parmetros que puedan ser funcionales en algn escenario y su nica finalidad es didctica.
Comando GET CHALLENGE

El comando Get Challenge genera la emisin de un desafo (p.e. un nmero aleatorio) que podr formar parte de un procedimiento de seguridad.
Codificacin del comando

Byte CLA INS P1 P2 LC Data Valor 0x00 0x84 0x00 0x00 Significado
0x08
Vaco Vaco Longitud del desafo de 8 bytes, para establecimiento de canal seguro
Mensaje de respuesta
Datos SW1-SW2 Significado Datos del desafo Bytes de estado
Condiciones de estado
SW1 0x67 0x6A SW2 0x00 0x86 Significado Longitud incorrecta Parmetros incorrectos P1-P2
Ejemplo:
Terminal 00 84 00 00 08 xx xx xx xx xx xx xx xx 90 00 (Nmero aleatorio, 8 bytes) Tarjeta
19
Comando GET CHIP INFO

Permite obtener informacin del chip relativa al nmero de serie.

Byte CLA INS P1 P2 LC Data LE Valor 0x90 0xB8 0x00 0x00 Significado
0x07
Vaco Vaco Nmero de serie
Datos SW1-SW2 Tamao Significado 0x07 Nmero de serie Bytes de estado
SW1 0x67 0x6A Significado Longitud incorrecta (el campo Lc no 0x00 es correcto) 0x86 Parmetros P1-P2 incorrectos SW2
Ejemplo:
Terminal 90 B8 00 00 07 xx xx xx xx xx xx xx 90 00 (Nmero de serie, 7 bytes) Tarjeta
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 podra ser transmitida por el protocolo T=0.

Byte CLA INS P1 P2 LC Data LE Valor 0x00 0xC0 0x00 0x00 Significado
Vaco Vaco Longitud de los datos esperados como respuesta
Significado Mensaje respuesta(o parte) de acuerdo a LE Bytes de estado
Datos SW1-SW2
SW1 0x61 0x69 0x6C 0x90 SW2 0xXX 0x85 0xXX 0x00 Significado Ejecucin correcta. Quedan datos disponibles en la tarjeta. Condiciones de uso no satisfechas Longitud incorrecta (XX indica el valor correcto) Ejecucin correcta.
Ejemplo:
Terminal 00 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) Tarjeta
21
Comando EXTERNAL AUTHENTICATION.

Completa la ejecucin de un protocolo de tipo desafo-respuesta con el fin de autenticar a una entidad externa. Se trata de una autenticacin de la entidad externa, habitualmente un terminal, como parte un intercambio de claves para el establecimiento de canal seguro segn EN-14890-1 apartado 8.4. Est basado en claves RSA de 1024 bits, y requiere que la clave pblica del terminal sea cargada en la tarjeta mediante un certificado.

Byte CLA INS P1 P2 LC Data LE Valor 0x00 0x82 0x00 0x0X Significado
Key Id Longitud de los datos, coincide Kpub de la tarjeta Datos Vaco
Long
Estructura del comando para autenticacin segn 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 segn 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 derivacin 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 segn ISO 9796-2 (option 1)
El bloque de datos 6A || PRND2 || K IFD || h || BC es firmado con la clave privada del terminal (SK.IFD.AUT). Al resultado de esta firma (SIG) se le aplica la funcin SIGMIN para luego poder encriptar el resultado con la clave pblica de la tarjeta (PK.ICC.AUT). Para poder realizar esta operacin, es necesario que el tamao 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 pblica 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 autenticacin.
22
Mensaje del comando

Meaning Data field SW1-SW2 Vaco Bytes de estado
SW1 0x63 0x65 0x67 0x69 0x69 0x6A 0x6A 0x6A 0x6A SW2 0xCX 0x81 0x00 0x83 0x85 0x80 0x86 0x87 0x88 Meaning El cdigo de autenticacin no es vlido. X expresa el nmero de intentos posibles. Error de memoria Longitud incorrecta Mtodo de autenticacin bloqueado Condiciones de uso no satisfechas Error en el campo de datos Parmetros incorrectos P1-P2 Lc inconsistente con P1-P2 Datos referenciados no encontrados
Ejemplo:
Terminal 00 82 00 00 P3 xx xx xx ..... xx xx P3: long clave pblica de tarjeta xx xx xx .... xx xx Datos para autenticacin externa por parte del terminal 90 00 Tarjeta
23
Comando INTERNAL AUTHENTICATION.

Inicia el clculo de una autenticacin del origen de la tarjeta. El sistema de transmisin manda un desafo a la tarjeta que se firma con la clave privada RSA interna de identificacin. 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 utilizarn para establecer un canal seguro con intercambio de claves segn EN-14890-1 apartado 8.4. Se utilizan claves RSA de 1024, y una firma SHA1

Byte CLA INS P1 P2 LC Data LE Valor 0x00 0x88 0x00 0x00 0x10 Significado
Autenticacin interna con establecimiento de canal Autenticacin segn EN-14890 RND.IFD || SN.IFD Autenticacin segn EN-14890 ap. 8.4 Vaco
Mensaje de respuesta Autenticacin segn 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 segn 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 derivacin de claves del canal seguro. h[PRND1 || KICC || RND.IFD || SN.IFD2 ] = hash SHA1 que incluye

) 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 autenticacin. Al resultado de esta firma (SIG) se le aplica la funcin SIGMIN para luego poder encriptar el resultado con la clave pblica del terminal (PK.IFD.AUT), que previamente se deber haber cargado (mediante certificados verificables en la tarjeta), y seleccionado en la plantilla de autenticacin. Para poder realizar esta operacin, es necesario que el tamao de las dos claves RSA implicadas (PK.IFD.AUT y SK.ICC.AUT) sea el mismo.
24
SW1 0x61 0x62 0x65 0x69 0x69 0x6A 0x6A 0x6A 0x6A SW2 0xXX 0x83 0x81 0x82 0x85 0x80 0x82 0x86 0x88 Significado SW2 indica el nmero de bytes disponibles en la tarjeta como datos de respuesta. El fichero seleccionado est invalidado Error de memoria Condiciones de seguridad no satisfechas Condiciones de uso no satisfechas Error en el campo de datos No se ha encontrado el EF criptogrfico Parmetros incorrectos P1-P2 Datos referenciados no encontrados
Ejemplo:
Terminal 00 88 00 00 10 xx .. xx yy .. yy xx .. xx desafo del Terminal yy .. yy n serie Terminal 61 LL 00 C0 00 00 LL xx xx xx .. xx xx 90 00 (Datos de la tarjeta para la autenticacin interna) P3 = longitud clave de la tarjeta Tarjeta
25
Comando MANAGE SECURITY ENVIRONMENT.

Este comando permite la seleccin de las diferentes claves y algoritmos que sern 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 funcin determinada, en las que se pueden seleccionar distintos parmetros necesarios para operaciones criptogrficas posteriores. Algunos de los parmetros incluidos en estas plantillas son referencias a distintas claves existentes en la tarjeta. Los formatos de estas referencias se describen en la siguiente tabla:
Tipo de referencia KRT_CRYPTO KRT_IDENT KRT_MEMORY
Tamao 2 bytes 2 bytes N bytes
Formato 0x01 || KeyID 0x02 || KeyID CHR del certificado
Descripcin Referencia una clave RSA privada almacenada en ICC.CRYPTO con el identificador KeyID Referencia una clave RSA (pblica o privada) almacenada en ICC.ID con el identificador KeyID Referencia claves pblica RSA en memoria. Su valor debe coincidir con el campo Certificate Holder Refererence (CHR) incluido en el certificado utilizado para cargar la clave.
A continuacin se detallan las plantillas definidas, y los parmetros permitidos por cada una:
Plantilla Autenticacin (AT).
Firma (DST)
Parmetros oReferencia a la clave privada de la tarjeta, para la autenticacin. Tiene que estar en ICC.ID, y con un identificador entre 0x10 y 0x1f Referencia a la clave pblica del terminal, para la autenticacin. Tiene que estar en memoria, y haber sido cargada mediante un certificado de terminal correctamente verificado. Identificador de algoritmo, indicando el tipo de autenticacin que se va a realizar Referencia a la clave privada con la que se quiere realizar una operacin de firma (con PSO:Sign). Tiene que estar en ICC.CRYPTO Referencia a una clave pblica que se quiere utilizar para verificar un certificado. Puede tratarse de una clave de CA raz, 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 operacin de firma posterior 26

Byte CLA INS P1 P2 LC Data LE Valor 0x00 0x22 0xX1 0xXX Significado
Tipo de operacin. Plantilla a modificar Vaco o longitud del campo de datos Data Objects a incluir en la plantilla
El parmetro P1 indica qu tipo de operacin se va a realizar, y qu elementos se estn suministrando a la plantilla. Slo se soporta la modificacin del SE actual, por lo que el segundo nibble siempre deber ser 0001. La siguiente tabla muestra la codificacin de este valor.
b b7 8 - - 1 1 - B6 1 b5 1 b4 0 b3 0 b2 0 b1 1 Significado Asegurar el mensaje que aparece en campo de datos del comando Asegurar el mensaje que aparece en campo de datos de respuesta Clculo, descifrado, autenticacin interna y acuerdo de claves Verificacin, cifrado, autenticacin externa y acuerdo de claves SET
La siguiente tabla muestra los posibles valores de P2, que identifican la plantilla a utilizar.
Valor A4 A6 B6
Significado Plantilla de autenticacin Plantilla para intercambio de claves Plantilla para firmas
Datos SW1-SW2 Significado Vaco Bytes de estado
SW1 0x62 0x6A 0x6A 0x6A 0x6A SW2 0x83 0x82 0x86 0x87 0x88 Significado Fichero invalidado Fichero no encontrado Parmetros incorrectos P1-P2 Longitud de datos incorrecta Datos referenciados no encontrados
27
Ejemplo:
Ejemplo 1: Seleccin de la clave Root CA
Terminal 00 22 81 B6 04 83 02 02 0F 90 00 Tarjeta
Ejemplo 2: Seleccin de la clave en memoria

Terminal 00 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 Tarjeta
Ejemplo 3: Seleccin de la clave en memoria para Autenticacin interna

Terminal 00 22 C1 A4 0A 83 0C xx .. xx 84 02 02 1F xx .. xx Nmero de serie del Terminal (12 bytes) 90 00 Tarjeta
Ejemplo 4: Seleccin de la clave para autenticacin

Terminal 00 22 41 B6 04 83 02 01 01 01 01 Identificador fichero de la clave para autenticacin (2 bytes) 90 00 Tarjeta
28
Ejemplo 5: Seleccin de la clave para firma

Terminal 00 22 41 B6 04 84 02 01 02 01 02 Identificador fichero de la clave para firma o no repudio (2 bytes) 90 00 Tarjeta
Comando PERFORM SECURITY OPERATION.

Este comando permite realizar las siguientes operaciones relacionadas con los procesos de autenticacin y firma:
Validacin de un certificado
Este sub-comando permite la verificacin de un certificado, utilizando la clave pblica de la autoridad certificadora raz almacenada en la tarjeta, o una clave pblica de una autoridad certificadora intermedia, cargada anteriormente mediante otro certificado. El formato de los certificados en el definido en el documento EN-14890-1 captulo 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 pblica de una autoridad certificadora intermedia. Su formato es el siguiente:
7F 21 81 CE 5F 37 81 80 C_CV certificate Longitud de la firma (ejemplo para claves de 1024 bits) 6A = Relleno segn 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 estn en claro en el certificado, si no que son la entrada de la firma incluida en esta seccin. PK_part2 = XX ... XX (MSB..LSB) || 00 01 00 01 Incluye el resto de la clave pblica, que no se pudo poner en PK_part1 (resto del mdulo y exponente pblico en 4 bytes) Se incluye tambin en claro para poder CAR identificar la autoridad que firma el certificado
5F 38
3D
42
08
29
La codificacin 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 pblica 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 autorizacin 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 ms significativa del identificador de aplicacin definido en EN-14890 (A0 00 00 01 67 45), y el ltimo byte es el identificador de rol del certificado. OID es un campo de siete bytes con el identificador de objeto definido en EN-14890. Su valor debe ser 2B 24 03 04 02 02 01 PK_part1 es la primera parte de la clave pblica incluida en el certificado. La clave pblica RSA est formada por el mdulo, concatenado con el exponente pblico codificado en 4 bytes. En este campo se incluir el mximo nmero de bytes posible (en funcin del tamao de las claves) y el resto deber ir en claro en el campo PK_part2 Hash es el resultado de aplicar la funcin SHA1 a la concatenacin de los campos CPI, CAR, CHR, CHA, OID, y la clave pblica completa. PK_part2 es el campo con la parte de la clave pblica 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 tamao que la clave RSA con la que est firmado el certificado. Los certificados con CPI=4 son utilizados para la cargar la clave pblica de un terminal, que ser utilizada a continuacin en un proceso de autenticacin. Su formato es el siguiente:
7F 21 81 CD 5F 37 81 80 C_CV Certificate Longitud de la firma (ejemplo para claves de 1024 bits) 6A = Relleno segn ISO 9796-2 CPI = 04 CAR = Defined by Card Manufacturer CHR = Certificate Holder Reference CHA = AID[1..6] || Role Identifier OID = 2B 24 07 02 01 01 PK_part1 = xx..xx (MSB..LSB) Hash = xx..xx BC Los campos descritos no estn en claro en el certificado, si no que son la entrada de la firma incluida en esta seccin. PK_part2 = XX ... XX (MSB..LSB) || 00 01 00 01 Incluye el resto de la clave pblica, que no se pudo poner en PK_part1 (resto del mdulo y exponente pblico en 4 bytes) Se incluye tambin en claro para poder CAR identificar la autoridad que firma el certificado
5F 38
3C
42
08
La codificacin 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 nmero de serie del terminal propietario del certificado. El campo ocupa siempre doce bytes. Si el nmero de serie es de menor longitud, se completar con ceros a la izquierda. Se considera que el nmero de serie es al menos de ocho bytes. CHA indica los niveles de autorizacin 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 ms significativa del identificador de aplicacin definido en EN-14890 (A0 00 00 01 67 45), y el ltimo byte es el identificador de rol del certificado. OID es un campo de seis bytes con el identificador de objeto definido en EN-14890. Su valor debe ser 2B 24 07 02 01 01 PK_part1 es la primera parte de la clave pblica incluida en el certificado. La clave pblica RSA est formada por el mdulo, concatenado con el exponente pblico codificado en 4 bytes. En este campo se incluir el mximo nmero de bytes posible (en funcin del tamao de las claves) y el resto deber ir en claro en el campo PK_part2 Hash es el resultado de aplicar la funcin SHA1 a la concatenacin de los campos CPI, CAR, CHR, CHA, OID, y la clave pblica completa. PK_part2 es el campo con la parte de la clave pblica 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 tamao que la clave RSA con la que est firmado el certificado. Los identificadores de rol soportados son los siguientes:
Rol ID 0010 0001 0010 0010 0000 0010
Uso del certificado Puede utilizarse para la verificacin de firma en una cadena cruzada de certificados Puede utilizarse para la verificacin de firma en una cadena de certificados Puede utilizarse en el proceso de establecimiento de un canal seguro de usuario
31
Firma de un hash calculado externamente

Este sub-comando permite firmar unos datos directamente enviados en el comando. La firma se realiza con una clave privada RSA ubicada en ICC.CRYPTO. El formato de rellenos de los datos sobre los que se realizar el hash viene indicado en la tabla siguiente:
DSI PKCS#1 V2.x T -
L
-
V (Ejemplo con mdulo de 1024 bits) 00 = Byte de inicio 01 = Tipo de bloque FF..FF = Cadena de relleno, PS (mnimo 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 debern exceder el 40% del tamao de la clave RSA utilizada.

Byte CLA INS P1 P2 LC Dato s LE Valor 0x00 0x2A 0xXX 0xXX 0x14 Significado
Tag indicando el tipo de datos de la respuesta Tag indicando el tipo de datos enviado Longitud de los datos Datos de entrada Datos de salida
La siguiente tabla indica las posibles combinaciones de P1-P2 soportadas
P1 00 90
P2 AE 80
90
A0
Operacin Verificacin de certificado. Los datos de entrada son el certificado, y no se esperan datos de respuesta Calculo de hash. En la entrada se entregan datos sin estructura, y la respuesta es el hash calculado por la tarjeta. Este hash quedar disponible para una firma realizada en el siguiente comando Calculo de hash. En la entrada se entregan los datos 32
9E
9A
con estructura, permitiendo realizar el hash parcialmente fuera de la tarjeta. La respuesta ser el hash calculado Calculo de una firma. Si el tamao de los datos de entrada es cero, se firmar el hash generado anteriormente, en caso contrario, se firmarn los datos enviados en el comando. La respuesta es la firma generada
Significado Mensaje respuesta(o parte) de acuerdo a LE Bytes de estado
Datos SW1-SW2
SW1 0x62 0x65 0x69 0x69 0x69 0x6A 0x6A 0x6A 0x6A 0x6A SW2 0x83 0x81 0x82 0x85 0x86 0x80 0x82 0x86 0x87 0x88 Significado Fichero invalidado Error de memoria Condiciones de seguridad no satisfechas Condiciones de uso no satisfechas (secuencia de comandos incorrecta) Tipo de fichero incorrecto Campo de datos incorrecto Fichero no encontrado Parmetros incorrectos P1-P2 Longitud de datos incorrecta Datos referenciados no encontrados
Ejemplos:
Ejemplo 1: Verificar Certificado Autoverificable CA intermedia
Terminal 00 2A 00 AE P3
Tarjeta
xx .. xx 90 00 xx .. xx Certificado autoverificable de la CA intermedia (longitud P3)
33
Ejemplo 2: Verificar Certificado Autoverificable Certificado Terminal

Terminal 00 2A 00 AE P3 xx .. xx 90 00 xx .. xx Certificado autoverificable del Terminal (longitud P3) Tarjeta
Ejemplo 3: Clculo de un hash en la tarjeta

Terminal 00 2A 90 80 P3 xx .. xx datos sobre los que se calcular el hash. Longitud de los datos P3 61 14 0x14, hash disponible (longitud 20 bytes) Tarjeta
Ejemplo 4: Firma de un hash con formato PKCS#1

Terminal 00 2A 9E 9A 23 00 2A 9e 9A 23 30 21 30 09 06 05 2b 0e 03 02 1A 05 00 04 14 83 9b 54 3f b0 9d 20 c8 03 b4 6e 6f 8f 07 47 24 49 51 82 2f Datos = Digest Info + SHA1 61 xx Firma disponible formato PKCS#1 (longitud xx bytes, long de la clave RSA que firma) Tarjeta
34
Comando SELECT.
Este comando permite la seleccin de fichero dedicado (DF) o de un fichero elemental (EF).

Byte CLA INS P1 P2 LC Data LE Valor 0x00 0xA4 0x00 0x04 0x00 Significado
Selecciona DF o EF por Id (data field = id) Seleccin directa de DF por nombre. Longitud del campo de datos Datos de acuerdo a P1-P2 Vacio
Significado Plantilla FCI acorde con ISO 78164/9. Bytes de estado
Datos SW1-SW2
La informacin de control del fichero (FCI) es la cadena de datos que se recibe en respuesta a un comando SELECT FILE.
0x6F T 0x84 0x85
Long.
Plantilla FCI acorde con ISO 7816-4/9. Longitud de los subsiguientes Objetos de Datos L Valor 0xXX Nombre del DF name. (Solo para DFs) 0xXX Informacin propietaria: Long. Significado 0x01 0x02 0x02 0x05
File descriptor byte: 0x01 Elementary File (EF) 0x34 Dedicated File (DF) 0x15 EF propietario para claves. Linear variable SIMPLE-TLV Identificador de Fichero Nmero de datos en el fichero, excluyendo la informacin de la estructura cabecera del fichero Atributos de seguridad, informacin propietaria
35
0x6F T 0x84 0x85
Long.
Plantilla FCI acorde con ISO 7816-4/9. Longitud de los subsiguientes Objetos de Datos L Valor 0xXX Nombre del DF name. (Solo para DFs) 0xXX Informacin propietaria: Long. Significado
Control Flag for Security files Security Efs (type 0x15)
------------0000 ------1---10-01---1 ----100 -010 -001 000-b 001-b 010-b 011-b 100-b 101-b 110-b 1---b 1---b 1---b 1---b 111-b 111-b 111-b 111-b CHV keys App Keys RFU RFU Empty RSA KEY file RFU Active RSA Key Key generated internally RSA Key in CRT format RSA Key without CRT RFU Inactive RSA Key Inactive RSA Key Type 1 Inactive RSA Key Type 2 Inactive RSA Key Type 3
0x01
Control bytes for RSA cryptographic files Cryptographic Efs (type 0x15)
RSA KEY in CRT format ---- ----b XXXX XXXXb bit length of the key in 64 base 0000 0000b ---- ----b empty key 1--- ----b ---- ----b q present -1-- ----b ---- ----b p present --1- ----b ---- ----b CRT present ---1 ----b ---- ----b d mod (p-1) present ---- 1---b ---- ----b d mod (q-1) present ---- --1-b ---- ----b public exponent present ---- ---1b ---- ----b modulus present 1111 1011b ---- ----b valid RSA with CRT key Inactive RSA KEY ---- ----b XXXX XXXXb bit length of the key in 64 base 0000 0000b ---- ----b empty key ---- -1--b ---- ----b A8h-A9h-B8h present ---- --1-b ---- ----b Aah-ABh-BAh present ---- ---1b ---- ----b Ach-BCh Hash present 0000 0111b ---- ----b valid inactive RSA key RSA KEY without CRT ---- ----b XXXX XXXXb bit length of the key in 64 base 0000 0000b ---- ----b empty key ---- -1--b ---- ----b private present ---- --1-b ---- ----b public exponent present ---- ---1b ---- ----b modulus present 0000 0111b ---- ----b valid RSA key
0x02
- significa que el valor no tiene significado en el contexto X significa cualquier valor
SW1 0x61 0x62 0x65 0x6A 0x6A 0x6A SW2 0xXX 0x83 0x81 0x82 0x86 0x87 Significado Ejecucin correcta. Se indica el nmero de bytes disponibles en respuesta al comando como una estructura FCI. Fichero seleccionado invalidado Error de memoria (FCI errneo) Fichero no encontrado Parmetros incorrectos P1-P2 Lc inconsistente con P1-P2
36
Ejemplos:
Ejemplo 1: Seleccin del fichero elemental Id: 60 1F
Terminal 00 A4 00 00 02 60 1F 61 0E 00 C0 00 00 0E 6F 0C 85 0A FF FF 90 00 01 60 1F 03 25 00 FF FF Tarjeta
Ejemplo 2: Seleccin por nombre del fichero dedicado PKCS-15

Terminal 00 A4 04 00 0C A0 00 00 00 63 50 4B 43 53 2D 31 35 61 1C 00 C0 00 00 1C 6F 1A 84 0C A0 00 00 00 63 50 4B 43 53 2D 31 35 85 0A 38 50 15 00 0C FF FF FF FF FF 90 00 Tarjeta
37
Comando READ BINARY.

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

Byte CLA INS P1-P2 LC Data LE Valor 0x0X 0xB0 Significado
Offset del primer byte a leer desde el principio del fichero. Vaco Vaco Nmero de bytes a leer
Si el campo Le=0 entonces el nmero de bytes a leer es 256.
Significado Datos leidos (LE bytes) Bytes de estado
DatOS SW1-SW2
SW1 0x62 0x65 0x69 0x69 0x69 0x6A 0x6B 0x6C SW2 0x83 0x81 0x82 0x85 0x86 0x82 0x00 0xXX Meaning El EF o DF seleccionados estn invalidados Error de memoria Condiciones de seguridad no satisfechas Condiciones de uso no satisfechas Comando no permitido (no existe un EF seleccionado) Fichero no encontrado Parmetros incorrectos (el offset est fuera del EF) Longitud incorrecta (XX indica la longitud exacta)
38
Ejemplo: Lectura Binaria

Terminal 00 B0 00 00 50 xx ..xx 90 00 xx .. xx Contenido del fichero (primeros 0x50 bytes) longitud = 80 bytes, 00 B0 00 50 40 yy .. yy 90 00 yy .. yy Contenido del fichero a partir del offset 0x50 (longitud = 64 bytes), Tarjeta
Comando VERIFY.
El comando Verify inicia la comparacin en la tarjeta de los datos de verificacin de usuario enviados desde el dispositivo externo con los almacenados en la tarjeta. Esta operacin se suele denominar verificacin de PIN o CHV.

Byte CLA INS P1 P2 LC Data LE Valor 0x00 0x20 0x00 0x00 Significado
Datos de referencia (cdigo CHV) Vaco o longitud del campo de datos Vaco o datos de verificacin
Significado Datos SW1-SW2 Vaco Bytes de estado
39
SW1 0x63 0x65 0x69 0x69 0x69 0x6A 0x6A 0x6A 0x6A SW2 0xCx 0x81 0x82 0x83 0x863 0x82 0x84 0x86 0x88 Significado Verificacin fallida: X indica el nmero de intentos disponibles. Error de memoria Condiciones de seguridad no satisfechas Mtodo de autenticacin bloqueado Identificador de CHV no permitido No se encuentra el fichero CHV No hay memoria suficiente Parmetros incorrectos P1-P2 Datos refrenciados no encontrados
Ejemplo: Presentacin de PIN

Terminal 00 20 00 00 08 xx .. xx xx .. xx PIN del usuario longitud en este ejemplo = 8 bytes 90 00 Verificacin satisfactoria del PIN de usuario Tarjeta
40
ANEXO III Informacin necesaria para el establecimiento del canal seguro de usuario. Clave Pblica ROOT CA para autenticacin 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-)
Mdulo = EADEDA455332945039DAA404C8EBC4D3B7F5DC869283CDEA 2F101E2AB54FB0D0B03D8F030DAF2458028288F54CE552F8 FA57AB2FB103B112427E11131D1D27E10A5B500EAAE5D940 301E30EB26C3E9066B257156ED639D70CCC090B863AFBB3B FED8C17BE7673034B9823E977ED657252927F9575B9FFF66 91DB64F80B5E92CD Exponente_pblico = 010001

Certificado de la CA intermedia de Terminal verificable por la tarjeta :
C_CV_CA = 7F2181CE5F3781803CBADC3684BEF32041AD155089258DFD 20C69115D72F9C38AA99AD6C1AEDFAB2BFAC9092FC70CCC0 0CAF482A4BE31AFDBD3CBC8C8382CF06BC0719BAABB56B6E C80760A4A93FA2D7C347F34427F9FF5C8DE6D65DAC95F2F1 9DAC0053DF11A507FB625EEB8DA4C0299E4A2112AB704758 8B8D6DA7592214F2DBA140C7D122579B5F383D2253C8B9CB 5BC3543A55660BDA80946AFB0525E8E5586B4E63E8924149 7836D8D3AB088CD44C214D6AC856E2A007F44F8374333737 1ADD8E030001000142086573524449600006
Identificador de esta CA intermedia (CHR):
CHR = 000000006573534449600006
Certificado de Terminal verificable por la tarjeta:
C_CV_IFD = 7F2181CD5F3781802563FCF6714624C0C4F5D75F67305EBF 8F3A6BB772996AFB6497BB466A238E731D08D378E9F4ECC0 4070E3717C138EA8D6D35A14ED1862B7F84E351B2DCE4CFB 30F8C76B8AD1731E9AA84AB0B3BD30C3F00DA274E2005A51 EB4213FD5523ABC97584A9FBD2576CB5DD9DD572AE49A597 E14ECFFA91F76E04F6081292AE07CEF75F383C258B73CFB9 4A739CB5E97392E599E8FB45A60072CAA6FCD5F215C3C7E0 25EA3C9EB2CBE47DE9FEE8002BF2F6D4A24350AB3F5F15DB 05A1270001000142086573534449600006 41
Identificador de este certificado (CHR):
CHR: 000000002000000000000001
Clave privada asociada para realizar la autenticacin del Terminal:
Mdulo: DB2CB41E112BACFA2BD7C3D3D7967E84FB9434FC261F9D09 0A8983947DAF8488D3DF8FBDCC1F92493585E134A1B42DE5 19F463244D7ED384E26D516CC7A4FF7895B1992140043AAC ADFC12E856B202346AF8226B1A882137DC3C5A57F0D2815C 1FCD4BB46FA9157FDFFD79EC3A10A824CCC1EB3CE0B6B439 6AE236590016BA69 Exponente_pblico: 010001 Exponente_privado: 18B44A3D155C61EBF4E3261C8BB157E36F63FE30E9AF2889 2B59E2ADEB18CC8C8BAD284B9165819CA4DEC94AA06B69BC E81706D1C1B668EB128695E5F7FEDE18A908A3011A646A48 1D3EA71D8A387D474609BD57A882B182E047DE80E04B4221 416BD39DFA1FAC0300641962ADB109E28CAF50061B68C9CA BD9B00313C0F46ED
42
ANEXO IV Ejemplo de firma electrnica para autenticacin con establecimiento previo de canal seguro de usuario y presentacin de PIN.
El presente anexo muestra un ejemplo de implementacin con los comandos necesarios y el orden de estos comandos para el establecimiento del canal seguro de usuario, presentacin de PIN, y realizacin de una firma con la clave de autenticacin del usuario. Tenga en cuenta que se trata de un ejemplo con finalidad didctica y que los valores utilizados y obtenidos son los aplicables a la tarjeta con la que se llev a cabo el experimento.
1) Datos criptogrficos necesarios para el establecimiento del canal seguro.
Vase el anexo III.

2) Establecimiento de canal seguro de usuario.
2.a) Reiniciar la tarjeta. En este primer paso, reiniciamos la tarjeta para que pierda cualquier estado previo. Se asume que la tarjeta acaba de ser alimentada y que se ha devuelto un ATR vlido. 2.b) Peticin del nmero de serie de la tarjeta: Para ello utilizamos el comando Get Chip Info:
90b8000007 065a85ca586f329000
El nmero de serie de la tarjeta objeto de la prueba es: 065a85ca586f32 2.c) Seleccin y lectura de los certificados de componente, y de autoridad intermedia de componente: Empezamos seleccionado el fichero del certificado de la autoridad de certificacin 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 seleccin del fichero, vemos que el tamao del mismo es 0x042C bytes, as que lo leemos mediante varios comandos Read Binary:
43
00b00000ff 3082042830820391a00302010202101aed357a7ba8c87b43 fadf3fa9775680300d06092a864886f70d01010505003081 87310b300906035504061302455331283026060355040a0c 1f444952454343494f4e2047454e4552414c204445204c41 20504f4c49434941310d300b060355040b0c04444e494531 1c301a060355040b0c134143205241495a20434f4d504f4e 454e5445533121301f06035504030c183030303030303030 36353733353234343439363030303036301e170d30363032 32313039333730335a170d3331303232303137313331355a 3072310b300906035504061302455331283026060355040a 0c1f444952454343494f4e2047454e9000 00b000ffff 4552414c204445204c4120504f4c49434941310d300b0603 55040b0c04444e4945310d300b060355040b0c04464e4d54 311b301906035504030c12414320434f4d504f4e454e5445 532030303130819f300d06092a864886f70d010101050003 818d0030818902818100de3cc30b668cb2353485fd42a119 2125f4a82504197ebd3cb6abffb8e68f2e84293bb725fd61 8fd10fda1a409737d74bd1b97984685156ceff55f5e3525b c58bfd3799c2a7e300471d9303105ee8ec4c67d476dc48d1 834670c27ebf4668779d7b855b44afa733da451bb954994a 718910fde6313aab6266313fdbd1564fa57d0203010001a3 8201a7308201a330120603551d13019000 00b001feff 01ff040830060101ff020100301d0603551d0e041604143f 320e9794b8f9566ea3d721a61754fa923a12b1301f060355 1d2304183016801445d76465f22504d8045e6627419d7650 05a2d158300e0603551d0f0101ff04040302010630370603 551d200430302e302c0604551d20003024302206082b0601 05050702011616687474703a2f2f7777772e646e69652e65 732f647063308201020603551d1f0481fa3081f73081f4a0 81f1a081ee8623687474703a2f2f63726c732e646e69652e 65732f63726c732f41524c434f4d2e63726c8681c66c6461 703a2f2f6c6461702e646e69652e65732f434e3d43524c2c 434e3d3030303030303030363537339000 00b002fdff 3532343434393630303030362c4f553d4143253230524149 5a253230434f4d504f4e454e5445532c4f553d444e49452c 4f3d444952454343494f4e25323047454e4552414c253230 44452532304c41253230504f4c494349412c433d45533f61 7574686f726974795265766f636174696f6e4c6973743f62 6173653f6f626a656374636c6173733d63524c4469737472 69627574696f6e506f696e74300d06092a864886f70d0101 050500038181008f837ad2f2a8c4ba6ab45e0d4b392d6ec0 e66b9da3f97efb08da7dc3bbd3a6549be10471ff7f28209a 17f0717af6f6d51e9f30dfd58fe804f02bf2b25820def595 c2ed85e3b080380438d824702180469000 00b003fc30 44
2667f29d75b30cb9f2bb4a03dda58de2c150ed316ab9b29c a63210017dd70ffc21316f88f753904d743b70214523760a 9000 Realizamos la misma operacin de seleccin y lectura con el certificado de componente, ubicado en el fichero 3F00/601F: 00a4000002601f 610e 00c000000e 6f0c850a01601f032500ffffffff9000 00b00000ff 308203213082028aa003020102021031a75901575f510643 ff47d829436117300d06092a864886f70d01010505003072 310b300906035504061302455331283026060355040a0c1f 444952454343494f4e2047454e4552414c204445204c4120 504f4c49434941310d300b060355040b0c04444e4945310d 300b060355040b0c04464e4d54311b301906035504030c12 414320434f4d504f4e454e54455320303031301e170d3036 303232343137353232345a170d3137303232343137353232 345a3026310b300906035504061302455331173015060355 0403130e303635413835434135383646333230819f300d06 092a864886f70d010101050003818d9000 00b000ffff 0030818902818100d1d60b95e4522a480b12b8bd565a6141 3c79279eab0e60d7d490199e6786d1c965a9cefe06a38edb 9a5b89c47248fbd44932c8b908cf5111d9fb9635d1fcc94e 3f0ef3e654f7c062686ba4c63ae7319899bd32b0e1b74ea2 889e6b98def58ed17d4d0e55d9f12b6c61a5d2a535cbc253 65513479458337b3f84556acb807511d0203010001a38201 023081ff300c0603551d130101ff04023000300e0603551d 0f0101ff040403020388301d0603551d0e04160414b20804 697314e07b66f48b0140009a26ed41654a301f0603551d23 0418301680143f320e9794b8f9566ea3d721a61754fa923a 12b1303f06082b06010505070101049000 00b001feff 333031302f06082b060105050730028623687474703a2f2f 7777772e646e69652e65732f63657274732f41435261697a 2e637274305e0603551d1f045730553053a051a04f864d68 7474703a2f2f63726c732e666e6d742e646e69652e65732f 63726c732f43524c38343931343432323932433433423733 413445453131443844344635413846374132413944323334 2e63726c300d06092a864886f70d01010505000381810057 5c9b73f6dea428b98f6008cc6f66e03ed4a408f6247f2b36 ee0450072297f29b749beb49cfb965d575a533eb342f4d3a 4b25805dc0f98e0bcd02c56c13861eee635bb9760bde4840 59bd7caa77ed8274d4a405bccd4d8c9000 00b002fd28 45
55a441f4e0492fc7ff7fd6b0b76dfcb98972720fe3f8c1d8 58c3a96de551d4a0bb02131279d20a199000
Una vez ledos ambos certificados, se deber verificar la cadena de certificacin de componente, utilizando la clave pblica de la autoridad certificadora raz. Del certificado de componente, extraemos la clave pblica de componente, que luego tendremos que utilizar para completar las autenticaciones interna y externa. Clave pblica de ICC:
Mdulo = d1d60b95e4522a480b12b8bd565a61413c79279eab0e60d7 d490199e6786d1c965a9cefe06a38edb9a5b89c47248fbd4 4932c8b908cf5111d9fb9635d1fcc94e3f0ef3e654f7c062 686ba4c63ae7319899bd32b0e1b74ea2889e6b98def58ed1 7d4d0e55d9f12b6c61a5d2a535cbc25365513479458337b3 f84556acb807511d Exponente pblico = 010001
2.d) Seleccin y carga de la cadena de certificados verificables en la tarjeta. Seleccionamos en la tarjeta la clave pblica de la autoridad certificadora raz de la jerarqua de certificados verificables por la tarjeta. Para ello utilizamos el comando Manage Security Environment, utilizando la referencia del fichero donde reside la clave (020f):
002281b6048302020f 9000
Enviamos el certificado de la autoridad intermedia verificable por la tarjeta (C_CV_CA). Para ello utilizamos el comando Perform Security Operation:
002a00aed27f2181ce5f3781803cbadc3684bef32041ad15 5089258dfd20c69115d72f9c38aa99ad6c1aedfab2bfac90 92fc70ccc00caf482a4be31afdbd3cbc8c8382cf06bc0719 baabb56b6ec80760a4a93fa2d7c347f34427f9ff5c8de6d6 5dac95f2f19dac0053df11a507fb625eeb8da4c0299e4a21 12ab7047588b8d6da7592214f2dba140c7d122579b5f383d 2253c8b9cb5bc3543a55660bda80946afb0525e8e5586b4e 63e89241497836d8d3ab088cd44c214d6ac856e2a007f44f 83743337371add8e030001000142086573524449600006 9000
Al responder 9000, la tarjeta indica que el certificado ha sido correctamente verificado y que su clave pblica ha quedado almacenada en memoria.
46
A continuacin, seleccionamos la clave pblica recin cargada con el comando Manage Security Environment, y utilizando la referencia del certificado anterior (CHR):
002281b60a83086573534449600006 9000
Enviamos el certificado del Terminal, verificable por la tarjeta (C_CV_IFD), utilizando el comando Perform Security Operation:
002a00aed17f2181cd5f378180825b69c6451e5f51707438 5f2f17d64dfe2e68567567094b57f3c578e830e425572de8 28faf4de1b01c394e345c2fb0629a393492f94f570b00b1d 677729f755d107022bb0a116e1d7d7659db5c4ac0ddeab07 ff045f37b5daf1732b54eab238a2ce17c9794187759cea9f 92a17805a27c1015ec56cc7e471a488e6f1b91f7aa5f383c adfc12e856b202346af8226b1a882137dc3c5a57f0d2815c 1fcd4bb46fa9157fdffd79ec3a10a824ccc1eb3ce0b6b439 6ae236590016ba690001000142086573534449600006 9000
Seleccionamos la clave pblica recin cargada para autenticacin. En el mismo comando Manage Security Environment aprovechamos para seleccionar en la tarjeta la clave privada de componente (referencia 021F) que tambin se usar en los comandos de autenticacin.
0022c1a412830c0000000020000000000000018402021f 9000
2.e) Autenticacin interna (de la tarjeta). Enviamos el comando Internal Authentication, mediante el que se le pide a la tarjeta que demuestre que posee la clave privada asociada a su certificado de componente. Para este comando, el Terminal deber generar un valor aleatorio de 8 bytes. (en el ejemplo RND.IFD = 231dac737ba0fe6e):
0088000010231dac737ba0fe6e2000000000000001 6180 00c0000080 437393b30d1f0161455bb132e999de7bb8f7d82f91d507d6 d116074d33e60457f189b976235cab5762b64f896be8a924 1a245dcac976fa2d0cac8719157e2927c61e0bcb48b51170 ea0898381ef919398e46417899abe82708addd1b755c056f 5f7b96ba69bd56fc576c809b27b8f8364fc4d559d1da8681 fa04145ddd636eb79000

La respuesta de la tarjeta es un mensaje cifrado con la clave privada de componente de la tarjeta, a continuacin se le ha aplicado la funcin SIGMIN, y por ltimo se ha cifrado de nuevo con la clave pblica del Terminal:
47
E[PK.IFD.AUT] (SIGMIN) Donde SIGMIN = min (SIG, N.ICC - SIG) y SIG= DS[SK.ICC.AUT] ( 6A = relleno segn 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 derivacin de claves del canal seguro. h[PRND1 || KICC || RND.IFD || SN.IFD ] = hash SHA1 que incluye

) Por lo tanto, para verificarlo hay que empezar por descifrarlo con la clave privada del Terminal:
Mensaje entregados por la tarjeta: 437393b30d1f0161455bb132e999de7bb8f7d82f91d507d6 d116074d33e60457f189b976235cab5762b64f896be8a924 1a245dcac976fa2d0cac8719157e2927c61e0bcb48b51170 ea0898381ef919398e46417899abe82708addd1b755c056f 5f7b96ba69bd56fc576c809b27b8f8364fc4d559d1da8681 fa04145ddd636eb7 Mensaje descifrado con clave privada de Terminal: 0b9b44777590ea6c4d1f1f724c235964c5ffed0109aab5d4 80b05b7a31c224a4d1c7effe147d454eaaf7d47c35f0dd01 824023282bf8bb3cf1adecd576509672348a9eb196c8b8f1 f49931ea73e634f681a7474480243992f177a92f386747a0 6f57ae0566b5557efc0217cc8be84f50dae24b0a35cd3df1 f2429b96545464d5
Ahora lo que tenemos es el resultado de la funcin 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 pblica de componente de la tarjeta:
Descifrado con clave pblica de tarjeta: 670f3942a1c15faed26cf22c0c87a8930dc3c1f73f772c82 096fe5198ef3b03b72257a8bf8d5c26425faf638758072f3 357ef10ee95f1284f8f277444fb0416ef092d8007abd245d 46b12f3dcfbc303bb7f3e0134d53e542dcccc6f4269784b4 affdb92cadd0494dcc58a142e901a8c940ed480554077ba1 b2263e8b415e8461
Sobre este mensaje descifrado hay que comprobar si se ajusta al formato esperado, y si coincide el hash. En este ejemplo no coincide el relleno (debera empezar por 0x6A, y acabar con 0xBC), as que pasamos a probar si el resultado de la funcin SIGMIN fue N.ICC-SIG. Calcularemos N.ICC-SIGMIN(..), y desciframos de nuevo con la clave pblica de la tarjeta:
48
N.ICC-SIGMIN(..) c63ac71e6ec13fdbbdf3994b0a3707dc76793a9da163ab03 53dfbe2435c4ad2493e1defff226498cef63b5483c581ed2 c6f2a590dcd695d4e84da9605bac32dc0a845534be2f0770 73d272dbc700fca21815eb6c6193150f9726c269a68e4731 0df56050733bd5ed65a3bad8a9e373028a6ee96f0fb5f9c2 0602bb1663b2ec48 Descifrado con clave pblica de tarjeta: 6ac6d2534290ca9938a5c69149d2b8ae2eb565a76b973455 cb203484d893218df38454720dcdcc777460938bfcc888e1 13b3d7aa1f703e8ce1091ef1824c87df4e7c1be5da3a9c05 21ba75886b2b015ce1c9529d9463695fabd1a4a4b85e0a1c cd4f55292c20e21e954d31624cca198a2463ec73f17bbc12 461f182176a8ccbc
En este caso s que obtenemos el relleno correcto, as que pasamos a descomponerlo de acuerdo a la estructura del mensaje, y comprobamos el hash:
6A = relleno segn 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 derivacin de claves del canal seguro. h[PRND1 || KICC || RND.IFD || SN.IFD ]
6A c6d2534290ca9938a5c69149d2b8ae2e b565a76b973455cb203484d893218df3 8454720dcdcc777460938bfcc888e113 b3d7aa1f703e8ce1091ef1824c87df4e 7c1be5da3a9c0521ba75 886b2b015ce1c9529d9463695fabd1a4 a4b85e0a1ccd4f55292c20e21e954d31 624cca198a2463ec73f17bbc12461f18 2176a8cc bc
= hash SHA1 que incluye los datos aportados por la tarjeta y por el terminal
Datos sobre los que calcular el hash: c6d2534290ca9938a5c69149d2b8ae2eb565a76b973455cb 203484d893218df38454720dcdcc777460938bfcc888e113 b3d7aa1f703e8ce1091ef1824c87df4e7c1be5da3a9c0521 ba75 886b2b015ce1c9529d9463695fabd1a4a4b85e0a1ccd4f55 292c20e21e954d31 231dac737ba0fe6e 2000000000000001 Hash calculado: 624cca198a2463ec73f17bbc12461f182176a8cc
Al coincidir el hash calculado con el recuperado en el mensaje descifrado la autenticacin interna se considera correcta. El valor de Kicc debemos guardarlo, ya que se utilizar mas adelante para el clculo de las claves de canal.
49
2.f) Autenticacin externa (del terminal). El siguiente objetivo es realizar la autenticacin externa, para lo cual hay que comenzar solicitando a la tarjeta un desafo 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 segn 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 derivacin de claves del canal seguro. h[PRND2 || KIFD || RND.ICC || SN.ICC ] = hash SHA1 que incluye

Generamos PRN2 y Kifd como valores aleatorios de la longitud apropiada:
PRN2: 2a5c7300d96df9190ec2ae1cef89bde15678a78b7f7d4df3 d7d9bcfa313a0986efcc39695bd29812d2ce5931e1c2fc2d 068a5caf3de5bafef621cd8ba7082659a307d9a45318d479 8084 Kifd: cd97dbf2235760d8b3e9c4d7e9a691fb12cd207c42660df9 c69357ba7b25d0fc

Calculamos el hash:
Datos sobre los que calcular el hash: 2a5c7300d96df9190ec2ae1cef89bde15678a78b7f7d4df3 d7d9bcfa313a0986efcc39695bd29812d2ce5931e1c2fc2d 068a5caf3de5bafef621cd8ba7082659a307d9a45318d479 8084 cd97dbf2235760d8b3e9c4d7e9a691fb12cd207c42660df9 50
c69357ba7b25d0fc eaefa8fbd31ac8ec 00065a85ca586f32 Hash calculado: b82a94c0aea15d96eb0deb0a68828a1bef1b43fc

Construimos el mensaje en claro:
6A = relleno segn 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 derivacin 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 segn ISO 9796-2 (option 1)
6a 2a5c7300d96df9190ec2ae1cef89bde1 5678a78b7f7d4df3d7d9bcfa313a0986 efcc39695bd29812d2ce5931e1c2fc2d 068a5caf3de5bafef621cd8ba7082659 a307d9a45318d4798084
cd97dbf2235760d8b3e9c4d7e9a691fb 12cd207c42660df9c69357ba7b25d0fc b82a94c0aea15d96eb0deb0a68828a1b ef1b43fc
bc
Este mensaje lo cifraremos en primer lugar con la clave privada del Terminal:
SIG: 59d8b4c3cbe41cf96b60dadc845c53f7147a8269a75e24c3 db06d974d59e3de1b7d913acfef9b83321b938740df1c8f1 d7bfd4f6aa84507702b0437c24d19e617e2302a08ac9a7fc 0a972317c8d63cbde35c519f22dee850c9f829b4f8e765ff 47692ca26ce8da55b286bb2f09f18d6048e6c75ad0674380 cd6c49b50274289c

Calculamos N.IFD-SIG para poder obtener SIGMIN, que en este ejemplo coincide con SIG:
N.IFD-SIG: 8153ff5a45479000c076e8f7533a2a8de719b2927ec17845 2f82aa1fa81146a71c067c10cd25da1613cca8c093c264f3 42348e2da2fa830ddfbd0df0a2d36117178e9680b53a92b0 a364efd08ddbc576879bd0cbf7a938e7124430a2f7eb1b5c d8641f1202c03b2a2d76bebd301f1ac483db23e2104f70b8 51
9d75eca3fda291cd SIGMIN: 59d8b4c3cbe41cf96b60dadc845c53f7147a8269a75e24c3 db06d974d59e3de1b7d913acfef9b83321b938740df1c8f1 d7bfd4f6aa84507702b0437c24d19e617e2302a08ac9a7fc 0a972317c8d63cbde35c519f22dee850c9f829b4f8e765ff 47692ca26ce8da55b286bb2f09f18d6048e6c75ad0674380 cd6c49b50274289c

Por ltimo cifraremos el mensaje con la clave pblica de componente de la tarjeta, lo que nos da:
Datos autenticacin externa: af7f20e622485f3700ab7473c201940dd855d36c68b5ebec ddac383464f41cdea31d5b4045e7025d5f394a9e4c298747 ae9300725bee8dfac5dab68df80ecb38e98109f2fe83effc fc74c7c850f6cd752f60ea9fcbd4acc4da3a453a08c937a0 88fe7580c1f0578892d945926c84f282c4ae00ebe2acbc54 8fc0ee396d2764c8

Enviamos el comando a la tarjeta, y si todo est bien calculado, deber aceptarlo sin error (devolver 9000):
0082000080af7f20e622485f3700ab7473c201940dd855d3 6c68b5ebecddac383464f41cdea31d5b4045e7025d5f394a 9e4c298747ae9300725bee8dfac5dab68df80ecb38e98109 f2fe83effcfc74c7c850f6cd752f60ea9fcbd4acc4da3a45 3a08c937a088fe7580c1f0578892d945926c84f282c4ae00 ebe2acbc548fc0ee396d2764c8 9000

2.g) Clculo de las claves de canal. El canal ya est establecido, slo nos queda calcular las claves de canal. En primer lugar calculamos Kifdicc como el XOR de los valores de Kifd y Kicc obtenidos anteriormente:
Kifd: cd97dbf2235760d8b3e9c4d7e9a691fb 12cd207c42660df9c69357ba7b25d0fc Kicc: 886b2b015ce1c9529d9463695fabd1a4 a4b85e0a1ccd4f55292c20e21e954d31 Kifdicc: 45fcf0f37fb6a98a2e7da7beb60d405f b6757e765eab42acefbf775865b09dcd

La clave de cifrado Kenc se obtiene como los primeros 16 bytes del hash de Kifdicc concatenado con el valor 00000001:
52
Datos para el hash: 45fcf0f37fb6a98a2e7da7beb60d405f b6757e765eab42acefbf775865b09dcd 00000001 hash: 598f26e36e11a8ec14b81e19bda223ca ebc69784 Kenc: 598f26e36e11a8ec14b81e19bda223ca
De la misma forma, la clave para el clculo del mac, Kmac se obtiene como los primeros 16 bytes del hash de Kifdicc concatenado con el valor 00000002:
Datos para el hash: 45fcf0f37fb6a98a2e7da7beb60d405f b6757e765eab42acefbf775865b09dcd 00000002 hash: 5de2939a1ea03a930b88206d8f73e8a7 aefdaa4b Kmac: 5de2939a1ea03a930b88206d8f73e8a7
Por ltimo el contador de secuencia SSC se obtiene concatenando los 4 ltimos bytes del desafo de la tarjeta (RND.ICC), con los cuatro ltimos del desafo del Terminal (RND.IFD):
RND.ICC: eaefa8fbd31ac8ec RND.IFD: 231dac737ba0fe6e SSC: d31ac8ec7ba0fe6e
3) Construccin de un mensaje cifrado. Como ejemplo de construccin de un mensaje cifrado para su envo a la tarjeta una vez establecido el canal seguro, analizaremos un comando de seleccin por nombre del fichero maestro (Master.File). El estado inicial del canal para este ejemplo es el siguiente:
Kenc: 598f26e36e11a8ec14b81e19bda223ca Kmac: 5de2939a1ea03a930b88206d8f73e8a7 SSC: d31ac8ec7ba0fe74
53
El mensaje en claro que queremos enviar es
Mensaje en claro: 00a404000b4d61737465722e46696c65 CLA: 00 INS: a4 P1 P2: 0400 P3: 0b Datos: 4d61737465722e46696c65
Como tenemos campo de datos, en primer lugar lo completamos con relleno (7816) hasta obtener una longitud mltiplo de 8 bytes. En este caso nos quedarn dos bloques de 8 bytes:
Datos con relleno 7816: 4d61737465722e46 696c658000000000

A continuacin 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 aadimos 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. Aadimos el TLV de datos. Volvemos a completar con relleno 7816 hasta mltiplo de 8 bytes. En nuestro ejemplo:
CLA con los bits de mensaje cifrado: 0c Cabecera con relleno 7816: 0ca4040080000000 Aadiendo el TLV de datos: 0ca4040080000000 8711013e9ac315a8 54
e855dd3722f29107 8ac2bd Completando de nuevo con relleno 7816: 0ca4040080000000 8711013e9ac315a8 e855dd3722f29107 8ac2bd8000000000
Para calcular el MAC sobre estos datos deberemos realizar un cifrado DES con CBC de estos datos, y en el ltimo bloque se utilizar triple DES. La clave para el cifrado DES son los ocho primeros bytes de Kmac, y para el triple DES ser Kmac completa (con key3=key1). El valor inicial del IV para el encadenamiento CDB, ser en contador de secuencia SSC incrementado antes de ser utilizado. La siguiente figura ilustra este proceso:
Los primeros cuatro bytes del ltimo bloque cifrado ser el MAC que incluiremos en el mensaje a la tarjeta. Con los datos de nuestro ejemplo:
SSC incrementado: d31ac8ec7ba0fe75 Cifrado DES: DES(d31ac8ec7ba0fe75) = 8818b3bff0cb40f5 XOR con bloque de datos: 8818b3bff0cb40f5 XOR 0ca4040080000000 = 84bcb7bf70cb40f5 Cifrado DES: DES(84bcb7bf70cb40f5) = dc6a4a7c11d0b384 55
XOR con bloque de datos: dc6a4a7c11d0b384 XOR 8711013e9ac315a8= 5b7b4b428b13a62c Cifrado DES: DES(5b7b4b428b13a62c) = 5a04399a0116a291 XOR con bloque de datos: 5a04399a0116a291 XOR e855dd3722f29107 = b251e4ad23e43396 Cifrado DES: DES(b251e4ad23e43396) = a398ffc834a23278 XOR con bloque de datos: a398ffc834a23278 XOR 8ac2bd8000000000 = 295a424834a23278 Cifrado triple DES: DES(295a424834a23278) = b6f56963ca2b8632 MAC: b6f56963
Construimos el TLV del MAC (tag = 0x8e), y construimos el mensaje completo, que incluir la cabecera (con el CLA indicando mensaje cifrado), el TLV de datos, y el TLV con el MAC:
TLV del MAC: 8e04b6f56963 Mensaje cifrado: 0ca40400198711013e9ac315a8e855dd3722f291078ac2bd 8e04b6f56963

Enviamos este mensaje a la tarjeta:
0ca40400198711013e9ac315a8e855dd3722f291078ac2bd 8e04b6f56963 612d 00c000002d 872101bb10c8915f0ddb630cf38ed799a202647ca47449d2 79139fc226d25c20765645990290008e049aa777079000

Para descifrar y comprobar la respuesta de la tarjeta, empezamos descomponiendo los TLV que lo forman:
TLV de datos: 872101bb10c8915f0ddb630cf38ed799a202647ca47449d2 79139fc226d25c20765645 TLV con respuesta del comando: 99029000 TLV con el MAC: 8e049aa77707
Para calcular el MAC utilizaremos como entrada todos los TLV devueltos por la tarjeta, excepto el propio TLV del MAC. El procedimiento es el descrito anteriormente:
Datos de entrada del MAC: 872101bb10c8915f0ddb630cf38ed799a202647ca47449d2 56
79139fc226d25c2076564599029000 Con relleno 7861: 872101bb10c8915f0ddb630cf38ed799a202647ca47449d2 79139fc226d25c207656459902900080 MAC calculado: 9aa77707

Como coincide con el enviado por la tarjeta, consideramos el mensaje correctamente cifrado. Los datos del TLV de datos deberemos descifrarlos, y eliminar el relleno 7816 para obtener los datos devueltos por el comando en claro:
TLV de datos: 872101bb10c8915f0ddb630cf38ed799a202647ca47449d2 79139fc226d25c20765645 Datos encriptados: bb10c8915f0ddb63 0cf38ed799a20264 7ca47449d279139f c226d25c20765645 Desencriptando con Kenc: 6f19840b4d617374 65722e46696c6585 0a383f00000bffff ffffff8000000000 Eliminando relleno 7816: 6f19840b4d617374 65722e46696c6585 0a383f00000bffff ffffff
Por tanto, la respuesta equivalente de la tarjeta, puesta en claro sera:
Respuesta en claro: 6f19840b4d61737465722e46696c65850a383f00000bffff ffffff9000
3) Proceso de firma. El primer paso para realizar una operacin de firma con una tarjeta DNIe ser establecer un canal seguro de usuario, tal como se ha descrito anteriormente. En este ejemplo asumimos que el canal acaba de ser establecido, y las claves del canal son:
Kenc: 598f26e36e11a8ec14b81e19bda223ca Kmac: 5de2939a1ea03a930b88206d8f73e8a7 SSC: d31ac8ec7ba0fe6e

El siguiente paso es la presentacin 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 presentacin de PIN sern:
57
[002000000843525950544f4b49] 0c20000019871101ce1ab937c332f3faee43336d4311ef33 8e046908df4e 610a 00c000000a 990290008e04b4bbf3a69000 [9000]

NOTA: Los smbolos y indican los comandos antes de cifrar, y los smbolos y indican los comandos cifrados que realmente se envan 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 informacin de las claves privadas almacenadas en la tarjeta. Los datos que nos interesan son su identificador de PKCS11 (CKA_ID), su etiqueta de PKCS11 (CKA_LABEL), y el path donde reside la clave. En nuestro ejemplo, en el PrKDF tendremos descritas dos claves:
Primera Clave: CKA_LABEL = KprivAutenticacion CKA_ID = A065A85CA586F3220060302120000 Path = 3F110101 Segunda Clave: CKA_LABEL = KprivFirmaDigital CKA_ID = F065A85CA586F3220060302000000 Path = 3F110102
Para simplificar este ejemplo no se incluye la secuencia de comandos para seleccionar, leer y analizar el PrKDF. Para ello nicamente es necesario utilizar los comandos de Select File y de Read Binary. Su contenido se ajusta a la estructura ASN.1 descrita en el PKCS15 para este fichero. La clave que queremos utilizar es la de autenticacin, 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, adems del hash, tambin incluimos el DigestInfo del SHA1 para que sea incorporado a la firma (3021300906052b0e03021a05000414):
[002a9e9a233021300906052b0e03021a05000414839b543f b09d20c803b46e6f8f0747244951822f] 0c2a9e9a31872901e2f39b27db5bc373dde1ea4de7c84371 1529a8f8ded8092fbc88ba9c2b6b7c18b9ffbf4f01def59a 8e04ae86da97 6100 00c0000000 8782010901e4e9ca20eb996f14f219d086b13187d640a7f7 d9a93b74368870e7300ec5db202e683e8507ae871ff9fe6c 10cd6b66e942affac1996a2048e0564d8edd8b0057eaa057 6ec83e0b62eb07bea6f74a43a8d4a518f55daeba0bc6a87f 0e30fb1a75d4472108ecb043dcd2f22f85db5640c86b500b f5a819ac7363d879f98b4295359d2f7c04f134fd28af07b7 e5b327f3214a816fcda489b17e0a0f9b9c3af5b7ceaa4311 c7a66eece210de9b471c78aef858cfeaeb11da40ba932d49 900b73f6a14451c0cae04b085b62aa19037b62eaf7b97bf7 e6df54cb8a4e3db5bc56818467ac756b53ba04b5db0f55c1 db23f2289f9e2c359671ba174a9ecde26117 00c0000017 784dd3609f32f040dae1c1447e990290008e04999b1e4e9000 [632369fa040ccb9f298fdcc2a3e344d815be131e2a609792 9cf9d1fe35fd472580f56c67e040a2437d37f1320a7d8025 27e6eb2734f848315625f6bd14935ed72d1c1e42f5f41bc6 53d83fc180b98fff5b0f3ba5ef159d2de0737e9d4a86469a 156ca7711ad7d9c2d10c797696062cac0b656c0b04b988c7 e447fdf43add6e3a379f1f6e4e115916a49f1cf18ce4421e 41ac044c5dca70a90e58b155212b7caa22bfd1e42ba60a02 92d531943f2adf6bd0f238ecf931bbdfd98d085edc0050dc c799480415f0282e1f9e57b013ea3732330dffa6daba8957 a55d34d004fd3259e6bdd9e568face8118d2e1eff13adeb2 3e1c58f5fafefe38e1374c631281a6689000]
Por lo tanto, la firma calculada es:
Firma del hash de los datos: 632369fa040ccb9f298fdcc2a3e344d815be131e2a609792 9cf9d1fe35fd472580f56c67e040a2437d37f1320a7d8025 27e6eb2734f848315625f6bd14935ed72d1c1e42f5f41bc6 53d83fc180b98fff5b0f3ba5ef159d2de0737e9d4a86469a 156ca7711ad7d9c2d10c797696062cac0b656c0b04b988c7 e447fdf43add6e3a379f1f6e4e115916a49f1cf18ce4421e 59
41ac044c5dca70a90e58b155212b7caa22bfd1e42ba60a02 92d531943f2adf6bd0f238ecf931bbdfd98d085edc0050dc c799480415f0282e1f9e57b013ea3732330dffa6daba8957 a55d34d004fd3259e6bdd9e568face8118d2e1eff13adeb2 3e1c58f5fafefe38e1374c631281a668

Lectura del certificado de autenticacin y verificacin 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 descripcin de la estructura de este fichero puede encontrarse en la especificacin del PKCS15. Los datos que nos interesan son su identificador de PKCS11 (CKA_ID), su etiqueta de PKCS11 (CKA_LABEL), y el path hasta donde reside el certificado:
Primer certificado: CKA_LABEL = CertAutenticacion CKA_ID = A065A85CA586F3220060302120000 Path = 60817002 Segundo certificado: CKA_LABEL = CertFirmaDigital CKA_ID = F065A85CA586F3220060302000000 Path = 60817001 Tercer certificado: CKA_LABEL = CertCAIntermediaDGP CKA_ID = S065A85CA586F3220060302000000 Path = 60617003
La relacin entre un certificado y su clave privada es que ambos tienen el mismo CKA_ID. En nuestro caso, el certificado correspondiente a la clave que hemos utilizado es el primero (CKA_LABEL= CertAutenticacion), que est en la ruta 6081/7002. Seleccionamos el fichero del certificado (empezando por el fichero maestro), y lo leemos:
[00a404000b4d61737465722e46696c65] 0ca40400198711013e9ac315a8e855dd3722f291078ac2bd 8e04b6f56963 612d 00c000002d 872101bb10c8915f0ddb630cf38ed799a202647ca47449d2 79139fc226d25c20765645990290008e049aa777079000 [6f19840b4d61737465722e46696c65850a383f00000bffff ffffff9000] [00a40000026081] 0ca4000011870901251c58d6b01d4e098e04fb732ce1 60
612d 00c000002d 872101fad72ff5311c10b8a755837dd24460dcf522cfea3a 198b9ca5c5c2d09ef7dc19990290008e0457cd226d9000 [6f178409444e49652e50726976850a3860810009e0ffffff ff9000] [00a40000027002] 0ca40000118709012ca1509017522a6c8e04470c1fde 611d 00c000001d 8711012b9724c0ebbec01c697f4693b659d8aa990290008e 0460c777959000 [6f0c850a24700204f21120ffffff9000] [00b00000ef] 0cb00000099701ef8e0482fc8ba1 61fe 00c00000fe 8781f101711c55e3704a007ff352b1bcafcac96b43e11e87 697f6b7bae797005d20adbafbba31fc2f8e9ceaeb90b7963 1a230e69e57c06fb7f58e3f2ef0e11211195d87572a2ee38 ec91e8722bd660db01c718d6f0d8509de1e4b81cc169e18a 128c638c705f4b5e5ebe0f02d9c5edf06908f472feda8953 f04db368cd270baf5098fd8d38447df3d44952100510fc09 a85b9055ce475867beb21f252e28e68bb0188abf70103d37 2c9ffba2270a6e13c393256ab44504f9021037d45a621e82 8307a14efdcd5796f39190632861ff195ffc9d2167a1879d 0abc269354a76489cd574d2ea76e40ee7c3d04e0aeeb7dfd f917cbb3990290008e042d30f6009000 [e8050000b3040000789c3368627d62d0c472660133132313 9300af5929b7e022f54617b62713652f1cbe6bc0cbc6a9d5 e6d1f69d9791919595c120c690db80938d3994854d98c935 d850c3400dc4e1e29177f10c727576f6f4f7537077f5730d 72f451707155f0715408f0f7f174f67434e435e006a9e4e6 6171f1f3743514311002719979b81d9d1540220a06068606 72e2bc066606c6064686464666a6e65140ae8581259c6b50 866abb90810088c32acc69000646c621307b587858bc421d fd0c050df8415c2d1e0ed7e000c7c313fd7d0c0d0df42156 6bc08414600c1d059026050dc7d01057bf104f674767cf90 00] [00b000efef] 0cb000ef099701ef8e04b08c0cd5 61fe 00c00000fe 8781f1017490b8866e13cdcd7929262740e34d3e97d2c0e7 61
fa9c9259e12392e14ebfbe81549405a5038343e85b774eb0 2b7df7e57ece210bff119f5f9ecf3de16fbfe9e5516273b2 81ef0e21f40b9aa6e5ebcac0450a18784c3b3989c6c3b9b4 e5aa20d95cb9e1333842696f154316055c408553cb47f7d5 ffc4315d44fa4c851c16c55f5f06a897ecc0e6fbb67398dc 9f414b771ebe0039c506e49e529ec757e2550ab85c38320a b1aa977a70e803d9f35da6bfb1e1e7ef5be4748d33234966 c00840a733e05e67107a1234a9f41219ee92f0228504e8b7 1baf9affddc36093ead8705008b3fc62cba13cf7c9b02b76 41b955cb990290008e04398d9f209000 [c393fd340d9a1895900382919581b989919f0128cec5d4c4 c8c870e84ab9f987c4f4e3efda98f4d466fd75bd1a7d2469 a7e81de1996bf8e79a374f7ca9707f6148c633d7aacf5e37 e4265ca9c91311769733b1bb3a7d9bfbffd8779716cecbf5 5abaafff5ef8b2c88c98b0d07b7d6a063c9f9a67e90b862c f2cede90e9b8f4a8bbe3b9eb16ce13b98df8b6adb294fffd b14177c934f3042df179afe35ab5fe67346cac6b0e773f31 4b80e9b0cbf7290b647beb736b3a0c9cdc17c878f9796854 88bf9c715a607dc4ddc7524527aaa48e7f9b312dbde5bfc8 01ff6f4aa9ccde0bfee42707e87ae74418fc993aebe3cc90 00] [00b001deef] 0cb001de099701ef8e04537dd3e6 61fe 00c00000fe 8781f101c80473207556fd7f00d1c0a2ef0b156ec3d6901f efc8ea9a5ad065b30ac38839b6242b4a5ac4f7af7c620917 e022b35ac5c59b6918dead31cea1488aabd7c2b35a7c2e6c a4159a02c660f7674fd04aa31a013452b40bf36fe4a0c2fe 53552b56a0f6814fcd4bbbd17b8d1974bb69067ead830a49 7109b513507b76a41df522641a965b0d087f32d3c101b88e 446219ecf77727fa033c315f277a888d0492498d5f227f0e 2e8a3c99f5631e5485a252ad43b42b1fa768bac9d54a5ac9 796b32ce14c03b790cd4474ca7f1583e14b99ba26e30dc40 97e3f61248b9b5d237dc53010b5ae8f34f647febf8a1d0b8 9844a15d990290008e04df3d0c1d9000 [30a545b396093f69ea7aae5bb46d717c3acf85c31b0aeebc 3eba2dce4be0ad466224c789231b565a356a3031edf48bd4 6060af093775f3fbcec4ccc8c0b8b889a9cda089a9c98007 18bcb2c28c8cff59980c180cf8403c7e108f859989bdc140 16c4e7631163117999fe5026f2d31df3cbda496d026bee30 aeb9af9e62200f9256669130106b1091ea5c71f45d7f596c 6861e7676bd3bdab5819a6e61b28b17168b301d3223b2333 8b98818801071b1b0b439f1b23239cc562900057c3c81262 10043414ca37606c13ce282929b0d2d7cf4f2e2ed04bc9cb 4cd54b2d06a6089802a63665a882f2f27298bc7e726a5190 00]
62
[00b002cdef] 0cb002cd099701ef8e048e11b7f4 61fe 00c00000fe 8781f101d18a6305065cc06862c9e6e1011528d61ccd546c a61d59930bc697fbba768ed933d6fd8b79ef635449a94a51 9071ce33e9176b7968520c42f8c2f92a314062f35060e63c 1d4246d540f2680b4f539b0c21b8ff94f699fd962b2283d9 593246c289f200e75533819f95b7e172117b3b8cc2f7191f 61c785905c500a69a362a9f82c95877f6aeec27236a48170 c224ae7c96948a95e2858d5377ca208a0df25b74392a6eef c3a773e196193bdee3e42aa5c2da03c74a9fd886668c4e59 e9482624d7abad231090f2f63d9c97738b4c4c5cafda92c5 738a4ccc7f7377ab2f2650c98e69377d0faa1fe578092c0e 4ada6869990290008e0486200d469000 [49b1bea373506266955e7251898135c8990a2c2606460606 6c1c09ad21c0ccc3c462a082701e13a398181693520a920d 1a3fc0ddc7c4d2f8d8a0f181811113d003dc6c9c096d1e8c a9cc2c4c8c2c0aa1b67cacf60fd64bc7cc683388bfece376 f4a1d2b33ba6191327cdbef5b850ff7936480f03a97aac80 cac18e052aa7402f1ba97a3540e1c5c9a268200f4c0050cf 73321a0a4af01b5a9a0173be91a9a111280b471938c18293 8591c5ccc004e44b2634db02abd2fa1e2e7aecb7dcf75ff8 9d4a815f6bc3c38d27a9ba7194fe7f97bd7a52ca12b4428b 199445bd180515365cef3c1a1dbd5ecf6dddda7edd733190 00] [00b003bcef] 0cb003bc099701ef8e04dd235d61 61fe 00c00000fe 8781f101750c77ccaf5c18cdfe6c0cbd5a66772ca56995d8 1932677e0d3954f87010b02e070502dc3444023faa127a5a 28cad4db3f1adcb0e0848c35fd418dbcfa0b9acf9bff811b ac4d6ef1b0c5df7818539eb8ba1f3edc51874d6cfa8f2a1d 93a245523755dabe07f44b364afc3265236ce3c55cb0217b 00e6da7cd9afd861d1a0840086ef1aac2e1b842357ca44c1 e918c877ce60edaac1b8529644b64baba80cc3c74867d5f9 132f19cabe8094496a8ff6994963982a43ba41eb733f16ab 83b3e7941fcc0ef9c0b5bb472c25b0227c0b9fe9c537a0b1 1ce03ec92fb82c2d10a47163194319a1a54a57da771a14eb c86f5d2a990290008e0413713a3f9000 [ca7107799d04152b4fbc522ffbd693ce71ecb3700d4f9432 7b36c39ca2d9499fddd6bb7f9512baca1ab9fa8de6c52d8f 1497e50598e77e6b38ecfc96d9fbda84047f79d7f33396f7 316d3511564daa3fd1adaa98fe9d7dc5d5f61533ffa807ec dbecaff7cce7f2c16d425646ec4eacc63f76711c79762ae8 5bc3df42f557738eaf13ba21788ad5e976df3bb9e90a3fd5 5a0bfb74e34ae6ed50bb9e7fdab2c349f3ee8ac7073e45e8 63
ce2ff25a6ada29f96285ef9aeb31f5acb7cc2cb6cc7a9260 3cc1904ff460b83b8364e5676d91d9520fd62bb71fe5edb6 2958ccc4ab9f719be123df963333bf046e4b75faf7f6a690 00] [00b004ab47] 0cb004ab099701478e04960bfd2f 610a 00c000000a 99026c108e043190b8309000 [6c10]
[00b004ab10] 0cb004ab099701108e0462d211ad 6125 00c0000025 87190144fdab7ba445a1cb602b7e45138b561cbd4f6596d0 16bcb6990290008e047c5ed3c19000 [810bdff7e4830fe75e780e00c9adeabc9000]

El contenido del fichero que acabamos de leer es el certificado comprimido con la librera zlib, con una pequea cabecera que indica el tamao de los datos comprimidos, y los datos comprimidos:
Tamao de los datos descomprimidos: e8050000 Tamao de los datos comprimidos: b3040000 Datos comprimidos: 789c3368627d62d0c4726601331323139300af5929b7e022 f54617b62713652f1cbe6bc0cbc6a9d5e6d1f69d97919195 95c120c690db80938d3994854d98c935d850c3400dc4e1e2 9177f10c727576f6f4f7537077f5730d72f451707155f071 5408f0f7f174f67434e435e006a9e4e66171f1f374351431 1002719979b81d9d1540220a0606860672e2bc066606c606 4686464666a6e65140ae8581259c6b50866abb90810088c3 2acc69000646c621307b587858bc421dfd0c050df8415c2d 1e0ed7e000c7c313fd7d0c0d0df421566bc08414600c1d05 9026050dc7d01057bf104f674767cfc393fd340d9a189590 0382919581b989919f0128cec5d4c4c8c870e84ab9f987c4 f4e3efda98f4d466fd75bd1a7d2469a7e81de1996bf8e79a 374f7ca9707f6148c633d7aacf5e37e4265ca9c913117697 33b1bb3a7d9bfbffd8779716cecbf55abaafff5ef8b2c88c 98b0d07b7d6a063c9f9a67e90b862cf2cede90e9b8f4a8bb e3b9eb16ce13b98df8b6adb294fffdb14177c934f3042df1 79afe35ab5fe67346cac6b0e773f314b80e9b0cbf7290b64 7beb736b3a0c9cdc17c878f979685488bf9c715a607dc4dd c7524527aaa48e7f9b312dbde5bfc801ff6f4aa9ccde0bfe e42707e87ae74418fc993aebe3cc30a545b396093f69ea7a 64
ae5bb46d717c3acf85c31b0aeebc3eba2dce4be0ad466224 c789231b565a356a3031edf48bd46060af093775f3fbcec4 ccc8c0b8b889a9cda089a9c9800718bcb2c28c8cff59980c 180cf8403c7e108f859989bdc14016c4e7631163117999fe 5026f2d31df3cbda496d026bee30aeb9af9e62200f925666 9130106b1091ea5c71f45d7f596c6861e7676bd3bdab5819 a6e61b28b17168b301d3223b23338b98818801071b1b0b43 9f1b23239cc562900057c3c8126210043414ca37606c13ce 282929b0d2d7cf4f2e2ed04bc9cb4cd54b2d06a6089802a6 3665a882f2f27298bc7e726a5149b1bea373506266955e72 51898135c8990a2c26064606066c1c09ad21c0ccc3c462a0 82701e13a398181693520a920d1a3fc0ddc7c4d2f8d8a0f1 81811113d003dc6c9c096d1e8ca9cc2c4c8c2c0aa1b67cac f60fd64bc7cc683388bfece376f4a1d2b33ba6191327cdbe f5b850ff7936480f03a97aac80cac18e052aa7402f1ba97a 3540e1c5c9a268200f4c0050cf73321a0a4af01b5a9a0173 be91a9a111280b471938c182938591c5ccc004e44b2634db 02abd2fa1e2e7aecb7dcf75ff89d4a815f6bc3c38d27a9ba 7194fe7f97bd7a52ca12b4428b199445bd180515365cef3c 1a1dbd5ecf6dddda7edd7331ca7107799d04152b4fbc522f fbd693ce71ecb3700d4f94327b36c39ca2d9499fddd6bb7f 9512baca1ab9fa8de6c52d8f1497e50598e77e6b38ecfc96 d9fbda84047f79d7f33396f7316d3511564daa3fd1adaa98 fe9d7dc5d5f61533ffa807ecdbecaff7cce7f2c16d425646 ec4eacc63f76711c79762ae85bc3df42f557738eaf13ba21 788ad5e976df3bb9e90a3fd55a0bfb74e34ae6ed50bb9e7f dab2c349f3ee8ac7073e45e8ce2ff25a6ada29f96285ef9a eb31f5acb7cc2cb6cc7a92603cc1904ff460b83b8364e567 6d91d9520fd62bb71fe5edb62958ccc4ab9f719be123df96 3333bf046e4b75faf7f6a6810bdff7e4830fe75e780e00c9 adeabc
Si los datos comprimidos los expandimos con la librera zlib obtendremos el certificado X509 de autenticacin del ciudadano:
Certificado X509: 308205e4318204cca00302010202100d36750b11a2278144 06e4911dd0c3dd300d06092a864886f70d0101050500305c 310b300906035504061302455331283026060355040a0c1f 444952454343494f4e2047454e4552414c204445204c4120 504f4c49434941310d301b060355040b0c04444e49453114 301206035504030c0b414320444e494520303031301e170d 3036303330323132323635375a170d303830393032313232 3635375a3076310b30090603550406130245533112301006 035504051309303030303030323354310d300b0603550404 0c044a55414e3111300b060355042a0c0845535041c3914f 4c3131302f06035504030c2845535041c3914f4c20455350 41c3914f4c2c204a55414e2028415554454e544943414349 c3934e2930820122300d06092a864886f70d010101050003 82010f003082010a0282010100c2d47737f06167c7ee8602 2e269afd45d55bc462b915dc1399ac0f9d378391e920dfa1 65
5468e6457af34ad81e90d47c6e1413471e343ed597b647ff 5deed2a19e6d4aa5be8fde57a659685c5655de8e26300cf2 839a2f1154a24b6bb06941a5c54741ced73843910b320eb6 aa391ffbf1802da49637602a179eeb5e852aff6880b17e83 5747c89a1002c344f794a01d8d7f6d7c88304247a01c4a4e 48287817e998cb10af58dde31a72c87a1ac7f698966784ff 14c04ff62265034ba0fc6f63502d4b6c5830fc959af19956 22a29aa613e4828ae72d72b6a35f670cd0c3b070dcebc5b6 5e4a10ed28615908c8c4b0a93a81280202b94e592800077c 5735464ef70203010001a382028630820282300c0603551d 130101ff04023000300e0603551d0f0101ff040403020780 301d0603551d0e04160414e967e11c59f2dc37d32b628610 acdc01acdf2764301f0603551d230418301680141a89a8c5 ee8f765d557189f33b35bdaa0500956f302206082b060105 05070103041630143008060604008e460101300806060400 8e460104306006082b0601050507010104543052301f0608 2b060105050730018613687474703a2f2f6f6373702e646e 69652e6573302f06082b060105050730028623687474703a 2f2f7777772e646e69652e65732f63657274732f41435261 697a2e637274303b0603551d200434303230300608608554 01020202043024302206082b060105050702011616687474 703a2f2f7777772e646e69652e65732f6470633081f00608 2b060105050701020481e33081e03032020101300b060960 86480165030402010420553d0e053fe0af1b5c9886305fd3 4c46c5e122e6dc356891929bdae3712fe76b303202010030 0b06096086480165030402010420553d0e053fe0af1b5c98 86305fd34c46c5e122e6dc356891929bdae3712fe76b303a 0609608554010202040201300b0609608648016503040201 0420553d0e053fe0af1b5c9886305fd34c46c5e122e6dc35 6891929bdae3712fe76b303a060960855401020204020630 0b06096086480165030402010420553d0e053fe0af1b5c98 86305fd34c46c5e122e6dc356891929bdae3712fe76b3028 0603551d090421301f301d06082b06010505070901311118 0f31393630313032353132303030305a3042060860855401 02020401043630343032020102300b060960864801650304 02010420517a668ee1a2e34ea75dfe57dc7910faad575733 9225460875ffee6bab9264a4300d06092a864886f70d0101 05050003820101004a011120b0d789c55b5baf2e46aead8f 2dce5c235ec10d42112179c8ea2776f68c6708c6f3137c0c 5a23076b009c729b62f346af47f51a12d50559abec29d1b4 e221a66e50376df680c343ed034bd690604f1f45cf98a78e 02b5341325627fc88b252167f707a8d587a899fc2750beb3 4f2ee64cd3c1b6123a3206420533f8ba08c4e6ca52f680fd 7127ea9cc7ae12d811ca0542db8eee1e9720f92685718e2d 5e749eb826d76fcb39884229dda8e3c0f2582d9f724aa535 8919e8a84dacd75c7f05da3638b49ae4603390310e15c157 47001979f32b149b1ae0af2387c50d8b3c70a3020d2f68db 00f10eb4cc99f451b66542deedd930440ef763c1e19dd0e7
Este certificado deber ser verificado con la cadena de validacin de certificados, comprobar caducidad, lista de revocados, etc...
66
De l podemos obtener la clave pblica que nos servir para comprobar la firma realizada anteriormente: Clave pblica de autenticacin:
Mdulo = 2cd47737f06167c7ee86022e269afd45d55bc462b915dc13 99ac0f9d378391e920dfa15468e6457af34ad81e90d47c6e 1413471e343ed597b647ff5deed2a19e6d4aa5be8fde57a6 59685c5655de8e26300cf2839a2f1154a24b6bb06941a5c5 4741ced73843911c320eb6aa391ffbf1802da49637602a17 9eeb5e852aff6880b17e835747c89a1002c344f794a01d8d 7f6d7c88304247a01c4a4e48287817e998cb10af58dde31a 72c87a1ac7f698966784ff14c04ff62265034ba0fc6f6350 2d4b6c5830fc959af1995622a29aa613e4828ae72d72b6a3 5f670cd0c3b070dcebc5b65e4a21ed28615908c8c4b0a93a 81280202b94e592800077c5735464ef7 Exponente pblico: 010001
Desencriptando con esta clave pblica la firma generada anteriormente:
Datos firmados con clave de autenticacin: 632369fa040ccb9f298fdcc2a3e344d815be131e2a609792 9cf9d1fe35fd472580f56c67e040a2437d37f1320a7d8025 27e6eb2734f847315625f6bd14935ed72d1c1e42f5f41bc6 53d83fc180b98fff5b0f3ba5ef159d2de0737e9d4a86469a 156ca7711ad7d9c2d10c797696062cac0b656c0b04b988c7 e447fdf43add6e3a379f1f6e4e115916a49f1cf18ce4421e 41ac044c5dca70a90e58b615212b7caa22bfd1e42ba60a02 92d531943f2adf6bd0f238ecf931bbdfd98d085edc0050dc c799480415f0282e1f9e57b013ea3732330dffa6daba8957 a55d34d004fd3259e6bdd9e568face8118d2e1eff13adeb2 3e1c58f5fafefe38e1347c631281a668 Firma desencriptada: 0001ffffffffffffffffffffffffffffffffffffffffffff ffffffffffffffffffffffffffffffffffffffffffffffff ffffffffffffffffffffffffffffffffffffffffffffffff ffffffffffffffffffffffffffffffffffffffffffffffff ffffffffffffffffffffffffffffffffffffffffffffffff ffffffffffffffffffffffffffffffffffffffffffffffff ffffffffffffffffffffffffffffffffffffffffffffffff ffffffffffffffffffffffffffffffffffffffffffffffff ffffffffffffffffffffffffffffffffffffffffffffffff ffffffff003021300906052b0e03021a05000414839b543f b09d20c803b46e6f8f0747244951822f
Donde podemos comprobar que est el hash que solicitamos firmar, y al que se le ha incluido el relleno PKCS1 hasta completar el tamao de la clave.
67

2010.09.30 - Manual de Comandos Del DNIe - Tractis

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

2010.09.30 - Manual de Comandos Del DNIe - Tractis

Cargado por

Copyright:

Formatos disponibles

MINISTERIO DEL INTERIOR

DIRECCIN GENERAL DE LA POLICA Y DE LA GUARDIA CIVIL

CUERPO NACIONAL DE POLICA

Marco legal bsico.

Certificado de componente. Su propsito es la identificacin de la tarjeta del DNI

Certificado de firma. Destinado a la firma de documentos garantizando la

Actividad de validacin de los certificados.

Identificacin de usuario mediante cdigo CHV.

Identificacin de usuarios mediante datos biomtricos.

Desbloqueo y cambio de cdigo CHV.

Estados del sistema.

Requisitos de seguridad. Asunciones de entorno.

Servicio de Atencin al Ciudadano.

Servicio de Atencin al Ciudadano para consultas de carcter administrativo 902.364.444 sac@dnielectronico.es

Consultas tcnicas de ciudadanos, empresas y Administraciones oficinatecnica@dnielectronico.es

Glosario de trminos y expresiones habituales.

ANEXO I Desarrollo de la funcionalidad de seguridad

Comando GET CHALLENGE

Codificacin del comando

Comando GET CHIP INFO

Codificacin del comando

Vaco Vaco Nmero de serie

Comando GET RESPONSE

Codificacin del comando

Vaco Vaco Longitud de los datos esperados como respuesta

Comando EXTERNAL AUTHENTICATION.

Codificacin del comando

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

Estructura del comando para autenticacin segn EN-14890 ap 8.4

los datos aportados por la tarjeta y por el terminal

Mensaje del comando

Comando INTERNAL AUTHENTICATION.

Codificacin del comando

Mensaje de respuesta Autenticacin segn EN-14890 ap. 8.4

los datos aportados por la tarjeta y por el terminal

Comando MANAGE SECURITY ENVIRONMENT.

Tipo de referencia KRT_CRYPTO KRT_IDENT KRT_MEMORY

Tamao 2 bytes 2 bytes N bytes

Formato 0x01 || KeyID 0x02 || KeyID CHR del certificado

Plantilla Autenticacin (AT).

Codificacin del comando

Ejemplo 2: Seleccin de la clave en memoria

Ejemplo 3: Seleccin de la clave en memoria para Autenticacin interna

Ejemplo 4: Seleccin de la clave para autenticacin

Ejemplo 5: Seleccin de la clave para firma

Comando PERFORM SECURITY OPERATION.

Rol ID 0010 0001 0010 0010 0000 0010

Firma de un hash calculado externamente

Codificacin del comando

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

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

Ejemplo 2: Verificar Certificado Autoverificable Certificado Terminal

Ejemplo 3: Clculo de un hash en la tarjeta

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

Codificacin del comando

0x6F T 0x84 0x85

0x6F T 0x84 0x85

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

Ejemplo 2: Seleccin por nombre del fichero dedicado PKCS-15

Comando READ BINARY.

Codificacin del comando

Si el campo Le=0 entonces el nmero de bytes a leer es 256.

Ejemplo: Lectura Binaria

Codificacin del comando