Archivo de la categoría: Criptografía

DISI 2007

3 respuestas

El pasado 3 de diciembre de 2007 tuvo lugar el DISI 2007: Segundo Dí­a Internacional de la Seguridad de la Información.

Toda la jornada fue muy interesante pero para mí fue muy emocionante especialmente por la mañana.

La primera ocasión al poder saludar personalmente a Mr Martin Hellman y poder charlar brevemente con él. No me he lavado la mano desde el lunes 😉

El doctor Martin Hellman es coautor de una de las primeras patentes de criptografía de clave pública (Martin E. Hellman, Bailey W. Diffie, and Ralph C. Merkle) y de los trabajos seminales sobre el tema.

Su disertación fue muy interesante. Hizo un recorrido de las pricipales aportaciones iniciales a este tipo de criptografía, dedicando un pequeño homenaje a varios «Unsung heroes».

When I was first studying cryptography, my colleagues were almost uniform in their appraisal that my efforts were foolish. Citing NSA’s huge budget, they asked how I could ever hope to discover something NSA did not already know. And they argued that, if I did find anything good, the government would classify it. Both arguments were valid, and later came back to haunt me. Yet, in hindsight, this fool’s errand was a very worthwhile adventure.

In this talk I recount those early days: what brought me to cryptography; why I disregarded the conventional wisdom; the roles of Diffie, Merkle, RSA, and NSA; and the thought sequence that led us to pubic key cryptography. I will also shine some light on several unsung heroes of those early days and discuss the work of the NRC Committee to Study National Cryptographic Policy (1994-96). Although not as intimately involved in cryptography’s current study, I will also venture a few thoughts on its future.

Luego, el doctor Hugo Scolnik presentó un trabajo muy interesante y prometedor sobre la posibilidad de factorizar eficientemente los productos de grandes números primos que son la base del sistema criptográfico de clave pública RSA.

Fernando Acero ha descrito con cierto detalle la presentación del doctor Scolnik.

Aunque es pronto para saber si se trata de un método genérico, permite vaticinar que la necesidad de cambiar a otro tipo de criptografía no basada en RSA empieza a ser acuciante. Son interesantes algunos comentarios que Fernando ha recibido a su artículo en Kriptópolis.

En fin, todas las charlas fueron interesantes. A ver si en una posterior actualización voy poniendo más cosas sobre ellas.

Y para colofón una divertida reflexión de Juan Carlos García Cuartango sobre la escasa industrialización del software en el devenir de 30 años. Me gustaría conseguir el video de su charla.

Actualización.

Ya están disponibles los «abstracts»:

      Conferenciantes Internacionales Invitados

      Ponentes Nacionales Invitados

ISO 7816-8 Identification cards — Integrated circuit. Part 8: Commands for security operations

1 respuesta

Una de las normas que hay que conocer para gestionar tarjetas inteligentes a bajo nivel es la ISO 7816-8.

Para que valoreis si merece la pena comprarla (cuesta 96 Francos Suizos, unos 60 euros), os adjunto su índice:

Foreword
Introduction
1 Scope
2 Normative references
3 Terms and definitions
4 Abbreviations and notation
5 Interindustry commands for cryptographic operations
5.1 GENERATE ASYMMETRIC KEY PAIR command
5.2 PERFORM SECURITY OPERATION command
5.3 COMPUTE CRYPTOGRAPHIC CHECKSUM operation
5.4 COMPUTE DIGITAL SIGNATURE operation
5.5 HASH operation
5.6 VERIFY CRYPTOGRAPHIC CHECKSUM operation
5.7 VERIFY DIGITAL SIGNATURE operation
5.8 VERIFY CERTIFICATE operation
5.9 ENCIPHER operation
5.10 DECIPHER operation
Annex A (informative) Examples of operations related to digital signature
Annex B (informative) Examples of certificates interpreted by the card
Annex C (informative) Examples of asymmetric key import/export
Bibliography

TrueCrypt, seguro, rápido y de fuente libre

6 respuestas

A través de aramsmith.com he encontrado esta interesante información sobre TrueCrypt.

Una ingeniosa herramienta rápida y segura que permite crear un disco virtual cifrado en cualquier dispositivo de almacenamiento, tal como una memoria USB sin miedo a perder datos y que estos queden al alcance de quien la encuentre.

TrueCrypt permite:

  • Definir un fichero como disco virtual cifrado que, una vez «montado» en el sistema queda accesible como cualquier otro.

  • Cifrar toda una partición del disco o todo un dispositivo, como por ejemplo una memoria Flash USB.

  • Copiar ficheros a o desde la zona cifrada, de forma que el cifrado y descifrado es automático, en tiempo real (al vuelo) y transparente.

  • Definir dos niveles de inaccesibilidad plausible (plausible deniability) para el caso de que nos veamos forzados a revelar la password.

  • Seleccionar los algoritmos de cifrado entre AES-256, Blowfish (clave de 448-bits), CAST5, Serpent, Triple DES, y Twofish. Modo de operatcon: LRW (se soporta CBC por compatibilidad).

Para usarlo, hay que instalar el programa TrueCrypt o ejecutarlo (por ejemplo si llevamos los ficheros .exe y .sys en el propio lápiz USB o disco, se ejecuta desde allí).

Al ejecutarlo se crea un volumen cifrado seleccionando el algoritmo de cifrado o una combinación de ellos. Se proteje el volumen con una password. La password puede ser además de una palabra clave, una imagen, un archivo MP3 u otro documento o una combinación de ambas. A continuación se «monta» el volumen que se comportará como cualquier disco local. La robustez del algoritmo afecta a la velocidad de cifrado y descifrado.

