Archivo de la categoría: Criptografía

Firma electrónica en el teléfono móvil celular con Movistar

11 respuestas

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.

Camisa para TSM-500Necesitá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.

Smartcard SDIO ReaderAl 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).

El algoritmo de hash del DNI electrónico

7 respuestas

Estos días he leido muchas tonterías (a mí me lo parecen) sobre si el SHA-1 es malo y lo único bueno es el SHA-256 y sobre lo que esto implica en el nuevo DNI electrónico.

Lo cierto es que desde hace unos pocos años, algunas personas afirman de oidas que se ha roto el MD-5 o el SHA-1.

Lo que ha sucedido es que se ha demostrado que la probabilidad de encontrar dos documentos distintos con el mismo hash, siendo muy pequeña, es menos pequeña de lo que se sospechaba cuando se diseñó el algoritmo.

Con esto en mente, podemos afirmar que no es cierto que unos algoritmos de hash sean buenos y otros malos, así sin más.

En todo caso, no hay algoritmos buenos, sino más o menos vulnerables a determinados tipos de ataque.

Y, desde luego, la mejor opción es utilizar 2 algoritmos de hash simultáneamente.

Lo que esto quiere decir es que si, sumando casualidades, somos capaces de generar un documento que tiene una información que nos interesa y con el que queremos sustituir a otro para el que se ha calculado el Hash, habremos conseguido que el hash firmado para el documento sustituido ampare al documento con el que lo sustituimos.

En general, en documentos estructurados esto es imposible incluso con mecanismos de hash "·malos" porque es importante preservar la legibilidad y consistencia del documento. No es lo mismo con ficheros gráficos o con ficheros que tengan áras de "pad" (de manipulación) porque es posible manipular esas áreas o los bits menos significativos del gráfico hasta que el fichero entre por el aro (lo que tampoco es nada fácil).

De todas formas, cuando existen dos algoritmos de hash simultáneos, lo que podamos hacer para "arreglar" el fichero de cara a un Hash, nos lo "descojona" de cara al otro.

En definitiva, el certificado incluido en el DNI electrónico es lo suficientemente seguro ya que el hash generado con SHA-1 implica que no es posible generar otro certificado con el mismo aspecto y cambiando algunos datos según nos interese. Pero ya es la releche al volver a firmar por la CA el SHA-256 del mismo contenido. Aunque no podamos utilizarlo ni con Internet Explorer, ni con Opera, ni con Firefox. Es, desde luego, INFALSIFICABLE.

Otro aspecto distinto es la manera en la que firmemos nosotros nuestros documentos con el DNI electrónico. Ahí sí que podemos hacer lo que queramos. Por ejemplo, desarrollar por nuestra cuenta un programa de software que utilice formatos no estándar al cifrar y al descifrar (firmar y comprobar la firma), y que emplee MD-4, MD-5, SHA-1 y SHA-256 simultánemaente.

A ver si vamos a ser muy paranóicos con las gilipoyeces y luego no comprobamos si el certificado está revocado o no.

Firma electrónica y servicios de certificación electrónica

Deja un comentario

El pasado 29 de octubre de 2003 tuvo lugar en la sede de la Editorial El Derecho un encuentro propiciado por la editorial junto con la Asociación Española de Derecho y Propiedad Intelectual (AEDPI), en la que tuve la oportunidad de participar, para debatir sobre un tema innovador y de  actualidad: La firma electrónica y los servicios de certificación.

Se incluye a continuación el resumen publicado en la  Revista de la Asociación de Antiguos Alumnos – Centro de Estudios Garrigues en su número de diciembre de 2003

