Capítulo II. Estado del arte

Transcripción

1 Capítulo II. Estado del arte 1. Conceptos sobre seguridad y firma digital 1.1 Introducción Uno de los mayores desafíos que se plantean en la utilización de documentos electrónicos es determinar su autenticidad, es decir la capacidad de asegurar si una determinada persona ha manifestado su conformidad sobre el contenido del documento electrónico. Este desafío es resuelto por lo que comúnmente se denomina como firma digital, que se basa en procedimientos criptográficos. Su función respecto de los documentos digitales es similar a la de la firma de puño y letra en los documentos impresos: ser el sello irrefutable que permite atribuir a una persona algo escrito o su conformidad en un documento. El receptor, o un tercero, podrán verificar que el documento esté firmado, sin lugar a dudas, por la persona cuya firma aparece en el documento y que éste no haya sufrido alteración alguna. El sistema de firma digital consta de dos partes: un método que haga imposible la alteración de la firma y otro que permita verificar que la firma pertenece efectivamente al firmante. Como conclusión, se puede decir que la seguridad se basa en cuatro pilares: Confidencialidad: Evitar que un tercero pueda interceptar (leer) la información enviada, si se trata de datos sensibles. Integridad: Evitar que un tercero pueda modificar (insertar, borrar, desordenar,...) la información enviada. Autenticidad: Evitar que una tercera persona pueda suplantar la identidad de la otra parte (fabricar un mensaje falso, replicar uno auténtico,...) No repudio: Evitar que la otra parte pueda negar haber participado en la comunicación (bien como origen o como destino). La herramienta básica de todos los procesos criptográficos y de seguridad es el cifrado. Así, todo mensaje original se puede cifrar aplicándole un determinado algoritmo con una clave de cifrado, obteniendo de esta manera el mensaje cifrado. De manera recíproca es posible descifrar el mensaje original, conociendo el algoritmo y la clave pertinente, como se puede observar en la Ilustración 4: Ilustración 4. Procedimiento de cifrado y descifrado de un mensaje.

2 Desde este punto de vista la criptografía se divide en dos grandes ramas: 1. Criptografía de clave simétrica o privada. 2. Criptografía de clave asimétrica o pública. Ambas técnicas de cifrado se pasan a detallar a continuación. 1.2 Técnicas de criptografía simétrica Este tipo de cifrado se basa en el uso de una única clave, tanto para el cifrado como para el descifrado. Se va a comentar de forma somera ya que para el presente Proyecto el tipo de cifrado que tiene gran relevancia es el de clave pública. La criptografía simétrica [4] se refiere al conjunto de métodos que permiten tener comunicación segura entre las partes, siempre y cuando anteriormente se hayan intercambiado la clave correspondiente, que se denomina clave simétrica. La simetría se refiere a que las partes tienen la misma clave tanto para cifrar como para descifrar. A este tipo de criptografía se conoce también como criptografía de clave privada. Existe una clasificación de este tipo de criptografía en tres familias: la criptografía simétrica de bloques (block cipher). la criptografía simétrica de flujo (stream cipher) la criptografia simétrica de resumen (hash functions). Aunque con ligeras modificaciones, un sistema de criptografía simétrica de bloques puede modificarse para convertirse en alguna de las otras dos formas. La criptografía simétrica ha sido la más usada en toda la historia. Ésta ha sido implementada en diferentes dispositivos manuales, mecánicos, eléctricos, hasta los algoritmos actuales que son programables en cualquier ordenador. La idea general es aplicar diferentes funciones al mensaje que se quiere cifrar de tal modo que solo conociendo una clave pueda aplicarse de forma inversa para poder así descifrarlo. Aunque no existe un tipo de diseño estándar, quizá el más popular es el de Fiestel, que consiste esencialmente en aplicar un número finito de interacciones de cierta forma, que finalmente da como resultado el mensaje cifrado. Este es el caso del sistema criptográfico simétrico más conocido, DES El sistema DES DES (Data Encryption Standard) es un sistema criptográfico que toma como entrada un bloque de 64 bits del mensaje y éste se somete a 16 interacciones, con una clave de 56 bits. En la práctica el bloque de la clave tiene 64 bits, ya que a cada conjunto de 7 bits se le agrega un bit que puede ser usado como de paridad. Dependiendo de la naturaleza de la aplicación DES tiene cuatro modos de operación para poder implementarse: ECB (Electronic Codebook Mode) para mensajes cortos, de menos de 64 bits, CBC (Cipher Block Chaining Mode) para mensajes largos, CFB (Cipher Block Feedback) para cifrar bit por bit ó byte por byte y el OFB (Output Feedback Mode) el mismo uso pero evitando propagación de error. En la actualidad no se ha podido romper el sistema DES desde la perspectiva de poder deducir la clave simétrica a partir de la información interceptada, sin embargo con un método a fuerza bruta, es decir probando alrededor de 256 posibles claves, se pudo romper DES en Enero de Lo anterior quiere decir que, es posible obtener la clave del sistema DES en un tiempo relativamente corto, por lo que lo hace inseguro para propósitos de alta seguridad. La opción que se ha tomado para poder suplantar a

3 DES ha sido usar lo que se conoce como cifrado múltiple, es decir aplicar varias veces el mismo algoritmo para fortalecer la longitud de la clave, esto ha tomado la forma de un nuevo sistema de cifrado que se conoce actualmente como triple-des o TDES El sistema triple-des. El funcionamiento de TDES consiste en aplicar tres veces DES. Utiliza una clave de 168 bits, aunque se ha podido mostrar que los ataques actualmente pueden romper a TDES con una complejidad de 2112, es decir efectuar al menos 2112 operaciones para obtener la clave a fuerza bruta, además de la memoria requerida. Se optó por TDES ya que es muy fácil interoperar con DES y proporciona seguridad a medio plazo. En los últimos 20 años se han diseñado una gran cantidad de sistemas criptográficos simétricos, entre algunos de ellos están: RC-5, IDEA, FEAL, LOKI'91, DESX, Blowfish, CAST, GOST, etc. Sin embargo no han tenido el alcance de DES, a pesar de que algunos de ellos tienen mejores propiedades. Podemos afirmar que el estado actual de la criptografía simétrica es la búsqueda de un nuevo sistema que pueda reemplazar a DES en la mayor parte de aplicaciones. Es así como se ha optado por convocar a un concurso de sistemas criptográficos simétricos y que se decida cual será el nuevo estándar al menos para los próximos 20 años El sistema AES El NIST (National Institute of Standards Technology) convocó a un concurso para poder tener un sistema simétrico que fuese seguro y puediera usarse al menos en los próximos 20 años como estándar. En el concurso resultaron cinco finalistas: MARS, RC6, Rijndael, Serpent y Twofish. Las principales características que se pidió a AES (Advanced Encryption Standard) es que al menos fuese tan seguro y rápido como TDES, es decir, que al menos evitase los ataques conocidos; además de que puediera ser implementado en una gran parte de aplicaciones. AES puede ser usado tanto como cifrador de bloques (block cipher), como cifrador de flujo (stream cipher), como función resumen (hash function), y como generador de números pseudoaleatorios. El elegido por AES fue el propuesto por Rijndael. Los cifradores de flujo o stream ciphers, son usados donde se cuenta con un ancho de banda restringido (el número de bits que se transmiten a la vez), además de que se requiere independencia en los bloques transmitidos. Entonces la mejor opción es cifrar bit por bit o byte por byte. Este tipo de cifradores tiene la característica además de ser muy rápido. Los algoritmos más conocidos de este tipo son RC-4, SEAL y WAKE. Como colofón a estos ejemplos de algoritmos de cifrado de clave simétrica, hay que resaltar que es muy crítico en estos sistemas el hecho de la distribución de la clave, ya que es única y debe conocerla tanto el emisor como el receptor de la comunicación. Para solucionar este problema se inventaron los sistemas de clave asimétrica o pública, como se verá en el siguiente apartado. Además, el NIST en su documento del pasado mes de Agosto de 2007 [5] considera que para 2011, los cifrados simétricos con seguridades de 80 bits en la clave, estarán fuera de juego al menos para la identificación personal, y los sistemas deberán haber migrado a una seguridad equivalente a 112 bits o hacia cotas más elevadas aún. 1.3 Técnicas de criptografía asimétrica Introducción Hasta 1976, que fue el año en que Diffie y Hellman propusieron esta nueva técnica criptográfica, lo que se tenía era el cifrado simétrico convencional basado en sencillas operaciones de sustitución y permutación (o combinaciones de estas), y su problemática del intercambio de la única clave para cifrado y descifrado. Los criptógrafos Diffie y Hellman revolucionaron en su momento con una aproximación totalmente nueva dentro del campo de las técnicas criptográficas. Originalmente idearon este nuevo sistema como un

4 mecanismo para el intercambio de la clave simétrica por el consabido problema que tiene, aunque como se verá, para el interés de este Proyecto, la aplicación más importante de la técnica de cifrado con clave pública será la firma digital. El fundamento de esta técnica consiste en que se utilizan dos claves diferentes, una para cifrar y otra para descifrar. En este punto se debe aclarar una cuestión, y es que la criptografía asimétrica no necesariamente es de clave pública, pero sí en el sentido contrario de la expresión. Por ejemplo el algoritmo de encriptación de Pohlig Hellman es asimétrico pero no posee información pública. Dicho esto, conviene aclarar que en adelante se utilizarán ambas expresiones indistintamente, como sinónimas, ya que en más de un 90% de los casos se tratan con algoritmos asimétricos y públicos (como el más importante para este Proyecto, el RSA) La siguiente figura ilustra de forma conceptual lo dicho anteriormente: Ilustración 5. No todos los algoritmos asimétricos son de clave pública. [6] Descripción de los sistemas de clave pública Como se ha dicho anteriormente, estos algoritmos de cifrado asimétrico utilizan un par de claves diferentes en la comunicación, una para cifrar y otra para descifrar. Ambas claves están matemáticamente relacionadas entre sí y es prácticamente imposible deducir una a partir de la otra. El par de claves se genera según el algoritmo de cifrado asimétrico que se utilice, quedando una como secreta (privada) y otra como conocida para terceros (clave pública). Ilustración 6. Esquema de comunicación en un sistema de clave asimétrica.

5 En la Ilustración 6 se observa a modo de compendio lo dicho previamente. El mensaje en claro es encriptado con la clave privada/pública y sólo su pareja (pública/privada) puede descifrarlo. La seguridad de este sistema se basa en la imposibilidad de calcular una clave a partir de la otra, además, claro está, de mantener la clave privada en secreto. En la figura también se tienen los componentes fundamentales del sistema criptográfico de clave pública, que se pasa a analizar a continuación: Claves pública (KU) y privada (KR). Pareja de claves seleccionadas por los participantes de la comunicación, estos son el emisor y el receptor. Cada algoritmo de cifrado determina cómo son esas claves y su proceso de selección. Una permanecerá oculta (privada) y otra se hará pública. Una descifra lo que la otra cifra, y es recíproco. Texto en claro o mensaje a enviar (X). Es el mensaje o los datos de entrada. Algoritmo de cifrado (E). Realizará las operaciones o transformaciones matemáticas sobre el texto en claro. Dependerá de la clave (habitualmente la privada) que recibe como entrada el algoritmo. Texto cifrado (Y). Es el mensaje producido como consecuencia de efectuar las operaciones de cifrado sobre el texto en claro X. Depende del texto en claro y de la clave de cifrado, entonces para un mensaje dado, dos claves distintas producirán dos cifrados distintos. Algoritmo de descifrado (D). Realiza las transformaciones (operaciones matemáticas) sobre el texto cifrado con la clave pública 1 que recibe como entrada. Con estos componentes, las condiciones que debe verificar todo algoritmo de clave pública son las siguientes (según Diffie y Hellman) [7]: 1. Debe ser computacionalmente fácil para cada parte generar un par de claves (pública / privada). 2. Debe ser computacionalmente fácil para un emisor cifrar un mensaje, conociendo la clave pública del receptor y el mensaje. Esto es lo que se conoce como funciones unidireccionales (one-way functions). Y = E KUB [X] 3. Debe ser computacionalmente fácil para el destino descifrar un texto cifrado conociendo la clave privada. La inversión de lo hecho por la función unidireccional es sencilla si se conoce cierta información adicional (la clave privada). Esto es posible ya que las funciones unidireccionales tienen una puerta trampa secreta (trap-door). X = D KRB [Y] = D KRB [E KUB [X]] 4. Debe ser computacionalmente impracticable para un oponente determinar la clave privada conociendo la clave pública. 5. Debe ser computacionalmente impracticable para un oponente determinar el mensaje original a partir de la clave pública y del texto cifrado. 6. Cualquiera de las 2 claves puede usarse para cifrar, y la otra para descifrar: M = D KRB [E KUB (M)] = D KUB [E KRB (M)] 1 Habitualmente, aunque también sería válido con la privada si se cifró con la pública.

