Alternativas a los Applets de Java en

las aplicaciones Web de firma

electrnica

Alternativas a los Applets de Java en las aplicaciones

Web de firma electrnica
Versin: 1.2
Fecha: 05 de Noviembre de 2013

http://creativecommons.org/licenses/by-sa/3.0/es/

Pgina 1 de 24

Alternativas a los Applets de Java en

las aplicaciones Web de firma
electrnica

HOJA DE CONTROL
Ttulo

Alternativas a los Applets de Java en las aplicaciones Web de firma electrnica

Nombre del

Alternativas a los Applets de Java en las aplicaciones Web de firma electrnica.pdf

fichero
Autor

Toms Garca-Mers

Versin

1.2

Copyright

MinHAP

Licencia
Aprobado por

CC-by-sa
MinHAP

Fecha Versin

05/11/2013

http://creativecommons.org/licenses/by-sa/3.0/es/

Fecha Aprobacin

05/11/13

N Total de pginas

24

Pgina 2 de 24

Alternativas a los Applets de Java en

las aplicaciones Web de firma
electrnica

Contenido
1

Introduccin .................................................................................................................................. 5

Opcin 1: Extensiones en navegadores Web................................................................................ 5

2.1

Descripcin de la solucin ....................................................................................................... 5

2.2 Reutilizacin de activos existentes en el proyecto @firma y estimacin esfuerzo necesario

para cada solucin ............................................................................................................................. 7
3

Opcin 2: API JavaScript normalizado y nativo a los navegadores Web ...................................... 8

3.1

Soporte del W3C a la criptografa va JavaScript ..................................................................... 9

3.2

Detalle propuesta de tareas a realizar para la implementacin prctica de la alternativa .. 10

3.2.1

API Bsico JavaScript ..................................................................................................... 10

3.2.1.1

Definicin del API ...................................................................................................... 10

3.2.1.2

Implementacin del API como extensin de Firefox ................................................ 12

3.2.1.3

Implementacin del API como extensin de Chrome / Chromium .......................... 12

3.2.1.4

Tareas de normalizacin ........................................................................................... 13

3.2.2

API Extendido JavaScript ............................................................................................... 13

3.2.2.1

PAdES......................................................................................................................... 14

3.2.2.2

XAdES......................................................................................................................... 15

3.3 Reutilizacin de activos existentes en el proyecto @firma y estimacin esfuerzo necesario

para cada solucin ........................................................................................................................... 16
4

Opcin 3: Uso de aplicaciones nativas invocadas mediante protocolo (protocolo a medida) ... 17
4.1

Descripcin de la solucin ..................................................................................................... 17

Pgina 3 de 24

Alternativas a los Applets de Java en

las aplicaciones Web de firma
electrnica

4.2 Reutilizacin de activos existentes en el proyecto @firma y estimacin esfuerzo necesario

para cada solucin ........................................................................................................................... 19
5

Tareas comunes independientes de opcin de implementacin ............................................... 20

Resumen ..................................................................................................................................... 23

Pgina 4 de 24

Alternativas a los Applets de Java en

las aplicaciones Web de firma
electrnica

1 Introduccin
Desde hace ya tiempo, se vienen sufriendo ciertos problemas con Java que estn poniendo
cada da ms difcil considerar los Applets de Java como una solucin de futuro para el Cliente
@firma. Desde la falta de soporte en las nuevas plataformas operativas (Apple iOS, Google
Android, Microsoft Windows Phone, RT y 8 y superiores en modo UI Moderno, BlackBerry
10, etc.) hasta los grandes problemas de seguridad que plantean (continuas vulnerabilidades
descubiertas), pasando por las dificultades que los navegadores ponen a su ejecucin, como
advertencias y dilogos de confirmacin.
La sustitucin de los Applets de Java por otra tecnologa no es tarea fcil, ya que, por una
parte, se necesita una comunicacin bidireccional con el JavaScript de la pgina Web (la firma
electrnica es un paso ms dentro de un completo flujo de trabajo) y, por otra, un acceso a
los almacenes de claves y certificados, siendo por supuesto deseable el soporte de tarjetas
inteligentes y dispositivos externos (como el DNIe).
En este sentido, son varias las opciones posibles, siendo tres las ms asequibles y alineadas
con el proyecto Cliente @firma:
1. Desarrollo de extensiones para navegadores Web
2. Implantacin de un API JavaScript normalizado
3. Uso de aplicaciones nativas con invocacin por protocolo

2 Opcin 1: Extensiones en navegadores Web

2.1

Descripcin de la solucin

La mayora de los navegadores Web soportan ampliaciones de su funcionamiento va los

llamados plugins y addons (extensiones). Estos se desarrollan habitualmente con tecnologa
nativa (usualmente C o C++), teniendo muy pocas restricciones en lo referente al acceso al
sistema operativo subyacente (y por lo tanto a los almacenes de claves) y permiten exponer
un API va JavaScript para ser usados desde las aplicaciones Web.
No obstante, lo que hace unos pocos aos no era tan mala opcin (de hecho, fue la escogida
por muchos componentes de firma electrnica), en la actualidad no es ptima, como a
continuacin se explica, en su soporte (enumerando las distintas tecnologas) en las
Pgina 5 de 24

