Estudio Alternativas Applets Java Cliente Afirma 1.2

8/17/2019 Estudio Alternativas Applets Java Cliente Afirma 1.2

1/24

Alternativas a los Applets de Java enlas aplicaciones Web de firma

electrónica

Página 1 de 24

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/

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


2/24


electrónica

Página 2 de 24

HOJ DE CONTROL

Título Alternativas a los Applets de Java en las aplicaciones Web de firma electrónica

Nombre del

fichero

Alternativas a los Applets de Java en las aplicaciones Web de firma electrónica .pdf

Autor Tomás García -Merás

Versión 1.2 Fecha Versión 05/11/2013

Copyright MinHAP

Licencia CC-by-sahttp://creativecommons.org/licenses/by-sa/3.0/es/

Aprobado por MinHAP Fecha Aprobación 05/11/13

Nº Total de páginas 24

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


3/24


electrónica

Página 3 de 24

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


4/24


electrónica

Página 4 de 24

4.2 Reutilización de activos existentes en el proyecto @firma y estimación esfuerzo necesariopara cada solución ........................................................................................................................... 19

5 Tareas comunes independientes de opción de implementación ............................................... 20

6 Resumen ..................................................................................................................................... 23


5/24


electrónica

Página 5 de 24

1 Introducción

Desde hace ya tiempo, se vienen sufriendo ciertos problemas con Java que están poniendocada 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”, BlackBerry10, etc.) hasta los grandes problemas de seguridad que plantean (continuas vulnerabilidadesdescubiertas), pasando por las dificultades que los navegadores ponen a su ejecución, comoadvertencias 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 unaparte, se necesita una comunicación bidireccional con el JavaScript de la página Web (la firmaelectrónica es un paso más dentro de un completo flujo de trabajo) y, por otra, un acceso alos almacenes de claves y certificados, siendo por supuesto deseable el soporte de tarjetasinteligentes y dispositivos externos (como el DNIe).

En este sentido, son varias las opciones posibles, siendo tres las más asequibles y alineadascon 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 soluc ión

La mayoría de los navegadores Web soportan ampliaciones de su funcionamiento vía losllamados plugins y addons (extensiones). Estos se desarrollan habitualmente con tecnologíanativa (usualmente C o C++), teniendo muy pocas restricciones en lo referente al acceso alsistema operativo subyacente (y por lo tanto a los almacenes de claves) y permiten exponerun 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 escogidapor muchos componentes de firma electrónica), en la actualidad no es óptima, como acontinuación se explica, en su soporte (enumerando las distintas tecnologías) en las


6/24


electrónica

Página 6 de 24

siguientes plataformas operativas:

Microsoft Windowso 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 iOSo Safari no admite complementos.o Chrome no admite complementos.

Apple Mac OS Xo NSAPI/NPAPI para Safari, Chrome, Firefox y otros.

Google Androido Chrome no admite complementos.o Extensiones XPCOM para Mozilla Firefox.

Linuxo NSAPI/NPAPI para Chrome, Firefox y otros.

Otros entornoso 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 extensionesde navegador podría dar una buena experiencia de usuario en Chrome y Firefox tanto enLinux, 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 deMicrosoft.

No obstante, esta opción daría soporte a la gran mayoría de los usuarios, proporcionando unaexperiencia de usuario muy buena, ya que si se exponen las operaciones de firma víaJavaScript el usuario realmente no apreciaría ni cambios de contexto, ni advertencias, ninecesidad de acciones manuales ni otros efectos adversos que sí padecen los Applets deJava.

No obstante, se introduce un inconveniente realmente difícil de evitar, que no se encontrabacon los Applets de Java, y es la heterogeneidad de los entornos operativos, aspecto que afectaen dos sentidos:


7/24


electrónica

Página 7 de 24

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 cualimplica esfuerzos adicionales.

Distintas tecnologías de almacenes de claves y certificados que obligan a distintosdesarrollos, incluso para un mismo navegador.

o CAPI en Windows, Llavero en Mac OS X, el almacén central de Android, NSSpara 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 proyectosde desarrollo en diferentes entornos (Visual Studio, Xcode, GCC, etc.).

2.2 Reutil ización de activos exis tentes en el pro yecto @firm a yestimación esfuerzo necesario para cada solu ción

Extensión Active Xpara Internet Explorer