6 Tras citar brevemente las condiciones que enumeraron Diffie y Hellman para los sistemas asimétricos, se van a analizar algunos ataques que podrían pensarse como factibles en el entorno de seguridad del cifrado de clave pública. Y es que aunque un sistema de cifrado con clave asimétrica cumpla esos requisitos, como todo sistema de seguridad, puede ser vulnerable a los ataques por fuerza bruta (como en el cifrado simétrico). Como solución a este posible problema se tiene el uso de claves largas, de 512 o 1024 bits. No obstante surge un problema adicional, y es que, al estar el sistema basado en el uso de funciones invertibles, la clave debe ser grande para evitar ataques por fuerza bruta como se ha comentado anteriormente; pero también debe ser lo suficientemente pequeña como para permitir que las operaciones de cifrado y descifrado se realicen de una forma eficiente. Otro ataque posible, que surge siempre que se habla de la relación matemática que existe entre las claves pública y privada, consiste en poder encontrar una a partir de la otra. No se ha probado que matemáticamente sea imposible de realizar este tipo de ataque, si bien los algoritmos de cifrado asimétrico están diseñados para que sea un problema computacionalmente costosísimo. Por todo esto se puede decir que no es comprometido para la seguridad este tipo de ataques. Por último, citar el ataque conocido como de mensaje probable que es exclusivo de los métodos asimétricos. El ataque consiste en que dado un mensaje corto, esto es de pocos bits de longitud (56 bits p. ej.), un oponente podría descifrar el mensaje original encontrando aquel que coincida con el texto cifrado transmitido, ya que no importa la longitud de la clave puesto que sería un ataque por fuerza bruta de 56 bits. Si bien parece realizable, es muy sencilla su solución ya que los algoritmos añaden bits aleatorios cuando los mensajes son simples El algoritmo RSA Si hay que destacar un algoritmo de entre todos los que existen en los criptosistemas de clave pública, el que mayor interés tiene para este Proyecto y para el mundo de la Firma Digital, ése es sin duda el RSA del que se puede decir que es el estándar de facto. Es el más usado y también el más sencillo de entender e implementar, y debe su nombre a sus tres inventores: Ronald Rivest, Adi Shamir y Leonard Adleman, que lo publicaron por primera vez en Ha estado bajo patente de los Laboratorios RSA hasta el año 2000 por lo que su uso comercial estuvo restringido hasta esa fecha. Antes de comenzar con el análisis del algoritmo RSA, se procede a comentar algunos algoritmos de clave pública que también tienen cierto interés [8]: Algoritmo de Rabin. Publicado en 1979 por Michael O. Rabin; este criptosistema basa su seguridad, al igual que RSA, en la complejidad de la factorización. Sin embargo, la ventaja del criptosistema de Rabin es que se ha demostrado que la complejidad del problema en el que se basa es tan duro como la factorización de enteros, cosa que se desconoce si es cierto en el caso del RSA simple. El inconveniente que tiene es que cada salida de la función de Rabin puede ser generada por 4 posibles entradas, y si cada salida es un texto cifrado se requiere un tiempo extra en el descifrado para identificar cual de las 4 posibles entradas era el correcto texto en claro. Algoritmo DSA (Digital Signature Algorythm). Es un estándar del gobierno federal de los Estados Unidos de América para firmas digitales. DSA se hizo público en 1991y sirve tan solo para firmar y no para cifrar información. Además, una desventaja de este algoritmo es que requiere mucho más tiempo de cómputo que RSA. Algoritmo de ElGamal. Se basa en problemas matemáticos de algoritmos discretos y cuya seguridad se fundamenta en la suposición de que la función utilizada es de un sólo sentido y la dificultad de calcular un logaritmo discreto es elevada. El procedimiento de cifrado y descifrado está basado en cálculos sobre un grupo cíclico cualquiera (G), lo que lleva a que la seguridad del algoritmo dependa de la dificultad de calcular logaritmos discretos en G.

7 Algoritmos de Curva Elíptica (EC). Es una variante de la criptografía asimétrica. Se basa en las matemáticas de las curvas elípticas. Sus autores argumentan que la Criptografía de Curvas Elítpicas puede ser más rápida y puede usar claves más cortas que los métodos anteriores, como RSA, al tiempo que proporcionan un nivel de seguridad equivalente. Su fundamento matemático se basa en que una curva elíptica puede ser descrita mediante la expresión: y 2 = x 3 + ax + b, y con el conjunto de puntos G que forman la curva (i.e., todas las soluciones de la ecuación más un punto O, llamado punto en el infinito) más una operación aditiva de suma, se forma un grupo conmutativo. Si las coordenadas x e y se escogen desde un campo finito, entonces estamos en presencia de un grupo abeliano o conmutativo finito. El problema del logaritmo discreto sobre este conjunto de puntos se cree que es más difícil de resolver que el correspondiente a los campos finitos. De esta manera, las longitudes de claves en criptografía de curva elíptica pueden ser más cortas con un nivel de seguridad comparable. La utilización de curvas elípticas en criptografía fue propuesta de forma independiente por Neal Koblitz y Victor Miller en Retomando el algoritmo RSA, como ya se ha indicado, se basa en la dificultad que presenta la factorización de números grandes. Los mensajes enviados usando el algoritmo RSA se representan mediante números y el funcionamiento se basa en el producto de dos números primos grandes (mayores que ) elegidos al azar para conformar la clave de descifrado. El método emplea expresiones exponenciales en aritmética modular y su seguridad radica en que no hay maneras rápidas de factorizar un número grande en sus factores primos utilizando computadores convencionales. A continuación se va a proceder a explicar el funcionamiento básico del algoritmo [9]: 1. Generación del par de claves. El usuario que desea generar sus claves privada y pública elige 2 números primos grandes p y q (con gran cantidad de cifras decimales). Esos dos números primos se multiplican entre sí y se tiene el número N, que será público. N = pq A ese número N, se le aplica la función phi de Euler: φ(n) = (p-1) (q-1) Tras ello, se elige otro número e que no tenga factores en común con φ(n). El número e también es público. Con él se obtiene otro número d que cumple que ed 1 módulo φ(n), esto es, el inverso de e en la aritmética módulo φ(n). Y este número d, es privado. Una vez hecho lo anterior, ya se tiene el par de claves generado. Siendo N y e la clave pública y p, q y d la clave privada. Cada usuario del sistema deberá seguir esos pasos para obtener un par de claves asociadas a su identidad. 2. Cifrado y descifrado de mensajes. Si ahora al usuario que ha generado el par de claves anterior se le desea enviar un mensaje que sólo pueda leer él, se debe conocer primero su clave pública (N,e) que por ser pública no compromete su seguridad. El mensaje que se desea transmitir tiene un equivalente en código numérico (normalmente binario) que se nombra como m. Entonces se calcula el número m e módulo N y se envía.

8 El usuario cuya clave pública es (N,e) recibe m e (módulo N), y con su clave secreta (privada) toma de ella el número d y calcula, siempre módulo N, lo siguiente: (m e ) d = m ed y como e y d son números inversos módulo φ(n), el resultado es m, el mensaje original que se quería enviar. 3. Seguridad del algoritmo. En los años 60 se podían factorizar de manera relativamente sencilla números de unas 40 cifras decimales. A finales de los 80, el récord estaba en unas 100 cifras. A lo largo de los 90 se han llegado a factorizar números cada vez más grandes: en 1994 cayó el sistema RSA129 (clave de 129 cifras decimales) y dos años después, el RSA130. También han caído otros como el RSA-576, en Actualmente la empresa RSA ofrece una recompensa de dólares por encontrar la factorización del sistema RSA-2048, de 617 cifras decimales como se observa en la ilustración 7: Ilustración 7. Si se consigue factorizar un número como este, RSA recompensa con $. En este sentido hay que destacar que una de las ventajas de RSA con respecto a otros criptosistemas, es que el tamaño de las claves no es fijo, es decir que a medida que pueda comprometerse la factorización de los módulos RSA empleados (incluso con el desarrollo de nuevos dispositivos hardware), se puedan elegir claves de longitudes mayores que mantengan la seguridad del criptosistema. En los años 80 la recomendación habitual era usar claves de 512 bits; mientras que hoy día se recomiendan claves de 768 bits para usuarios, de 1024 bits para empresas y organismos, y de 2048 bits para Autoridades de Certificación. En la siguiente tabla se puede observar la complejidad computacional que conllevaría el intento de factorizar los números que se manejan en este algoritmo, lo que hace que la seguridad sea elevada, si bien también implica que a mayor longitud de claves, mayor tiempo de cálculo en el algoritmo.

9 Tamaño clave (en bits) Nº total operaciones (Tiempo total) Tamaño base factores Memoria para criba Memoria para reducción matriz 428 5, Kb 24 Mb 128Mb 465 2, ,2 Mb 64 Mb 825 Mb 512 1, Mb 128 Mb 2 Gb 768 1, Mb 10 Gb 160 Gb , ,5 Gb 256 Gb 10 Tb Tabla 1. Comparativa de los recursos necesarios para factorizar módulos de varios tamaños. [10] Aplicaciones de los sistemas de clave pública Como colofón, hay que resaltar las aplicaciones más importantes de la criptografía de clave pública: Confidencialidad en la comunicación. El origen puede cifrar el mensaje con la clave pública del destino. Así solo lo puede leer el que posea la clave privada asociada a esa clave pública, o lo que es lo mismo, el receptor deseado. Distribución de claves. Se utiliza el cifrado para negociar una clave de sesión entre las partes. Así esta clave de sesión se puede enviar cifrada con la clave pública de la otra parte para que no haya compromiso en la distribución. Firma Digital. El origen firma un mensaje con su clave privada. Es la aplicación más importante para este Proyecto, y la que se va a ampliar a continuación. 1.4 La Firma Digital Generalidades Dentro del ámbito de los criptosistemas de clave pública se encuentra una aplicación fundamental de los mismos, la Firma Digital. Como se ha dicho en el apartado anterior, el algoritmo RSA es reversible. Esto es que además de permitir el cifrado con la clave pública y descifrar el mensaje con la privada, también permite cifrar con la clave privada y descifrar con la pública. Este último modo de cifrado no da confidencialidad ya que cualquiera puede descifrar el mensaje original al poder obtener siempre la componente pública del interlocutor, sin embargo el hecho de poder cifrar un mensaje con la clave secreta de un usuario implica una identificación inequívoca (así se consigue la autenticidad y el no repudio), ya que solo con la clave asociada a su identidad es posible descifrarlo, al igual que lo hace una firma manuscrita; por lo que este proceso se conoce como Firma Digital. Una Firma Digital consta básicamente de tres partes: 1. Generación del par de claves, la privada (con la que se firmará) y la pública (con la que se verificará por parte de un tercero). Esta generación de claves se hace de acuerdo a un algoritmo concreto, como el que se ha visto anteriormente: el RSA. 2. Firma del documento. Dado un mensaje, con la clave privada se firma dicho mensaje.

