Versión: 1.2. Fecha: 05 de Noviembre de 2013

Transcripción

1 Alternativas a los Applets de Java en las aplicaciones Web de firma Versión: 1.2 Fecha: 05 de Noviembre de Página 1 de 24

2 HOJA DE CONTROL Título Alternativas a los Applets de Java en Nombre del Alternativas a los Applets de Java en.pdf fichero Autor Tomás García-Merás Versión 1.2 Fecha Versión 05/11/2013 Copyright MinHAP Licencia CC-by-sa Aprobado por MinHAP Fecha Aprobación 05/11/13 Nº Total de páginas 24 Página 2 de 24

3 Contenido 1 Introducción Opción 1: Extensiones en navegadores Web Descripción de la solución Reutilización de activos existentes en el y estimación esfuerzo necesario para cada solución Opción 2: API JavaScript normalizado y nativo a los navegadores Web Soporte del W3C a la criptografía vía JavaScript Detalle propuesta de tareas a realizar para la implementación práctica de la alternativa API Básico JavaScript Definición del API Implementación del API como extensión de Firefox Implementación del API como extensión de Chrome / Chromium Tareas de normalización API Extendido JavaScript PAdES XAdES Reutilización de activos existentes en el y estimación esfuerzo necesario para cada solución Opción 3: Uso de aplicaciones nativas invocadas mediante protocolo (protocolo a medida) Descripción de la solución Página 3 de 24

4 4.2 Reutilización de activos existentes en el y estimación esfuerzo necesario para cada solución Tareas comunes independientes de opción de implementación Resumen Página 4 de 24

5 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 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 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 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 ), 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

6 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

7 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 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 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 Instalador CAdES - Ampliación motor CAdES a multifirmas PAdES - Adaptación itextsharp PAdES - Motor PAdES XAdES - Motor XAdES TOTAL 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

8 @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 Estructura extensión XPCOM Instalador Windows Instalador Mac OS X Instalador Linux CAdES - Ampliación motor CAdES a multifirmas PAdES - Ampliación bibliotecas Haru para soporte firmas PAdES - Motor PAdES en lenguaje C XAdES - Motor XAdES TOTAL 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 s (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: Página 8 de 24

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

10 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 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. 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 API Básico JavaScript Definición del API La base del proyecto es la definición de un API JavaScript normalizado que permita la realización de firmas s usando las claves privadas que el usuario tuviese instaladas en su navegador o sistema operativo. Página 10 de 24

11 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 o En base al KeyUsage 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

12 W3C sobre criptografía, buscando en todo momento la reutilización y colaboración entre equipos de trabajo: Web Cryptography API : WebCrypto Key Discovery: https://dvcs.w3.org/hg/webcryptokeydiscovery/raw-file/tip/overview.html 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 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

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

14 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: https://github.com/ziyan/javascript-rsa Etc 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

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

16 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 y estimación esfuerzo necesario para cada solución Ningún activo actual del proyecto 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 General - API ASN.1 RSA basado en biblioteca software libre CAdES - Motor ASN.1 JavaScript CAdES - Motor CAdES PAdES - Ampliación JSPDF para soporte de firmas XAdES - Motor XAdES General - Extensión Firefox General - Gestión referencias claves privadas JavaScript TOTAL Página 16 de 24

17 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 ya implementa medios de firma 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 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 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 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 se realiza desde JavaScript en la aplicación Web de firma, en vez de la carga del 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 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

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

19 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 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 y estimación esfuerzo necesario para cada solución En los expedientes en curso del se incluye ya soporte de invocación por protocolo 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). Página 19 de 24

20 Para mejora del soporte, sería no obstante conveniente la ampliación del soporte monofásico del para Windows 8 a PAdES. Tarea Coste estimado CAdES - Ampliación motor CAdES a multifirmas PAdES - Adaptación itextsharp PAdES - Motor PAdES TOTAL Tareas comunes independientes de opción de implementación Observando las cifras del actual proyecto (http://devel.uji.es/sonar/dashboard/index/1993), con 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 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 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

21 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 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 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: ninguno ofrece las facilidades de itext (las bibliotecas que usa actualmente el 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 usa un desarrollo propio basado en este, ya que el original presentaba problemas en las firmas s. Página 21 de 24

22 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 (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) Clientes Trifásicos C Motor CAdES C Clientes Trifásicos C# /.NET Motor CAdES C# /.NET Clientes Trifásicos Java Motor CAdES Java App Apple ios 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