Programación y uso de tarjetas criptográficas NFC (DNIe, TUI, etc) con Android

29/11/2015
Tomás García-Merás
tomas.garciameras@atos.net
clawgrip@hotmail.com
Programación y uso de
tarjetas criptográficas
NFC (DNIe, TUI, etc)
con Android

29/11/2015
Conceptos básicos de tarjetas
inteligentes
Programación y uso
de tarjetas
criptográficas NFC
(DNIe, TUI, etc) con
Android

3
Agenda
▶ Tarjetas inteligentes
▶ ISO 7816
▶ PC/SC
▶ ASN.1
▶ PKCS#15
▶ CWA-14890
▶ PACE

4
Tarjetas inteligentes
criptográficas
▶ Chip con capacidad de proceso insertado en
una tarjeta plástica:
– Procesador de uso general con capacidad
de memoria y potencia limitados.
– Coprocesador criptográfico con múltiples
capacidades: 3DES, RSA, AES, EC, etc.
– Velocidad de comunicaciones muy limitada
(típicamente 9.600 en modo serie).
▶ Puede tener otros formatos:
– MicroSD, USB, PCI, software, etc.

5
Tarjetas inteligentes criptográficas
Comunicación con la tarjeta
▶ El interfaz con una tarjeta es muy sencillo, y se basa en la norma ISO 7816-4:
– El IFD envía un comando en forma de octetos binarios (APDU) al chip de la
tarjeta (ICC), y este contesta con otra APDU.
• La tarjeta únicamente enviará datos al IFD como respuesta a un envío
previo de este, nunca inicia las comunicaciones.
▶ Ejemplo:
COMMAND APDU
RESPONSE APDU
ICCIFD
90B8000007
0203CC950536219000
ICCIFD

6
Comunicación con la tarjeta – ISO 17816-4
▶ Las APDU están normalizadas en la ISO 7816-4:
– Define un formato unificado para los comandos APDU y las APDU de
respuesta a estos.
• Ciertas tarjetas pueden ignorar esta norma e implementar otras equivalentes (por
ejemplo, las SIM implementan GSM 11.11).

7
▶ Ejemplo de APDU: 00A40000026020
– 00 Clase de APDU (0x00 = APDU estándar)
– A4 Instrucción (0xA4 = Selección del fichero)
– 00 Primer parámetro de la instrucción
– 00 Segundo parámetro de la instrucción
– 02 Longitud del campo de datos (0x02 = dos octetos)
– 60 20 Campo de datos (6020 es el nombre del fichero a seleccionar)
Selección (sin parámetros) del fichero 6020 dentro del directorio actual
▶ A este comando un DNIe contestará: 610E
– 61 Operación correcta, hay respuesta disponibles.
– 0A La respuesta disponible mide 0x0A octetos.

8
▶ Prueba simple:
Nota: Un comando de respuesta correcta termina siempre en 9000 o en 61xx