10 3. Verificación de la firma, por parte de un tercero. Dada la firma y la clave pública, otro usuario podrá validar la firma Funciones resumen Uno de los requisitos que debe cumplir toda firma digital es que se debe basar en el contenido del documento y debe ser distinta para cada documento firmado. Como el coste computacional de los algoritmos de clave pública es medianamente elevado, al firmar una gran cantidad de datos, cuando un mensaje es grande, podría conllevar que la Firma Digital se realizase de forma extremadamente lenta. Por todo esto, lo que se hace para firmar un documento es que se aplica sobre el mismo una función unidireccional de resumen (funcion hash) para obtener un valor hash, que no es más que un resumen del documento. De esta manera, para obtener la firma digital, se cifra o encripta el valor hash con la clave privada del firmante. La creación de la firma digital se lleva a cabo a través de un algoritmo que combina los caracteres que conforman la clave privada con los caracteres del documento resumido. Las funciones de resumen o hash sirven para comprimir un texto o documento en un bloque de longitud fija. Las ventajas de su utilización en el proceso de la firma digital son varias: No tener que cifrar todo el texto en los servicios de autenticación y Firma Digital, ya que, como se ha dicho anteriormente, este proceso puede ser lento en los algoritmos asimétricos. Para comprobar la integridad de un documento, ya que si ha sido dañado o modificado durante la transmisión o la recepción el resumen del documento recibido jamás coincidirá con el descifrado. Por mínimo que sea el cambio realizado, aunque solo sea un bit, el resultado de aplicar la función de resumen debe variar completamente; como así lo atestigua la siguiente tabla: Valor del mensaje Valor Hash Juan Yuan Tabla 2. Ejemplo de variación del hash de dos mensajes muy similares Las funciones hash deben ser públicas e irreversibles, es decir, que a partir del resumen no se pueda recuperar el texto original. No cifran, solo comprimen textos o documentos en un bloque de longitud fija, sea cual sea la longitud del documento a resumir como se observa en la ilustración 8: Ilustración 8. Las funciones de resumen siempre obtienen a un bloque de longitud constante. [11] Normalmente ese bloque de longitud fija consta de 160 bits, que serán más manejables para los propósitos de Firma Digital que todo el documento.

11 Las funciones de hash más conocidas e implementadas actualmente son las siguientes: DES, MD5, SHA-1 y RIPEMD 160, siendo el algoritmo SHA-1 el más conocido y usado para Firmas Digitales (en este Proyecto es el que se usa) y por ello se procede a comentar. La familia SHA (Secure Hash Algorithm, Algoritmo de Hash Seguro) es un sistema de funciones hash criptográficas relacionadas de la Agencia de Seguridad Nacional de los Estados Unidos y publicadas por el NIST. El primer miembro de la familia fue publicado en 1993 es oficialmente llamado SHA. Sin embargo, hoy día, de forma extraoficial se le llama SHA-0 para evitar confusiones con sus sucesores. Dos años más tarde el primer sucesor de SHA fue publicado con el nombre de SHA-1. Desde entonces, existen cuatro variantes más que se han publicado y cuyas diferencias se basan en un diseño algo modificado y rangos de salida incrementados: SHA-224, SHA-256, SHA-384, y SHA-512 (llamándose SHA- 2 a todos ellos). En 1998, un ataque a SHA-0 fue encontrado pero no fue reconocido para SHA-1, se desconoce si fue la NSA (National Security Agency) quien lo descubrió pero aumentó la seguridad del SHA-1. El algoritmo de hashing SHA-1 ha sido examinado muy de cerca por la comunidad criptográfica pública, y no se ha encontrado ningún ataque efectivo. No obstante, en el año 2004, un número de ataques significativos fueron divulgados sobre funciones criptográficas de hash con una estructura similar a SHA- 1; lo que ha planteado dudas sobre la seguridad a largo plazo de SHA-1. Este algoritmo produce una salida resumen de 160 bits de un mensaje que puede tener un tamaño máximo de 2 64 bits, y se basa en principios similares a los usados por el profesor Ronald L. Rivest en el diseño de los algoritmos de resumen de mensaje MD4 y MD Generación y verificación de una Firma Digital Como se ha citado anteriormente, la Firma Digital, gracias a los algoritmos criptográficos asimétricos, permite reemplazar a la firma tradicional sobre el papel, ya que ofrece las características de: Integridad del documento. Esto se consigue mediante las funciones de hashing. Si el documento fue modificado durante la transmisión, la verificación de la firma resultará fallida. Identidad y autenticidad. Sólo una clave pública asociada al usuario que firmó con su clave privada es capaz de desencriptar la Firma Digital correctamente. No repudio. El usuario que firmó no podrá negar su autoría en la Firma Digital. Así pues, cuando un usuario desea enviar un documento firmado a su interlocutor, el proceso que sigue para generar la Firma Digital y anexionarla al documento (al igual que las manuscritas) es el siguiente: 1. A partir del documento original, le aplica al mismo una función de resumen (hash) utilizando un algoritmo conocido, como por ejemplo el SHA-1. Como resultado de la operación, se obtendrá un resumen del documento de 160 bits. 2. El resumen del documento, también conocido como hash o huella digital, procede a encriptarse o cifrarse mediante la clave privada del usuario, y según un algoritmo de cifrado asimétrico, como puede ser el RSA. 3. A esa cadena de bits, que procede del cifrado de la huella digital, es a lo que se conoce como Firma Digital, y se anexiona al mensaje o no según el tipo de firma que se desee. Como resumen y para ilustrar estos pasos, se muestra la siguiente figura:

12 Ilustración 9. Proceso de generación de una Firma Digital. Con el documento firmado, el emisor (usuario que desea enviar la Firma Digital) procede a transmitirlo por alguna red de datos, como puede ser Internet. Al pasar por la red y en la recepción, el documento podría verse alterado o modificado, bien por ataques de terceros o simplemente por errores en la transmisión. No obstante la Firma garantiza la integridad de los datos y su autenticidad, por lo que estos errores se harían patentes durante el proceso de verificación de la firma, que se detalla a continuación: 1. Para verificar la Firma Digital, el receptor lo primero que hace es separar el contenido no cifrado (documento original) de la Firma propiamente dicha. 2. Una vez se aísla la Firma Digital del documento, el receptor procede a calcular el hash del documento recibido según el algoritmo utilizado (en este caso el SHA-1). Como resultado obtiene 160 bits. 3. Ahora se procede a calcular el descifrado de la Firma recibida con la clave pública del emisor, y según el mismo algoritmo asimétrico con que se cifró (RSA en este caso). Así se obtiene una cadena de160 bits que deberían coincidir con la huella digital calculada en el paso anterior. 4. Si coinciden ambos, la verificación es correcta: el documento fue firmado por el emisor y sin que los datos fueran corrompidos. Hay que destacar que la Firma Digital no implica confidencialidad de los datos, ya que el propio mensaje viaja en claro por la red, lo que se cifra es el resumen pero no por motivos de confidencialidad sino por los propósitos de integridad, autenticidad y no repudio que son los fundamentos de la Firma Digital. Si se desease dotar al documento firmado de confidencialidad, se podría realizar mediante el cifrado de dicho documento con la clave pública del receptor, ya que de esta forma sólo él sería capaz de descifrarlo con su clave privada, gracias a las propiedades de los criptosistemas asimétricos. A continuación, en la Ilustración 10, se pueden ver de manera esquemática los pasos para la comprobación de una Firma Digital:

13 Ilustración 10. Proceso de verificación de una Firma Digital Formatos de Firma Una Firma Digital puede realizarse de diferentes maneras, y según la manera en que se conforme se corresponde con uno de los formatos existentes. Hay dos normas fundamentales de la ETSI (European Telecommunications Standards Institute) de Firma Digital: la TS y la TS [12]. Esta clasificación se realiza según la sintaxis en la que se realice la firma, la primera de las normas se corresponde con la sintaxis ASN.1 y la segunda con XML. Aunque para este Proyecto solo tendrá relevancia el formato que se especifica en la TS , se comenta brevemente la otra norma. Dentro de las firmas con sintaxis XML podemos distinguir a su vez dos: XMLDSig. Es el formato de mayor expansión dentro de las XML puesto que es usado frecuentemente en aplicaciones de Internet. Es bastante similar funcionalmente al CMS (Cryptographic Message Syntax) pero la codificación original de firmas y certificados se realiza en Base64. XAdES. Siglas del inglés XML Advanced Electronic Signatures (Firma electrónica avanzada XML), es un conjunto de extensiones a la recomendación de XMLDSig, que la hacen adecuada para la realización de firma electrónica avanzada. Todo esto se relaciona en el sentido de la directiva de la Unión Europea 1999/93/EC de firma electrónica reconocida. La nomenclatura y otros aspectos legales en lo que concierne a la Firma Digital se detallarán en el apartado posterior de Ley de Firma electrónica en España. A continuación se detallan los formatos de firma con sintaxis ASN.1, de gran importancia en este Proyecto ya que es el que se implementará en el desarrollo de la aplicación. En este sentido hay que decir que este es el formato tradicional de la Firma Digital, con referencia en el estándar RFC 3852 del IETF (Internet Engineering Task Force) basado en el grupo de estándares PKCS#7 (Public-Key Cryptographic Standars) de los laboratorios RSA. El estándar PKCS#7 tiene su evolución en el CMS aunque son prácticamente idénticos y además existe total compatibilidad entre ambos, por lo que se tratarán de forma conjunta. PKCS#7 / CMS. Es un estándar utilizado para firmar y/o cifrar mensajes en Infraestructura de Clave Pública (PKI). La referencia es el estándar CMS elaborado a partir de los estándares del

14 IETF RFC 2360 y RFC A veces también es usado para la distribución de certificados como respuesta a un mensaje PKCS#10 de solicitud de certificado. Se trata de un formato de encapsulamiento normalmente codificado en ASN.1, aunque también puede ser codificado en Base64. CMS permite incluir diferentes firmantes en la firma bajo dos modalidades: encadenada y mancomunada. La firma propiamente dicha es un compendio de datos formales referidos al tipo de firma así como de atributos firmados y no firmados bajo una estructura dada. La estructura de una Firma realizada en formato CMS es la siguiente: Tabla 3. Estructura de una Firma Digital con formato PKCS#7/CMS. [13] Como se observa en la tabla del formato CMS, se incluyen ciertos campos en los que se indica información adicional a la firma propiamente dicha. Algunos de estos datos son: el tipo de contenido que alberga la firma, la fecha y la hora de la firma, etc. Esto es común a todos los formatos de firma, incluidos los de sintaxis XML, y entre ellos tenemos las siguientes modalidades según el contenido de la Firma Digital: Firma básica. Es la firma que se ha explicado anteriormente, por recapitular hay que decir que es la resultante de practicar al documento original la operación de hashing y cifrar esa huella digital con la clave privada del firmante. A su vez puede ser: o Attached. Si la firma y los datos están juntos en un mismo fichero. Pudiendo ser esta agrupación de tipo envolvente (si la firma contiene a los datos que se firman) o envuelta (si los datos que se firman contienen a la propia Firma Digital). o Detached. Si la Firma Digital se encuentra separada del contenido que se ha firmado; esto es, en archivos distintos. Firma fechada. A la firma básica se le añade un sello de tiempo calculado a partir del hash del documento. Firma validada o completa. A la firma fechada se le añade información sobre la validez del certificado procedente de una consulta realizada a la Autoridad de Certificación pertinente, de este modo se libera al receptor de la firma del problema de ubicar al