Alternativas a los Applets de Java en

las aplicaciones Web de firma
electrnica

siguientes plataformas operativas:

Microsoft Windows
o ActiveX para Internet Explorer, se necesitan versiones diferentes de 32 y 64
bits para las distintas arquitecturas del navegador.
o NSAPI/NPAPI para Chrome, Firefox y otros.
Microsoft Windows 8 y 8.1 en modo UI Moderno y Windows RT
o Internet Explorer no soporta complementos.
Apple iOS
o Safari no admite complementos.
o Chrome no admite complementos.
Apple Mac OS X
o NSAPI/NPAPI para Safari, Chrome, Firefox y otros.
Google Android
o Chrome no admite complementos.
o Extensiones XPCOM para Mozilla Firefox.
Linux
o NSAPI/NPAPI para Chrome, Firefox y otros.
Otros entornos
o Internet Explorer en Windows Phone no admite complementos.
o El navegador Web de BlackBerry 10 no admite complementos.

Se puede observar de los datos anteriormente enumerados que una estrategia de extensiones
de navegador podra dar una buena experiencia de usuario en Chrome y Firefox tanto en
Linux, Windows, Mac OS X y Android, pero sin poder ofrecer compatibilidad en Apple iOS.
Sera necesario para Internet Explorer un desarrollo especfico para el desarrollo de un control
ActiveX, si bien conviene tener en cuenta que no funcionara en las versiones UI Moderno
de Windows 8 y 8.1, ya que la tecnologa ActiveX est en pleno abandono por parte de
Microsoft.
No obstante, esta opcin dara soporte a la gran mayora de los usuarios, proporcionando una
experiencia de usuario muy buena, ya que si se exponen las operaciones de firma va
JavaScript el usuario realmente no apreciara ni cambios de contexto, ni advertencias, ni
necesidad de acciones manuales ni otros efectos adversos que s padecen los Applets de
Java.
No obstante, se introduce un inconveniente realmente difcil de evitar, que no se encontraba
con los Applets de Java, y es la heterogeneidad de los entornos operativos, aspecto que afecta
en dos sentidos:

Pgina 6 de 24

Alternativas a los Applets de Java en

las aplicaciones Web de firma
electrnica

Arquitectura de las extensiones de los navegadores.

o Siendo las extensiones habitualmente desarrolladas en cdigo nativo, se
tienen que generar ejecutables para distintos entornos y arquitecturas, lo cual
implica esfuerzos adicionales.
Distintas tecnologas de almacenes de claves y certificados que obligan a distintos
desarrollos, incluso para un mismo navegador.
o CAPI en Windows, Llavero en Mac OS X, el almacn central de Android, NSS
para los almacenes de Firefox, etc.

El resultado final sera un ncleo de cdigo comn, y luego, en base a un esfuerzo adicional,
toda una coleccin de mdulos de acceso a almacenes de claves y certificados y proyectos
de desarrollo en diferentes entornos (Visual Studio, Xcode, GCC, etc.).

2.2 Reutilizacin de activos existentes en el proyecto @firma y

estimacin esfuerzo necesario para cada solucin
Extensin Active Xpara Internet Explorer
Dada la posibilidad de creacin de controles ActiveX usando C# con .NET, es posible la
reutilizacin de ciertos activos del Cliente @firma para Windows 8, entre los que encontramos:

El motor de firma CAdES.

La adaptacin de las bibliotecas BouncyCastle para C#.

En este sentido, sera necesario ejecutar las siguientes tareas para cerrar un control ActiveX
completamente funcional:
Tarea
Coste estimado
Estructura control ActiveX
4.509
Instalador
7.200
CAdES - Ampliacin motor CAdES a multifirmas
5.400
PAdES - Adaptacin iTextSharp
7.200
PAdES - Motor PAdES
5.400
XAdES - Motor XAdES
27.000
TOTAL
56.709
Extensin NPAPI / NSAPI / XPCOM
Al haberse programado el motor CAdES para Apple iOS en C estndar (en contraposicin a
Objective C, muy ligado a sistemas Apple), sera posible reutilizar ciertos activos del Cliente

Pgina 7 de 24

Alternativas a los Applets de Java en

las aplicaciones Web de firma
electrnica

@firma para Apple iOS, entre los que encontramos:

El motor de firma CAdES (incluidas las compilaciones ASN.1).

La adaptacin de las bibliotecas OpenSSL.

