programación y uso de tarjetas criptográficas nfc (dnie, tui, etc) con android
TRANSCRIPT
02/05/2023
Tomás García-Merá[email protected]@hotmail.com
Programación y uso de tarjetas criptográficas NFC (DNIe, TUI, etc) con Android
02/05/2023
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áficasComunicació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 APDURESPONSE APDU
ICCIFD
90B80000070203CC95053621900
0ICCIFD
6
Tarjetas inteligentes criptográficasComunicació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
Tarjetas inteligentes criptográficasComunicación con la tarjeta – ISO 17816-4
▶ 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
Tarjetas inteligentes criptográficasComunicación con la tarjeta – ISO 17816-4
▶ Prueba simple:
Nota: Un comando de respuesta correcta termina siempre en 9000 o en 61xx
9
Tarjetas inteligentes criptográficasComunicación con la tarjeta – ISO 17816-4
▶ 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).
E F E F
D F D F E F
M F
10
Tarjetas inteligentes criptográficasComunicación con la tarjeta – ISO 17816-4
▶ 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
Tarjetas inteligentes criptográficasComunicació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
Tarjetas inteligentes criptográficasComunicación con la tarjeta – IFD è ICC
▶ ¿Cómo le hago llegar un comando a la tarjeta?– 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
Tarjetas inteligentes criptográficasComunicación con la tarjeta – IFD è ICC
▶ ¿Cómo le hago llegar un comando a la tarjeta?– ¿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
Tarjetas inteligentes criptográficas¿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
Tarjetas inteligentes criptográficas¿Qué hay dentro de una tarjeta? ASN.1
▶ 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
Tarjetas inteligentes criptográficas¿Qué hay dentro de una tarjeta? ASN.1
▶ 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
Tarjetas inteligentes criptográficas¿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
Tarjetas inteligentes criptográficas¿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
Tarjetas inteligentes criptográficasConsideraciones 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
02/05/2023
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
30
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
REFERENCIA 1REFERENCIA 2REFERENCIA 3REFERENCIA 4
▶ 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>
Fundamentos técnicos de las 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.
Fundamentos técnicos de las 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 -> PAdES2. XMLDSig -> XAdES3. 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
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