15 prestador de los servicios de certificación y de determinar los procedimientos de validación disponibles. Estos tipos tienen su correspondencia en la sintaxis del PKCS#7/CMS con los siguientes tipos de datos: Data. Solo datos, utilizado para enviar datos sin encriptar. SignedData. Datos firmados, usado para autentificación del remitente. Es cualquier tipo de datos que estén firmados por uno o varios firmantes mediante un resumen de los datos y su posterior encriptación utilizando la clave privada de cada firmante sobre el hash de los datos, a esta encriptación del resumen es a lo que se llama Firma Digital. El resumen del mensaje encriptado y otra información específica del remitente se agrupan en un campo del objeto llamado SignerInfo. EnvelopedData. Datos juntos, o envueltos, que pueden ser datos o datos firmados o datos encriptados o varios de ellos a la vez, utilizados para comunicación confidencial. Signed-and-enveloped Data. Datos firmados y envueltos. Garantizan autenticidad y confidencialidad. DigestedData. Datos resumidos para comprobar la integridad del mensaje. EncryptedData. Datos encriptados, utilizados para confidencialidad. 1.5 La infraestructura de clave pública Introducción Una infraestructura de clave pública [14] (public-key infrastruture, PKI) es un conjunto de aplicaciones y de servicios que nos permite utilizar la criptografía de clave pública (certificados y Firma Digital) de una forma fácil y efectiva. Se puede ver también bajo el punto de vista de que se trata de una combinación de hardware y software, políticas y procedimientos de seguridad que permiten la ejecución con garantías de operaciones criptográficas como el cifrado, la firma digital o el no repudio de transacciones electrónicas. El término PKI se utiliza para referirse tanto a la autoridad de certificación (AC) y al resto de componentes, como para referirse, de manera más amplia y a veces confusa, al uso de algoritmos de clave pública en comunicación electrónicas. Este último significado es incorrecto, ya que no se requieren métodos específicos de PKI para usar algoritmos de clave pública. PKI se basa en la criptografía de clave pública, ya que las propiedades de que goza dicho sistema, cuyo uso más común se plasma en la Firma Digital, la convierten en candidata ideal para prestar esos servicios ya citados como la autenticación de usuarios, el no repudio, la integridad de la información, y el acuerdo de claves secretas para garantizar la confidencialidad de la información intercambiada. Ahora bien, cómo se puede estar seguro de que la clave pública de un usuario, que ha sido encontrada por ejemplo en un directorio o una página web, corresponde realmente a ese individuo y no ha sido falsificada por otro? Por qué una clave pública puede ser de fiar? La solución más ampliamente adoptada consiste en recurrir a una tercera parte de confianza, erigida en la figura de una autoridad de certificación La función básica de una AC reside en verificar la identidad de los solicitantes de certificados, crear los certificados y publicar listas de revocación (Certificate Revocation Lists, CRL) cuando éstos son inutilizados. El certificado contiene de forma estructurada información acerca de la identidad de su titular, su clave pública y la AC que lo emitió. Por lo tanto una infraestructura de clave pública se puede utilizar para: Gestión de claves. Permite crear, revisar o revocar claves, así como gestionar niveles de confianza.

16 Publicación de claves. Una vez creadas las claves, PKI permite difundir la clave publica de un usuario, así como localizar las claves publicas de otros usuarios, junto con su estado (clave revocada, etc). Utilización de claves. Una vez recuperada una clave, PKI facilita el uso de la misma. De todo lo dicho anteriormente se puede inferir que la criptografía de clave pública, de por sí, no basta si deseamos reproducir en un mundo electrónico las condiciones del comercio tradicional basado en el papel. También necesitamos políticas de seguridad para definir las reglas según las cuales deben funcionar productos para generar, almacenar y gestionar las claves; y procedimientos para establecer cómo generar, distribuir y emplear las claves y certificados. La PKI proporciona el marco de acción para un amplio conjunto de componentes, aplicaciones, políticas y prácticas para combinar y obtener las cuatro funciones principales de seguridad (autenticidad, integridad, no repudio y confidencialidad) para transacciones comerciales. Al igual que cualquier tecnología nueva y crítica para el negocio, la evaluación e implementación de una solución PKI es un proceso complicado e intrincado, que requiere una buena planificación, gestión y unas directrices claras El Certificado Digital Un certificado es un documento emitido y firmado digitalmente por una Autoridad de Certificación que asocia el nombre distintivo de una persona física o entidad con su clave pública durante un periodo de tiempo. Son documentos digitales que sirven para asegurar la veracidad de la clave pública perteneciente al propietario del certificado o de la entidad, con la que se firman digitalmente documentos que puedan proporcionar las más absolutas garantías de seguridad. En definitiva, los certificados digitales son el equivalente digital del DNI, en lo que a la autentificación de individuos se refiere, ya que permiten que un individuo demuestre que es quien dice ser, es decir, que está en posesión de la clave privada o secreta asociada a su certificado. Para los usuarios proporcionan un mecanismo para verificar la autenticidad de programas y documentos obtenidos a través de la red, el envío de correo encriptado y/o firmado digitalmente, el control de acceso a recursos, etc. Como se ha dejado ya entrever, los certificados digitales sólo son útiles si existe alguna Autoridad Certificadora que los valide, ya que si uno se certifica a sí mismo no hay ninguna garantía de que su identidad sea la que anuncia, y por lo tanto, no debe ser aceptada por un tercero que no lo conozca. Es importante ser capaz de verificar que una autoridad certificadora ha emitido un certificado determinado, y detectar si un certificado no es válido. Para evitar la falsificación de certificados, la entidad certificadora después de autentificar la identidad de un sujeto, firma el certificado digitalmente. De esta forma, los certificados digitales proporcionan un mecanismo criptográfico para implementar la autentificación; como también proporcionan un mecanismo seguro y escalable para distribuir claves públicas en comunidades grandes y potencialmente inseguras. Existen varios formatos de certificados, siendo el más extendido el X.509 versión 3. Este formato es un estándar del ITU-T (International Telecommunication Union-Telecommunication Standarization Sector) y el ISO/IEC (International Standards Organization / International Electrotechnical Commission) que se publicó por primera vez en El formato de la versión 1 fue extendido en 1993 para incluir dos nuevos campos que permiten soportar el control de acceso a directorios. Después de emplear el X.509 v2 para intentar desarrollar un estándar de correo electrónico seguro, el formato fue revisado para permitir la extensión con campos adicionales, dando lugar al X.509 v3, publicado en El formato de certificados X.509 se especifica en un sistema de notación denominado sintaxis abstracta uno (Abstract Syntax One o ASN.1). Para la transmisión de los datos se aplica el DER (Distinguished Encoding Rules o reglas de codificación distinguible), que transforma el certificado ASN.1 en una secuencia de octetos apropiada para la transmisión en redes reales. En la Tabla 4 se muestra la estructura básica de un certificado digital X.509 :

17 Versión Número de serie del certificado Identificador del algoritmo de firmado Nombre del emisor Periodo de validez Nombre del sujeto Información de la clave pública del sujeto Identificador único del emisor Identificador único del sujeto Extensiones Firma del certificado por la entidad emisora (AC) Tabla 4. Estructura de un certificado X.509. [15] Esos campos en detalle significan lo siguiente: Versión. El campo de versión contiene el número de versión del certificado codificado. Los valores aceptables son 1, 2 y 3. Número de serie del certificado. Este campo es un entero asignado por la autoridad certificadora. Cada certificado emitido por una CA debe tener un número de serie único. Identificador del algoritmo de firmado. Este campo identifica el algoritmo empleado para firmar el certificado (como por ejemplo el RSA o el DSA). Nombre del emisor. Este campo identifica la Autoridad de Certificación que ha firmado y emitido el certificado. Periodo de validez. Este campo indica el periodo de tiempo durante el cual el certificado es válido y la AC está obligada a mantener información sobre el estado del mismo. El campo consiste en una fecha inicial, la fecha en la que el certificado empieza a ser válido y la fecha después de la cual el certificado deja de serlo. Nombre del sujeto. Este campo identifica la identidad cuya clave pública está certificada en el campo siguiente. El nombre debe ser único para cada entidad certificada por una CA dada, aunque puede emitir más de un certificado con el mismo nombre si es para la misma entidad. El campo de sujeto (subject), que contiene los datos que identifican al sujeto titular, está expresado en notación DN (Distinguished Name), donde un DN se compone a su vez de diversos campos siendo los más frecuentes los siguientes: CN (Common Name), OU (Organizational Unit), O (Organization) y C (Country). Un ejemplo para identificar un usuario mediante el DN, es el siguiente: CN=JOSE PEREZ LOPEZ, O=FNMT, OU=FNMT Clase2 CA, C=ES. Información de clave pública del sujeto. Este campo contiene la clave pública, sus parámetros y el identificador del algoritmo con el que se emplea la clave.

18 Identificador único del emisor. Este es un campo opcional que permite reutilizar nombres de emisor. Identificador único del sujeto. Este es un campo opcional que permite reutilizar nombres de sujeto. Extensiones. Las extensiones del X.509 v3 proporcionan una manera de asociar información adicional a sujetos, claves públicas, etc. Un campo de extensión tiene tres partes: o Tipo de extensión. Es un identificador de objeto que proporciona la semántica y el tipo de información (cadena de texto, fecha u otra estructura de datos) para un valor de extensión. o Valor de la extensión. Contiene el valor actual del campo. o Indicador de importancia. Es una bandera que indica a una aplicación si es seguro ignorar el campo de extensión si no reconoce el tipo. El indicador proporciona una manera de implementar aplicaciones que trabajan de modo seguro con certificados y evolucionan conforme se van añadiendo nuevas extensiones. El ITU y el ISO/IEC han desarrollado y publicado un conjunto de extensiones estándar en un apéndice al X.509 v3. Estas extensiones son: o Limitaciones básicas. Este campo indica si el sujeto del certificado es una AC y el máximo nivel de profundidad de una ruta de certificación a través de esa AC. o Política de certificación. Este campo contiene las condiciones bajo las cuales la AC emitió el certificado y el propósito del certificado. o Uso de la clave. Este campo restringe el propósito de la clave pública certificada, indicando, por ejemplo, que la clave solo se debe usar para firmar, para la encriptación de claves, para la encriptación de datos, etc. Este campo suele marcarse como importante ya que la clave solo está marcada para un propósito y utilizarla para otro no estaría validado en el certificado. Firma Digital del Certificado. Se trata de la corroboración electrónica por la que la Autoridad de Certificación asegura la vinculación de una identidad con el certificado presente. En realidad la firma consta de una secuencia de campos que se corresponde con la firma digital de todos los campos previos. Esta secuencia contiene tres atributos, el algoritmo de firma utilizado, el hash de la firma, y la propia firma digital en sí, realizada con la clave privada de la AC. Por último, comentar las extensiones típicas de archivo que se pueden presentar los certificados digitales de usuario X.509, ya que algunos pueden contener la clave pública y privada, o bien tenerlas por separado. Así pues según su formato de almacenamiento se tiene lo siguiente: Extensión Tipo Descripción.CER.DER.PEM Certificado codificado en CER Certificado codificado en DER Certificado codificado en Base64 CER: Canonical Encoding Rules. Norma ITU: X.690 DER: Distinguished Encoding Rules. Norma ITU: X.690. Es un certificado DER encerrado entre las sentencias BEGÍN

