Por Álvaro de la Escalera y Fernando de la Puente
Título un poco extraño éste, por si no fuera lo suficiente complicado este asunto de la firma electrónica. Hoy nos vamos a fijar en un aspecto que para algunos será rizar el rizo, pero para otros trae más de un quebradero de cabeza y se devanan los sesos intentando encontrar soluciones a tan peliaguda cuestión. Nos referimos a la cuestión que titula este pequeño artículo: la importancia del entorno de seguridad para los dispositivos de creación de firma.
Pero... ¿qué entendemos por entorno de seguridad?
Aún a riesgo de entrar definiciones circulares, un entorno de seguridad es precisamente eso, un entorno de seguridad. Éste es un concepto que se emplea cuando es necesario certificar un dispositivo (en el sentido amplio, el dispositivo de creación de firma podría ser incluso software) e indica qué es lo que vamos a certficar...
Pongamos un ejemplo; supongamos que tenemos una tarjeta criptográfica que realiza firma electrónica y queremos certificarla para que cumpla un determinado nivel de FIPS 140-1, o un EAL. Lo primero que tenemos que decidir es qué vamos a certificar. ¿Vamos a certificar solamente un componente del chip criptográfico? ¿Vamos a certificar el chip criptográfico, más la placa de contactos, tarjeta e incluso un determinado lector? o por el contrario, ¿vamos a certificar la tarjeta, el lector, los cables e incluso el ordenador desde el que se va a utilizar?
Pues eso precisamente es el entorno de seguridad; simplemente es lo que nosotros vamos a considerar que debe de cumplir unas determinadas características de seguridad, ni más ni menos.
Y... ¿un dispositivo seguro de creación de firma?
Ya se ha hablado en este mismo blog sobre los dispositivos de creación de firma. Baste recordar que según la Ley 59/2003 artículo 3, apartado 3:
2. Un dispositivo de creación de firma es un programa o sistema informático que sirve para aplicar los datos de creación de firma.
3. Un dispositivo seguro de creación de firma es un dispositivo de creación de firma que ofrece, al menos, las siguientes garantías:
A. Que los datos utilizados para la generación de firma pueden producirse sólo una vez y asegura razonablemente su secreto.
B. Que existe una seguridad razonable de que los datos utilizados para la generación de firma no pueden ser derivados de los de verificación de firma o de la propia firma y de que la firma está protegida contra la falsificación con la tecnología existente en cada momento.
C. Que los datos de creación de firma pueden ser protegidos de forma fiable por el firmante contra su utilización por terceros.
D. Que el dispositivo utilizado no altera los datos o el documento que deba firmarse ni impide que éste se muestre al firmante antes del proceso de firma.
El punto A hace referencia a que el generador de números aleatorios utilizado para generar las claves esté implementado adecuadamente. Además, las claves generadas deberán estar también protegidas adecuadamente.
El punto B hace referencia a que debe de ser muy difícil obtener las claves del usuario (lógico) por otra persona, y que la firma no pueda ser modificada por otro sin poseer las claves.
El punto C indica que las “claves” deben de estar bien protegidas, lo cual también es de cajón.
Y desde mi punto de vista, con el punto D entramos en el meollo el asunto, y a esto quiero llegar con el presente artículo. De acuerdo; resulta que debemos asegurar que el dispositivo utilizado no altera los datos o el documento y no impide que éste se muestre al firmante antes del proceso de firma. Pues esto puede parecer relativamente sencillo dado lo que hemos conseguido con nuestro dispositivo en los apartados A, B y C, pero yo creo que esto no es así.
La importancia de los detalles
Sigamos con el ejemplo de nuestro dispositivo de firma, que podríamos imaginar que es una tarjeta inteligente, o incluso podríamos imaginar que es nuestro querido DNIe. Vamos a ver qué tal cumple los apartados A,B,C y D de la ley de firma electrónica.
Con los apartados A,B y C no veo demasiadas pegas: las claves utilizadas para firmar son generadas internamente, el chip tiene un buen generador de números aleatoriso por hardware (que supongo que es utilizado), y las claves privadas no se las deja que puedan ser exportadas fuera de la tarjeta. Por otra parte, el proceso de firma no utiliza ningún algoritmo “extraño” que no sea utilizado en miles de aplicaciones y se puede considerar suficientemente robusto (aunque el algoritmo de hash que según creo se sigue utilizando parece que tiene alguna pega); de todas maneras, la tarjeta (y su software asociado) está preparada para utilizar otros algoritmos.
Y vamos con el apartado D. Parece claro que el dispositivo no altera los datos o el documento (nos fiamos de quien fabricó el DNIe), y éste no impide que la aplicación que nos pasa algo a firmar nos muestre lo que se va a firmar. Pues estamos todos de acuerdo ¿no? El DNIe cumple tambien el apartado D. Pues bueno, tampoco es esto exactamente así, si nuestro entorno de seguridad es simplemente el DNIe, sí que lo cumple. Si nuestro entorno de seguridad está formado por el conjunto DNIe más el lector de tarjetas, las cosas ya se empiezan a complicar, porque un lector de tarjetas es más sencillo de manipular que una tarjeta inteligente (a alguien con acceso físico al lector se le podría ocurrir hacer alguna cosa para que no se cumpla este punto D tan alegremente), y si seguimos podríamos ver que si ampliamos el entorno de seguridad al software que corre en el ordenador al que está conectado el conjunto tarjeta/lector, cada vez es más complicado.
Como se suele decir, todo en esta vida tiene solución menos la muerte y el pago que te pega Hacienda. Por lo tanto, en el siguiente artículo de la serie analizaremos las soluciones que se han ideado para que nuestras firmas electrónicas puedan llegar a ser lo suficientemente seguras.
Autores:
- Álvaro de la Escalera Arminio.
- Fernando de la Puente Arrate es director de eSignus.
Encantado
jonsito21 Mayo 2011 - 3:57pm
(Se os echaba de menos por este foro...)
La verdad, esta introducción promete. Me imagino que ahora vendrán artículos sobre cómo proteger el canal, la necesidad de confirmación del usuario para las operaciones de firma, etc, etc, etc...
En la mente de todos los Kriptopoleros está la pelea sobre DNIe vs FNMT, sobre la inseguridad intrínseca de los certStore software... te sugeriría que a la par que con el DNIe hicieras una comparación con otros tokens sofware
Al punto C yo añadiría, aparte de la seguridad de las claves, la salvaguarda del hash y de su firma: garantizar en la medida de lo posible que no hay ningún sistema "recolector" de duplas hash/firma que eventualmente pudiera llegar a tener datos suficientes como para inferir las claves. Es una de las razones de tener en el DNIe dos certificados distintos: uno para autenticar y otro para firmar
¿Nos veremos en el HackFest del DNIe?
Juan Antonio
Encantado yo ...
Alvaro de la es...23 Mayo 2011 - 8:11am
Lo cierto es que siempre ando por aquí curioseando y te leo de cuando en cuando, pero ahora ya no ando tan relacionado con los temas que tratas tú, por lo que ya vez que participo poco.
La segunda parte va sobre las soluciones que conocemos a los problemas que planteamos, y hacemos un pequeño análisis de cada una de ellas. Y si, tienes razón, la gran pelea es como proteger el canal (ya sea por medios físicos o lógicos), y la protección de la entrada de datos por el usuario.
Realmente no nos centramos en el DNIe, se menciona porque "vende" mucho, pero creo que es válido para otras tarjetas o dispositivos criptográficos,ya sean hard o soft.
Respecto a lo que comentas del punto C, pienso que si los algoritmos utilizados son susceptibles a un ataque de esas características, tenemos un problema muy serio y lo que deberíamos hacer sería utilizar otros. De todas maneras, si ya estamos protegiendo el canal, como veremos en el segundo artículo, al mismo tiempo estamos evitando el posible ataque al que te refieres.
Saludos