Dada la posibilidad de creación de controles ActiveX usando C# con .NET, es posible lareutilizació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 ActiveXcompletamente funcional:

Tarea Coste estimadoEstructura 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 aObjective C, muy ligado a sistemas Apple), sería posible reutilizar ciertos activos del Cliente


8/24


electrónica

Página 8 de 24

@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óncompletamente funcional:

Tarea Coste estimadoEstructura 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 losnavegadores Web

Si bien las extensiones de los navegadores Web constituyen en muchos casos una opciónviable para la realización de firmas electrónicas (hay que recordar que los Applets Java seejecutan con Java Plugin, que no es otra cosa que una extensión), lo óptimo sería que pudiesehacerse el 100% del proceso en JavaScript con las funcionalidades estándar que

proporcionan los navegadores, eliminando así la necesidad de binarios adicionales… Pordesgracia, el API JavaScript normal de los navegadores Web no incluye las funcionalidadesnecesarias.

Adicionalmente, sería un error acotar las funcionalidades necesarias a la implementación delas operaciones criptográficas (RSA, huellas digitales, etc.) en JavaScript, que si bien es unatarea difícil (JavaScript no está pensado para los tratamientos binarios que requiere ASN.1 ylos algoritmos RSA y de huellas digitales), lo cierto es que éste es una tema resuelto desdehace 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/

http://code.google.com/p/crypto-js/http://code.google.com/p/crypto-js/http://www.ohdave.com/rsa/http://www.ohdave.com/rsa/http://www.ohdave.com/rsa/http://code.google.com/p/crypto-js/


9/24


electrónica

Página 9 de 24

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