19 Base64 CERTIFICATE y END CERTIFICATE.P7B (Ver.P7C) - -.P7C Estructura PKCS#7 Estructura SignedData sin el tipo Data. Tan solo el certificado y/o la CRL..PFX (Ver.P12) - -.P12 Certificado PKCS#12 Evolución de PFX (Personal information exchange). Utilizado para aunar en un único fichero las claves pública y privada con protección por contraseña. Tabla 5. Extensiones de los archivos de Certificados Digitales. [16] Componentes de la Infraestructura La Infraestructura de Clave Pública es el marco subyacente que permite que las tecnologías y criptosistemas de clave pública se puedan implantar de un modo extenso, proporcionando la base de confianza imprescindible para la correspondencia electrónica entre aquellos usuarios que no pueden intercambiar manualmente sus claves. Por lo tanto, mediante la administración de los certificados de claves públicas de una PKI, se puede establecer y mantener un entorno de red seguro, posibilitando el uso de servicios de cifrado y, especialmente, de Firma Digital en una amplia gama de aplicaciones. En entornos reales, especialmente en aquellos que involucran a una gran diversidad de empresas y comunidades de usuarios que trabajan de forma conjunta, encontramos el problema de cómo estructurar las relaciones entre las entidades de los diversos dominios involucrados. De todo esto se desprende que una Infraestructura de Clave Pública es una combinación de productos de hardware y software, políticas y procedimientos; como ya se dijo en el apartado introductorio. La PKI ofrece la seguridad básica requerida para llevar a cabo negocios electrónicos de forma que los usuarios, que no se conocen entre sí, o están muy alejados entre sí, pueden comunicarse con seguridad a través de una cadena de confianza. La PKI se basa en identidades digitales, que son los certificados digitales, que actúan como "pasaportes electrónicos", y vinculan la firma digital del usuario a su clave pública. La implantación de estos servicios de seguridad en redes supone un coste añadido, tanto en elementos adicionales e incremento de tráfico en la red como en requerimientos para las entidades que participan de estos servicios, ya sea a costa de hardware específico adicional o a costa de capacidad de cálculo de su procesador. La infraestructura de clave pública debe estar compuesta por los siguientes elementos: Política de seguridad. Una política de seguridad establece y define la dirección de máximo nivel de una organización sobre seguridad de información, así como los procesos y principios para el uso de la criptografía. Por lo general, incluye declaraciones sobre cómo gestionará la empresa las claves y la información valiosa, y establecerá el nivel de control requerido para afrontar los niveles de riesgo. Declaración de práctica de certificados (Certificate Practice Statement). Algunos sistemas de PKI se gestionan mediante Autorizadores de Certificados Comerciales (CCA) o Terceras Partes Seguras, y, por lo tanto, requieren de CPS.

20 Autoridad de Certificación. Una autoridad de certificación es una entidad o servicio que emite certificados. El sistema de ACs es la base de confianza de una Infraestructura de Clave Pública, ya que gestiona los certificados de clave pública durante toda su vida. La cuestión que surge de esto es que si la Autoridad Certificadora avala los datos del certificado de los usuarios, quién avala a la autoridad Certificadora?. Para resolver esto se han creado una serie de entidades autorizadas a emitir certificados, de tal forma que éstas a su vez son avaladas por otras entidades de mayor confianza, hasta llegar a la cabeza de la jerarquía, en la que figuran unas pocas entidades de reconocido prestigio y confianza, que se autofirman su certificado (llamado certificado raíz). Cada certificado emitido por una AC debe estar firmado por una AC de mayor grado en el esquema jerárquico de autoridades certificadoras, formándose así una cadena de certificados, en los que unas AC se avalan a otras hasta llegar a la AC superior, que se certifica a sí misma. La jerarquía de firmas y la cadena con ella formada están contempladas en el estándar X.509 v3, que indica la forma correcta de realizar estas cadenas de certificaciones. En resumen se puede decir que las autoridades de certificación emiten certificados vinculando la identidad de un usuario o sistema a una clave pública con una firma digital, programan las fechas en la que expiran los certificados y garantizan que los certificados se revocan cuando sea necesario, publicando listas de revocación de certificados (CRL). La Ilustración 11 muestra estos niveles de confianza entre autoridades de certificación: Ilustración 11. Jerarquía de autoridades de certificación. Para terminar la descripción de las autoridades de certificación, se citan algunas de las AC comerciales más importantes y reconocidas: - Thawte Consulting. Proveedor internacional de certificados digitales. - VeriSign. Una de las primeras Autoridades certificadoras que se creó. Proporciona tanto certificados de cliente como de servidor. - Belsing. Principal proveedor europeo de certificados digitales. - GTE CyberTrust. AC norteamericana.

21 - Certisign Certification Digital Ltda. Autoridad de certificados brasileña. - Safelayer. Autoridad española privada certificadora, se encarga de la seguridad en los correos electrónicos y de mensajería de la OTAN (Organización del Tratado Atlántico Norte). - Camerfirma. Servicio de certificación digital de las cámaras de comercio, industria y navegación de España. - Dirección General de la Policía. El Ministerio del Interior, a través de la Policía, ejerce como Autoridad de Certificación para la expedición del certificado contenido en el nuevo DNI electrónico. - Fábrica Nacional de Moneda y Timbre (FNMT) y Real Casa de la Moneda (RCM). La FNMT se erige como la autoridad certificadora más extendida entre la Administración española, con sus casi dos millones de certificados expedidos 2. Autoridad de Registro. Con el paso del tiempo, una autoridad de certificación puede verse fácilmente desbordada si cubre un área geográfica muy extensa o la zona a la que presta sus servicios está muy poblada, por lo que a menudo delega en las llamadas autoridades de registro (AR) las función de verificar la identidad de los solicitantes del certificado digital. Las AR pueden abrir multitud de oficinas regionales dispersas por un gran territorio, llegando hasta los usuarios en los sitios más remotos, mientras que la AC se limitaría así a certificar a todos los usuarios aceptados por las AR dependientes de ella. Gracias a esta descentralización se agiliza el proceso de certificación y se aumenta la eficacia en la gestión de solicitudes. En definitiva, una infraestructura de clave pública incluirá una o varias autoridades de registro para certificar la identidad de los usuarios; una o varias autoridades de certificación que emitan los certificados digitales; un repositorio de certificados, accesible vía web u otro medio, donde se almacenen los certificados; las listas de revocación de certificados (CRL), donde se listan los certificados suspendidos o revocados; y, por supuesto, los propios certificados. Sistema de distribución de certificados. El sistema de distribución puede ser variado, será uno u otro en función de la estructura PKI que se utilice. Por ejemplo, los certificados pueden publicarse en un servidor de directorio mientras que la lista de certificados revocados puede estar en un servidor de validación Ventajas e inconvenientes de la PKI Como conclusión a este apartado de infraestructura de clave pública, se muestran las ventajas e inconvenientes y debilidades que se presentan cuando se habla de todo lo relacionado con la PKI. Entre sus puntos favorables se puede decir que las claves no viajan a través de la red desde el cliente al servidor, dado que los certificados constituyen información pública. También ofrece mejores medios para identificar al usuario ya que los certificados contienen información verificable relacionada con la identidad del usuario, lo cual no ocurre en la autenticación basada en otros mecanismos existentes. Los certificados basados en tecnología de clave pública proveen un mecanismo de autenticación muy fuerte, puesto que sólo el usuario que lo posee conoce la forma de acceder a su clave privada. Y como en un futuro próximo se espera, la simplificación de la Administración (convirtiendo la mayoría de trámites en trámites online) y con ello, la disminución de costos. 2 En su página web (cert.fnmt.es) a día 21/08/08 se contabilizaban certificados expedidos.

22 A pesar de todos los puntos favorables que se han comentado, también ofrece algunos puntos de vista problemáticos, que sin duda son mucho menores a los puntos positivos. Entre estos aspectos se citan algunos como la falta de interoperabilidad, ya que el mero hecho de ceñirse al estándar X.509 v3 no garantiza en absoluto que dos certificados generados por dos sistemas desarrollados por casas distintas sean mutuamente compatibles. El coste ha sido un problema desde el principio ya que al no existir un mercado suficientemente maduro en la PKI, cada empresa que ofrece soluciones de clave pública tarifica en función de criterios diversos (por certificado, por uso de certificado, por servidores instalados,...), de manera que la inversión en PKI puede resultar elevada. Finalmente, para dar un impulso definitivo a la tecnología PKI que signifique el despegue de las transacciones electrónicas y la e-administración, hay que tener muy en cuenta que al usuario final se le antoja un tanto esotérica, que no terminan de entender del todo la jerga relacionada ni su funcionamiento concreto. El usuario tradicional está acostumbrado a autenticarse sin más que introducir su nombre y contraseña, y por ello puede sentirse fácilmente rebasado por la complejidad tecnológica de las firmas digitales y demás funciones criptográficas. 2. Tecnologías actuales Como ya se comentó en la introducción de este Proyecto, el desarrollo de la Firma Digital en los dispositivos móviles es un punto clave en la expansión del comercio electrónico ya que proporciona confianza y seguridad al sistema. En los últimos años, han sido desarrolladas diferentes tecnologías e infraestructuras con el objetivo de implementar estos sistemas de firma digital móvil. Existen algunos sistemas basados en tarjetas SIM (subscriber identity module módulo de identidad del abonado), otros trabajan sobre el middleware del terminal móvil y proveedores criptográficos, y finalmente también existen esquemas que son independientes de una tecnología móvil concreta y hacen que la firma digital móvil esté proporcionada por los proveedores de las aplicaciones. De todo esto se deduce que existe un amplio rango de soluciones y sistemas posibles para implementar la firma digital en un terminal móvil, que serán descritos en los sucesivos apartados. 2.1 Basadas en Tarjetas Inteligentes Hoy día, las tarjetas SIM son tarjetas multiaplicación, en las cuales múltiples aplicaciones funcionan al mismo tiempo, además de ser por supuesto el núcleo de las comunicaciones móviles por representar a la identidad de un abonado. Cada aplicación posee su funcionalidad y alguna de ellas puede ofrecer el servicio de Firma Electrónica. Como se puede observar en la Ilustración 12, una tarjeta inteligente SIM (el resto de tarjetas inteligentes, Smartcard, también) tiene dos tipos de memoria: la ROM y la EEPROM, que se detallan a continuación:

23 Ilustración 12. Arquitectura de una tarjeta SIM multiaplicación. [17] En la memoria ROM se encuentra la capa física que incluye el sistema operativo de la tarjeta, el sistema de gestión de la memoria, así como la interfaz de entrada / salida. Cercano a ellos, se observa la máquina virtual JavaCard, que es la intérprete para las aplicaciones. El gestor de la tarjeta (Card Manager) controla el ciclo de vida de cada aplicación, el SIM Toolkit Security añade cabeceras de seguridad a los mensajes cortos y varias APIs (Application Programming Interface) para los desarrolladores. En esta zona de memoria también se encuentra la aplicación GSM que ha sido estampada en la tarjeta por el fabricante y no puede ser borrada. En la memoria EEPROM es donde se encuentran las diferentes aplicaciones. Esta zona de memoria sí que puede ser controlada y modificada durante el ciclo de vida de la tarjeta SIM. La aplicación GSM controla las comunicaciones con la red GSM y almacena los ficheros, que se puedan generar durante esas comunicaciones, en la EEPROM. Esos ficheros contienen las claves de la red GSM, los contactos y la agenda, los mensajes cortos (SMS), etc. Los applets USAT son unas aplicaciones desarrolladas con tecnología SAT (SIM Application Toolkit), como por ejemplo el intérprete USAT. Y por último, el módulo WIM otorga la posibilidad de realizar las funcionalidades criptográficas en la propia tarjeta SIM Servicio de mensajes cortos El servicio de mensajes cortos (Short Message Service, SMS) es un servicio que se encuentra disponible en prácticamente el cien por cien de los teléfonos y terminales móviles. Mediante este servicio existe la posibilidad de autenticar y cifrar la comunicación con el uso de paquetes de seguridad. Estos paquetes son unas cabeceras especiales, llamadas security headers, que se añaden a los datos de usuario o de las aplicaciones. La aplicación que desea enviar los datos, los prepara y los manda a la entidad de la tarjeta SIM encargada para el propósito de comunicaciones GSM, que es quien añade esas cabeceras y envía el SMS. De este modo, en el teléfono receptor, la entidad de la tarjeta SIM toma el SMS y lo analiza según lo indican las cabeceras security headers. Desde el punto de vista de la Firma Digital, estas cabeceras de seguridad contienen 3 elementos básicos: El indicador de parámetros de seguridad (Security Parameter Indicator, SPI). Encargado de codificar en 2 octetos el tipo de operación criptográfica. El indentificador de clave (Key identifier, KID). Codifica en 1 byte la clave y el algoritmo utilizado. Los 4 primeros bits codifican el algoritmo, entre una de estas 2 opciones: DES o Triple- DES. Los últimos 4 bits indican la clave usada en el proceso de encriptación. La Firma Digital (Digital Signature, DS). Contiene la firma digital de los datos, y se almacena en una cantidad variable de bits. Este mecanismo fue la primera aproximación para conseguir la firma electrónica, en cuanto a las especificaciones de la tarjeta SIM se refiere; no obstante presentaba numerosos inconvenientes. Para comenzar tan solo pueden realizarse procesos criptográficos simétricos, y además depende exclusivamente del fabricante de la tarjeta la creación y el grabado en ella de las claves simétricas. Por último, el servicio SMS proporciona un pequeñísimo ancho de banda que solo permite el envío de unos pocos bytes por cada mensaje. Podría pensarse que para solucionar este problema sería conveniente el empleo de los MMS (Multimedia Message Service)ya que permiten transportar una gran cantidad de bytes, pero a cambio de pagar por la conexión GPRS/UMTS; y además la mensajería MMS está soportada por el propio terminal móvil, no por la tarjeta SIM.