Una vez montado el disco virtal cifrado se puede formatear y poner otros ficheros en él. Dado que el disco virtual se basa en un fichero, ese fichero se puede copiar a cualquier dispositivo, por lo que al hacerlo se incluyen los archivos que están en el disco virtual.

Esta herramienta, disponible en código fuente se puede obtener en su propio sitio web TrueCrypt

WikiSTC compendio de información de seguridad

2 respuestas

A través de Harlok me he enterado de que se ha publicado la versión española del Wiki sobre seguridad WikiSTC. Habrá que ir dándose de alta para colaborar.

i-Button como Medio de Pago

Deja un comentario

Anillo Java con i-ButtonLa verdad es que poder contar con algo tan sencillo de llevar como un anillo parece la única opción capaz de mejorar la facilidad de uso de las tarjetas de crédito.

Un anillo, de hecho, es más resistente al robo que una tarjeta, ya que es más fácil de detectar si están intentando quitártelo.

Respecto a las tarjetas convencionales, tiene una ventaja clara: la capacidad de procesamiento inteligente embebida en el dispositivo, lo que permite utilizar avanzados algoritmos criptográficos. Esa misma capacidad permite almacenar claves de todo tipo y censar todas las operaciones en las que interviene, lo que permite crear un log de transacciones individualizado, como elemento complementario de seguridad.

Contenido del i-ButtonEl coste del i-Button, de 1,4 dólares por unidad (en pequeñas cantidades) podría ser un elemento en contra, pero teniendo en cuenta que ya se considera al i-Button una alternativa al RFID, incluso en coste, parece que por ese lado también aparecen ventajas.

Además, la robustez de la tecnología y la duración de la alimentación hasta 10 años extiende la vida de las actuales tarjetas de crédito (de plástico), que vienen a durar 3 años como máximo, si se quieren mantener unas condiciones dignas de presentación y operatividad.

Por tanto, disminuyen los costes asociados a la expedición de dispositivos, y al control de entrega a su destinatario.

Si no es necesaria la personalización, como lo es en el caso de las tarjetas de plástico, aún se disminuyen más los costes, ya que el anillo se puede entregar en la sucursal en el mismo momento de la contratación, y en ese mismo momento. también, se asocia a su titular.

Un riesgo de este sistema es la pérdida de control de elementos de marca, dado lo reducido del espacio grabado para incluir diseños. Así y todo, cabe pensar en un diseño elegante y compacto que transmita la imagen de la entidad financiera, así como la marca de maedios de pago tal como VISA o MasterCard. En el caso que se muestra, la imagen Java queda muy elegantemente destacada.

Entre los inconvenientes, cabe citar la necesidad de desplegar una infraestructura de recogida de operaciones: Terminales Punto de Venta (POS: Point of Sale) y Cajeros Automáticos (ATM: Automatic Teller Machine). Sin embargo, dada la actual presión por desplegar infraestructura de recogida de operaciones para tarjetas chip bajo la especificación EMV (especialmente desde la resolución adoptada en el área SEPA, Single Euro Paymen Area, de generalizar la adopción de EMV antes de fin del 2010) , cabría pensar en que por el mismo coste se puede disponer de una infraestrucrura que sirva tanto para EMV como para i-Button.

Además, pese a lo innovador de la propuesta, la tecnología i-Button es una tecnología madura, con muchos años en el mercado, y que ha llevado al fabricante, incluso, a definir modelos de almacenamiento de valor como el escasamente exitoso «monedero electrónico» que en la especificación CEPS («Common Electronic Purse Specification») ha sido poco respaldado por las entidades financieras.

Efectivamente, Dallas/Maxim ha publicado la especificacion de monedero: Digital Monetary Certificates, como nota de aplicación en la que se estudia de forma detallada la gestión de información asociada.

Estoy deseando poder definir el proyecto piloto de este medio de pago con una entidad financiera que se considere avanzada. A ver si alguna se anima…

Ya tengo mi DNI electrónico

1 respuesta

Hay que reconocer que la infraestructura desplegada por la DGP es impresionante. Y todo para conseguir que el ciudadano pueda llevarse el DNI «puesto» en una sola visita.

Ciertamente la apariencia de los equipos es un tanto «industrial». Claramente no son equipos de gran tirada ni destinados al consumo.

Pero todo parece diseñado para tranquilizar a los más paranoicos: las claves públicas y privadas que gestiona el DNI-e las genera el propio chip (lo que ralentiza un poco el proceso, dado el tamaño de las claves).

Se escanean las huellas dactilares de los 2 dedos índices de ambas manos, se incorpora la firma manuscrita y la foto, que se almacena en color aunque se imprima en blanco y negro.

El sistema genera una clave para teclear, con la que se protegen las dos claves privadas que se entrega al ciudadano en el mismo acto, impresa en un sobre opaco mediante una impresora de impacto. Además, en las propias instalaciones de la policía un kiosko de autoservicio permite comprobar los datos que figuran en el DNI y cambiar la clave. Incluso si no se recuerda la clave anterior, permite la identificación mediante una de las huellas dactilares.

Los funcionarios que atienden los puestos actuan con aplomo, como si el procedimiento de generación del DNI electrónico estuviera tan trillado como se supone que a día de hoy es el procedimiento de obtención del DNI convencional (en pocos meses, ESTE DNI será el CONVENCIONAL).

En fin: la impresión que he obtenido es muy satisfactoria. Creo que los especialistas de la Policía y de las empresas contratadas han hecho un buen trabajo.

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.