9
▶ La organización básica de datos dentro de una tarjeta también está normalizada
en la ISO 7816-4:
– MF: Master File, directorio raíz de la tarjeta.
– DF: Dedicated File, equivalente a un directorio.
– EF: Elementary File, equivalente a un fichero.
Cada elemento puede referenciarse por su nombre (longitud arbitraria, normalmente
un texto ASCII o su identificador (dos octetos, por ejemplo).
EF EF
DF DF EF
MF

10
▶ ISO 7816-4 define un catálogo de comandos y respuestas para las
operaciones más comunes.
• Las tarjetas implementan además comandos propietarios no catalogados en la ISO.
▶ Por ejemplo:
– READ BINARY
– WRITE BINARY
– UPDATE BINARY
– ERASE BINARY
– READ RECORD(S)
– WRITE RECORD
– APPEND RECORD
– UPDATE RECORD
– GET DATA
– PUT DATA
– SELECT FILE
– VERIFY
– INTERNAL AUTHENTICATE
– EXTERNAL AUTHENTICATE
– GET CHALLENGE
– MANAGE CHANNEL

11
Comunicación con la tarjeta – IFD ICC
▶ ¿Cómo le hago llegar un comando a la tarjeta?
– La práctica totalidad de los lectores de tarjetas siguen la norma USB CCID:
• http://www.usb.org/developers/docs/devclass_docs/DWG_Smart-Card_CCID_Rev110.pdf
– La práctica totalidad de los sistemas operativos exponen un API PC/SC para
el acsesso a los lectores de tarjetas:
• http://www.pcscworkgroup.com/
– La mayoría de los sistemas operativos traen de serie un controlador para
lectores CCID que expone el API PC/SC.
– La mayoría de los lenguajes de programación (.NET, Java, etc.) contienen
API de alto nivel para el acceso a PC/SC.
CCIDFW Driver PC/SC App

12
– API Java
• JSR 268: Java Smart Card I/O API (incluido de serie en Linux, Windows,
OS X y Solaris desde Java 6)
– https://jcp.org/en/jsr/detail?id=268
Ejemplo:
final List<CardTerminal> terminals = TerminalFactory.getDefault().terminals().list();
final Card card = terminales.get(0).connect(*);
final CardChannel canal = card.getBasicChannel();
final ResponseAPDU response = canal.transmit(new CommandAPDU(COMMANDO));

13
– ¿Android?
• Android no tiene controladores para lectores USB CCID, es necesario
implementar nuestra propia implementación de la normativa.
– https://github.com/ctt-gob-es/jmulticard/tree/master/jmulticard-android
• Es posible usar el canal inalámbrico NFC para enviar APDU a tarjetas
compatibles con ISO 14443 (NFC es un subconjunto de esta normativa).
Ejemplo:
final IsoDep isoDep = IsoDep.get(tag);
isoDep.connect();
isoDep.setTimeout(ISODEP_TIMEOUT);
final byte[] response = isoDep.transceive(APDU_COMANDO);

14
¿Qué hay dentro de una tarjeta? ASN.1
▶ ASN.1 es un lenguaje de descripción de datos de uso general en
muchos protocolos y normativas:
– LDAP, UMTS, X.400, X.25, SNMP.
– Basado en estructuras binarias tipo TLV:
• Por ejemplo: 020101
– 02: Tipo de datos (0x02 = Número entero)
– 01: Longitud de los datos (0x01 = 1 octeto)
– 01: Valor de los datos (0x01 = Número uno)
– Muy compacto en cuanto a tamaño, muy eficiente en cuanto a uso de
recursos para su proceso (memoria, potencia de proceso), per muy
molesto de aprender y depurar.
– Recursos de aprendizaje:
• http://www.oss.com/asn1/resources/books-whitepapers-pubs/asn1-books.html#dubuisson
• http://www.oss.com/asn1/resources/books-whitepapers-pubs/asn1-books.html#larmouth

15
▶ ASN.1 define muy diversos tipos de datos de forma implícita:
Simple Types Tag Typical Use
BOOLEAN 1 Model logical, two-state variable values
INTEGER 2 Model integer variable values
BIT STRING 3 Model binary data of arbitrary length
OCTET STRING 4 Model binary data whose length is a multiple of eight
NULL 5 Indicate effective absence of a sequence element
OBJECT
IDENTIFIER 6 Name information objects
REAL 9 Model real variable values
ENUMERATED 10 Model values of variables with at least three states
CHARACTER
STRING *
Models values that are strings of characters from a specified
characterset

16
▶ ASN.1 define muy diversos tipos de datos de forma implícita:
Structured Types Tag Typical Use
SEQUENCE 16 Models an ordered collection of variables of different type
SEQUENCE OF 16 Models an ordered collection of variables of the same type
SET 17 Model an unordered collection of variables of different types
SET OF 17 Model an unordered collection of variables of the same type
CHOICE *
Specify a collection of distinct types from which to choose
one type
SELECTION * Select a component type from a specified CHOICE type
ANY *
Enable an application to specify the type
Note: ANY is a deprecated ASN.1 Structured Type. It has been
replaced with X.680 Open Type.

17
¿Qué hay dentro de una tarjeta? PKCS#15
▶ La normativa PKCS#15 (fuertemente basada en ASN.1) defines las
estructuras internas de las tarjetas inteligentes, así como su
organización en la memoria de la tarjeta:

18
¿Qué hay dentro de una tarjeta? PKCS#15
▶ PKCS#15 nos va a indicar la localización dentro de la tarjeta de las
claves públicas, las claves privadas, los certificados, etc. Para eso
define una estructura compleja de ficheros y punteros a ficheros.

19
Consideraciones adicionales
▶ Las tarjetas inteligentes pueden estableces mecanismos adicionales
de seguridad:
– Autenticación externa:
• La tarjeta autentica al IFD.
– Autenticación interna:
• El IFC autentica al ICC.
– Canal cifrado
• CWA-14890.
– PACE

29/11/2015
Conceptos básicos de criptografía y
firma electrónica
Programación y uso
de tarjetas
criptográficas NFC
(DNIe, TUI, etc) con
Android

21
Agenda
▶ Introducción a la criptografía
– Huellas digitales
– Códigos de autenticación de mensajes
– Cifrado
– Firma digital
▶ Claves, certificados y almacenes
– Conceptos
– Formatos de firma
▶ Sobres electrónicos
▶ Cifrado simétrico

22
Introducción a la criptografía
▶ Es la parte de la criptología que estudia los algoritmos, protocolos, sistemas,…
que permiten la seguridad en las comunicaciones.
▶ Se basa en el uso de mecanismos matemáticos que aseguran la complejidad
computacional y/o estadística de violar la seguridad del las comunicaciones.
▶ La está orientada a proporcionar las siguientes propiedades de un mensaje:
– Confidencialidad
• El mensaje sólo es legible para su autor y/o destinatario.
– Integridad
• El mensaje no se ha modificado.
– Autenticidad
• El mensaje ha sido creado por quien dice ser.

23
▶ La huella electrónica es una breve serie de octetos que identifica unívocamente
a un binario. Una huella digital solo puede provenir de un binario específico y
debe ser imposible modificar un binario sin que cambie su huella digital.
▶ Evidentemente, es conceptualmente imposible
que esta definición se cumpla, por lo que, siendo
estricto, podríamos dejarlo en “debe ser
estadísticamente muy raro encontrar dos binarios
con la misma huella digital y computacionalmente
muy costoso construir un binario a partir de una
huella digital o modificar el binario sin que cambie
esta última”.
▶ El concepto “computacionalmente costoso” varía según avanza la tecnología,
por lo que los algoritmos de huella digital se quedan obsoletos con el tiempo.
Huellas Digitales

24
▶ Los códigos de autenticación de mensajes (MAC) son porciones de datos
generados a partir de un mensaje que permiten comprobar su integridad.
▶ El MAC de un mensaje suele enviarse adjunto al mismo, de tal forma que en
destino se puede comprobar si el mensaje o el código son alterados durante el
transporte.
▶ Para asegurar la autenticidad de los datos. El MAC de un mensaje suele
depender de una clave conocida por emisor y destinatario.
▶ Las funciones MAC más utilizadas son las de tipo HMAC en donde el código de
autenticación se genera a partir de una huella digital y una clave secreta.
– Además de la integridad, nos permite verificar la autenticidad del mensaje.
Código de Autenticación de
Mensaje

25
▶ El cifrado es un procedimiento criptográfico mediante el que a partir de un
mensaje legible se obtiene un mensaje ilegible de tal forma que se puede
revertir el proceso.
▶ El cifrado simétrico o cifrado de clave simétrica/secreta es aquel en el que se
utiliza una clave para el cifrado del mensaje y la misma clave para el descifrado.
▶ El cifrado asimétrico o cifrado de clave asimétrica/pública es aquel en el que
se utiliza una clave para el cifrado del mensaje y otra clave distinta para su
descifrado. Este par de claves es único, de tal forma que lo cifrado por una se
descifra con la otra (y viceversa) y no con ninguna otra clave.
Cifrado
Clave Secreta Clave Secreta
Clave A Clave B

26
▶ El cifrado RSA funciona con un par de claves complementarias (criptografía
asimétrica), lo que se cifra con la primera solo puede ser descifrado con la
segunda y viceversa.
▶ El concepto clásico es que el titular de las claves conserva una en secreto (clave
privada) y distribuye públicamente la otra (clave pública).
– Si cifra algo con la privada, todo el mundo puede descifrarlo con la pública:
• Así demostramos que el cifrado lo he hecho yo, porque solo yo tengo la
clave privada.
– Si alguien usa la clave pública de otra persona para cifrar algo se asegura que
solo esta puede descifrarlo, puesto que solo ella tiene la clave privada.
▶ El problema de la criptografía con algoritmo RSA es que es computacionalmente
costoso, por lo que solo puede usarse con datos de tamaño reducido.
Cifrado RSA

27
▶ Si unimos una huella digital y un cifrado RSA…
▶ Si unimos en una operación atómica la extracción de la huella digital de un
binario y el posterior cifrado de esta con una clave privada RSA tenemos:
– La operación solo la puedo haber realizado yo, puesto que ha sido hecha con
la clave privada.
– La operación está unívocamente ligada a un fichero binario, puesto que lo que
se cifra es su huella digital.
– Ligado unívocamente a un único documento y a una única persona…
• ¡Una firma electrónica! (O casi)
Firma digital

28
▶ Las firmas electrónicas no son solo una huella digital y un cifrado RSA, sino que
se introducen una serie de estructuras con información adicional.
– Información sobre los algoritmos usados
– Información sobre el firmante
– Información sobre el proceso de la firma (momento, etc.)
▶ En la práctica, estas estructuras pueden ser ASN.1 (CAdES, CMS, PAdES,…) o
XML (XAdES, XMLDSig, ODF,…).
Firmas electrónicas

29
<?xml version="1.0" encoding="UTF-8"?>
<Envelope xmlns="urn:envelope">
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n- 20010315#WithComments"/>
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>
<Reference URI="">
<Transforms>
<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>uooqbWYa5VCqcJCbuymBKqm17vY=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>KedJuTob5gtvYx9qM3k3gm7kbLBwVbEQRl26S2tmXjqNND7MRGtoew==</SignatureValue>
<KeyInfo> <KeyValue> … </KeyValue> </KeyInfo>
</Signature>
</Envelope>
Firmas electrónicas

31
▶ Un par de claves (pública + privada) se empaqueta también junto a otras
estructuras de metadatos en lo que se llama un certificado digital.
▶ Solo existe una variante: ASN.1 (normativa X.509). No hay versión XML.
Certificados electrónicos

32
▶ Certificado autofirmado
– Certificado firmado con su propia clave privada.
▶ ¿Quién nos asegura que ese certificado pertenece a quien dice ser?
▶ Autoridad de certificación (CA)
– Entidad de confianza encargada de la emisión de certificados que establece
las políticas necesarias para garantizar la identidad de los usuarios de sus
certificados.
▶ Cadena de certificación
– Listado ordenado de certificados de clave pública utilizados para la firma del
certificado de usuario.
▶ Certificado Raíz
– Certificado autofirmado de la cadena de certificación.
▶ Certificado de Autoridad intermedia
– Certificado intermedio de la cadena de certificación.
Certificados electrónicos

33
▶ Los certificados se almacenan en almacenes de certificados que pueden estar
cifrados para proteger las claves de usuario y certificados de terceros.
▶ Los sistemas operativos suelen contar con un almacén de sistema al que
cualquier aplicación puede acceder para hacer uso de los certificados que
contiene.
– Windows: CAPI
– Linux: Mozilla
– Apple: KeyChain
▶ Existen distintos formatos de almacenes en disco:
– PKCS#12 (PFX)
– JKS (Java KeyStore)
– BKS (BouncyCastle KeyStore)
Almacenes de claves

34
▶ Es el marco de trabajo para el acceso y desarrollo de funciones criptográficas en
la plataforma Java. Se diseño entorno a los principios:
– Independencia de la implementación:
• La implementación de los distintos proveedores presenta una interfaz
estándar.
– Interoperabilidad entre aplicaciones:
• Una aplicación es dependiente de un proveedor concreto.
– Extensibilidad de algoritmos:
• Es posible agregar nuevos proveedores que aporten compatibilidad con
nuevos algoritmos.
▶ Se dispone de diversos proveedores que proporcionan las distintas funciones
criptográficas para algoritmos concretos.
Java Cryptography Architecture
(JCA)

35
▶ Tipos de proveedores disponibles:
– MessageDigest: Motor para la generación de huellas digitales.
– Keystore: Motor para el acceso y gestión de almacenes de claves.
– Cipher: Motor para el cifrado y descifrado de datos.
– Signature: Motor para la generación y validación de firmas digitales.
– KeyGenerator: Motor para la generación de claves secretas.
– KeyPairGenerator: Motor para la generación de pares de claves asimétricas.
– Mac: Motor para la generación y validación de códigos de autenticación.
– SecureRandom: Motor para la generación de números aleatorios.
– …
Java Cryptography Architecture
(JCA)

36
▶ Según CERES: Es el conjunto de datos en forma electrónica, consignados junto
a otros o asociados con ellos, que pueden ser utilizados como medio de
identificación del firmante.
▶ Según INCIBE: La firma electrónica, como su propio nombre indica, es el
equivalente electrónico de nuestra firma manuscrita. Para resumirlo de forma
sencilla, es un conjunto de datos que nos permiten acreditarnos y cerrar
acuerdos por medios electrónicos, principalmente por Internet. La firma
electrónica se conoce también como firma digital.
▶ Más bien una mezcla: La firma electrónica es un conjunto de datos
electrónicos que declaran la conformidad con otros datos por parte de un
firmante identificado.
▶ En España, desde el año 2003, la firma electrónica tiene el mismo valor a
efectos legales que la firma manuscrita. (LEY 59/2003, del 19 de diciembre,
de firma electrónica)
Firma electrónica

37
▶ La firma electrónica avanzada es la firma electrónica que permite identificar al
firmante y detectar cualquier cambio ulterior de los datos firmados, que está
vinculada al firmante de manera única y a los datos a que se refiere y que ha
sido creada por medios que el firmante puede mantener bajo su exclusivo
control.
▶ Para que una firma electrónica pueda ser considera firma electrónica avanzada,
la ley marca el cumplimiento de los siguientes requisitos:
– La identificación o autenticación de usuarios
– Integridad
– No repudio
– Confidencialidad
Firmas Avanzada

38
▶ Se considera firma electrónica reconocida la firma electrónica avanzada basada
en un certificado reconocido y generada mediante un dispositivo seguro de
creación de firma.
▶ Certificado reconocido es aquel emitido por una autoridad de certificación
reconocida.
▶ Dispositivo de creación de firma es aquel programa o sistema informático que
permite crear una firma electrónica. Este se considera seguro cuando asegura:
– Que la firma no se puede reproducir.
– Que no se pueden obtener los datos utilizados para la generación de la firma.
– Que los datos de creación de firma pueden ser protegidos de forma fiable por
el firmante contra su utilización por terceros.
– Que el dispositivo utilizado no altera los datos antes de la firma.
▶ El dispositivo seguro de creación de firma más común en España es el DNIe.
Firmas Reconocidas

39
▶ Un documento de firma puede contener más de una firma.
▶ En la firma manuscrita también ocurre.
▶ La firma en paralelo (Cofirma) es aquella en la que varios firmantes muestran su
conformidad con unos datos.
– Da igual el orden.
▶ La firma en cascada (Contrafirma) es aquella en la que un firmante muestra su
conformidad con otra firma.
– Aplica a una firma concreta, no a los datos.
Firmas en paralelo y en cascada
Firma Cofirma Contrafirma

40
▶ ¿Se descifra adecuadamente con la clave pública el valor “PKCS#1” de la firma?
▶ ¿Coincide el dato resultante con la huella digital de los datos firmados?
– Es necesario recalcular la huella digital de los datos siempre.
▶ ¿Es el certificado de firma correcto?
– ¿Está dentro de su periodo de validez?
– ¿Está revocado?
• OCSP
• CRL
– ¿Está emitido por una CA de confianza?
▶ ¿Es la estructura general de la firma correcta?
– Formato de firma: XAdES, CAdES, PAdES, etc.
– Firmas adicionales en sub-estructuras internas.
Validación de firmas

41
▶ Los formatos de firma son especificaciones, comúnmente aprobadas como
estándares reconocidos, que definen qué información debe o puede contener
una firma electrónica y el cómo se estructura esa información.
▶ Existen varios formatos de firma electrónica estandarizados. Principalmente se
suelen dividir entre:
– Formatos genéricos: CAdES, XAdES, CMS/PKCS#7,…
– Formatos específicos de documentos: PAdES, OOXML, ODF,…
▶ Paralelamente, también puede diferenciarse entre:
– Formatos binarios: CAdES, CMS/PKCS#7, PAdES…
– Formatos XML: XAdES, OOXML, ODF…
Formatos de firmas electrónica

42
▶ El resultado de la firma es siempre un fichero XML.
▶ Las firmas XML son aptas tanto para ficheros XML como para archivos binarios.
– Los ficheros binarios se codifican en Base64 (representación en un
subconjunto de caracteres ASCII de los datos binarios) para poder ser
insertados en el XML final.
▶ Distintas variantes:
– Enveloping
– Enveloped
– Detached
▶ Varios formatos de firma XML:
– XMLDSig
– XAdES (firmas XML avanzadas)
– ODF (Open Document Format, firmas de documentos OpenOffice.org)
– OOXML (Office Open XML, firmas de documentos MS-Office)
– SOAP (Simple Object Access Protocol, firma de mensajes para servicios Web)
– …
Firmas XML

43
▶ El XML contiene una serie de referencias a los elementos que se desean
firmar electrónicamente.
▶ Del destino de cada referencia, se calcula la huella digital para asegurar
que el contenido se de-referencia intacto.
▶ Finalmente, se firma la combinación de las referencias.
Fundamentos técnicos de las
firmas XML

44
▶ En el siguiente ejemplo, hay una única referencia, que indica que hemos firmado
el fichero http://www.claw.org/doc-a-firmar.xml:
<?xml version="1.0" encoding="UTF-8"?>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-
c14n-20010315"/>
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI="http://www.claw.org/doc-a-firmar.xml">
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue/>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue/>
</ds:Signature>
firmas XML

45
▶ Una firma XML puede contener múltiples referencias, las cuales pueden apuntar
a datos que están dentro del mismo fichero XML o dentro del mismo contexto
XML, pero también que apunten a datos externos accesibles mediante URL
(http/https).
▶ Una firma XML no solo contiene una referencia a los datos que queremos firmar,
sino que también incluye referencias a otros atributos o metadatos, como por
ejemplo:
– Copia de datos del firmante (certificado, clave pública)
– Otros atributos
▶ El Cliente @firma soporta únicamente una referencia a datos a firmar (solo
podemos firmar un dato en cada fichero de firma), e incluye además otras
referencias obligadas por las normativas.
firmas XML

46
▶ En una firma XML Detached, la referencia apunta a unos datos que no están en
el mismo contexto XML que la propia firma electrónica.
▶ Dos posibilidades:
– Los datos no están en el mismo contexto, pero si en el mismo fichero XML:
– Los datos no están en el mismo fichero XML, y son accesibles vía HTTP o
HTTPS:
INTERNALLY DETACHED
EXTERNALLY DETACHED
XML Detached

47
▶ En este caso se inserta una copia de los datos firmados dentro de la
estructura XML de firma:
▶ Si los datos son XML, se insertan directamente, y si no son XML se
convierten antes a Base64.
XML Enveloping

48
▶ En este caso se inserta la estructura XML de firma dentro de los propios
datos, siempre que estos también se encuentren en formato XML.
▶ No es posible usarlo con datos que no estén en formato XML
XML Enveloped

49
▶ ODF
– Los documentos ODF de OpenOffice.org son colecciones de ficheros XML y de
recursos dentro de un contenedor comprimido (ZIP), y se firman con
XMLDSig Detached, pero siguiendo unas pautas específicas.
– El Cliente @firma v3 soporta firmas de documentos ODF (hojas de cálculo,
presentaciones, documentos de texto, etc.) generados con OpenOffice 3 y
superiores o programas equivalentes.
▶ OOXML
– Los documentos OOXML de MS-Office 2007 y superiores son, al igual que los
ODF, colecciones de ficheros de recursos y XML, y se firman igualmente con
XMLDSig Detached.
– El Cliente @firma no soporta firmas de documentos OOXML.
▶ SOAP
– Las firmas SOAP son firmas XMLDSig organizadas siguiendo el esquema
definido por SOAP.
– El Cliente @ firma no soporta firmas SOAP
Variantes de XML

50
▶ Las firmas avanzadas XAdES (XML Advanced Electronic Signature) son firmas
XMLDSig que añaden ciertas referencias adicionales para firmar nuevos
atributos y metadatos.
▶ Distintas variedades:
– BES (Básica)
• Atributos adicionales sobre el firmante, los datos firmados y el proceso de
firma
– T (Timestamped)
• BES + Sello de Tiempo
– C (Completa)
• BES + Referencias a los datos de validación (listas de revocación o
repuestas OCSP)
– X (EXtendida)
• C pero con sellos de tiempo en las referencias a los datos de validación.
Firmas XML Avanzadas: XAdES

51
▶ Distintas variedades (Continuación):
– XL (Longevidad extendida)
• BES + Datos de validación (las listas de revocación o las respuestas OCSP
en sí, y no las referencias a ellas)
– A (Archivo)
• Permite encadenar referencias a sellados de tiempo periódicos (evita la
degradación de la seguridad por obsolescencia)
– EPES (Acorde a política)
• Incluye una referencia a la política que rige el proceso de firma
Firmas XML Avanzadas: XAdES

52
▶ Respecto a XMLDSig, la referencia adicional que se firma tiene este aspecto:
<xades:QualifyingProperties xmlns:xades="http://uri.etsi.org/01903/v1.3.2#" Id="QualifyingProperties"
Target="#Signature" xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<xades:SignedProperties Id="SignedProperties">
<xades:SignedSignatureProperties>
<xades:SigningTime>2010-01-13T10:19:04+01:00</xades:SigningTime>
<xades:SigningCertificate>
<xades:Cert>
<xades:CertDigest>…</xades:CertDigest>
<xades:IssuerSerial>…</xades:IssuerSerial>
</xades:Cert>
</xades:SigningCertificate>
</xades:SignedSignatureProperties>
<xades:SignedDataObjectProperties>
<xades:DataObjectFormat ObjectReference=“#Reference">
<xades:Description/>
<xades:MimeType>text/xml</xades:MimeType>
<xades:Encoding/>
</xades:DataObjectFormat>
</xades:SignedDataObjectProperties>
</xades:SignedProperties>
</xades:QualifyingProperties>
Ejemplo de firma XAdES (BES)

53
▶ Las firmas binarias son en aplicación completamente equivalentes a las firmas
XML, solo que los datos se describen en lenguaje ASN.1 (datos binarios).
– El lenguaje de descripción de datos ASN.1 es en muchos aspectos equivalente
a XML, pero con las siguientes ventajas:
• Ocupa mucho menos espacio
– Menos tiempo y coste en la transmisión de datos
• Es mucho más rápido
– Y los siguientes inconvenientes:
• No es legible por las personas
• No es posible una variante como la Enveloped XML en la que los datos
contengan las firmas, o al menos no de forma genérica.
▶ La normativa más extendida de firma binaria es CMS, una evolución de la más
antigua PKCS#7.
▶ Hay una variante avanzada de CMS: CAdES
▶ Hay usos propietarios de PKCS#7/CMS similares al Enveloped:
– JAR (Sun Microsistems), PE (Microsoft), PDF (Adobe), ZIP (PKWare), etc.
Firmas Binarias

54
▶ Al igual que ocurría con las firmas XML, no solo se firman los datos, sino
también una serie de información y metadatos adicionales.
▶ Se mantiene internamente una lista de elementos a firmar, uno de los
elementos de esta lista apunta a los datos que queremos firmar.
▶ De cada uno de los elementos de la lista se guarda una huella digital, y
finalmente se firma la combinación de huellas digitales.
▶ Es posible omitir o incluir los datos que se firman dentro de la firma resultante:
– Implícita:
• La firma contiene tanto la huella digital de los datos firmados como los
propios datos firmados.
– Explícita:
• La firma contiene únicamente la huella digital de los datos firmados, pero
no estos últimos.
Fundamentos de las firmas
binarias

55
▶ Una firma binaria basada en PKCS#7 (como CMS y CAdES) no funciona con un
modelo de referencias que permite firmar un número arbitrario de binarios en
una única firma individual.
SignedData ::= SEQUENCE {
version CMSVersion,
digestAlgorithms DigestAlgorithmIdentifiers,
encapContentInfo EncapsulatedContentInfo,
certificates [0] IMPLICIT CertificateSet OPTIONAL,
crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,
signerInfos SignerInfos
}
EncapsulatedContentInfo ::= SEQUENCE {
eContentType ContentType,
eContent [0] EXPLICIT OCTET STRING OPTIONAL
}
▶ En resumen: Los campos están prefijados, un único contenido por firma.
Diferencias conceptuales con las
firmas XML

56
▶ CAdES es una especificación de firma pareja a XAdES, y encontramos los
mismos subtipos:
– BES (Básica), EPES (acorde a política), T (con sello de tiempo), A (para
archivo), etc.
▶ El Cliente @firma v3 soporta dos variantes de CAdES:
– BES
• Se añade un atributo sobre el firmante dentro de la lista de elementos a
firmar. Es lo mínimo para considerar una firma CMS como CAdES-BES.
– EPES
• Incluye un atributo que indica el identificador de la política de firma que se
ha aplicado.
• A nivel funcional es exactamente igual a XAdES.
CAdES

57
▶ PDF (Adobe Portable Document Format)
– Las firmas de los documentos PDF son en realidad firmas PKCS#7 incrustadas
en un lugar específico dentro del documento, y que firman una huella digital
que cubre la totalidad del contenido del documento (y deja fuera aspectos
variables).
– El Cliente @Firma soporta firmas PDF usando huellas digitales SHA-512, tal y
como recomienta Adobe PDF v9.
▶ PAdES (Firmas Avanzadas PDF)
– Las firmas PAdES, en su perfil básico (BES), son en realidad firmas PDF
normales realizadas de una forma específica.
– Existen, al igual que con el resto de firmas AdES, más variantes.
Otras Variantes de las Firmas
Binarias (I)

58
▶ PE (Microsoft Portable Executable)
– Las firmas PE son firmas PKCS#7 incrustadas en los ficheros ejecutables de
MS-Windows (EXE).
▶ JAR (Sun Microsystems Java Archive)
– Las firmas de ficheros JAR son directamente firmas PKCS#1 de una lista
textual de huellas digitales de cada uno de los ficheros que hay dentro del
JAR.
▶ ZIP
– De nuevo, las firmas de ficheros comprimidos ZIP consisten en firmas
PKCS#7 (referentes a las huellas digitales de cada uno de los ficheros
contenidos en el ZIP) incrustadas en el binario original.
– El Ciente @Firma no soporta firmas PE ¡Solicitadlo si necesitáis este tipo
de firmas en el Cliente!
• Importante: Si soportáis ZIP en vuestros esquemas de interoperabilidad
plantead que el soporte de firmas ZIP puede ser la opción más natural.
Otras Variantes de las Firmas
Binarias (y II)