24 2.1.2 Desarrollo de aplicaciones SIM La tecnología para el desarrollo de aplicaciones para la tarjeta SIM (SAT) define un completo juego de comandos y eventos entre la tarjeta SIM 2G y un teléfono GSM. Esto facilita enormemente el desarrollo de nuevos servicios basados en las tarjetas inteligentes como la SIM, independientes de los fabricantes de teléfonos y de las tarjetas. Estas aplicaciones, alojadas en la propia tarjeta SIM, son capaces de mostrar diferentes elementos en un menú del terminal móvil y así interactuar con el usuario. También podrían establecer procesos dentro del teléfono, como comenzar una llamada de teléfono o enviar un SMS. En las 2 ilustraciones siguientes se puede observar el escenario usual de intercambio de comandos (se llaman comandos proactivos) entre una tarjeta SIM y el dispositivo móvil. La segunda de las ilustraciones muestra de un modo más amigable una comunicación entre una aplicación desarrollada con SAT y el terminal: Ilustración 13. Modelo de comunicación SAT.[17] Ilustración 14. Comunicación entre una SIM Application y el terminal móvil. [18] La tecnología SAT está presente en una gran cantidad de los teléfonos y terminales móviles existentes en la actualidad, y su evolución es la Universal-SAT (U-SAT), para los teléfonos de 3ª generación. Aun así, los principios y los conceptos son muy similares a los de la primera versión, lo único que cambia es que existe la posibilidad de abrir conexiones HTTP desde los comandos proactivos. Una aplicación SAT es normalmente un applet para JavaCard. Esta tecnología ha significado un importante avance en el campo del desarrollo de aplicaciones basadas en tarjetas SIM. Entre las ventajas que ofrece está el entorno seguro de ejecución, la posibilidad de desplegar diferentes applets en la misma tarjeta, y el uso de APIs específicas: JavaCard API y la SIM Toolkit API. Estas soluciones son interesantes de cara al mundo de la Firma Digital, pero presentan diferentes problemas como la lentitud en la generación de las claves y el proceso de seguridad; y además las claves presentan un grave riesgo de seguridad ya que no tienen protección hardware especial dentro de la tarjeta y podrían visualizarse.

25 2.1.3 Módulo de identidad inalámbrico El módulo de identidad inalámbrico (Wireless Identity Module, WIM) es una especificación de seguridad de la OMA (Open Mobile Alliance) que define como almacenar y gestionar las credenciales criptográficas, éstas son: las claves simétricas y asimétricas, el certificado de usuario y de terceras partes de confianza y objetos de autenticación, como por ejemplo el PIN (Personal Identification Number). También se define cómo debe ser y realizarse la Firma Digital en una tarjeta SIM de forma segura. Esa forma segura, se refiere al hecho de que exista cierta protección por hardware para hacer que la extracción de información sensible sea inviable a menos que lo desee el usuario. El estándar WIM se basa en el PKCS#15, que habilita un formato flexible de información para un elemento de seguridad. El módulo WIM está definido en una aplicación independiente en la SmartCard, como lo son los applets GSM o SAT. Este módulo puede ser utilizado para realizar operaciones criptográficas con diferentes protocolos y algoritmos, e interaccionar con otras aplicaciones de la tarjeta, como por ejemplo las SAT. Una tarjeta SIM, con módulo WIM en su interior, puede considerarse un elemento seguro ya que el par de claves se genera dentro de la tarjeta y los procesos de firma se realizan en el propio módulo. Así la clave privada nunca saldría de la tarjeta. Por todas estas razones, una firma generada en una tarjeta WIM sería totalmente válida y segura, y es por ello por lo que esta tecnología se considera como una de las fundamentales para la expansión de la firma digital en el mundo móvil. Actualmente todos los fabricantes están incluyendo este módulo en las tarjetas SIM. 2.2 Basadas en el dispositivo móvil Existen diferentes tecnologías móviles como los sistemas operativos Symbian y Windows Mobile, y Java MicroEdition (J2ME), que permiten realizar todos los procesos de Firma Digital en un terminal móvil Sistema Operativo Windows Mobile Este sistema operativo es el desarrollado por Microsoft para los dispositivos móviles y constituye la base para el desarrollo de dos tipos de plataformas: Pocket PC y Smartphone. Un Pocket PC es una PDA (Personal Digital Assistant, Asistente Digital Personal), es decir un ordenador de tamaño bolsillo; y un Smartphone está más orientado a funcionalidades como teléfono móvil, aunque también con grandes capacidades para datos. El sistema criptográfico de Microsoft se compone fundamentalmente de varios componentes: aplicaciones, sistema operativo y algunos proveedores de servicio criptográfico (CSP Cryptographic Service Providers). Las aplicaciones se comunican con el sistema operativo a través de la API criptográfica, llamada CryptoAPI (CAPI), y el sistema operativo se comunica con los CSP a través de la interfaz CSP (CryptoSPI), como se muestra en la ilustración 15:

26 Ilustración 15. Arquitectura de Seguridad de Windows Mobile. [17] Como se observa, la CAPI trabaja con varios CSP. Un CSP es un módulo independiente que contiene implementaciones criptográficas de varios algoritmos y estándares de autenticación, cifrado, almacenamiento de claves y firma digital. En la CryptoAPI se indican las siguientes funciones: generación e intercambio de claves, encriptación y desencriptación de datos, codificación y decodificación de certificados, creación y verificación de firmas digitales y cálculo de hash. El sistema operativo ofrece mecanismos para la generación y almacenamiento de claves, gestión de certificados y realización de operaciones criptográficas a través de la CryptoAPI y tres CSP predefinidos: Proveedor RSA Base, Proveedor RSA mejorado, y el proveedor para DSS (Digital Signature Standard) y Diffie-Hellman. A pesar de esta característica, a veces se requiere el uso de librerias criptográficas externas para el desarrollo de nuevos CSP y para mejorar las funciones de la CryptoAPI. Así pues, el desarrollo de nuevos CSP permite una fácil incorporación de dispositivos seguros, para firma electrónica y generación y almacenamiento de claves, como son las tarjetas inteligentes (smartcards). Existen en el mercado lectores para tarjetas inteligentes compatibles con Windows Mobile, que se conectan mediante las interfaz de entrada / salida (SDIO Secure Digital Input Output) o Bluetooth. Por tanto, este es un método alternativo para el manejo seguro de las claves privadas. La firma obtenida puede ser tanto en PKCS#1 como en PKCS#7 / CMS, por ello se trata de una buena alternativa para las soluciones de firma digital en dispositivos móviles. Como conclusión, decir que Windows Mobile tiene una robusta arquitectura de seguridad que permite soportar todo el ciclo de vida de la firma electrónica, pero se restringe al uso de PDA y Smartphones que poseen este sistema operativo Sistema operativo Symbian Este sistema operativo ha sido desarrollado exclusivamente para terminales móviles y su código se proporciona a los principales fabricantes de teléfonos como Nokia, SonyEricsson y Motorola entre otros. Este sistema ha sido desarrollado durante los últimos años y su última versión anunciada en 2007 es la v9.5. En lo que a aspectos de seguridad respecta, entre sus numerosas características, destaca que proporciona importantes funcionalidades relacionadas con la autenticación, y confidencialidad e integridad de datos. También hay que resaltar los mecanismos seguros de instalación de aplicaciones, que permiten mediante firma digital de software la autorización y autenticación durante su proceso de instalación.

27 Otro aspecto positivo es que permite la gestión de certificados con un módulo criptográfico, y la implementación de algoritmos estándares criptográficos, funciones hash, generación de claves y de números aleatorios. Estas funciones no pueden ser usadas directamente, pero sí a través de otros módulos como el de gestión de certificados. En la ilustración 16, se muestra la arquitectura de seguridad del sistema Symbian, que consiste primordialmente en 2 grandes niveles de componentes. Uno es el de gestión de certificados, cuyo propósito es el de almacenar y recuperar certificados, asignación de un nivel de confianza a un certificado de una aplicación, construcción y validación de la cadena de certificados y verificación de la confianza de un certificado. El otro componente es un elemento criptográfico cuyas tareas se han comentado en el párrafo anterior. Ilustración 16. Arquitectura de Seguridad de Symbian. Estos módulos son la base para un gran número de componentes de más alto nivel, que incluyen una interfaz de usuario para gestión de certificados, instalación de software con autenticación mediante firmas digitales, y comunicaciones seguras (SSL/TLS, WTLS, IPSec, etc.). De una forma parecida a Windows Mobile, Symbian define un elemento de seguridad que permite la posibilidad de integrar dispositivos criptográficos como WIM. A pesar de todos los puntos a favor que presenta Symbian para generar firmas digitales, también hay que mencionar ciertos inconvenientes como que su uso está limitado a los teléfonos que tienen este sistema operativo, y además el acceso a los elementos necesarios para desarrollar aplicaciones criptográficas está restringido Java Mobile Edition La empresa Sun Microsystems lanzó a mediados de los años 90 el lenguaje de programación Java que, aunque en un principio fue diseñado para generar aplicaciones que controlaran electrodomésticos como lavadoras, frigoríficos, etc, debido a su gran robustez e independencia de la plataforma donde se ejecutase el código, desde sus comienzos se utilizó para la creación de componentes interactivos integrados en páginas Web y programación de aplicaciones independientes. Estos componentes se denominaron applets y casi todo el trabajo de los programadores se dedicó al desarrollo de éstos. Con los años, Java ha progresado enormemente en varios ámbitos como servicios HTTP, servidores de aplicaciones, acceso a bases de datos, etc. Como se observa en la ilustración 17, Java se ha ido adaptando a las necesidades tanto de los usuarios como de las empresas ofreciendo soluciones y servicios tanto a unos como a otros. Debido a la explosión tecnológica de estos últimos años Java ha desarrollado soluciones personalizadas para cada ámbito tecnológico. Sun ha agrupado cada uno de esos ámbitos en una edición distinta de su lenguaje Java. Estas ediciones son Java 2 Stantard Edition, orientada al desarrollo de aplicaciones independientes y de applets, Java 2 Enterprise Edition, enfocada al entorno empresarial y Java 2 Micro Edition, orientada a la programación de aplicaciones para pequeños dispositivos. En esta última edición de Java es en la que se centra el análisis siguiente.

