Download Comunidad "Cliente @Firma"

Alternativas a los Applets de Java en
las aplicaciones Web de firma
electrónica
Alternativas a los Applets de Java en las aplicaciones
Web de firma electrónica
Versión: 1.2
Fecha: 05 de Noviembre de 2013
http://creativecommons.org/licenses/by-sa/3.0/es/
Página 1 de 24
Alternativas a los Applets de Java en
las aplicaciones Web de firma
electrónica
HOJA DE CONTROL
Título
Alternativas a los Applets de Java en las aplicaciones Web de firma electrónica
Nombre del
Alternativas a los Applets de Java en las aplicaciones Web de firma electrónica.pdf
fichero
Autor
Tomás García-Merás
Versión
1.2
Copyright
MinHAP
Licencia
Aprobado por
CC-by-sa
MinHAP
Fecha Versión
05/11/2013
http://creativecommons.org/licenses/by-sa/3.0/es/
Fecha Aprobación
05/11/13
Nº Total de páginas
24
Página 2 de 24
Alternativas a los Applets de Java en
las aplicaciones Web de firma
electrónica
Contenido
1
Introducción .................................................................................................................................. 5
2
Opción 1: Extensiones en navegadores Web................................................................................ 5
2.1
Descripción de la solución ....................................................................................................... 5
2.2 Reutilización de activos existentes en el proyecto @firma y estimación esfuerzo necesario
para cada solución ............................................................................................................................. 7
3
Opción 2: API JavaScript normalizado y nativo a los navegadores Web ...................................... 8
3.1
Soporte del W3C a la criptografía vía JavaScript ..................................................................... 9
3.2
Detalle propuesta de tareas a realizar para la implementación práctica de la alternativa .. 10
3.2.1
API Básico JavaScript ..................................................................................................... 10
3.2.1.1
Definición del API ...................................................................................................... 10
3.2.1.2
Implementación del API como extensión de Firefox ................................................ 12
3.2.1.3
Implementación del API como extensión de Chrome / Chromium .......................... 12
3.2.1.4
Tareas de normalización ........................................................................................... 13
3.2.2
API Extendido JavaScript ............................................................................................... 13
3.2.2.1
PAdES......................................................................................................................... 14
3.2.2.2
XAdES......................................................................................................................... 15
3.3 Reutilización de activos existentes en el proyecto @firma y estimación esfuerzo necesario
para cada solución ........................................................................................................................... 16
4
Opción 3: Uso de aplicaciones nativas invocadas mediante protocolo (protocolo a medida) ... 17
4.1
Descripción de la solución ..................................................................................................... 17
Página 3 de 24
Alternativas a los Applets de Java en
las aplicaciones Web de firma
electrónica
4.2 Reutilización de activos existentes en el proyecto @firma y estimación esfuerzo necesario
para cada solución ........................................................................................................................... 19
5
Tareas comunes independientes de opción de implementación ............................................... 20
6
Resumen ..................................................................................................................................... 23
Página 4 de 24
Alternativas a los Applets de Java en
las aplicaciones Web de firma
electrónica
1 Introducción
Desde hace ya tiempo, se vienen sufriendo ciertos problemas con Java que están poniendo
cada día más difícil considerar los Applets de Java como una solución 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 ejecución, como
advertencias y diálogos de confirmación.
La sustitución de los Applets de Java por otra tecnología no es tarea fácil, ya que, por una
parte, se necesita una comunicación bidireccional con el JavaScript de la página Web (la firma
electrónica es un paso más 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 más asequibles y alineadas
con el proyecto Cliente @firma:
1. Desarrollo de extensiones para navegadores Web
2. Implantación de un API JavaScript normalizado
3. Uso de aplicaciones nativas con invocación por protocolo
2 Opción 1: Extensiones en navegadores Web
2.1
Descripción de la solución
La mayoría de los navegadores Web soportan ampliaciones de su funcionamiento vía los
llamados plugins y addons (extensiones). Estos se desarrollan habitualmente con tecnología
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 vía JavaScript para ser usados desde las aplicaciones Web.
No obstante, lo que hace unos pocos años no era tan mala opción (de hecho, fue la escogida
por muchos componentes de firma electrónica), en la actualidad no es óptima, como a
continuación se explica, en su soporte (enumerando las distintas tecnologías) en las
Página 5 de 24
Alternativas a los Applets de Java en
las aplicaciones Web de firma
electrónica
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 podría 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.
Sería necesario para Internet Explorer un desarrollo específico para el desarrollo de un control
ActiveX, si bien conviene tener en cuenta que no funcionaría en las versiones “UI Moderno”
de Windows 8 y 8.1, ya que la tecnología ActiveX está en pleno abandono por parte de
Microsoft.
No obstante, esta opción daría soporte a la gran mayoría de los usuarios, proporcionando una
experiencia de usuario muy buena, ya que si se exponen las operaciones de firma vía
JavaScript el usuario realmente no apreciaría 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 difícil 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:
Página 6 de 24
Alternativas a los Applets de Java en
las aplicaciones Web de firma
electrónica


Arquitectura de las extensiones de los navegadores.
o Siendo las extensiones habitualmente desarrolladas en código nativo, se
tienen que generar ejecutables para distintos entornos y arquitecturas, lo cual
implica esfuerzos adicionales.
Distintas tecnologías 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 almacén central de Android, NSS
para los almacenes de Firefox, etc.
El resultado final sería un núcleo de código común, y luego, en base a un esfuerzo adicional,
toda una colección de módulos de acceso a almacenes de claves y certificados y proyectos
de desarrollo en diferentes entornos (Visual Studio, Xcode, GCC, etc.).
2.2 Reutilización de activos existentes en el proyecto @firma y
estimación esfuerzo necesario para cada solución
Extensión Active Xpara Internet Explorer
Dada la posibilidad de creación de controles ActiveX usando C# con .NET, es posible la
reutilización de ciertos activos del Cliente @firma para Windows 8, entre los que encontramos:

El motor de firma CAdES.

La adaptación de las bibliotecas BouncyCastle para C#.
En este sentido, sería necesario ejecutar las siguientes tareas para cerrar un control ActiveX
completamente funcional:
Tarea
Coste estimado
Estructura control ActiveX
4.509 €
Instalador
7.200 €
CAdES - Ampliación motor CAdES a multifirmas
5.400 €
PAdES - Adaptación iTextSharp
7.200 €
PAdES - Motor PAdES
5.400 €
XAdES - Motor XAdES
27.000 €
TOTAL
56.709 €
Extensión NPAPI / NSAPI / XPCOM
Al haberse programado el motor CAdES para Apple iOS en C estándar (en contraposición a
Objective C, muy ligado a sistemas Apple), sería posible reutilizar ciertos activos del Cliente
Página 7 de 24
Alternativas a los Applets de Java en
las aplicaciones Web de firma
electrónica
@firma para Apple iOS, entre los que encontramos:

El motor de firma CAdES (incluidas las compilaciones ASN.1).

La adaptación de las bibliotecas OpenSSL.
En este sentido, sería necesario ejecutar las siguientes tareas para cerrar una extensión
completamente funcional:
Tarea
Coste estimado
Estructura extensión NSAPI/NPAPI
3.500 €
Estructura extensión XPCOM
3.500 €
Instalador Windows
1.800 €
Instalador Mac OS X
2.300 €
Instalador Linux
3.500 €
CAdES - Ampliación motor CAdES a multifirmas
11.500 €
PAdES - Ampliación bibliotecas Haru para soporte firmas
32.000 €
PAdES - Motor PAdES en lenguaje C
15.200 €
XAdES - Motor XAdES
32.000 €
TOTAL
105.300 €
3 Opción 2: API JavaScript normalizado y nativo a los
navegadores Web
Si bien las extensiones de los navegadores Web constituyen en muchos casos una opción
viable para la realización de firmas electrónicas (hay que recordar que los Applets Java se
ejecutan con Java Plugin, que no es otra cosa que una extensión), lo óptimo sería que pudiese
hacerse el 100% del proceso en JavaScript con las funcionalidades estándar 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, sería un error acotar las funcionalidades necesarias a la implementación de
las operaciones criptográficas (RSA, huellas digitales, etc.) en JavaScript, que si bien es una
tarea difícil (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 años, y se pueden encontrar trabajos previos en los que basarse:
 http://code.google.com/p/crypto-js/
 http://www.ohdave.com/rsa/
Página 8 de 24
Alternativas a los Applets de Java en
las aplicaciones Web de firma
electrónica


http://www-cs-students.stanford.edu/~tjw/jsbn/
Etc.
Partiendo de estos trabajos, se podría desarrollar la base para realizar cifrados RSA y huellas
digitales SHA-1 y SHA-2, más un API ASN.1 básico (lo indispensable para operaciones
PKCS#1), y con reutilizaciones adicionales y un trabajo extra de consolidación, 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 ningún 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 criptografía vía JavaScript
Hace un tiempo que se publicó por parte del W3C el borrador de una especificación 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 adoptaría previsiblemente en Firefox y Chrome), más un apoyo
algo más tímido por parte de Microsoft, quien expresa (a consultas del equipo del Cliente
@firma) su intención de soportarla en Internet Explorer, una vez pasase de borrador a
especificación final y fuese adoptada de forma general por la industria.
Con el soporte de tres grandes navegadores en un estándar promovido por la W3C sería
previsible su adopción por el resto del mercado (especialmente por Apple WebKit, que
es la base de Apple Safari, Opera y el navegador de Android) y podría darse la impresión
de que el problema estaría resuelto. No es así ya que, si se entra en el detalle de la
especificación, se puede observar que lo que se propone es una implementación de
ciertas operaciones criptográficas comunes (como cifrados RSA y firmas PKCS#1) a las
cuales se le daría un API normalizado en JavaScript. Esas operaciones podrían 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 especificación del W3C específicamente 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 especificación muestra que es justo lo que se necesita: el acceso a
Página 9 de 24
Alternativas a los Applets de Java en
las aplicaciones Web de firma
electrónica
claves privadas pre-provisionadas (previamente instaladas en el equipo del ciudadano).
De nuevo, existen inconvenientes, y son que la especificación no cuenta con un apoyo
generalizado de la industria. Está promovida por Netflix con el interés de permitir modos
avanzados de gestión de derechos digitales (DRM, básicamente sistemas anti-piratería
y anti-copia) y esta orientación choca con el modelo de negocio de Google (que obtiene
sus ingresos de la publicidad, en contraposición a la venta de activos digitales) y con el
espíritu abierto de la Fundación Mozilla, por lo que no es previsible su soporte ni en
Chrome ni en Firefox.
En esta difícil situación, una de las vías de avance abiertas desde el equipo del Cliente
@firma consiste en el inicio de contactos con la Fundación Mozilla para evaluar la
posible ampliación de la Web Cryptography API con funcionalidades que permitiesen
referenciar claves privadas pre-existentes para operaciones seguras de firma
electrónica. La respuesta ha sido muy positiva (con involucración directa de la
Fundación Mozilla y Mozilla Hispano), siendo los pasos siguientes a recorrer una
definición detallada del API necesario, más una implementación de referencia junto al
resto de la especificación Web Cryptography API (posiblemente como una extensión de
Firefox), mientras se propone como un API estándar (que vendría directamente con el
navegador, sin necesitar extensiones).
Por supuesto, sería necesaria también una coordinación cohesionada con Chromium y
Google (igualmente con una extensión como implementación de referencia, intentando
reutilizar el máximo número de activos de la extensión de Firefox), y más adelante, ya
con el API consolidado y las implementaciones de referencia, contactar con Microsoft.
Si se consiguiese la ampliación del estándar con el soporte de Mozilla, Google y
Microsoft, sería cuestión de tiempo verlo reflejado en Apple WebKit y, por lo tanto,
soportado en la práctica totalidad de las plataformas.
3.2 Detalle propuesta de tareas a realizar para la implementación
práctica de la alternativa
3.2.1 API Básico JavaScript
3.2.1.1 Definición del API
La base del proyecto es la definición de un API JavaScript normalizado que
permita la realización de firmas electrónicas usando las claves privadas que el
usuario tuviese instaladas en su navegador o sistema operativo.
Página 10 de 24
Alternativas a los Applets de Java en
las aplicaciones Web de firma
electrónica
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 serán como mínimo:
 Selección (segura) de una clave privada en base a su alias en el almacén
de claves y certificados del usuario.
 Esta operación 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 múltiples usos dentro de la misma sesión, con o sin
confirmación explícita (habilitando así el uso en firmas masivas).
 Se deberá poder establecer filtros en la selección de la referencia en
base a las características del certificado de su titular.
o
En base al número de serie del certificado.
o
En base al titular (sintaxis según RFC 2254).
o
En base al emisor (sintaxis según RFC 2254).
o
En base al KeyUsage
o
Otros filtros pre-construidos:

Uso de DNIe.

Cualificado de firma en base a su par de
autenticación.

Etc.
 Firma PKCS#1 de un contenido en Base64 usando una referencia a una
clave privada.
 Obtención 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
Página 11 de 24
Alternativas a los Applets de Java en
las aplicaciones Web de firma
electrónica
W3C sobre criptografía, buscando en todo momento la reutilización y colaboración
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 Implementación del API como extensión de Firefox
El API JavaScript definido deberá implementarse como una extensión de Firefox
que use NSS como origen de los certificados y las claves privadas del usuario,
incluyendo los módulos PKCS#11 que el usuario tuviese instalados en Firefox
(viendo el usuario final todos los módulos como un único almacén).
La extensión 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 extensión deberá ser desarrollada en colaboración con la Fundación Mozilla,
de forma que puedan coordinarse, primero con la actual extensión 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 Implementación del API como extensión de Chrome / Chromium
El API JavaScript definido deberá implementarse como una extensión 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 colaboración y coordinación con Google que
permita un trabajo conjunto en la implementación futura de los API del W3C.
Página 12 de 24
Alternativas a los Applets de Java en
las aplicaciones Web de firma
electrónica
3.2.1.4 Tareas de normalización
Para asegurar que el API generado es una opción viable como estándar futuro de
mercado, deberán trabajarse en las siguientes líneas:
 El Centro Criptológico 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 estándares desarrollados por esta
organización.
 Debe procurarse un trabajo conjunto con Google y Mozilla, de forma que se
intente que el API forme parte del núcleo 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 tecnologías en Internet Explorer.
 Se deberá trabajar en implementaciones de servicios de referencia con
organismos de “primera línea”, no solo como pruebas piloto, sino como forma
de influencia general. Por ejemplo:

Agencia Tributaria

Ministerio de Hacienda y Administraciones Públicas

Ministerio de Industria, Energía y Turismo.

Etc.
3.2.2 API Extendido JavaScript
Si bien el soporte de criptografía RSA, PKCS#1 y huellas digitales más el
tratamiento seguro de claves privadas constituye la base mínima 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
Página 13 de 24
Alternativas a los Applets de Java en
las aplicaciones Web de firma
electrónica
Tareas adicionales a realizar (cada tarea tiene dependencias con las anteriores):
 API de tratamiento binario básico sobre Base64.
 API ASN.1 completo.
 API X.509 completo.

Como mínimo tratamiento del TBSCertificate (To Be Signed),
del Principal de emisor y titular, de clave pública, número de
serie y KeyUsage.
 API CAdES.

Capaz de generar al menos CAdES-BES-EPES.

Contenido firma explícito o implícito.

SigningCertificatev1 o SigningCertificatev2.
Deberán 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):
Página 14 de 24
Alternativas a los Applets de Java en
las aplicaciones Web de firma
electrónica
 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 evolución.
3.2.2.2 XAdES
De forma análoga a CAdES, deberá implementarse un API que permita la
formación de firmas XAdES-BES/EPES completas, soportando al menos las
siguientes variantes:
 Tipos de dereferenciación:

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
Página 15 de 24
Alternativas a los Applets de Java en
las aplicaciones Web de firma
electrónica

Enveloping

Referencias con MANIFEST
Las tareas a desarrollar serían las siguientes:
 API XML genérico.
 API XML para transformaciones.
 API XML para dereferenciaciones.
 API XML para XMLDSig con atributos XAdES.
Como en el resto de tareas, debe buscarse la reutilización de activos existentes
de software libre (API XML, etc.) con licencia compatible y calidad apropiada.
3.3 Reutilización de activos existentes en el proyecto @firma y
estimación esfuerzo necesario para cada solución
Ningún activo actual del proyecto Cliente @firma sería directamente reutilizable, por lo que
sería necesario el desarrollo desde cero (usando bibliotecas de software libre cuando sea
posible) de la totalidad de los módulos:
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 - Ampliación JSPDF para soporte de firmas
45.000 €
XAdES - Motor XAdES
37.000 €
General - Extensión Firefox
3.500 €
General - Gestión referencias claves privadas JavaScript
5.500 €
TOTAL
142.200 €
Página 16 de 24
Alternativas a los Applets de Java en
las aplicaciones Web de firma
electrónica
4 Opción 3: Uso de aplicaciones nativas invocadas
mediante protocolo (protocolo a medida)
4.1
Descripción de la solución
En la actualidad, el Cliente @firma ya implementa medios de firma electrónica 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
invocación por protocolo de aplicaciones nativas.
La invocación por protocolo consiste en que una aplicación 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 aplicación.
Esta técnica 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 telefonía IP (Microsoft
Lync por ejemplo en un sistema Windows).
Trasladando esto al Cliente @firma, sería necesario desarrollar una aplicación nativa que
registre el tratamiento de una URI cuyo esquema con seguridad no va a utilizar ninguna otra
aplicación (por ejemplo “afirma://”). Así, cualquier llamada a este protocolo, hará que se abra
la aplicación 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 aplicación Web de firma electrónica, en vez de la
carga del Applet @firma, una llamada a este protocolo que contenga todo lo necesario para
realizar la operación de firma, por ejemplo:
“afirma://sign?data=DATOSAFIRMAR&alg=SHA512withRSA&format=CAdES”
Esto provocaría que nuestra aplicación nativa (una nueva versión 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 invocación por protocolo consigue comunicar aplicación JavaScript en un navegador
Web con una aplicación nativa que puede acceder a claves privadas de los ciudadanos sin
exponer vulnerabilidades de seguridad, lo hace en un único sentido, siendo necesario
Página 17 de 24
Alternativas a los Applets de Java en
las aplicaciones Web de firma
electrónica
implementar medios adicionales para devolver por parte de la aplicación nativa los datos
firmados al JavaScript que la invocó.
Dado que no se puede establecer una comunicación IP local (causaría problemas de XSS si
la Web original está alojada con SSL), una solución es que la aplicación nativa la envíe al
servidor donde se aloja la aplicación Web para que ésta, mediante JavaScript asíncrono, la
recoja cuando esté disponible.
El proceso resultante sería más o menos el descrito en la imagen:
1. El navegador Web invoca a una App nativa mediante una URI especial, indicando una
serie de información (datos a firmar, formato, opciones, etc.).
2. La App recibe los datos y realiza la firma electrónica usando las funciones nativas de
gestión 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 operación del firma del servidor
intermediario y continúa la ejecución de la lógica de negocio.
5. El resultado es que se consigue una comunicación bidireccional asíncrona entre
aplicación JavaScript y Aplicación nativa que permite prescindir de los Applets de Java.
Evidentemente, al proceso se le han añadido medidas de seguridad para que el
tránsito de su firma por la red en el camino desde la aplicación Web hacia el JavaScript
no implique peligro.
Página 18 de 24
Alternativas a los Applets de Java en
las aplicaciones Web de firma
electrónica
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 podría pensar en la posibilidad de registrar este tratamiento de protocolo
a medida asociándolo a una aplicación Java, lo cual permitiría la reutilización de los activos
actuales del Cliente @firma en Java. Aunque las aplicaciones seguirían siendo Java, ya no
serían Applets de Java, que es lo realmente problemático (por seguridad y compatibilidad) y,
al menos Windows, Linux y Mac OS X, estarían cubiertos con un esfuerzo más o menos
acotado.
4.2 Reutilización de activos existentes en el proyecto @firma y
estimación esfuerzo necesario para cada solución
En los expedientes en curso del Cliente @firma se incluye ya soporte de invocación por
protocolo para la mayoría de los entornos:

Microsoft Windows 7, Vista, XP
o

Apple OS X
o

PAdES y CAdES (carencia de XAdES monofásico).
Apple iOS
o

Soporte completo.
Google Android
o

Soporte completo.
Linux
o

Soporte completo.
CAdES (carencia de XAdES y PAdES monofásico).
Windows / Windows RT 8 y 8.1
o
CAdES (carencia de XAdES y PAdES monofásico).
Página 19 de 24
Alternativas a los Applets de Java en
las aplicaciones Web de firma
electrónica
Para mejora del soporte, sería no obstante conveniente la ampliación del soporte monofásico
del Cliente @firma para Windows 8 a PAdES.
Tarea
CAdES - Ampliación motor CAdES a multifirmas
PAdES - Adaptación iTextSharp
PAdES - Motor PAdES
TOTAL
5 Tareas comunes
implementación
independientes
Coste estimado
5.400 €
7.200 €
5.400 €
18.000 €
de
opción
de
Observando
las
cifras
del
actual
proyecto
Cliente
@firma
(http://devel.uji.es/sonar/dashboard/index/1993), con 30.000 líneas de código, es fácil
observar que el esfuerzo necesario para lograr la actual funcionalidad ha sido ingente, y por
lo tanto que el migrarlo a distintos lenguajes de programación, con distintas bibliotecas, no
será tampoco pequeño.
Lo cierto es que una implementación 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 optásemos por la vía de API
JavaScript estándar en los navegadores Web, ya que este código podría 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 implementación 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 aún de soporte de contrafirmas y cofirmas.
Página 20 de 24
Alternativas a los Applets de Java en
las aplicaciones Web de firma
electrónica
o
o
o

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 habría 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
desdeñable la dificultad de la tarea.
o Android
 Afortunadamente, el trabajo sobre JSE es 100% compatible con
Android con unas pequeñas 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 versión de iText para Android, el
Cliente @firma usa un desarrollo propio basado en este, ya
que el original presentaba problemas en las firmas
electrónicas.
Página 21 de 24
Alternativas a los Applets de Java en
las aplicaciones Web de firma
electrónica

Motores XAdES
o En cualquiera de los casos es necesaria una implementación 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 aproximación al problema sea
problemática.
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 (apoyándose en una
aplicación externa), el peso de la dificultad en la implementación puede estar en la
implementación de los motores de firma en los distintos formatos.
En general, se podría tener cierto nivel de reutilización de los activos actuales del proyecto
Cliente @firma (en verde módulos necesarios que pueden tener cierto nivel de reutilización,
en azul aquellos que deben desarrollarse desde cero):
Interfaz Esquema Protocolo URL o API JavaScript (nativo o vía extensiones de navegador)
App
Apple
iOS
Clientes Trifásicos C
Clientes Trifásicos C# / .NET
Clientes Trifásicos
Java
Motor CAdES C
Motor CAdES C# / .NET
Motor CAdES Java
Extensión NSAPI/NPAPI
Almacén
NSS
Llavero
Mac OS X
App
Windows
8 / RT
App
Windows
Phone
Almacén PKCS#12
Aplicación
Windows
XP, Vista y
7
App
Google
Android
Applet
Java
No obstante, todo problema tiene siempre distintas formas de resolverse, ya que estamos
quizás olvidando que existen los llamados “procesos de firma en varias fases”, en los que
parte del proceso, y es justo la composición del formato final de firma, se realiza en un servidor.
Página 22 de 24
Alternativas a los Applets de Java en
las aplicaciones Web de firma
electrónica
Este modelo está ya implementado con éxito en el Cliente @firma, en producción para algunos
casos muy particulares (implantado en organismos como la Diputación 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 pequeño resumen de la técnica 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 solución ideal si prescindiésemos de los Applets
de Java? No exactamente; más bien quiere decir que son soluciones parcialmente adecuadas
para la mayoría de los casos, mientras se desarrollan las tareas que permitan tener soluciones
absolutamente adecuadas para la mayoría de los casos.
Por ejemplo, el enfoque del firma multifase del Cliente @firma es tener al menos la
implementación de CAdES simple (sin cofirmas ni contrafirmas) en un modo tradicional
(ejecución 100% en el cliente) y por eso se están 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 solución sería una
firma PAdES local, podría 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… ¿Cuáles de ellas deben abordarse? ¿Cuáles
deben descartarse? El carácter abierto y colaborativo del proyecto permitirá sin duda que se
tenga en cuenta la opinión de muchos y que muchos puedan colaborar en llevar a cabo las
tareas…
A modo de resumen, se podría describir la situación actual como:
 Acceso a claves privadas y firma PKCS#1 (parte obligatoria en cliente)
o La opción deseable sería la implementación de un estándar Web, promovido
por la W3C e implementado por Google, Mozilla, Microsoft y Apple, y apoyado
técnicamente por el equipo del Cliente @firma.
 Aun si fuese viable, está al menos a más de 12 meses de distancia…
Página 23 de 24
Alternativas a los Applets de Java en
las aplicaciones Web de firma
electrónica
o

La opción más práctica y más compatible sería realizar aplicaciones
susceptibles de ser invocadas por protocolo, usando Java allí donde fuese
posible.
o Una opción intermedia serían las extensiones de los navegadores, aunque
quizás por eso, por quedarse corta en varios aspectos, es la menos atractiva.
Motores de firma.
o Es deseable una mezcla entre monofásico y trifásico, evolucionando los
primeros según se vayan pudiendo abordar los esfuerzos.
o Evidentemente, el lenguaje de implementación en el caso de la monofase
viene condicionado por la opción escogida para el acceso a claves privadas.
o Una implementación 100% JavaScript, incluso si el acceso a claves privadas
no está en JavaScript es tentadora ya que proporcionaría compatibilidad
universal.
Página 24 de 24