59
▶ Si el formatos tiene su propia normativa de firma, debemos usar siempre esa:
– PDF, OOXML, ODF, JAR, PE, ZIP, etc.
▶ ¿Vamos a transmitir directamente la firma por HTTP o en un Servicio Web?
– XAdES Enveloping
▶ ¿Firmamos un XML y necesitamos que el original pueda seguir siendo tratado
normalmente tras la firma?
– XAdES Enveloped
▶ ¿No tenemos ninguna restricción especial?
– CAdES, explícito o implícito
▶ ¿Queremos ligar la firma a un fichero descargable por Internet y que su sitio de
descarga se refleje en esta?
– XAdES Externally Detached
¿Qué formato de firma usar en
cada ocasión?

60
1. Los formatos que el Cliente @firma denomina XML Explícitos, tanto XMLDSig
como XAdES:
1. No se adecúan a ningún estándar en su concepción, por lo que pueden
originar problemas legales.
2. Cualquier firma con algoritmo de huella digital obsoleto:
1. MD2, MD5 e incluso SHA-1 deben ser abandonados a favor de SHA-512.
3. Los formatos simples si pueden ser sustituidos por formatos avanzados:
1. PDF -> PAdES
2. XMLDSig -> XAdES
3. CMS/PKCS#7 -> CAdES
4. XMLDSig/XAdES Externally Detached cuando los datos a firmar no sean
accesibles mediante HTTP/HTTPS o no tengamos garantía de permanencia por
mucho tiempo en sus direcciones Web.
¿Qué formatos de firma no
debemos usar?