Asistieron a este debate  José Luis Terrero Chacón, Magistrado de la Audiencia Nacional y miembro del Consejo Editorial del El Derecho Editores; José Daniel Sanz Heredero, Letrado jefe de la Sección de informática Judicial del C.G.P.J. y Magistrado de la Sala Contencioso Administrativa del T.S.J. de Madrid; César Belda Casanova, Director General de la Fundación para el Estudio de la Seguridad en las Comunicaciones (FESTE) y vocal de la Comisión de Control Informático del Colegio de Notarios; José María Anguiano Jiménez, Socio responsable de Nuevas Tecnologías de la firma Garrigues y Secretario General de la AEDPI; Julián Inza Aldaz, Director General de AC Camerfirma, S.A. y, como moderador del debate, intervino Alfonso García Catalán, Jefe del Área de Calidad y Desarrollo Estratégico (CERES) Fábrica Nacional de Moneda y Timbre.

En este apasionante debate se valoraron los aspectos más significativos del nuevo Proyecto de Ley de firma electrónica, que sustituirá al prematuro Real Decreto Ley 14/1999, aprobado tres meses antes que su norma rectora: la Directiva Comunitaria 1999/93/CE.

El nuevo marco normativo de la firma electrónica

Coincidieron los presentes  en la creencia de que el nuevo marco normativo, claramente influido por una política liberalizadora, pone fin, en palabras de César Belda, a una situación de facto de monopolio de la Fábrica Nacional de Moneda y Timbre para abrir la entrada a otros operadores en el mercado de la certificación.

La clave del éxito –según José María Anguiano– descansará en las propias prácticas y políticas de los Prestadores de servicios de certificación (PSC). Se generará, explicó, un auténtico mercado basado en la confianza, donde resultarán favorecidas las entidades que cuenten con mecanismos de confianza sólidos que las avalen.

La firma electrónica: su necesidad

Sobre la necesidad, o no, de la firma electrónica, José Luis Terrero afirmó que “la prueba seguirá siendo prueba, ya esté el documento firmado electrónicamente o mediante un grafismo”, de forma que, continuó diciendo, “al final un correo electrónico se puede convertir a fin de cuentas –de no impugnarse por la parte a quien perjudica- en un documento que despliegue con todo su vigor efectos probatorios, al igual que otro basado en tecnología de firma electrónica con criptosistemas asimétricos”.

En relación a este particular, Julián Inza consideró que no debe ser siempre necesaria la certificación. En este sentido, precisó, el cruce de correos electrónicos con personas conocidas, implica, la mayoría de las veces, para el destinatario una presunción de validez de la autoría del mensaje recibido.

El problema surge, explicó Julián Inza, en determinadas ocasiones, cuando el negocio jurídico o la declaración de voluntad inserta en el documento electrónico pretende vincular al autor de la misma frente al receptor, ya que de impugnarse el documento en sede judicial resultaría sencillo acreditar por un perito la falsificación de un e-mail, porque las técnicas con las que contamos en la actualidad lo permiten y, por ende, la posibilidad de diseñar éste a la medida de quien interese.

La eficacia probatoria de la firma electrónica

En el contexto del debate resultaba obligado abordar la eficacia probatoria de la firma electrónica.

Los efectos probatorios que en el marco del proceso pueda desplegar una firma electrónica están influidos por clase o tipo de firma, puesto que la redacción del nuevo ordinal tercero del artículo 326 de la ley de Enjuiciamiento Civil (LEC) remite a la Ley de firma electrónica que diferencia sus variantes.

Cuando la parte a quien interese la eficacia de un documento electrónico lo pida o se impugne su autenticidad, se procederá con arreglo a lo establecido en el artículo 3 de la Ley de Firma Electrónica

En este sentido, el artículo 3 del Proyecto comienza por dar una definición in genere del concepto de firma electrónica: “conjunto de datos en forma electrónica consignados junto a otros o asociados con ellos, que pueden ser utilizados como medio de identificación del firmante”.

Configura, además, dentro de este concepto otra clase de firma: la electrónica avanzada –en adelante F.E.Av.– entendida como “la que permite identificar al firmante y detectar cualquier cambio ulterior de los datos firmados-, que está vinculada al firmante de manera única y a los datos a que se refiere y por haber sido creada por medios que el firmante puede mantener bajo su exclusivo control.

