Decisiones Técnicas en Tractis: Componente de creación de firma

En el post anterior comenzábamos a describir decisiones arquitectónicas y de diseño que tomamos en el desarrollo de Tractis. Comentábamos nuestra experiencia a la hora de afrontar el reto de crear una infraestructura como la nuestra, donde diversos componentes heterogéneos en su función y base tecnológica se unen para componer un único servicio.

Como ya explicamos, podríamos haber optado por emplear una única tecnología para dar solución a todos los problemas. De este modo usaríamos un único lenguaje, un único paradigma y una única plataforma para dar solución a todos los retos que nos encontrábamos.

No obstante, descartamos esta idea ya que no existía una única tecnología óptima a la hora de cubrir todos los requisitos funcionales que se nos planteaban.

Así optamos por usar Ruby on Rails para la confección de nuestro frontal web, dado el enorme potencial para desarrollar aplicaciones de este.

Pero no solo por un tema de rapidez, sino sobretodo por su robustez y una capacidad de evolución y crecimiento excelentes.

No obstante a la hora de desarrollar Tractis no solo tuvimos que desarrollar un website a la usanza sino que este “frontend” ,aún siendo la más palpable por el usuario , es sólo una parte de nuestra infraestructura.

Nos topamos con una serie de decisiones tecnológicas y arquitectónicas que escapaban de lo que Ruby on Rails podía ofrecernos que venían derivadas de una de las funcionalidades más valiosas de las que aportamos: la firma de contratos.

El proceso de firma

Para nosotros con Tractis la gente que nos use debe poder firmar y además no debe poder firmar de cualquier modo, sino debe poder firmar con las garantías necesarias.Estas afirmaciones pueden parecer obvias y sin demasiado contenido, pero si nos paramos a analizar las consecuencias técnicas derivadas de ellas veremos que no es tan trivial.

Nuestros usuarios son gente que usa diferentes tecnologías de firma como tokens, tarjetas de identidad o certificados software que son emitidos por diferentes prestadores, de diferentes países y corriendo sobre diferentes navegadores y sistemas operativos.

Además las firmas deben ser fiables, con lo cual debemos dar las máximas garantías de que el firmante esta capacitado para poder ejercer la firma, validándola posteriormente para evitar fraudes.

Posteriormente debemos archivarla de manera segura, aplicando medios de preservación electrónica longeva por si en un futuro surgen disputas poder aportar las pruebas necesarias.

Estos condicionantes delimitan claramente diversos componentes complementarios de nuestra infraestructura: una aplicación de creación de firma, una aplicación de validación y una de custodia de documentos firmados.

Hablar de todos dos componentes sería demasiado para un post así que lo espaciaré en varios para hacer menos denso el contenido de los mismos.

Empezaré explicando nuestro componente de creación de firma para ver con un poco más de detalle todo lo que involucra el acto de “Apretar el botón de firma”.

Componente de creación de firma

El proceso de firma se diferencia principalmente del común de los procesos que se llevan a cabo en internet en que se invierte el paradigma productor/consumidor. Normalmente los navegadores piden un contenido a los servidores y una vez recibido se encargan de “renderizarlo” para mostrarlo al cliente. En el caso de la firma el servidor es el que requiere una acción del cliente (que realice la firma) que una vez realizada será validada y almacenada por éste.

Este proceso es así ya que las claves con las cuales el cliente firmará se encuentran dentro de un dispositivo criptográfico, hardware o software, y estas no salen del equipo del cliente en ningún momento, con el fin de que la custodia de las claves sea ejercida íntegramente por el usuario.

Como ya hemos comentado el cliente no tiene un perfil tecnológico concreto, desde el punto de vista de escenario desde el que se realizara la firma.

Así podemos tener un cliente que firme con Internet Explorer utilizando certificados almacenados en su Electronic Id Card (en el caso español sería nuestro dnie) mientras que otro puede firmar usando Linux con un token criptográfico desde Firefox y en ambos la experiencia y resultado de la firma deben ser equivalentes.

Este escenario se complica cuantos mas casuísticas intentamos cubrir, dado que la complejidad se multiplica con cada nuevo actor que vamos introduciendo. Así que no podíamos optar por una solución ligada a una tecnología concreta.

Hay muchos y buenos componentes de firma ligados a tecnologías o navegadores concretos. En estas categorías podemos encontrar por ejemplo componentes de firma Active X de Microsoft para su Internet Explorer o librerías de firma de Mozilla para su uso desde Javascript.