En este sentido, sera necesario ejecutar las siguientes tareas para cerrar una extensin
completamente funcional:
Tarea
Coste estimado
Estructura extensin NSAPI/NPAPI
3.500
Estructura extensin XPCOM
3.500
Instalador Windows
1.800
Instalador Mac OS X
2.300
Instalador Linux
3.500
CAdES - Ampliacin motor CAdES a multifirmas
11.500
PAdES - Ampliacin bibliotecas Haru para soporte firmas
32.000
PAdES - Motor PAdES en lenguaje C
15.200
XAdES - Motor XAdES
32.000
TOTAL
105.300

3 Opcin 2: API JavaScript normalizado y nativo a los

navegadores Web
Si bien las extensiones de los navegadores Web constituyen en muchos casos una opcin
viable para la realizacin de firmas electrnicas (hay que recordar que los Applets Java se
ejecutan con Java Plugin, que no es otra cosa que una extensin), lo ptimo sera que pudiese
hacerse el 100% del proceso en JavaScript con las funcionalidades estndar que
proporcionan los navegadores, eliminando as la necesidad de binarios adicionales Por
desgracia, el API JavaScript normal de los navegadores Web no incluye las funcionalidades
necesarias.
Adicionalmente, sera un error acotar las funcionalidades necesarias a la implementacin de
las operaciones criptogrficas (RSA, huellas digitales, etc.) en JavaScript, que si bien es una
tarea difcil (JavaScript no est pensado para los tratamientos binarios que requiere ASN.1 y
los algoritmos RSA y de huellas digitales), lo cierto es que ste es una tema resuelto desde
hace ya algunos aos, y se pueden encontrar trabajos previos en los que basarse:
http://code.google.com/p/crypto-js/
http://www.ohdave.com/rsa/
Pgina 8 de 24

Alternativas a los Applets de Java en

las aplicaciones Web de firma
electrnica

http://www-cs-students.stanford.edu/~tjw/jsbn/
Etc.