Por último, y como novedad, la Ley acuña el término firma electrónica reconocida –en adelante F.E.Rec.- (que se podría haber traducido como cualificada si se respetara el término en inglés de la Directiva de la que trae causa) para referirse a: ”la firma electrónica avanzada basada en un certificado reconocido (cualificado) y generada mediante un dispositivo seguro de
creación de firma”que “tendrá respecto de los datos consignados en forma electrónica, el mismo valor jurídico que la firma manuscrita en relación con los datos consignados en el papel”.

De tal manera que, reconocida la eficacia probatoria de toda clase de documentos firmados electrónicamente, públicos y privados, según avanza el Proyecto de Ley (en su artículo 3.5), el soporte en el que figuren los datos firmados electrónicamente será, siempre, admisible como prueba documental en juicio, siendo indiferente el tipo de firma utilizada.

Por otro lado, será posible defender la autoría de los documentos firmados con F.E.Av., con la proposición de un dictamen pericial conforme al artículo 352 L.E.C. en relación a su correlativo artículo 299.2 de la misma norma.

Sin embargo, podría ser estéril recurrir a un perito en el caso de que el signatario no utilice ni F.E.Av., ni F.E.Rec., ya que el resultado del dictamen no responderá a las expectativas de la parte que pugna por defender el valor probatorio del documento. Serán entonces las reglas de la sana crítica las que auxilien al Juez para establecer su valoración. Por tanto, el documento firmado con F.E.Rec. tendrá respecto a los datos consignados el mismo valor jurídico que la firma manuscrita (según se indica en el artículo 3.4), por lo que ipso iure se genera una presunción de validez.

César Belda apostilló que tendrá más valor, incluso, que la firma manuscrita. Esto es así porque en una eventual impugnación por la contraparte, no se precisa un cotejo pericial de letras, y el dictamen pericial demostraría tanto la autenticación de las partes, como la integridad del texto firmado. Por tanto sus efectos serían similares a los desplegados por un documento público, haciendo prueba plena en juicio sin necesidad de comprobación o cotejo salvo prueba en contrario.

En opinión de César Belda, el juez tendrá, además, que evaluar la diligencia de la entidad de certificación, ya que podríamos encontrarnos ante una usurpación de personalidad en la que un tercero se hiciera pasar por un supuesto signatario, firmando documentos electrónicamente con sus propios datos de creación de firma indebidamente asociados a la identidad usurpada.

Deberá decaer, al igual, la presunción de validez e imputabilidad del titular de la firma cuando los hechos justifiquen serias dudas de que la declaración se haya realizado conforme a la voluntad del firmante –por ejemplo por haber fallecido en fecha anterior.

La responsabilidad de los prestadores de los servicios de
certificación

Por último, en relación a la responsabilidad de los PSC, José María Anguiano expuso que la redacción actual del Proyecto permite la exoneración de responsabilidades de los prestadores de servicios de certificación.

César Belda ejemplificó en este sentido que el Proyecto de Ley obliga a que el receptor compruebe -en caso de recibir éste una proposición comercial de una persona jurídica- si ese acto de comercio se encuentra dentro del objeto social de la empresa; de manera que de no comprobar el receptor, esto podría ser causa de exoneración del PSC so pretexto de obviar el destinatario las restricciones del certificado electrónico respecto a sus usos.

De esta manera, y para concluir, nos encontramos ante una normativa que consagrará la utilización empresarial de las nuevas tecnologías, acrecentará el uso del comercio electrónico por los particulares, facilitará los actos de comunicación con la administración proporcionando seguridad, tanto a las empresas como a los ciudadanos, en la tramitación de sus gestiones, y permitirá, además, una mayor comodidad en las relaciones de abogados y procuradores junto con un mayor dinamismo y celeridad de la resolución de los procedimientos judiciales.