El problema es que estos componentes están ligados a la tecnología sobre la que corren y eso implica que intentar introducir navegadores/sistemas operativos nuevos en escena implica un coste de desarrollo y mantenimiento terrible.

Y entonces llegó Java

Una de las principales bondades de Java ,o almenos en sus inicios fue una de las mas laureadas, era el que solo debía llevarse a cabo un único desarrollo, compilar una única vez y el resultado podía ser distribuido y ejecutado en cualquier máquina.

Pero como dice el refrán : “hecha la ley, hecha la trampa” y la trampa en este caso es que debes tener una máquina virtual Java para poder correr programas realizados en éste lenguaje.

Aún así, es algo fenomenal el poder realizar un único desarrollo que corra de la misma manera en cualquier plataforma, sobretodo en el mundo internet. Desgraciadamente Java en internet en el lado del cliente es algo que comenzó con mucha fuerza cuando el Applet era aún un componente respetado, pero que ha caído en ,un inmerecido todo sea dicho, desuso.

A nuestro juicio, un de los errores mas comunes con los Applets es que eran usados para tareas en las que no destacan demasiado como por ejemplo como componente visual cuando para tal fin existían tecnologías muy superiores como flash o similares.

No obstante los Applets tienen un enorme potencial en otros campos mas cercanos a la lógica de negocio y alejados de la presentación de contenidos, dado que permiten correr aplicaciones Java dentro del navegador. Si algo podemos decir sobre Java es que dispone de un increíblemente bien diseñado sistema de librerías criptográficas, que además puede ser empleado en su totalidad dentro de los Applets.

Java y la firma digital.

Una de las cosas que nos hicieron decantarnos por Java como tecnología para implementar la infraestructura de creación de firma fue el excelente soporte que tiene para la criptografía y en especial para la firma digital.

No solo dispone de diferentes proveedores criptográficos, con lo cual no debes limitarte al uso del proveedor creado por el Sun, sino que puedes emplear proveedores de otros fabricantes e incluso de diferentes naturalezas y todo esto sin alterar la lógica de tu aplicación.

Ésto significa que podemos tener, mediante un único código, un componente que realice operaciones criptográficas que de soporte a diferentes tipos de dispositivos criptográficos y sobre diferentes plataformas.

Así, la complejidad de tratar con los diferentes dispositivos queda asumida por la máquina virtual y nosotros vemos su manejo a mucho mas alto nivel, evitando adaptar nuestro código a funcionamientos ad-hoc de cada tecnología de firma concreta.

De este modo trabajamos entonces con claves, certificados y firmas según interficies definidas y a muy alto nivel, sin la necesidad de bajar a detalles para particularizar el como o dónde se almacenan los certificados y las claves del usuario.

Esta abstracción revierte también en la simplicidad, robustez y reducción de tamaño del Applet, gran ventaja si es un componente que el usuario debe descargar a su navegador antes de poder firmar.

Para profundizar en el tema de criptografía en Java y para quien tenga interés en el tema recomiendo consultar alguna de la amplia documentación sobre la arquitectura criptográfica de Java como por ejemplo la editada por Sun o por grupos dedicados como Bouncy Castle.

Usando Java 1.6

Una de las decisiones más complicadas a tomar en el campo de aplicaciones que requieren el uso de Applets y Java en general es cual debe ser la versión mínima soportada de máquina virtual. Aquí, si escoges una versión demasiado novedosa tus usuarios deben actualizar su máquina virtual, mientras que si eliges dar soporte a máquinas virtuales ya obsoletas dejas fuera las funcionalidades añadidas en las últimas versiones.

En nuestro caso optamos por usar la última versión de máquina virtual de Java disponible actualmente, la máquina virtual de Java 1.6 (o 6.0). Esta versión aporta un gran número de mejoras sobre las capacidades criptográficas de Java sobretodo en el campo de soporte a las diferentes tecnologías de almacenamiento de certificados.

Usando ésta nueva versión podemos dar soporte de firma en Tractis a los certificados almacenados en ciertos tipos de repositorios hasta ahora no soportados por la máquina virtual sin el uso de librerias adicionales, como por ejemplo los que provee Windows mediante su Crypto API.
Dar soporte a este tipo de tecnología es vital para cumplir el fin de intentar hacer llegar la firma de Tractis al mayor número de usuarios posibles ya que són un gran porcentaje en el mercado actual de los certificados que se almacenan usando esta tecnología.