61
▶ EPES
– La firma electrónica informa de que esta se ha realizado acorde a una política
de firma.
• ¡Cuidado! No se comprueba que realmente sea así
• La política entera puede empotrarse en la firma
– Versión ASN.1 para firmas CAdES y PAdES
– Versión XML para firmas XAdES
– Las firmas XAdES y CAdES EPES se pueden generar directamente desde el
Cliente @firma (pero no PAdES EPES).
▶ T
– Se incorpora un sello de tiempo a la firma. El sello de tiempo no tiene
necesariamente que significar el momento de la firma, sino que en el
momento del sello la firma ya existía.
– Las firmas T no se generan directamente en el cliente, el sello de tiempo se
puede agregar en un momento posterior al de la firma y se hace en la
plataforma @firma Servidor.
• @firma Servidor no aplica sellos de tiempo a firmas PDF o PAdES.
Firmas Avanzadas

62
▶ C (Completa)
– Incluye referencias a la información de revocación de los certificados (listas
de revocación y/o mensajes OCSP).
– Es realmente poco útil, ya que no se incluye información temporal.
– Es necesario mantener siempre las referencias / enlaces activos.
▶ X (Extendida)
– Es igual que la completa, pero añade sellos de tiempo a las referencias, por lo
que podemos saber en que fecha era válida la información de revocación.
▶ XL (Extendida para largo plazo)
– En vez de referencias a la información de revocación se incluye empotrada
esta información completa, eliminando la necesidad de mantener las
referencias o enlaces activos.
▶ A (Archivo)
– Permite la aplicación periódica de sellos de tiempo para combatir la
obsolescencia de los algoritmos de cifrado y huella digital.
• Por ejemplo, podemos añadir un sello cada año usando siempre los
algoritmos más seguros disponibles.
Firmas Avanzadas

