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.

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.

1.2.1 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 1999. 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
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.

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

1.2.3 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

1.3.1 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
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]

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

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ública1 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 = EKUB[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 = DKRB[Y] = DKRB[EKUB[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 = DKRB[EKUB(M)] = DKUB[EKRB(M)]

1
Habitualmente, aunque también sería válido con la privada si se cifró con la pública.
 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.

1.3.3 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 1977. 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.
 • 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: y2 = x3
+ 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 1985.

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 10100 ) 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

me módulo N

y se envía.
 El usuario cuya clave pública es (N,e) recibe me (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 2003. Actualmente la empresa RSA ofrece una recompensa de
200.000 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 200000$.

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.
 Nº total
Tamaño clave (en Tamaño base Memoria para Memoria para
operaciones
bits) factores criba reducción matriz
(Tiempo total)

428 5,5 · 1017 600 Kb 24 Mb 128Mb

465 2,5 · 1018 1,2 Mb 64 Mb 825 Mb

512 1,7 · 1019 3 Mb 128 Mb 2 Gb

768 1,1 · 1023 240 Mb 10 Gb 160 Gb

1024 1,3 · 1026 7,5 Gb 256 Gb 10 Tb

Tabla 1. Comparativa de los recursos necesarios para factorizar módulos de varios tamaños. [10]

1.3.4 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

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

1.4.2 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 5755411357164
Yuan 8416409012872

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.
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 264 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 MD5.

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

 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:
 Ilustración 10. Proceso de verificación de una Firma Digital.

1.4.4 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 101 733 y la TS 101 903 [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 101 733, 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
 IETF RFC 2360 y RFC 3852. 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
 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

1.5.1 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.
 • 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.

1.5.2 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 1988. 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 1996.

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 :

 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.
• 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: Canonical Encoding Rules.

.CER Certificado codificado en CER
Norma ITU: X.690

DER: Distinguished Encoding

.DER Certificado codificado en DER
Rules. Norma ITU: X.690.

.PEM Es un certificado DER encerrado

Certificado codificado en
entre las sentencias BEGÍN
Base64
 Base64 CERTIFICATE y END
CERTIFICATE

.P7B (Ver .P7C) --

Estructura SignedData sin el tipo

.P7C Estructura PKCS#7 Data. Tan solo el certificado y/o
la CRL.

.PFX (Ver .P12) --

Evolución de PFX (Personal

inFormation eXchange).
Utilizado para aunar en un único
.P12 Certificado PKCS#12
fichero las claves pública y
privada con protección por
contraseña.

Tabla 5. Extensiones de los archivos de Certificados Digitales. [16]

1.5.3 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.
• 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.

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

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

1.5.4 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 1.765.425 certificados expedidos.
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:
 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.

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

2.2.1 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:
 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.

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

2.2.3 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.
 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:

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

• 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]:
 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.
 • 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

Tras la generación, mediante

Generación de claves interna (en BouncyCastle por ejemplo, se
Alta
el terminal) necesita que la autoridad de
certificación las valide.

Se requiere un sistema operativo

A través del sistema operativo Media compatible para almacenar
certificados.

Se necesita un servidor web que

A través de HTTP Alta almacene las claves y
certificados.

Específico de MIDP 2.0. Similar a

A través de HTTPS (SSL/TLS) Media la anterior pero con seguridad
mejorada.

A través de puertos (IR,

Media Se requiere MIDP 2.0.
Bluetooth...)

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

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

2.3.2 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,
 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 7816-4. 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
 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.
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.

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

2.4.2 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:
 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.

2.5.1 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
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]

Como se observa en la tabla 7, si el usuario del servicio desea consultar el saldo de su cuenta bancaria
asociada al servicio Mobipay, debe teclear el código USSD *148*2# y pulsar la tecla de llamada. Tras
ello se le requerirá la introducción de un PIN de seguridad para concluir la operación y acceder a la
consulta.

2.5.2 Firma Electrónica Móvil de Vodafone

La Firma Electrónica Móvil es un servicio que Vodafone [28] ofrece en exclusiva a sus clientes a través
del cual los usuarios podrán firmar sus documentos, utilizando su móvil. La Firma Electrónica Móvil de
Vodafone permite firmar documentos o validar transacciones de forma segura desde el teléfono móvil.

Está basada en Infraestructura de Clave Pública (PKI) y siempre bajo la legislación vigente de Firma
Electrónica Avanzada y Reconocida, y se pueden almacenar hasta 5 certificados personales en el
teléfono móvil, que además pueden ser de varias Autoridades Certificadoras. La aplicación de Firma
Electrónica Móvil de Vodafone se puede utilizar con cualquier teléfono móvil ya que se encuentra en la
SIM y hace uso del módulo WIM.

Este servicio posee las siguientes características criptográficas para el usuario:

• Se utilizan claves RSA de 1024 bits y un PIN de firma. Revocación y renovación delegada en la
Autoridades Certificadoras.

• Utilización de una tarjeta (U)SIM, con su seguridad inherente y mejorada que incluye módulo
WIM.

• Se evita el phising, mediante la firma de las peticiones. Opcionalmente, se puede emplear

encriptado extremo a extremo del contenido a firmar por el usuario.

El modelo de uso comienza por tener una SIM compatible con la Firma electrónica, que se puede
comprobar observándola si lleva grabado el anagrama “FEM/128K”. Esta nueva tarjeta se introduce en
el teléfono y hay que dirigirse dentro del menú Vodafone a la aplicación de Firma Móvil. Acepta las
condiciones de uso e introduce la clave de desbloqueo de la aplicación de Firma que te habrá facilitado
un Asesor Comercial de Vodafone (previo pago de 4€). El siguiente paso es solicitar a una Autoridad
Certificadora el certificado para el móvil. La Autoridad Certificadora descargará el certificado en el
teléfono. En este punto, la aplicación de Firma de Vodafone solicitará una clave como medida extra de
protección de la clave privada. El certificado se almacenará en el apartado de Certificados de la
aplicación.

El servicio comienza cuando un proveedor de servicio (banco, ayuntamiento, etc) quiera solicitar la
firma del usuario en una transacción. A partir de aquí, el servicio de Firma Electrónica Móvil de
Vodafone recoge la solicitud de firma y envía una notificación al terminal del usuario: se muestra por la
pantalla el documento a firmar. El usuario selecciona el certificado e introduce la clave de protección.
El servicio de Firma Electrónica Móvil de Vodafone recoge el documento firmado, y comprueba con la
Autoridad Certificadora que el certificado móvil es válido (no está revocado, no está caducado y la firma
es válida). Vodafone envía al prestador del servicio el resultado de la operación de firma y éste
realizará la transacción que has solicitado según el resultado de la operación de firma.

2.5.3 Firma Digital Móvil de Telefónica

Aunque por el momento no lo está comercializando, Telefónica y la Fábrica Nacional de Moneda y

Timbre anunciaron el pasado mes de Junio un acuerdo por el que, a partir de ahora, Telefónica podrá
ofrecer al mercado de empresas y Administraciones Públicas el servicio de Firma Digital Móvil y
proporcionar, así, tanto a las empresas como a los usuarios finales, todas las facilidades de autenticación
y firma digital sobre dispositivos móviles. Se trata pues de un acuerdo que la FNMT firma por separado a
otra operadora móvil, como ya hiciera con Vodafone [29].

Los certificados que se utilizarán serán unos especiales de firma electrónica diseñados por FNMT para
su utilización en tarjetas SIM de MoviStar – CriptoSIM. Para los grandes clientes, el servicio integral de
Telefónica facilitará la racionalización de los costes ligados a los métodos actuales de identificación del
cliente, a la vez que incrementará la seguridad, autenticidad y no repudio de las operativas y
transacciones realizadas por sus clientes.

Por el momento aún no ha trascendido más información sobre esta iniciativa de Telefónica, aunque se
presume que será muy similar a la que ya emplea su competidora Vodafone.