Algo después del verano de 2005 acabamos en Albalia Interactiva el sistema de firma electrónica en teléfonos móviles celulares que estuvimos desarrollando con Movistar.
Hago esta mención porque estos días se ha publicado que Vodafone ha logrado llevar a cabo la firma electrónica desde el móvil y parece que han sido los primeros en lograrlo.
No le quiero quitar mérito al asunto, porque ya he comprobado en mis carnes las dificultades de un proyecto de este tipo.
Pero creo que conviene poner en perspectiva el anuncio, respecto a la capacidad de innovación de cada operador, y a lo qué puede significar la innovación en un proceso que debería acabar con un producto en manos del público.
Hasta donde llegan mis noticias, el primer proyecto de firma electrónica desde el móvil se llevó a cabo en el año 2001, y lo acometió Safelayer en colaboración con Amena, entidad que participaba en su capital. En ese caso se trataba de firmar formularios a través de páginas WAP, en las que se disponía del protocolo WTLS y la posibilidad de tener certificados electrónicos (y sus claves privadas asociadas) en la tarjeta SIM del teléfono móvil. Uno de los retos del proyecto era la adaptación de una pasarela para que las firmas generadas en el lado WAP pudieran ser utilizadas en el lado HTML.
El proyecto de Albalia con Telefónica Móviles España (Movistar) pretendía firmar en un teléfono móvil mediante una tarjeta criptográfica que contuviera las claves y los certificados. La idea era que se pudiera utilizar con el DNI electrónico, aunque en aquel momento tuvimos que contentarnos con trabajar con prototipos del DNI-e.
El primer reto lo tuvimos cuando lo intentamos con teléfonos Java genéricos. En principio, todos los teléfonos celulares de última generación soportan java, sea cual sea el sistema operativo, pero las cosas no son tan fáciles. Para llevar a cabo la firma nos convenía que el teléfono implementara las funciones de MIDP 2 y eso limitaba mucho los teléfonos adecuados. A continuación necesitábamos teléfonos con la opción de incorporar un dispositivo lector de tarjeta chip (la famosa chipetera).
Un dato curioso es que los teléfonos móviles ya llevan un lector de tarjeta chip en su interior, puesto que lo necesitan para acceder a la SIM. Sin embargo, muy pocos incorporan un lector de tarjeta chip accesible desde el exterior. Los pocos modelos existentes, son unidades obsoletas de Motorola y Siemens que incorporaron lectores de tarjetas chip en proyectos desarrollados en torno al año 2000 cuando especificaciones como EMV y SET permitían vaticinar la adopción del teléfono móvil como sistema de pago asociado a una tarjeta bancaria.
La posibilidad de usar lectores externos de tarjeta chip redujo mucho el abanico de teléfonos móviles adecuados, y nos obligó a centrarnos en teléfonos móviles operados con sistemas operativos derivados de Windows CE. De hecho el ordenador de mano HP Jornada 720 (con la variante de sistema operativo Handhel PC2000) ya incluia lector de tarjeta chip, lo que parecía bastante prometedor.
La mala noticia es que, aunque según la información técnica de Microsoft existen lectores de tarjeta chip para Windows CE o Pocket PC, los modelos referenciados operan a través de RS-232 (lo que delata la antiguedad de la valoración), interfaz que la mayor parte de los modelos actuales no incorporan.
Necesitábamos un lector de tarjeta chip que se pudiera acoplar a un teléfono TSM-500 (equivalente al XDA II, al iMate Pocket PC o al Qtek 2020), o bien por la conexión del Craddle (la cuna de sincronización, existente en prácticamente todas las PDA y agendas con software Windows Pocket PC), o bien por la conexión SDIO (destinada originalmente para tarjetas de ampliación de memoria). Además el lector debería tener drivers PC/SC para Windows CE (en las versiones de base del sistema operativo 3.0, 4.2 o 5.0) o sus evoluciones como Windows Mobile (2002, 2003 y 2005), Windows Pocket PC o Windows Smartphone. Esto era imprescindible para poder utilizarlo dentro de las posibilidades que nos proporciona la Cripto API en Windows CE (que alcanzarían el máximo si pudiéramos contar con los drivers CSP, también para Windows CE de la tarjeta inteligente).
Después de mucho buscar, sólo encontramos un modelo que era fantásico desde el punto de vista de prestaciones y de factor de forma, porque encajaba perfectamente en la conexión de Craddle de la TSM-500, pero que en ese momento no tenía driver PC/SC. Contactamos con el Proveedor australiano, y mantenemos la puerta abierta para utilizarlo en futuros proyectos.
Sin embargo, esa linea de trabajo quedó en suspenso mientras aparecían los dichos drivers.
A través de C3PO encontramos un lector de tarjeta inteligente PCMCIA (el modelo 4040) con drivers PC/SC para Windows CE. La colaboración de C3PO con Albalia (o particularmente, la de Jorge Gómez, su Director General, conmigo) siempre ha sido muy buena y en este proyecto fue muy importante.
La buena noticia es que pudimos avanzar bastante en el desarrollo, aunque (la mala noticia) tuvimos que utilizar un entorno diferente al definitivo: la tarjeta PCMCIA 4040 se insertaba en un adaptador PCMCIA a CompactFlash (allí comprobamos que ambas conexiones son eléctricamente equivalentes aunque el factor de forma es distinto) y este en una PDA con conexión Compact Flash. Todavía no teníamos un lector SDIO pero ya podíamos empezar a entablar diálogo con la tarjeta chip del prototipo de DNI electrónico.
En esta fase del proyecto tuvimos que firmar un Acuerdo de Confidencialidad muy riguroso con la FNMT para acceder a la información de la tarjeta, y en particular sus comandos de bajo nivel APDU.
De esta forma podíamos pedirle a tarjeta que firmara un Hash con la clave privada y leer del directorio apropiado de la tarjeta el certificado asociado. Fue una proceso complejo buceando en una maraña de información y con el objetivo de generar un PKCS#7 en el entorno de la PDA.
Normalmente, generar un PKCS#7 no es un problema, porque es relativamente sencillo generarlo programando mediante la Cripto API. El problema es que no teníamos el CSP de la tarjeta criptográfica para Windows CE, y, por tanto las funciones de programación de Windows ignoraban la existencia de la tarjeta. Además las funciones de la Cripto API no permiten un uso «a trozos» de las operaciones atómicas de la firma. Así que, además, teníamos que acometer por nuestra cuenta el reto de generar un PKCS#7 bien formado. Otra vez vuelta a estudiar las especificaciones ASN.1 de la norma y a interpretar las Basic Encoding Rules (BER) para poder generar nuestro propio PKCS#7. Y esto tras intentar primero extraer la función correspondiente de librerías como OPENSSL y otras. Lo cierto es que en todas las librerías en las que están disponibles los fuentes, las generación del PKCS#7 está absolutamente enmarañada con otras cosas, y no era práctico ni extraer lo básico, ni moverlo todo a Windows CE. Demasiadas dependencias.
Al final lo logramos. Generamos nuestra propia interficie con la tarjeta chip, con nuestra propias funciones y librerías, lo que nos permite implementar tanto un driver CSP como PKCS#11 para el DNI electrónico en Windows CE.
Ya solo nos faltaba el dispositivo lector.
Tras mucho investigar, encontramos un lector de tarjetas inteligentes con interfaz SDIO, desarrollado originalmente para el Departamento de Defensa norteamericano.
Disponía de drivers PC/SC, por lo que pudimos adaptar todos los desarrollos que habíamos hecho para la PCMCIA con cierta facilidad.
Cuando hicimos la entrega del proyecto, nos atrevimos con algo a lo que nos debería haber disuadido nuestro profundo conocimiento de las Leyes de Murphy. Instalamos nuestri entorno en un teléfono nuevo que Movistar lanzaba por esas fechas: el Qtek S100. No lo habíamos probado. Simplemente los especialistas en firma electrónica en móvil de Telefónica Móviles tenían un equipo por allí y nos animamos a intentarlo el mismo día de la entrega. ¡Funcionó!
Instalamos los drivers en el S100, insertamos el conector del lector de tarjeta chip en la ranura SDIO del móvil, instalamos nuestra aplicación en el móvil, insertamos la tarjeta con un certificado autogenerado y otra con un certificado generado por un PSC (todavía no teníamos DNIs electrónicos auténticos) elegimos un fichero existente en el móvil y Voilá. Nos pedía el PIN y generaba el PKCS#7 que podíamos leer después en un ordenador con Windows.
Fue un proyecto largo y duro, pero del que nos sentimos muy orgullosos.
Por cierto, hasta donde yo sé, somos los únicos que tenemos este know-how, por lo que aquellos interesados en desarrollar aplicaciones para el DNI electrónico en dispositivos móviles, teléfonos y PDAs basados en Windows CE, deberían contactar con nosotros.
Por lo menos para adquirir la chipetera SDIO ya que nos hemos hecho distribuidores de estos dispositivos.
Por concluir, hay que reconocer que Amena fue el primer operador móvil en disponer de firma en teléfonos móviles WAP, Movistar el siguiente, pero esta vez con capacidad de firmar con tarjetas externas, como es el caso del DNI electrónico, y Vodafone el último operador en disponer de esta tecnología (y además en la opción «fácil» de instalar el certificado en la SIM).
Se trata de una aplicación de banca electrónica pionera en España, desarrollada de forma nativa para el canal móvil
Gracias a la incorporación de esta nueva versión de su banca móvil, la caja gallega continúa en la vanguardia de las soluciones financieras en movilidad, al ser la primera entidad española que presenta una aplicación nativa para el sistema Windows Phone 7. La fácil navegación y el fluido funcionamiento de la misma ha hecho que Microsoft la promocione en su canal de tecnología MSN como una de las cinco mejores aplicaciones de Windows Phone 7.
Todo es electrónico 