Partiendo de estos trabajos, se podra desarrollar la base para realizar cifrados RSA y huellas
digitales SHA-1 y SHA-2, ms un API ASN.1 bsico (lo indispensable para operaciones
PKCS#1), y con reutilizaciones adicionales y un trabajo extra de consolidacin, un buen API
JavaScript para X.509.
No obstante, esto no soluciona la incapacidad de acceder de forma segura a las claves
privadas de los ciudadanos desde JavaScript, asegurando que en ningn momento stas
queden accesibles para otro uso. De hecho, lo ideal es que el PKCS#1 por completo,
incluyendo la huella digital, se realizase de una forma opaca para el JavaScript,
proporcionando as una mayor seguridad.

3.1 Soporte del W3C a la criptografa va JavaScript

Hace un tiempo que se public por parte del W3C el borrador de una especificacin que
resulta bastante interesante en este sentido. La Web Cryptography API
(http://www.w3.org/TR/WebCryptoAPI/), que cuenta con el soporte directo de Mozilla y
Google (con lo que se adoptara previsiblemente en Firefox y Chrome), ms un apoyo
algo ms tmido por parte de Microsoft, quien expresa (a consultas del equipo del Cliente
@firma) su intencin de soportarla en Internet Explorer, una vez pasase de borrador a
especificacin final y fuese adoptada de forma general por la industria.
Con el soporte de tres grandes navegadores en un estndar promovido por la W3C sera
previsible su adopcin por el resto del mercado (especialmente por Apple WebKit, que
es la base de Apple Safari, Opera y el navegador de Android) y podra darse la impresin
de que el problema estara resuelto. No es as ya que, si se entra en el detalle de la
especificacin, se puede observar que lo que se propone es una implementacin de
ciertas operaciones criptogrficas comunes (como cifrados RSA y firmas PKCS#1) a las
cuales se le dara un API normalizado en JavaScript. Esas operaciones podran estar
aceleradas por el sistema operativo (y por hardware si este ltimo lo soporta), pero no
se resuelve el acceso seguro a las claves privadas y certificados del ciudadano.
Es sin duda un avance, pero no solventa el principal inconveniente.
No obstante, hay otra especificacin del W3C especficamente para tratar los aspectos
que la anterior dejaba sin hacerlo, la WebCrypto Key Discovery
(https://dvcs.w3.org/hg/webcrypto-keydiscovery/raw-file/tip/Overview.html). Una lectura
con detalle de la especificacin muestra que es justo lo que se necesita: el acceso a

Pgina 9 de 24

Alternativas a los Applets de Java en

las aplicaciones Web de firma
electrnica

claves privadas pre-provisionadas (previamente instaladas en el equipo del ciudadano).

De nuevo, existen inconvenientes, y son que la especificacin no cuenta con un apoyo
generalizado de la industria. Est promovida por Netflix con el inters de permitir modos
avanzados de gestin de derechos digitales (DRM, bsicamente sistemas anti-piratera
y anti-copia) y esta orientacin choca con el modelo de negocio de Google (que obtiene
sus ingresos de la publicidad, en contraposicin a la venta de activos digitales) y con el
espritu abierto de la Fundacin Mozilla, por lo que no es previsible su soporte ni en
Chrome ni en Firefox.
En esta difcil situacin, una de las vas de avance abiertas desde el equipo del Cliente
@firma consiste en el inicio de contactos con la Fundacin Mozilla para evaluar la
posible ampliacin de la Web Cryptography API con funcionalidades que permitiesen
referenciar claves privadas pre-existentes para operaciones seguras de firma
electrnica. La respuesta ha sido muy positiva (con involucracin directa de la
Fundacin Mozilla y Mozilla Hispano), siendo los pasos siguientes a recorrer una
definicin detallada del API necesario, ms una implementacin de referencia junto al
resto de la especificacin Web Cryptography API (posiblemente como una extensin de
Firefox), mientras se propone como un API estndar (que vendra directamente con el
navegador, sin necesitar extensiones).
Por supuesto, sera necesaria tambin una coordinacin cohesionada con Chromium y
Google (igualmente con una extensin como implementacin de referencia, intentando
reutilizar el mximo nmero de activos de la extensin de Firefox), y ms adelante, ya
con el API consolidado y las implementaciones de referencia, contactar con Microsoft.
Si se consiguiese la ampliacin del estndar con el soporte de Mozilla, Google y
Microsoft, sera cuestin de tiempo verlo reflejado en Apple WebKit y, por lo tanto,
soportado en la prctica totalidad de las plataformas.

3.2 Detalle propuesta de tareas a realizar para la implementacin

prctica de la alternativa
3.2.1 API Bsico JavaScript
3.2.1.1 Definicin del API
La base del proyecto es la definicin de un API JavaScript normalizado que
permita la realizacin de firmas electrnicas usando las claves privadas que el
usuario tuviese instaladas en su navegador o sistema operativo.

Pgina 10 de 24

Alternativas a los Applets de Java en

las aplicaciones Web de firma
electrnica

El API deber ser completamente seguro en lo referente a la custodia de las claves

privadas y debe permitir al usuario tener control completo en todo momento sobre
su uso.
Las funcionalidades a proporcionar por el API sern como mnimo:
Seleccin (segura) de una clave privada en base a su alias en el almacn
de claves y certificados del usuario.
Esta operacin devolver una referencia a la clave privada (nunca la
clave privada en s), sobre la que el usuario podr dar permiso para un
solo uso o para mltiples usos dentro de la misma sesin, con o sin
confirmacin explcita (habilitando as el uso en firmas masivas).
Se deber poder establecer filtros en la seleccin de la referencia en
base a las caractersticas del certificado de su titular.
o

En base al nmero de serie del certificado.

En base al titular (sintaxis segn RFC 2254).

En base al emisor (sintaxis segn RFC 2254).

En base al KeyUsage

Otros filtros pre-construidos:

Uso de DNIe.

Cualificado de firma en base a su par de

autenticacin.

Etc.

Firma PKCS#1 de un contenido en Base64 usando una referencia a una

clave privada.
Obtencin de la cadena de certificados asociada a una referencia a una

clave privada.
El API definido deber estar fuertemente basado en las actuales iniciativas de la
Pgina 11 de 24

Alternativas a los Applets de Java en

las aplicaciones Web de firma
electrnica

W3C sobre criptografa, buscando en todo momento la reutilizacin y colaboracin

entre equipos de trabajo:

Web Cryptography API : http://www.w3.org/TR/WebCryptoAPI/

WebCrypto Key Discovery: https://dvcs.w3.org/hg/webcryptokeydiscovery/raw-file/tip/Overview.html

3.2.1.2 Implementacin del API como extensin de Firefox

El API JavaScript definido deber implementarse como una extensin de Firefox
que use NSS como origen de los certificados y las claves privadas del usuario,
incluyendo los mdulos PKCS#11 que el usuario tuviese instalados en Firefox
(viendo el usuario final todos los mdulos como un nico almacn).
La extensin deber ser compatible con las siguientes versiones de Firefox:
Firefox 32 bits para Microsoft Windows
Firefox para Apple Mac OS X
Firefox para Google Android
Firefox 32 bits para Linux
La extensin deber ser desarrollada en colaboracin con la Fundacin Mozilla,
de forma que puedan coordinarse, primero con la actual extensin de David Dahl
para la W3C WebCrypto API (DOMCrypt: https://addons.mozilla.org/Enus/firefox/addon/domcrypt/) y con las futuras implementaciones de los API del
W3C.
3.2.1.3 Implementacin del API como extensin de Chrome / Chromium
El API JavaScript definido deber implementarse como una extensin de Google
Chrome / Chromium para Windows que use CAPI (Microsoft Crypto API) como
origen de los certificados y las claves privadas del usuario.
Debe buscarse en todo comento una colaboracin y coordinacin con Google que
permita un trabajo conjunto en la implementacin futura de los API del W3C.

Pgina 12 de 24

Alternativas a los Applets de Java en

las aplicaciones Web de firma
electrnica

3.2.1.4 Tareas de normalizacin

Para asegurar que el API generado es una opcin viable como estndar futuro de
mercado, debern trabajarse en las siguientes lneas:
El Centro Criptolgico Nacional (CCN: https://www.ccn.cni.es/) debe auditar
los trabajos y certificar la seguridad de los mismos.
Debe procurarse un trabajo con W3C, y en particular con Mozilla, Google y
Netflix para intentar influir en los estndares desarrollados por esta
organizacin.
Debe procurarse un trabajo conjunto con Google y Mozilla, de forma que se
intente que el API forme parte del ncleo JavaScript de Chrome y Firefox, con
independencia de si finalmente se corresponden con los trabajos del W3C.
Debe procurarse un contacto directo con Microsoft de forma que se pueda
tener influencia directa para el soporte de estas tecnologas en Internet Explorer.
Se deber trabajar en implementaciones de servicios de referencia con
organismos de primera lnea, no solo como pruebas piloto, sino como forma
de influencia general. Por ejemplo:

Agencia Tributaria

Ministerio de Hacienda y Administraciones Pblicas

Ministerio de Industria, Energa y Turismo.

Etc.

3.2.2 API Extendido JavaScript

Si bien el soporte de criptografa RSA, PKCS#1 y huellas digitales ms el
tratamiento seguro de claves privadas constituye la base mnima sobre la que
implementar firmas digitales, es necesario un trabajo adicional considerable para
poder construir firmas AdES completas, que se concreta en una serie de API
desarrollados completamente en JavaScript.
CAdES

Pgina 13 de 24

Alternativas a los Applets de Java en

las aplicaciones Web de firma
electrnica

Tareas adicionales a realizar (cada tarea tiene dependencias con las anteriores):
API de tratamiento binario bsico sobre Base64.
API ASN.1 completo.
API X.509 completo.

Como mnimo tratamiento del TBSCertificate (To Be Signed),

del Principal de emisor y titular, de clave pblica, nmero de
serie y KeyUsage.

API CAdES.

Capaz de generar al menos CAdES-BES-EPES.

Contenido firma explcito o implcito.

SigningCertificatev1 o SigningCertificatev2.

Debern reutilizarse los trabajos de software libre existentes que tengan una
calidad suficiente y una licencia compatible:
http://lapo.it/asn1js/
http://www.ohdave.com/rsa/
http://www-cs-students.stanford.edu/~tjw/jsbn/
http://kjur.github.io/jsrsasign/
https://github.com/ziyan/javascript-rsa
Etc.
3.2.2.1 PAdES
Tareas adicionales a realizar (cada tarea tiene dependencias con las anteriores, y
todo el bloque depende de la disponibilidad del soporte CAdES descrito en el
punto anterior):

Pgina 14 de 24

Alternativas a los Applets de Java en

las aplicaciones Web de firma
electrnica

API PDF general.

API diccionario PDF.
API firmas PDF.
El desarrollo deber basarse, siempre que sea posible, en el API PDF de Mozilla
(http://mozilla.github.io/pdf.js/), trabajando de forma conjunta con la Comunidad de
Software Libre de ese proyecto en su evolucin.
3.2.2.2 XAdES
De forma anloga a CAdES, deber implementarse un API que permita la
formacin de firmas XAdES-BES/EPES completas, soportando al menos las
siguientes variantes:
Tipos de dereferenciacin:

Local

Remota por HTTP o HTTPS cuando el destino de la referencia

no suponga un problema de XSS (Cross Site Scripting).

Tipos de transformaciones:

XPATH

XPATH2

Enveloped

Base64

Modos de firma

Externally Detached

Internally Detached

Enveloped

Pgina 15 de 24

Alternativas a los Applets de Java en

las aplicaciones Web de firma
electrnica

Enveloping

Referencias con MANIFEST

Las tareas a desarrollar seran las siguientes:

API XML genrico.
API XML para transformaciones.
API XML para dereferenciaciones.
API XML para XMLDSig con atributos XAdES.
Como en el resto de tareas, debe buscarse la reutilizacin de activos existentes
de software libre (API XML, etc.) con licencia compatible y calidad apropiada.

3.3 Reutilizacin de activos existentes en el proyecto @firma y

estimacin esfuerzo necesario para cada solucin
Ningn activo actual del proyecto Cliente @firma sera directamente reutilizable, por lo que
sera necesario el desarrollo desde cero (usando bibliotecas de software libre cuando sea
posible) de la totalidad de los mdulos:
Tarea
Coste estimado
General - API ASN.1 X.509 basado en biblioteca software libre
4.100
General - API ASN.1 RSA basado en biblioteca software libre
3.300
CAdES - Motor ASN.1 JavaScript
6.900
CAdES - Motor CAdES
36.900
PAdES - Ampliacin JSPDF para soporte de firmas
45.000
XAdES - Motor XAdES
37.000
General - Extensin Firefox
3.500
General - Gestin referencias claves privadas JavaScript
5.500
TOTAL
142.200

Pgina 16 de 24

Alternativas a los Applets de Java en

las aplicaciones Web de firma
electrnica

4 Opcin 3: Uso de aplicaciones nativas invocadas

mediante protocolo (protocolo a medida)
4.1

Descripcin de la solucin

En la actualidad, el Cliente @firma ya implementa medios de firma electrnica desde

aplicaciones Web que prescinden de Applets de Java, extensiones de navegador y API
nativos JavaScript, y es lo que actualmente est disponible en el Cliente @firma para Google
Android (https://play.google.com/store/apps/details?id=es.gob.afirma), usando para ello la
invocacin por protocolo de aplicaciones nativas.
La invocacin por protocolo consiste en que una aplicacin registra en el sistema operativo
que es capaz de atender un determinado protocolo, de forma que cuando se produzca una
llamada para apertura de una URI con ese protocolo, se invocar dicha aplicacin.
Esta tcnica no es novedosa, y se implementa en la actualidad en todos los sistemas
operativos y por miles de aplicaciones. As, en cualquier entorno operativo, si se pide abrir
una URI del tipo http://, se abrir el navegador Web, y si pide abrir otra que empiece por
sip:// (Session Initiation Protocol) se abrir, si se tiene, el programa de telefona IP (Microsoft
Lync por ejemplo en un sistema Windows).
Trasladando esto al Cliente @firma, sera necesario desarrollar una aplicacin nativa que
registre el tratamiento de una URI cuyo esquema con seguridad no va a utilizar ninguna otra
aplicacin (por ejemplo afirma://). As, cualquier llamada a este protocolo, har que se abra
la aplicacin nativa.
Entonces (tal y como se hace en las versiones para Android, iOS y Windows 8 del Cliente
@firma) se realiza desde JavaScript en la aplicacin Web de firma electrnica, en vez de la
carga del Applet @firma, una llamada a este protocolo que contenga todo lo necesario para
realizar la operacin de firma, por ejemplo:
afirma://sign?data=DATOSAFIRMAR&alg=SHA512withRSA&format=CAdES
Esto provocara que nuestra aplicacin nativa (una nueva versin del Cliente @firma) se
invocase recibiendo la URI completa, obteniendo entonces de ella qu es exactamente lo que
debe hacer (en este ejemplo simplificado, una firma CAdES con SHA512).
Si bien la invocacin por protocolo consigue comunicar aplicacin JavaScript en un navegador
Web con una aplicacin nativa que puede acceder a claves privadas de los ciudadanos sin
exponer vulnerabilidades de seguridad, lo hace en un nico sentido, siendo necesario
Pgina 17 de 24

Alternativas a los Applets de Java en

las aplicaciones Web de firma
electrnica

implementar medios adicionales para devolver por parte de la aplicacin nativa los datos
firmados al JavaScript que la invoc.
Dado que no se puede establecer una comunicacin IP local (causara problemas de XSS si
la Web original est alojada con SSL), una solucin es que la aplicacin nativa la enve al
servidor donde se aloja la aplicacin Web para que sta, mediante JavaScript asncrono, la
recoja cuando est disponible.
El proceso resultante sera ms o menos el descrito en la imagen:

1. El navegador Web invoca a una App nativa mediante una URI especial, indicando una
serie de informacin (datos a firmar, formato, opciones, etc.).
2. La App recibe los datos y realiza la firma electrnica usando las funciones nativas de
gestin de claves y certificados.
3. La App nativa deposita el resultado de la firma en un servidor intermediario mediante
una llamada a un servicio Web simple.
4. El navegador Web recoge el resultado de la operacin del firma del servidor
intermediario y contina la ejecucin de la lgica de negocio.
5. El resultado es que se consigue una comunicacin bidireccional asncrona entre
aplicacin JavaScript y Aplicacin nativa que permite prescindir de los Applets de Java.
Evidentemente, al proceso se le han aadido medidas de seguridad para que el
trnsito de su firma por la red en el camino desde la aplicacin Web hacia el JavaScript
no implique peligro.

Pgina 18 de 24

Alternativas a los Applets de Java en

las aplicaciones Web de firma
electrnica

Este proceso es viable en la totalidad de sistemas operativos actuales, incluyendo Apple iOS,
Windows 8 y RT y Windows Phone (a partir de Windows Phone 8).
Adicionalmente, se podra pensar en la posibilidad de registrar este tratamiento de protocolo
a medida asocindolo a una aplicacin Java, lo cual permitira la reutilizacin de los activos
actuales del Cliente @firma en Java. Aunque las aplicaciones seguiran siendo Java, ya no
seran Applets de Java, que es lo realmente problemtico (por seguridad y compatibilidad) y,
al menos Windows, Linux y Mac OS X, estaran cubiertos con un esfuerzo ms o menos
acotado.

4.2 Reutilizacin de activos existentes en el proyecto @firma y

estimacin esfuerzo necesario para cada solucin
En los expedientes en curso del Cliente @firma se incluye ya soporte de invocacin por
protocolo para la mayora de los entornos:

Microsoft Windows 7, Vista, XP

o

Apple OS X
o

PAdES y CAdES (carencia de XAdES monofsico).

Apple iOS
o

Soporte completo.

Google Android
o

Soporte completo.

Linux
o

Soporte completo.

CAdES (carencia de XAdES y PAdES monofsico).

Windows / Windows RT 8 y 8.1

o

CAdES (carencia de XAdES y PAdES monofsico).

Pgina 19 de 24

Alternativas a los Applets de Java en

las aplicaciones Web de firma
electrnica

Para mejora del soporte, sera no obstante conveniente la ampliacin del soporte monofsico
del Cliente @firma para Windows 8 a PAdES.

Tarea
CAdES - Ampliacin motor CAdES a multifirmas
PAdES - Adaptacin iTextSharp
PAdES - Motor PAdES
TOTAL

5 Tareas comunes
implementacin

independientes

Coste estimado
5.400
7.200
5.400
18.000

de

opcin

de

Observando
las
cifras
del
actual
proyecto
Cliente
@firma
(http://devel.uji.es/sonar/dashboard/index/1993), con 30.000 lneas de cdigo, es fcil
observar que el esfuerzo necesario para lograr la actual funcionalidad ha sido ingente, y por
lo tanto que el migrarlo a distintos lenguajes de programacin, con distintas bibliotecas, no
ser tampoco pequeo.
Lo cierto es que una implementacin auto-contenida, sin dependencias externas, en el que
toda la funcionalidad se agrupe en un programa local (como el actual MiniApplet Cliente
@firma), es absolutamente deseable, y muy especialmente si optsemos por la va de API
JavaScript estndar en los navegadores Web, ya que este cdigo podra utilizarse sin
modificaciones no solo en cualquier cliente (Windows, iOS, Android, etc.), sino incluso en
servidores.
No obstante hay muchos factores que condicionan el esfuerzo necesario para llegar a este
objetivo:
Motores CAdES.
o iOS, Linux, Mac OS X y Windows (excepto RT, UI Moderno y Phone)
Una implementacin en C portable, usando compiladores ASN.1 y las
bibliotecas OpenSSL es perfectamente viable (de hecho, es lo que se
est haciendo actualmente en el Cliente @firma para iOS).
No obstante, es un esfuerzo considerable, y el actual motor para iOS
carece an de soporte de contrafirmas y cofirmas.

Pgina 20 de 24

Alternativas a los Applets de Java en

las aplicaciones Web de firma
electrnica

Navegadores Web con JavaScript

Tenemos API ASN.1 en JavaScript muy primitivos que pueden servir
de base (incluso con un soporte inicial de X.509), pero el trabajo a
realizar es enorme.
Windows RT, Windows 8 y 8.1 (UI Moderno) y Windows Phone
La existencia de las bibliotecas BouncyCastle en C# alivia mucho el
esfuerzo necesario. De hecho, el Cliente @firma ya un motor CAdES
simple en .NET para Windows 8 perfectamente funcional.
Android
Afortunadamente, el trabajo sobre JSE es 100% compatible con
Android, por lo que este entorno operativo no presenta trabajo
adicional, gracias a la buena calidad de los actuales activos del
Cliente @firma.

Motores PAdES
o iOS, Linux, Mac OS X y Windows (excepto RT, UI Moderno y Phone)
El trabajo necesario para crear un API para el manejo de PDF en C o
C++ es enorme. Aunque hay productos de Software Libre sobre los
que empezar a trabajar (por ejemplo: http://podofo.sourceforge.net/),
ninguno ofrece las facilidades de iText (las bibliotecas que usa
actualmente el Cliente @firma).
o Navegadores Web con JavaScript
Est disponible el API pdf.js de Mozilla como punto de partida, pero
el trabajo que habra que realizar supera incluso al de un motor en
C/C++.
o Windows RT, Windows 8 y 8.1 (UI Moderno) y Windows Phone
La existencia de las bibliotecas iText en C# alivia mucho el esfuerzo
necesario, pero su calidad no es la misma que en Java, y no es
desdeable la dificultad de la tarea.
o Android
Afortunadamente, el trabajo sobre JSE es 100% compatible con
Android con unas pequeas modificaciones sobre iText, as que este
entorno operativo no presenta trabajo adicional (de nuevo gracias a la
alta calidad de los activos actuales).
Si bien existe iTextDroid, una versin de iText para Android, el
Cliente @firma usa un desarrollo propio basado en este, ya
que el original presentaba problemas en las firmas
electrnicas.

Pgina 21 de 24

Alternativas a los Applets de Java en

las aplicaciones Web de firma
electrnica

Motores XAdES
o En cualquiera de los casos es necesaria una implementacin completa
partiendo de un API XML.
.NET dispone de ciertas facilidades y existen bibliotecas de Software
Libre para C y C++ No obstante, la cantidad de opciones que dan
las firmas XML (dereferenciaciones, transformaciones, modos,
manifest, etc.) hace que cualquier aproximacin al problema sea
problemtica.

En este punto, vemos que si bien la parte de viabilidad de las alternativas viene dada por el
acceso a los almacenes de claves desde JavaScript de forma segura (apoyndose en una
aplicacin externa), el peso de la dificultad en la implementacin puede estar en la
implementacin de los motores de firma en los distintos formatos.
En general, se podra tener cierto nivel de reutilizacin de los activos actuales del proyecto
Cliente @firma (en verde mdulos necesarios que pueden tener cierto nivel de reutilizacin,
en azul aquellos que deben desarrollarse desde cero):
Interfaz Esquema Protocolo URL o API JavaScript (nativo o va extensiones de navegador)

App
Apple
iOS

Clientes Trifsicos C

Clientes Trifsicos C# / .NET

Clientes Trifsicos
Java

Motor CAdES C

Motor CAdES C# / .NET

Motor CAdES Java

Extensin NSAPI/NPAPI
Almacn
NSS

Llavero
Mac OS X

App
Windows
8 / RT

App
Windows
Phone

Almacn PKCS#12

Aplicacin
Windows
XP, Vista y
7

App
Google
Android

Applet
Java

No obstante, todo problema tiene siempre distintas formas de resolverse, ya que estamos
quizs olvidando que existen los llamados procesos de firma en varias fases, en los que
parte del proceso, y es justo la composicin del formato final de firma, se realiza en un servidor.

Pgina 22 de 24

Alternativas a los Applets de Java en

las aplicaciones Web de firma
electrnica

Este modelo est ya implementado con xito en el Cliente @firma, en produccin para algunos
casos muy particulares (implantado en organismos como la Diputacin Provincial de Ciudad
Real o el Ayuntamiento de Guadarrama), y permite reutilizar los activos existentes en Java en
aplicaciones JEE, relegando a los clientes nicamente aquellas operaciones que siempre
deben realizarse all (las dependientes de las claves privadas).
Un pequeo resumen de la tcnica puede encontrarse en el SVN del Cliente @firma:
http://svn-ctt.administracionelectronica.gob.es/svn/clienteafirma/docs/ANEXO_Firmaelectronica-en-varias-fases.docx
(requiere
alta
en
el
CTT
y
el
PAE:
http://administracionelectronica.gob.es/).
Quiere decir esto que la firma multifase es la solucin ideal si prescindisemos de los Applets
de Java? No exactamente; ms bien quiere decir que son soluciones parcialmente adecuadas
para la mayora de los casos, mientras se desarrollan las tareas que permitan tener soluciones
absolutamente adecuadas para la mayora de los casos.
Por ejemplo, el enfoque del firma multifase del Cliente @firma es tener al menos la
implementacin de CAdES simple (sin cofirmas ni contrafirmas) en un modo tradicional
(ejecucin 100% en el cliente) y por eso se estn desarrollando motores en C# (Microsoft
Windows 8, 8.1, RT y Phone) y en C portable (Apple iOS), mientras se reutiliza el motor Java
en Android. De igual forma, si un organismo considerase que su mejor solucin sera una
firma PAdES local, podra iniciar el desarrollo necesario, y mientras este finaliza, dar servicio
con los Applets actuales o con los modos en tres fases

6 Resumen
En el documento se desarrollan diversas opciones de futuro para el Cliente @firma, cada una
de ella con sus ventajas y sus inconvenientes Cules de ellas deben abordarse? Cules
deben descartarse? El carcter abierto y colaborativo del proyecto permitir sin duda que se
tenga en cuenta la opinin de muchos y que muchos puedan colaborar en llevar a cabo las
tareas
A modo de resumen, se podra describir la situacin actual como:
Acceso a claves privadas y firma PKCS#1 (parte obligatoria en cliente)
o La opcin deseable sera la implementacin de un estndar Web, promovido
por la W3C e implementado por Google, Mozilla, Microsoft y Apple, y apoyado
tcnicamente por el equipo del Cliente @firma.
Aun si fuese viable, est al menos a ms de 12 meses de distancia

Pgina 23 de 24

Alternativas a los Applets de Java en

las aplicaciones Web de firma
electrnica

La opcin ms prctica y ms compatible sera realizar aplicaciones

susceptibles de ser invocadas por protocolo, usando Java all donde fuese
posible.
o Una opcin intermedia seran las extensiones de los navegadores, aunque
quizs por eso, por quedarse corta en varios aspectos, es la menos atractiva.
Motores de firma.
o Es deseable una mezcla entre monofsico y trifsico, evolucionando los
primeros segn se vayan pudiendo abordar los esfuerzos.
o Evidentemente, el lenguaje de implementacin en el caso de la monofase
viene condicionado por la opcin escogida para el acceso a claves privadas.
o Una implementacin 100% JavaScript, incluso si el acceso a claves privadas
no est en JavaScript es tentadora ya que proporcionara compatibilidad
universal.

Pgina 24 de 24