28 Ilustración 17. Plataforma Java 2 de Sun Microsystems. [19] Java ME, previamente conocida como Java 2 Platform Micro Edition o J2ME, es una tecnología para el desarrollo de aplicaciones Java en terminales móviles como teléfonos y PDA. Java ME consiste en especificaciones de programación y una máquina virtual especial que permite que un programa Java ME pueda ser ejecutado en un dispositivo móvil. Los servicios JavaME se basan en programas locales, llamados MIDlets, que el usuario puede descargar e instalar en su terminal. Los MIDlets pueden ser ejecutados localmente en el dispositivo o también establecer sesiones cliente-servidor. Existen dos configuraciones para Java ME: Configuración para dispositivos con conexión limitada. Conocida como CLDC (Connected Limited Device Configuration), define un conjunto de interfaces de programación y una máquina virtual Java (Java Virtual Machine- JVM), la KiloByte Máquina Virtual (KVM) para pequeños dispositivos como teléfonos móviles y PDA. Configuración para disposivos conectados. Conocida como CDC (Connected Device Configuration), extiende las funcionalidades de CLDC y define una nueva máquina virtual, la CVM (Compact Virtual Machine), para trabajar en dispositivos con mayores capacidades como dispositivos embebidos, PDA de gama alta, etc. Estas configuraciones ofrecen un conjunto de funcionalidades comunes para un tipo determinado de teléfonos, y sobre estas existen perfiles que añaden una capa adicional a la configuración, ofreciendo APIs para cada tipo específico de dispositivo. Existen 4 perfiles estandarizados: Mobile Information Device Profile (MIDP) para CLDC. Personal Basis Profile, Personal Profile y Foundation Profile para CDC. La siguiente ilustración muestra la arquitectura de Java ME:

29 Ilustración 18. Arquitectura de Java Mobile Edition. [20] Si se centra el estudio en el perfil MIDP, ya que está orientado principalmente a teléfonos móviles, (aunque existe una implementación para PalmOS y PocketPC, por lo que es también utilizable en casi cualquier PDA), hay que comentar que los perfiles son una especificación publicada y desarrollada bajo el proceso comunitario Java (Java Community Process). La JSR 37 (para MIDP 1.0) y JSR 118 (para MIDP 2.0). En 2007, el perfil 3.0 se comenzó a desarrollar bajo la especificación JSR 271. Los primeros terminales MIDP se lanzaron comercialmente en abril de MIDP 1.0. Tan solo implementa las API del núcleo, que son las siguientes: o Javax.microedition.lcdui. Contiene todos los métodos necesarios para manejar el Display, de hecho su nombre (liquid cristal display user interface) así lo refleja. Un único elemento llamado Displayable permanece siempre activo. Esta API proporciona un pequeño conjunto de elementos que se pueden sacar por la pantalla del dispositivo como son: List, Alert, TextBox, Form y Canvas. Todos estos elementos están controlados por la implementación MIDP del terminal. o Javax.microedition.rms. Su nombre proviene de sistema de gestión de almacenamiento (Record Management System) y proporciona una manera de tener almacenamiento persistente en los sistemas Java ME. o Javax.microedition.midlet. Los MIDlet son las aplicaciones Java realizadas usando la especificación de MIDP, además, y ya que en el desarrollo del presente proyecto fin de carrera será implementada una aplicación mediante un MIDlet, es necesario comentar que un MIDlet es una aplicación que estará compuesta, al menos, por una clase principal que hereda directamente de la clase javax.microedition.midlet.midlet. MIDP 2.0. Añade API más específicas como las de multimedia y más paquetes opcionales. Entre las nuevas funcionalidades se encuentra la posibilidad de poder establecer conexiones HTTP y HTTPS, el manejo de imágenes como matrices de enteros, manejo de órdenes sobre línea serie, mejoras en Form y en Item, y lo que más interesa para este Proyecto: la mejora en la seguridad gracias a las API de javax.microedition.pki. El desarrollo de una aplicación para Java ME sigue varios pasos, que podemos esquematizar de la siguiente manera [21]:

30 1. Edición del código fuente. Consiste en la programación en Java propiamente dicha. Se suele utilizar algún entorno de desarrollo que facilite la labor. Entrando someramente en la programación, hay que destacar que existen dos clases de objetos asociados con acciones para la interacción con un MIDlet: Command, introducidas por el teclado y se les da nombre, acción y prioridad, la aplicación las procesa de forma asíncrona proporcionando un escuchador (interfaz CommandListener) consistente en un método CommandAction(); y los Item, que representan objetos relacionados con lo presentado en la pantalla del dispositivo. También existen contenedores de objetos en pantalla, que es una instancia de la clase Display y que es el gestor de lo presentado en la pantalla y así permite obtener información sobre ella y presentar objetos sobre ella. La interfaz Screen es de más alto nivel y simplifica la tarea al programar, pero impone modelos sobre la organización de los elementos en la pantalla. Entre ellos están: o Formularios (Form). o Cajas de texto (TextBox). o Alertas (Alert). Muestran avisos al usuario. o Listas (List). Son listas de selección. 2. Compilación. El código generado se compila y se obtienen los archivos compilados en extensión.class. 3. Preverificación. Al igual que en Java 2 Edición Estándar, el código necesita ser verificado para evitar que se propaguen e instalen aplicaciones maliciosas. Lo que sucede en este caso es que para los terminales MIDP, la verificación se realiza en 2 partes: una se realiza fuera de línea al generar el código compilado, y otra (más ligera) en la carga de las clases al instalar el MIDlet. Así se descarga y se aligera el proceso en el terminal móvil. 4. Empaquetado. Se genera un archivo JAR que contiene: a. Manifiesto (Manifest): describe el contenido. b. Clases Java para el/los MIDlet(s) y las clases compartidas por los MIDlets. c. Ficheros de recursos utilizados por los MIDlets. Además debe existir un archivo descriptor JAD que describe el conjunto que se ha empaquetado antes. 5. Despliegue. Instalación del MIDlet en el terminal móvil. Seguridad en Java ME A continuación se van a analizar diferentes maneras de realizar la generación de claves, la petición de certificados y el almacenamiento de los mismos. También se comentarán las diferentes operaciones requeridas para realizar las firmas digitales en terminales móviles usando la tecnología Java. Hay que resaltar que las operaciones criptográficas en Java ME se realizan con la incorporación de librerías criptográficas de acuerdo con el conjunto de APIs estandarizadas en la arquitectura criptográfica Java (Java Cryptographic Architecture JCA). Así pues estas son las librerías más comunes en Java para realizar las operaciones criptográficas en dispositivos móviles: Bouncy Castle. Es una API criptográfica gratuita que proporciona métodos para las operaciones más comunes: importación de claves y certificados, generación de claves y petición de certificados PKCS#10, realización de firma digital y encriptación. Existe una versión ligera para Java ME que puede usarse a partir del perfil MIDP 1.0 o posterior.

31 IAIK MicroEdition. Es una API criptográfica ligera cuyas principales características con el cifrado simétrico/asimétrico y la gestión de certificados. Es compatible con todos los perfiles Java ME y soporta la mayoría de algoritmos de cifrado. No es gratuita. Phaos Micro Foundation. Puede usarse con todos los perfiles y configuraciones. Sus principales características criptográficas son: AES, 3DES, DES, RC4, RC2, RSA, DSA, MD5, SHA-1 y la mayoría de estándares de firma y certificados. No es gratuita. NTRU Neo para Java. Esta librería contiene un reducido conjunto de algoritmos diseñados específicamente para dispositivos con recursos y funcionalidades limitados. Posee cifrado simétrico (AES) y asimétrico (algoritmo propio NTRU) y huella digital con SHA-1. No es gratis. Todas estas librerías proveen diferentes métodos para realizar operaciones criptográficas que requieren la ejecución de algoritmos. De todas formas, se necesita proveer de material criptográfico o parámetros para usar en todas esas operaciones, como pueden ser las claves, certificados, credenciales, etc. Además se necesitan mecanismos para el almacenamiento y gestión de todo ese material criptográfico en el dispositivo móvil. La tabla siguiente muestra una serie de posibles métodos para proporcionar todos estos datos (claves y/o certificados) al terminal móvil: Vía Compatibilidad Observaciones Generación de claves interna (en el terminal) A través del sistema operativo A través de HTTP A través de HTTPS (SSL/TLS) Alta Media Alta Media Tras la generación, mediante BouncyCastle por ejemplo, se necesita que la autoridad de certificación las valide. Se requiere un sistema operativo compatible para almacenar certificados. Se necesita un servidor web que almacene las claves y certificados. Específico de MIDP 2.0. Similar a la anterior pero con seguridad mejorada. A través de puertos (IR, Bluetooth...) Media Se requiere MIDP 2.0. Tabla 6. Posibles métodos de obtención de claves y certificados. De la misma manera, y si se quieren almacenar las claves y los certificados en un entorno Java ME existen diferentes métodos: Método de almacenamiento persistente de Java ME (RMS). Los MIDlets pueden almacenar datos y recuperarlos posteriormente de manera persistente. En MIDP 2.0 varios MIDlets pueden compartir el mismo almacén, lo que permitiría que la información criptográfica pudiera ser compartida por varias aplicaciones. A través del sistema de archivos. El almacenamiento en el sistema de archivos del sistema operativo depende de si la KVM soporta la JSR-75 (API de conexión de ficheros) o no. Por tanto si

32 es soportada, se puede acceder a la información almacenada en el sistema de ficheros como por ejemplo un archivo PKCS#12 que contenga el certificado y la clave privada. A través de una tarjeta externa inteligente (smartcard). Podría ser una opción factible ya que existen varios lectores Bluetooth en el mercado. Se requiere que el terminal posea la API JSR 80. También se podrían usar tarjetas internas como las SIM, pero esta alternativa requiere una librería Java que permita el acceso a ella. Para eso está la API de Seguridad y Servicios de Confianza (Security and Trust Services API SATSA), que será descrita en una sección posterior ya que la aplicación desarrollada en este Proyecto Fin de Carrera se fundamenta en ella. 2.3 Tecnologías híbridas Existe un elevado número de servicios que no son posibles de implementar completamente ni en la tarjeta SIM ni basado solamente en el dispositivo móvil. Estos servicios normalmente necesitan aprovechar ventajas del dispositivo como una interfaz de usuario muy amigable y altas prestaciones de procesamiento, y la seguridad que proporciona la tarjeta SIM WML Script / XHTML Script Las aplicaciones Web, desarrolladas para dispositivos móviles, pueden hacer uso de las características criptográficas del módulo WIM de la tarjeta SIM. Actualmente, los lenguajes Web más extendidos en el mundo móvil son el WML (Wireless Markup Language) y el XHTML (extensible HiperText Markup Language). Ambos tienen librerías de script para desarrollar procesos de criptografía asimétrica en el lado del cliente. Una de esas librerías es la Crypto Library, que está incluida en los navegadores que soportan WMLScript o XHTMLScript y son equivalentes al JavaScript de HTML. La Crypto Library tiene sólo una función llamada SignText que realiza la firma digital de un texto plano. Cuando se llama a esta función, el módulo WIM es quien realiza la operación de firma y devuelve en formato PKCS#7 / CMS. En este caso, el módulo WIM utiliza la clave privada del usuario que está almacenada en la SIM. Este tipo de aplicación se ejecuta en el navegador del terminal móvil, así pues el fabricante debe implementar esta funcionalidad. Los puntos más importantes de esta solución son el uso del estándar PKCS#7 / CMS, el desarrollo de todos los procesos de firma en una aplicación Web y la integración del módulo WIM. Esto último significa que la clave privada del usuario nunca abandona la tarjeta durante el proceso de firma API de Seguridad y Servicios de Confianza (SATSA) La API de Seguridad y Servicios de Confianza (Security and Trust Services API SATSA), es una especificación para Java ME que da la posibilidad de abrir un canal de comunicación entre un MIDlet Java y un elemento de seguridad [22]. Este elemento de seguridad puede ser una tarjeta inteligente con módulo criptográfico WIM, o bien el elemento de seguridad interno que proporciona el sistema operativo de un terminal móvil, aunque la especificación habla sobre el elemento de seguridad en términos de: - Almacenamiento seguro para proteger los datos sensibles, como la clave privada del usuario, el certificado, las credenciales del servicio, información personal, etc. - Ejecución segura, como las operaciones criptográficas para soportar protocolos de comercio electrónico, integridad y confidencialidad de datos. - Características personalizadas en que las aplicaciones Java ME puedan confiar para poder tener nuevos servicios de valor añadido, como identificación del usuario,