63
▶ La información se cifra con una clave simétrica
▶ Esta clave se incluye en el propio sobre, pero cifrada con una clave asimétrica
(una clave pública de un usuario).
▶ Además, puede incluir una firma electrónica del remitente.
▶ @firma Cliente genera sobres según las siguientes normativas:
– PKCS#7 Enveloped Data
– PKCS#7 Signed and Enveloped Data
• ¡Cuidado! El formato PKCS#7 Signed and Enveloped Data tiene
vulnerabilidades conocidas
– CMS Signed and Authentication Data
Sobres digitales

64
▶ ¿Para qué no son los sobres digitales?
– Para enviar datos a un particular.
• Ciertos dispositivos de almacén de certificados y claves privadas no
soportan la apertura de sobres digitales (DNIe, tarjetas FNMT, etc.).
– Es una restricción intencionada, una pérdida de la tarjeta no debe
ocasionar una pérdida irreparable de datos.
– Para cifrado personal de datos
▶ ¿Para que sí son los sobres digitales?
– Para que los ciudadanos envíen datos y documentos a una entidad.
• ¡Cuidado! Hay que tener ciertas precauciones con la clave privada.
– Mejor si es “de usar y tirar”
– Mejor si se reparte entre varios mediante un algoritmo de secreto
compartido
Sobres digitales