Partiendo de estos trabajos, se podría desarrollar la base para realizar cifrados RSA y huellasdigitales SHA-1 y SHA-2, más un API ASN.1 básico (lo indispensable para operacionesPKCS#1), y con reutilizaciones adicionales y un trabajo extra de consolidación, un buen APIJavaScript para X.509.

No obstante, esto no soluciona la incapacidad de acceder de forma segura a las clavesprivadas de los ciudadanos desde JavaScript, asegurando que en ningún momento éstasqueden 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 Sop or te del W3C a la crip to g rafía vía J avaSc rip t

Hace un tiempo que se publicó por parte del W3C el borrador de una especificación queresulta bastante interesante en este sentido. La Web Cryptography API(http://www.w3.org/TR/WebCryptoAPI/) , que cuenta con el soporte directo de Mozilla yGoogle (con lo que se adoptaría previsiblemente en Firefox y Chrome), más un apoyoalgo 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 aespecificació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íaprevisible su adopción por el resto del mercado (especialmente por Apple WebKit, quees la base de Apple Safari, Opera y el navegador de Android) y podría darse la impresiónde que el problema estaría resuelto. No es así ya que, si se entra en el detalle de laespecificación, se puede observar que lo que se propone es una implementación deciertas 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 estaraceleradas por el sistema operativo (y por hardware si este último lo soporta), pero nose 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 aspectosque la anterior dejaba sin hacerlo, la “WebCrypto Key Discovery”(https://dvcs.w3.org/hg/webcrypto-keydiscovery/raw-file/tip/Overview.html) . Una lecturacon detalle de la especificación muestra que es justo lo que se necesita: el acceso a

http://www-cs-students.stanford.edu/~tjw/jsbn/http://www-cs-students.stanford.edu/~tjw/jsbn/http://www.w3.org/TR/WebCryptoAPI/https://dvcs.w3.org/hg/webcrypto-keydiscovery/raw-file/tip/Overview.htmlhttps://dvcs.w3.org/hg/webcrypto-keydiscovery/raw-file/tip/Overview.htmlhttp://www.w3.org/TR/WebCryptoAPI/http://www-cs-students.stanford.edu/~tjw/jsbn/


10/24


electrónica

Página 10 de 24

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 apoyogeneralizado de la industria. Está promovida por Netflix con el interés de permitir modosavanzados de gestión de derechos digitales (DRM, básicamente sistemas anti-pirateríay anti-copia) y esta orientación choca con el modelo de negocio de Google (que obtienesus ingresos de la publicidad, en contraposición a la venta de activos digitales) y con elespíritu abierto de la Fundación Mozilla, por lo que no es previsible su soporte ni enChrome 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 laposible ampliación de la Web Cryptography API con funcionalidades que permitiesenreferenciar claves privadas pre-existentes para operaciones seguras de firmaelectrónica. La respuesta ha sido muy positiva (con involucración directa de laFundación Mozilla y Mozilla Hispano), siendo los pasos siguientes a recorrer unadefinición detallada del API necesario, más una implementación de referencia junto alresto de la especificación Web Cryptography API (posiblemente como una extensión deFirefox), mientras se propone como un API estándar (que vendría directamente con elnavegador, sin necesitar extensiones).

Por supuesto, sería necesaria también una coordinación cohesionada con Chromium yGoogle (igualmente con una extensión como implementación de referencia, intentandoreutilizar el máximo número de activos de la extensión de Firefox), y más adelante, yacon 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 yMicrosoft, 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 pro pu esta de tareas a realizar para la implem entaciónpr áct ic a de la alt ern ativ a

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 quepermita la realización de firmas electrónicas usando las claves privadas que elusuario tuviese instaladas en su navegador o sistema operativo.


11/24


12/24


electrónica

Página 12 de 24

W3C sobre criptografía, buscando en todo momento la reutilización y colaboraciónentre equipos de trabajo:

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

WebCrypto Key Discovery: https://dvcs.w3.org/hg/webcrypto-keydiscovery/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 Firefoxque 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 Dahlpara la W3C WebCrypto API (DOMCrypt: https://addons.mozilla.org/En-us/firefox/addon/domcrypt/) y con las futuras implementaciones de los API delW3C.

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 GoogleChrome / Chromium para Windows que use CAPI (Microsoft Crypto API) comoorigen de los certificados y las claves privadas del usuario.

Debe buscarse en todo comento una colaboración y coordinación con Google quepermita un trabajo conjunto en la implementación futura de los API del W3C.

http://www.w3.org/TR/WebCryptoAPI/https://dvcs.w3.org/hg/webcrypto-keydiscovery/raw-file/tip/Overview.htmlhttps://dvcs.w3.org/hg/webcrypto-keydiscovery/raw-file/tip/Overview.htmlhttps://addons.mozilla.org/En-us/firefox/addon/domcrypt/https://addons.mozilla.org/En-us/firefox/addon/domcrypt/https://addons.mozilla.org/En-us/firefox/addon/domcrypt/https://addons.mozilla.org/En-us/firefox/addon/domcrypt/https://dvcs.w3.org/hg/webcrypto-keydiscovery/raw-file/tip/Overview.htmlhttps://dvcs.w3.org/hg/webcrypto-keydiscovery/raw-file/tip/Overview.htmlhttp://www.w3.org/TR/WebCryptoAPI/


13/24


electrónica

Página 13 de 24

3.2.1.4 Tareas de normalización

Para asegurar que el API generado es una opción viable como estándar futuro demercado, deberán trabajarse en las siguientes líneas:

El Centro Criptológico Nacional (CCN: https://www.ccn.cni.es/) debe auditarlos trabajos y certificar la seguridad de los mismos.

Debe procurarse un trabajo con W3C, y en particular con Mozilla, Google yNetflix para intentar influir en los estándares desarrollados por estaorganización.

Debe procurarse un trabajo conjunto con Google y Mozilla, de forma que seintente que el API forme parte del núcleo JavaScript de Chrome y Firefox, conindependencia de si finalmente se corresponden con los trabajos del W3C.

Debe procurarse un contacto directo con Microsoft de forma que se puedatener 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 formade 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 eltratamiento seguro de claves privadas constituye la base mínima sobre la queimplementar firmas digitales, es necesario un trabajo adicional considerable parapoder construir firmas AdES completas, que se concreta en una serie de APIdesarrollados completamente en JavaScript.

CAdES

https://www.ccn.cni.es/https://www.ccn.cni.es/


14/24


15/24


electrónica

Página 15 de 24

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 deSoftware 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 laformación de firmas XAdES-BES/EPES completas, soportando al menos lassiguientes variantes:

Tipos de dereferenciación:

Local

Remota por HTTP o HTTPS cuando el destino de la referenciano suponga un problema de XSS ( Cross Site Scripting ).

Tipos de transformaciones:

XPATH

XPATH2

Enveloped

Base64

Modos de firma

Externally Detached

Internally Detached

Enveloped

http://mozilla.github.io/pdf.js/http://mozilla.github.io/pdf.js/


16/24


electrónica

Página 16 de 24

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 existentesde software libre (API XML, etc.) con licencia compatible y calidad apropiada.


Ningún activo actual del proyecto Cliente @firma sería directamente reutilizable, por lo quesería necesario el desarrollo desde cero (usando bibliotecas de software libre cuando seaposible) de la totalidad de los módulos:

Tarea Coste estimadoGeneral - 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 €


17/24


electrónica

Página 17 de 24

4 Opción 3: Uso de aplicaciones nativas invocadasmediante protocolo (protocolo a medida)

4.1 Descripción de la soluc ión

En la actualidad, el Cliente @firma ya implementa medios de firma electrónica desdeaplicaciones Web que prescinden de Applets de Java, extensiones de navegador y APInativos 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 lainvocación por protocolo de aplicaciones nativas.

La invocación por protocolo consiste en que una aplicación registra en el sistema operativoque es capaz de atender un determinado protocolo, de forma que cuando se produzca unallamada 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 sistemasoperativos y por miles de aplicaciones. Así, en cualquier entorno operativo, si se pide abriruna URI del tipo “http://”, se abrirá el navegador Web, y si pide abrir otra que empiece por“sip://” (Ses sion 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 queregistre el tratamiento de una URI cuyo esquema con seguridad no va a utilizar ninguna otraaplicación (por ejemplo “afirma://”). Así, cualquier llamada a este protocolo, hará que se abrala 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 lacarga 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) seinvocase recibiendo la URI completa, obteniendo entonces de ella qué es exactamente lo quedebe hacer (en este ejemplo simplificado, una firma CAdES con SHA512).

Si bien la invocación por protocolo consigue comunicar aplicación JavaScript en un navegadorWeb con una aplicación nativa que puede acceder a claves privadas de los ciudadanos sinexponer vulnerabilidades de seguridad, lo hace en un único sentido, siendo necesario

https://play.google.com/store/apps/details?id=es.gob.afirmahttps://play.google.com/store/apps/details?id=es.gob.afirma


18/24


electrónica

Página 18 de 24

implementar medios adicionales para devolver por parte de la aplicación nativa los datosfirmados al JavaScript que la invocó.

Dado que no se puede establecer una comunicación IP local (causaría problemas de XSS sila Web original está alojada con SSL), una solución es que la aplicación nativa la envíe alservidor donde se aloja la aplicación Web para que ésta, mediante JavaScript asíncrono, larecoja 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 unaserie 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 degestión de claves y certificados.

3. La App nativa deposita el resultado de la firma en un servidor intermediario medianteuna llamada a un servicio Web simple.

4. El navegador Web recoge el resultado de la operación del firma del servidorintermediario 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 entreaplicació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 eltránsito de su firma por la red en el camino desde la aplicación Web hacia el JavaScriptno implique peligro.


19/24


electrónica

Página 19 de 24

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 protocoloa medida asociándolo a una aplicación Java, lo cual permitiría la reutilización de los activosactuales del Cliente @firma en Java. Aunque las aplicaciones seguirían siendo Java, ya noserí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 menosacotado.


En los expedientes en curso del Cliente @firma se incluye ya soporte de invocación porprotocolo para la mayoría de los entornos:

Microsoft Windows 7, Vista, XP

o Soporte completo.

Apple OS X

o Soporte completo.

Linux

o Soporte completo.

Google Android

o PAdES y CAdES (carencia de XAdES monofásico).

Apple iOS

o CAdES (carencia de XAdES y PAdES monofásico).

Windows / Windows RT 8 y 8.1

o CAdES (carencia de XAdES y PAdES monofásico).


20/24


electrónica

Página 20 de 24

Para mejora del soporte, sería no obstante conveniente la ampliación del soporte monofásicodel Cliente @firma para Windows 8 a PAdES.

Tarea Coste estimadoCAdES - Ampliación motor CAdES a multifirmas 5.400 € PAdES - Adaptación iTextSharp 7.200 € PAdES - Motor PAdES 5.400 €

TOTAL 18.000 €

5 Tareas comunes independientes de opción deimplementación

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ácilobservar que el esfuerzo necesario para lograr la actual funcionalidad ha sido ingente, y porlo 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 quetoda 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 APIJavaScript estándar en los navegadores Web, ya que este código podría utilizarse sinmodificaciones no solo en cualquier cliente (Windows, iOS, Android, etc.), sino incluso enservidores.

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 seestá haciendo actualmente en el Cliente @firma para iOS).

No obstante, es un esfuerzo considerable, y el actual motor para iOScarece aún de soporte de contrafirmas y cofirmas.


21/24


electrónica

Página 21 de 24

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 arealizar es enorme.

o 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 CAdESsimple en .NET para Windows 8 perfectamente funcional.

o Android Afortunadamente, el trabajo sobre JSE es 100% compatible con

Android, por lo que este entorno operativo no presenta trabajoadicional, gracias a la buena calidad de los actuales activos delCliente @firma.

Motores PAdESo 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 oC++ es enorme. Aunque hay productos de Software Libre sobre losque empezar a trabajar (por ejemplo: http://podofo.sourceforge.net/),ninguno ofrece las facilidades de iText (las bibliotecas que usaactualmente 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 enC/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 esdesdeñ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 esteentorno operativo no presenta trabajo adicional (de nuevo gracias a laalta calidad de los activos actuales).

Si bien existe iTextDroid, una versión de iText para Android, elCliente @firma usa un desarrollo propio basado en este, yaque el original presentaba problemas en las firmaselectrónicas.


22/24


electrónica

Página 22 de 24

Motores XAdESo 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 danlas firmas XML (dereferenciaciones, transformaciones, modos,manifest, etc.) hace que cualquier aproximación al problema seaproblemática.

En este punto, vemos que si bien la parte de viabilidad de las alternativas viene dada por elacceso a los almacenes de claves desde JavaScript de forma segura (apoyándose en unaaplicación externa), el peso de la dificultad en la implementación puede estar en laimplementació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 proyectoCliente @firma (en verde módulos necesarios que pueden tener cierto nivel de reutilización,en azul aquellos que deben desarrollarse desde cero):

No obstante, todo problema tiene siempre distintas formas de resolverse, ya que estamosquizás olvidando que existen los llamados “procesos de firma en varias fases”, en los queparte del proceso, y es justo la composición del formato final de firma, se realiza en un servidor.

Motor CAdES C

AppApple

iOS

Extensión NSAPI/NPAPI

AlmacénNSS

LlaveroMac OS X

Motor CAdES C# / .NET

AppWindows

8 / RT

AppWindows

PhoneAplicaciónWindowsXP, Vista y

7Almacén PKCS#12

Motor CAdES Java

AppGoogleAndroid

AppletJava

Clientes Trifásicos C Clientes Trifásicos C# / .NET Clientes TrifásicosJava

Interfaz Esquema Protocolo URL o API JavaScript (nativo o vía extensiones de navegador)


23/24


electrónica

Página 23 de 24

Este modelo está ya implementado con éxito en el Cliente @firma, en producción para algunoscasos muy particulares (implantado en organismos como la Diputación Provincial de CiudadReal o el Ayuntamiento de Guadarrama), y permite reutilizar los activos existentes en Java enaplicaciones JEE, relegando a los clientes únicamente aquellas operaciones que siempredeben 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_Firma-electronica-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 Appletsde Java? No exactamente; más bien quiere decir que son soluciones parcialmente adecuadaspara la mayoría de los casos, mientras se desarrollan las tareas que permitan tener solucionesabsolutamente adecuadas para la mayoría de los casos.

Por ejemplo, el enfoque del firma multifase del Cliente @firma es tener al menos laimplementació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# (MicrosoftWindows 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 unafirma PAdES local, podría iniciar el desarrollo necesario, y mientras este finaliza, dar serviciocon 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 unade ella con sus ventajas y sus inconvenientes… ¿Cuáles de ellas deben abordarse? ¿Cuálesdeben descartarse? El carácter abierto y colaborativo del proyecto permitirá sin duda que setenga en cuenta la opinión de muchos y que muchos puedan colaborar en llevar a cabo lastareas…

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, promovidopor la W3C e implementado por Google, Mozilla, Microsoft y Apple, y apoyadotécnicamente por el equipo del Cliente @firma.

Aun si fuese viable, está a l menos a más de 12 meses de distancia…


24/24


electrónica

Página 24 de 24

o La opción más práctica y más compatible sería realizar aplicacionessusceptibles de ser invocadas por protocolo, usando Java allí donde fueseposible.

o Una opción intermedia serían las extensiones de los navegadores, aunquequizá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 compatibilidaduniversal.

Estudio Alternativas Applets Java Cliente Afirma 1.2

Documents

Transcript of Estudio Alternativas Applets Java Cliente Afirma 1.2