33 autenticación, banca online, servicios de pago, venta de entradas, compra de licencia de aplicaciones, etc. Un elemento de seguridad, como se ha dicho previamente, puede estar implementado de varias formas pero las más común es en una tarjeta inteligente. Con el uso de SATSA, también conocida por el número de su especificación en la comunidad Java JSR- 177, un elemento de seguridad puede realizar todos los procesos de seguridad como firma electrónica o autenticación de usuarios en aplicaciones Java ME. La API de SATSA dispone de cuatro paquetes opcionales que se ajustan a las distintas necesidades de comunicación que se puedan tener con el elemento de seguridad. El modo de comunicación dependerá del tipo de aplicación. En la siguiente ilustración se observan estos paquetes: Ilustración 19. APIs de SATSA. [23] Paquete APDU. Este paquete defina una API para el soporte de una comunicación con una aplicación de una tarjeta inteligente, usando el protocolo APDU (Application Protocol Data Unit) de acuerdo al estándar ISO/IEC Si un MIDlet desea comunicarse con una smartcard, necesita crear una conexión APDU que es la responsable del intercambio de los comandos APDU con un formato adeacuado al estándar. Si la tarjeta inteligente soporta múltiples canales, entonces se pueden crear varias conexiones APDU y pueden funcionar varias aplicaciones al mismo tiempo. El canal 0, que suele estar reservado para la tarjeta SIM en redes GSM/UMTS, no puede utilizarse. Paquete JCRMI. Define una API para cliente JavaCard RMI que permite a una aplicación Java ME invocar un método remoto de un objeto JavaCard. Es otra alternativa para la comunicación con una tarjeta inteligente. Se necesita establecer una conexión JavaCardRMI para inicializar e iniciar la sesión JCRMI con un applet JavaCard. Paquete PKI. Este será fundamental en el desarrollo de la aplicación de este Proyecto, ya que define una API que soporta gestión de credenciales y de firma digital a nivel de aplicación. Para dotar de una mayor posibilidad de reutilización, esta API es independiente del tipo de elemento de seguridad que emplee el dipositivo Java ME. Sus clases son la javax.microedition.pki y javax.microedition.securityservice. La primera contiene métodos para la gestión básica de certificados digitales; la segunda aporta métodos para la generación de firmas digitales conforme al formato CMS (Cryptographic Message Syntax).Con el gestor de credenciales de este paquete, una aplicación Java ME puede añadir o quitar un certificado o su

34 URI (Uniform Resource Identifier) del almacén de certificados. Es más, habilita a la aplicación para realizar peticiones de firma de certificados a una autoridad de certificación. Para la realización de las tareas de firma digital con una clave privada, los MIDlets pueden utilizar la función CMSMessageSignatureService que proporciona el servicio de firma con varios parámetros configurables. Estas operaciones criptográficas pueden usarse para implementar tareas de autenticación, autorización, integridad y no repudio. Dependiendo de la política de seguridad del elemento de seguridad, el uso de la clave privada puede requerir la inserción de un código PIN o algún otro mecanismo para acceder a ella. Paquete CRYPTO. Define un subconjunto de utilidades criptográficas de la Plataforma Java 2 Edición Estándar (J2SE). Proporciona métodos para la realización de operaciones criptográficas básicas para la verificación de firmas, encriptación y desencriptación (realizadas a través de la clase Cipher). Este paquete contiene la posibilidad de realizar cifrado simétrico y asimétrico RSA y DEA. Ilustración 20. Arquitectura de SATSA. [17] Como se observa en la ilustración 20, la JSR-177 (SATSA) no es una especificación de inclusión obligatoria en los terminales sino que está por encima del perfil MIDP. Es por eso por lo que no todos los terminales móviles soportan dicha especificación hoy en día. No obstante los fabricantes están incluyéndola cada vez más en los nuevos modelos. También hay que decir, a favor de la profusión de esta especificación, que la JCP (Java Community Process) ha definido una especificación llamada Arquitectura de Servicios Móviles (Mobile Service Architecture, MSA) [24] destinada a reducir la fragmentación que existe entre las capacidades de los terminales y a permitir a los vendedores y fabricantes distribuir terminales bajo este paraguas, y así garantizar que APIs adicionales posee el nuevo terminal; entre las que interesaría SATSA.

35 MSA para CLDC (JSR 248) define dos listas, una completa y otra que es un subconjunto como se observa en la ilustración 21: Ilustración 21. Torres de la arquitectura MSA. [25] 2.4 Independientes del terminal móvil Debido a la gran variedad de terminales y dispositivos móviles existentes en el mercado, esta opción significaría desarrollar aplicaciones proveedoras del servicio de firma digital que sirviesen para toda la gama de terminales. Entonces, debido al hecho de que existe una enorme cantidad de ellos, esta solución requiere grandes inversiones que probablemente sean mayores que los beneficios que se puedan obtener a cambio. No obstante existen dos posibilidades tecnológicas en este sentido, y en ambas la aplicación del cliente hace peticiones al servidor y devuelve alguna información para que el cliente la firme Firma basada en un servidor Al principio, los móviles tenían muy pocas capacidades (menos aún criptográficas). Por eso no eran capaces de realizar ninguna tarea de cifrado asimétrico, y para solventar este problema la solución fue introducir un servidor con la responsabilidad de custodiar la información requerida para generar firmas electrónicas en nombre del usuario. Este servidor se interponía en la red móvil, y así, la aplicación

36 proveedora del servicio hace la petición de firma desde el servidor en vez de desde el usuario final. El servidor genera la firma digital a partir del certificado y de la clave que tiene del cliente. En este tipo de solución, el teléfono móvil se utiliza para validar la creación de la firma en el servidor ya que éste, antes de crear la firma, pidió al usuario que se autenticara desde su terminal mediante un PIN, mensajes de autenticación (Message Authentication Code MAC) o la combinación de ambos (One Time Signatures - OTS) basada en el uso de funciones de resumen. Todo el proceso que se ha comentado se muestra en la siguiente ilustración: Ilustración 22. Proceso de firma en una solución basada en servidor. Esta solución se puede usar con dispositivos móviles con pocas capacidades computacionales, y además la principal ventaja que tiene es la simplicidad y facilidad de implantación del sistema. Pero hay que decir que estas soluciones no están estandarizadas y que la firma depende de cómo se realice en el servidor. La seguridad debería confiarse en el servidor, ya que es quien custodia el certificado y la clave privada del usuario. Para solucionar todo esto esta el servicio de firma móvil, que se detalla a continuación Servicio de firma móvil El servicio de firma móvil (Mobile Signature Service MSS) se creó para facilitar el desarrollo de soluciones basadas en firma digital móvil para los proveedores de aplicaciones. La definición de este servicio comprende varios informes técnicos y especificaciones publicadas por la ETSI. En MSS se pueden diferenciar varios papeles: usuario final, proveedor de la tarjeta inteligente, autoridad de registro (RA), autoridad de certificación (CA), proveedor del servicio de firma móvil (MSSP), proveedor de la aplicación (AP), MSSP en itinerancia y coordinador de la gestión del contrato. Estos se muestran en la siguiente figura:

37 Ilustración 23. Entorno del servicio de firma móvil. [14] El usuario final tiene un teléfono móvil que contiene una tarjeta inteligente adquirida a su proveedor (normalmente el operador móvil). Esta tarjeta contiene una aplicación criptográfica que realiza la firma electrónica con el fin de validar la identidad del usuario. Esta aplicación se encuentra protegida mediante un código PIN que posee la tarjeta. El certificado de usuario se obtiene de una autoridad certificadora, quien delega en la autoridad de registro la responsabilidad de comprobar verazmente la identidad del usuario final. El MSSP puede invocar a la aplicación de la tarjeta para que firme ciertos datos. Antes de generarse la firma, el usuario debe introducir el PIN de acceso a la aplicación en su teléfono, por motivos de seguridad. Así pues, el proceso de firma siempre está bajo control del usuario. Todo usuario final debe estar registrado con un MSSP para poder usar el servicio. Con este registro el MSSP le activa la funcionalidad de firma a su terminal, y normalmente este MSSP suele ser el operador móvil del usuario, que además puede ofrecer servicios de valor añadido como estampado de tiempo, página personal del usuario para comprobar sus transacciones, etc. Este sistema otorga gran flexibilidad en el sentido de que el proveedor de la aplicación puede configurar el proceso de firma según su necesidad, pero también tiene la gran desventaja del que el AP necesita establecer un acuerdo con un MSSP que tenga ese servicio. Y es que no todos los operadores móviles ofrecen esta solución actualmente. 2.5 Ejemplos de servicios existentes Para terminar este apartado del estado del arte se comentarán a continuación algunos de los servicios existentes hoy en día, que están relacionados con esta materia Mobipay Mobipay [26] fue el primer sistema de pago a través del móvil que tuvo gran repercusión, y aunque no utiliza ninguna función criptográfica ni de firma electrónica es de cierto interés su estudio. Se trata de un servicio que ofrecen a sus clientes los operadores móviles y las principales entidades financieras españolas, que permite realizar pagos y otras transacciones bancarias en movilidad. Con Mobipay, un usuario puede asociar a su teléfono móvil sus tarjetas de crédito, emitidas por su entidad financiera. Ello le permite poder recargar la tarjeta de prepago telefónico del propio móvil o de otra persona, pagar desde el teléfono móvil, las compras por internet, el taxi, hacer donativos, pagar la

38 lotería, etc. Así como consultar los saldos y movimientos de sus cuentas, de forma similar a un cajero automático. Adicionalmente, con Mobipay se pueden realizar pagos de pequeño importe (en máquinas de bebidas, parquímetros de las zonas de estacionamiento regulado, billetes de autobús, etc.) directamente para cargarse en la factura telefónica. Los pagos con Mobipay pueden efectuarse en aquellos puntos de venta (físicos o virtuales) en los que figure el distintivo del servicio. La operativa se realiza mediante el envío de mensajes de texto a su teléfono móvil con toda la información sobre la operación que esté realizando, con los pasos a seguir para llevarla a buen fin y con la confirmación de que se ha realizado correctamente. Esto es, entre el teléfono móvil del comprador y Mobipay, se establece la comunicación mediante mensajes cortos a modo de pregunta-respuesta, en la que el cliente recibe toda la información sobre la operación de pago que se está llevando a cabo, y la solicitud para que, también a través de su móvil y mediante envío de códigos específicos, la autorice. Entrando brevemente en la tecnología que utiliza este servicio, hay que decir que para el envío y recepción de operaciones desde y hacia el teléfono móvil, se emplea, con carácter general, la tecnología USSD (Unstructured Supplementary Services Data). Los códigos USSD son una tecnología compatible con todos los móviles existentes en el mercado, que funciona en modo interactivo y en tiempo real y tiene prioridad frente a otro tipo de comunicaciones. Un punto a favor es que, al igual que los mensajes cortos de texto, permite operar en condiciones de cobertura baja. Desde el punto de vista de la seguridad, la tecnología USSD posee los siguientes atributos: No deja rastro en el teléfono móvil de la transacción realizada (si alguien accede al móvil de otra persona, no puede ver qué operaciones ha realizado). No permitir la conexión "móvil a móvil", evitando así la posibilidad de suplantación o de desvío de llamada. En las compras realizadas en Internet, la autenticación del titular y el pago se realiza por un canal aparte (red GSM) al de la compra (Internet). Las transacciones presentan la propiedad de no repudio, al estar siempre autorizadas por la clave secreta personal del usuario (el PIN del servicio). Como alternativa al tecleo de los códigos numéricos USSD, se ha implantado la posibilidad de iniciar también las transacciones mediante el envío de SMS con "palabra clave". También el servicio recientemente creó una plataforma WAP para que los clientes que lo deseasen pudieran acceder ahí. A continuación se muestra un ejemplo de funcionamiento del servicio para Caja Madrid: Tabla 7. Códigos USSD de Mobipay para Caja Madrid. [27]