65
▶ Misma clave para cifrar y para descifrar.
▶ Dos tipos principales:
– Modo contraseña (PBE): Cualquier palabra (que no contenga caracteres
especiales como tildes, ‘ñ’, etc.) puede ser la seña para cifrar o descifrar.
– Modo clave: La clave debe seguir un complicado y estricto formato, que es
dependiente del algoritmo de cifrado.
▶ ¿Consejos de uso?
– Uso principal en el cifrado personal de datos.
– ¡Cuidado con la clave!
– Nunca para enviar datos cifrados a una entidad (para eso mejor un sobre).
• No es posible garantizar el envío.
– Envíos personales entre particulares… Pero para esto no debe intervenir una
administración pública.
▶ ¿Qué algoritmo usar?
– AES es siempre una buena opción.
– 3DES es un clásico que aun se mantiene seguro.
Cifrados Simétricos

29/11/2015
Tomás García-Merás
¡Gracias!
tomas.garciameras@atos.net
clawgrip@hotmail.com

67
▶ Tarjeta inteligente:
– https://github.com/ctt-gob-es/jmulticard/
▶ Firma electrónica
– https://github.com/ctt-gob-es/clienteafirma
▶ Todo lo anterior más documentación:
– http://svn-ctt.administracionelectronica.gob.es/svn/clienteafirma/
▶ Integración continua
– http://devel.uji.es/hudson/job/afirma-client/changes
Recursos propios

Programación y uso de tarjetas criptográficas NFC (DNIe, TUI, etc) con Android

Recomendados

Recomendados

Más contenido relacionado

Destacado

Destacado (18)

Similar a Programación y uso de tarjetas criptográficas NFC (DNIe, TUI, etc) con Android

Similar a Programación y uso de tarjetas criptográficas NFC (DNIe, TUI, etc) con Android (20)

Más de Tomás García-Merás

Más de Tomás García-Merás (20)

Último

Último (20)

Programación y uso de tarjetas criptográficas NFC (DNIe, TUI, etc) con Android

Notas del editor