Y es que en la versión 1.6 de Java Sun ha añadido soporte para nuevos tipos de repositorios a los tradicionales JKS, PKCS#12 y demás. Así, sin la necesidad de requerir ninguna librería extra, nuestro componente de firma local puede abarcar mas tipos de repositorios, facilitando un poco más la integración de diferentes tipos de certificados .

Conclusiones

En este primer post sobre los componentes de firma hemos esbozado brevemente algunas de las razones que nos llevaron a adoptar Java como tecnología para la confección de nuestro componente de creación de firma. Hemos comentado además el porque de que el componente de firma sea local y como es posible que podamos dar soporte multi navegador/sistema operativo.

En próximos posts hablaremos de decisiones de diseño similares pero referidas al sistema de validación y custodia de firmas que empleamos como parte de nuestro backend de firma digital cerrando el círculo de los componentes empleados para asegurar los contratos en Tractis.

Por David García
Guardado en: Anuncios | 5 comentarios » | 4 de Febrero de 2008

5 Comentarios en “Decisiones Técnicas en Tractis: Componente de creación de firma”

Gravatar de Francisco

Francisco
4 de Febrero de 2008 a las 3:05 pm    

Como siempre, muchas gracias por tan excelente post, que sin duda ayuda a los que estamos metidos en iniciativas emprendedoras. :-)

Gravatar de Roger Carhuatocto

Roger Carhuatocto
21 de Febrero de 2008 a las 4:01 pm    

Hola David!
Esta misma situación pasamos hace algunos añitos: “¿qué tecnologia usamos para firma digital en el lado cliente web?”, pues el problema fue la interoperabilidad en el lado cliente pero no por la creación de firma, sino por el acceso a las claves durante la creación de la firma.

La solución fue también Java applet y el soporte de la comunidad Open Source. Encontramos un Java Applet Open Source que firma y que accede a las claves/certificados. Lo interesante de este applet es su capacidad de acceder a diferentes keys storages (pkcs12, smart card via pkcs11 y/o CAPI,etc.) a través de java plugins y que funciona en windows al 100% y en linux algo menos del 100%.

Puedes crear una interfase Java-JavaScript para controlar el applet, ya hay unos ejemplos. También puedes crear tu plugin para que acceda al DNIe y dejar el rendering del documento y su firma a Ajax, DHTML, PDF… o cualquier equipo de futbol.

En fin, el applet se llama OpenSign y el link es: http://www.openoces.org/opensign

Bon profit!!

-roger

Gravatar de David Garcia

David Garcia
21 de Febrero de 2008 a las 4:32 pm    

Muchas gracias por el comentario Roger. Es agradable ver que profesionales con tanto peso en el sector nos leen :) .

Hay muchas soluciones open source y opensign es una bastante buena. De hecho las primeras versiones de tractis lo usaban pero optamos por desarollar nuestro propio componente ya que debemos dar soporte a Windows, Linux y Mac y permitimos el uso de certificados y claves dentro del repositorio de windows, del de Mac dentro de PKCS#11 y PKCS#12.

Además esto para las diferentes autoridades de certificación del país que usan desde Tokens, tarjetas … cada una de un fabricante y no todas las que soportamos estan perfectamente integradas en Java.

De hecho esta semana salimos dando soporte al eID Belga , no soportado por la máquina virtual de Java (nisiquiera con la 1.6), pero que en tractis hemos conseguido hacer funcionar con un poco de ayudita de amigos Belgas .

un saludo

Dave Garcia

Gravatar de perikitown

perikitown
17 de Marzo de 2008 a las 7:42 pm    

Ya que usais gran cantidad de componentes open source, ¿os habeis planteado la posibilidad de devolver parte de lo recibido desinteresadamente a la comunidad open source? El soporte de nuevos medios de firma para Opensign puede ser un magnífico ejemplo.

Felicidades por el éxito merecido.

Gravatar de David García

David García
18 de Marzo de 2008 a las 1:07 pm    

Estamos considerando el ir gradualmente contribuyendo componentes de nuestra infrastructura como open source. Las primeras acciones incluirian componentes como la funcionalidad de firma, pero de momento estamos en procesos de decisión del como y cuando podremos estar en disposición de hacerlo.

Muchas gracias y un saludo

Dave Garcia

Más entradas en Negonation Blog