http://www.kriptopolis.org/node/2333
Hace unos días, nuestro estimado José Manuel anunciaba que había tenido acceso a un documento en el que se demostraba que, bajo ciertas condiciones, se podían firmar digitalmente documentos a nombre de otras personas usando certificados X.509, como los expedidos por la Fábrica Nacional de Moneda y Timbre.
En este tiempo he intentado ponerme en contacto con responsables de las aplicaciones implicadas -como la Fábrica Nacional de Moneda y Timbre- y he generado los informes de "bugs" correspondientes para la gente de Mozilla, Enigmail y OpenOffice. El resultado de estas gestiones sería largo de explicar, pero la frase que mejor lo resume es "unos por otros y la casa por barrer" y por lo tanto, no entraremos en detalles.
Antes de empezar, quiero aclarar que aunque yo he descubierto el problema usando Linux (en mi casa no hay ni una licencia de Windows), este problema es común a todos los sistemas operativos, ya que se deriva del mismo estándar PKI, y así me han informado otras personas a las que les he consultado el caso, por lo que nadie le eche la culpa a Linux y sus aplicaciones, que ya estaba viendo la sonrisa de algunos. No obstante, para el que tenga curiosidad morbosa, aquí va mi configuración de sistema:
En mi ordenador, la última versión de OpenOffice (2.0.2), con el paquete de idioma castellano. Ni qué decir, que está funcionando sobre una Linux Mandrake 2006.0, actualizada al día de la fecha y con todos los paquetes relacionados con la seguridad, criptografía y firma instalados y configurados.
Aclaremos que OpenOffice (al igual que otras muchas aplicaciones que funcionan bajo Linux, como sistemas de mensajería instantánea o todas las derivadas de Mozilla, como Mozilla Suite, Firefox o Thunderbird), usa el sistema de firma digital de Mozilla. Por ello, para poder usar la firma digital con OpenOffice, es necesaria una instalación de una versión actualizada de Thunderbird, Mozilla Suite o Firefox. Estas aplicaciones se pueden usar de forma compartida con otros usuarios, o se puede disponer de diversas configuraciones para un mismo usario. Por ello, si se han creado varios perfiles en Thunderbird, Mozilla o Firefox, y se desea que OpenOffice utilice uno de ellos en concreto, se deberá modificar la variable de entorno MOZILLA_CERTIFICATE_FOLDER, para que apunte a la carpeta que contiene el perfil que se desea usar.
En mi Mozilla Suite con Enigmail, tengo instalados dos certificados digitales de la FNMT, el mío y el de mi señora, que se instalaron con la esperanza de poder enviar la declaración de la renta firmada por los dos, ya que es conjunta y concurrente, ya que no es posible firmar uno, cambiar a otro usuario y firmar el otro. Es decir, que tal como dice la Agencia Tributaria en su página web, han de estar ambos certificados presentes, tanto en Linux como en Windows.
Esto es lo que se puede ver en el gestor de certificados de Mozilla Suite, que es la aplicación que uso normalmente. Como se puede observar, hay dos certificados, el mío y el de mi amada esposa, que ahora queda a mi merced, como ave desvalida.
Veamos este curioso fallo de seguridad, paso por paso, fallo que algunos califican de "comportamiento normal" según el estándar PKI.
1) Para firmar el documento que tenemos en la pantalla del procesador de textos, es necesario usar la secuencia de mandatos Archivo | Firmas digitales de OpenOffice.
2) Si no hemos almacenado el archivo, OpenOffice avisará de que antes de firmarlo es necesario almacenarlo. Para ello, pulsamos el ratón sobre la opción "Sí" del cuadro de diálogo que nos aparece.
3) Seguidamente escribimos un nombre para el archivo (por ejemplo, prueba.odt) y hacemos "clic" con el ratón sobre el botón Guardar del cuadro de diálogo Guardar como.
4) Ahora nos aparece el cuadro de diálogo Firmas digitales. Todavía no aparecen los certificados disponibles, ya que la base de datos de certificados está cerrada con su contraseña. Para seguir, haremos "clic" con el ratón sobre el botón Agregar... de dicho cuadro.
5) Ahora OpenOffice nos pedirá la contraseña del almacén de certificados de Mozilla Suite, lo que se puede comprobar porque en la esquina superior izquierda del cuadro de diálogo de contraseñas aparece el texto NSS Certificate DB, que puede ser algo críptico para los no iniciados.
6) Hecho esto, nos aparecen los dos certificados que hay disponibles en el contenedor, el mío y el de mi amada señora. Selecciono con toda mi mala intención el de mi señora (que me parece más bonito para firmar un texto en latín) y del que no conozco la clave (es su certificado, no el mio) y pulso el botón Aceptar para consumar mi felonía. En este punto quiero señalar que puedo elegir el certificado que quiera, es indiferente; si hubiera habido cuarenta, los cuarenta estarían disponibles para la firma, sin necesidad de conocer la contraseña asociada a ninguno de ellos. Como diría Bart Simson: ¡Mosquis!, moooola.
7) A partir de ese momento, el archivo queda firmado por arte de magia y con la firma de mi señora, que de latín no tiene ni idea. Creo que puede ser el momento más adecuado para divorciarme y quedarme con todos los bienes gananciales en base a la libre donación firmada por mi señora ;) Al fin y al cabo, la legislación dice que no puede repudiar lo que haya firmado con su certificado. ¿Ella me ha entregado su contraseña? Pues no, no lo ha hecho, pero ella no sabe que no la necesito, por lo que se cree que está a salvo de mis maquinaciones.
8) Si una vez guardado el documento, cierro la aplicación y vuelvo a cargar el archivo, en la parte superior izquierda de la ventana que lo contiene me aparece un mensaje indicando que el archivo se encuentra firmado "prueba.odt (firmado)", mensaje que desaparece si modifico el archivo.
9) Si uso de nuevo la secuencia de mandatos Archivo | Firmas Digitales, me aparece un cuadro de diálogo de Firmas digitales que me indica que el archivo ha sido firmado adecuadamente por mi señora , lo que evidentemente no debería ser cierto bajo ningún concepto.
Para evitar este problema, una vez abierto el almacén de certificados y seleccionar uno de ellos, para poder firmar un documento debería ser imprescindible la solicitud de la contraseña asociada al certificado, lo que podría ser perfectamente posible desde el punto de vista técnico. Es decir, no se debería asumir la contraseña de la base de datos del certificados como la contraseña de todos los certificados que contiene, dejando firmar cualquier cosa simplemente seleccionando uno de los certificados presentes en el contenedor.
Pues bien, este grave problema de seguridad también se produce con cualquier aplicación que use un contenedor de certificados, ya sea bajo Linux o bajo Windows. ¿Cuáles son los motivos? Sencillo, son dos. El primero, dar cosas por sentado, y el segundo, pensar que es mejor la comodidad frente a la seguridad.
Se da por sentado que todos los certificados que habrá en un contenedor serán de una misma persona y que se encuentran bien protegidos por una única contraseña. Y por comodidad del usuario, una vez abierto el contenedor decidieron que se pudiera firmar cualquier documento sin necesidad de contraseña. Al fin y al cabo, la contraseña solamente estaba definida para el transporte seguros de certificados X.509, usando para ello un contenedor criptográfico según el estándar PKCS.12. Algo increíble, pero cierto.
Éste ha sido un craso error arrastrado por todos los implementadores de sistemas PKI, que decidieron no asociar el acto de firma de un documento a la introducción obligatoria de una contraseña asociada al certificado. Que sencillo hubiera sido que esto funcionase redondo.
Como se ha dicho, este problema está en el estándar PKI. Todos los implicados se han limitado a implementar los contenedores según ese estándar, con resultados tan desastrosos para la seguridad como el que hemos podido presenciar. Aclaremos también que aunque para reproducir el problema se han usado certificados de la FNMT, éste es un problema que afecta a cualquier certificado X.509, con independencia de su origen, no necesariamente de la FNMT.
Pero desde un punto de vista estricto, ¿podemos decir que no es cierto lo que de dice en la página de la FNMT en referencia a los certificados y la firma digital, al menos, en lo referente a asegurar la identidad del firmante?:
"Una firma digital es un conjunto de datos asociados a un mensaje que permite asegurar la identidad del firmante y la integridad del mensaje".
Pues es evidente que no es cierto, y que visto lo visto puedo cuestionarme con una duda razonable la autoría de una firma digital.
Es más, como no conozco el entorno en el que se realizó la firma del documento, gracias a este fallo puedo cuestionar, al menos con una duda razonable, si ese documento ha sido firmado realmente por la persona a la que pertenece el certificado. Puede que algunos no se den cuenta del problema, pero es más grave de lo que parece, si además, tenemos en cuenta lo que dice la legislación.
Como yo lo veo, el usuario solamente se debería preocupar de que no ha entregado a nadie su certificado con su contraseña, o que nadie tenga acceso a ello, es decir, que la seguridad del sistema debería garantizar que si no es en esas condiciones nadie pudiera firmar nada a nombre de otro. En algunos mensajes me han dicho que si tú metes tu certificado en un contenedor al que tiene acceso otra persona es que eres tonto, pero ¿alguien ha avisado de ello?. Pues no, es más, casi te animan a ello, como es el caso de la FMNT, o te obligan a ello, como es el caso de la Agencia Tributaria. A bote pronto, podemos pensar que en este momento, al menos en los matrimonios que presentan sus declaraciones de forma conjunta por Internet ya hay un montón de certificados comprometidos por esta circunstancia. Lo mismo, ocurre con los certificados que pueda haber en despachos de abogados, notarios, registradores de la propiedad, etc, y que sean compartidos en un mismo ordenador por varios profesionales del despacho. Si logro convencer a alguien de que instale su certificado en un ordenador, para ayudarle a mandar la declaración por Internet, listo, ya lo tengo a mi merced. Pues vaya seguridad del sistema...
En la página de las preguntas y respuestas más frecuentes de la FNMT se dice lo siguiente :
- A la pregunta ¿puedo tener más de un certificado instalado en mi navegador? se contesta: "Si, podrá tener más de uno. El número exacto dependerá de la versión de su navegador".
- A la pregunta: ¿Se puede tener el mismo certificado en varios navegadores? se contesta: "Si, una vez que se haya descargado el certificado, se puede instalar en varios navegadores utilizando las opciones de exportación e importación de certificados."
- A la pregunta: ¿Se puede tener más de un certificado por titular emitido por la FNMT Clase 2 CA? se contesta: "Las personas físicas titulares de un certificado solamente podrán tener un certificado en vigor emitido a su nombre. Las personas jurídicas podrán tener emitidos y en vigor, tantos certificados como representantes legales tengan."
La conclusión que se obtiene de analizar estas preguntas y respuestas es espeluznante. Por ejemplo, si en una empresa tienen que firmar un documento varios representantes legales de forma concurrente y simultánea, todos los certificados han de estar en el mismo contenedor, y con ello, a merced de cualquiera del que conozca la contraseña del mismo. Es más, ¿quién garantiza ahora que han firmado todos de forma voluntaria dicho documento y estaban presentes en el momento de la firma?. En ningún sitio se dice que introducir un certificado en un contenedor sea un peligro para la seguridad, tan grave como para permitir que otro firme a nuestro nombre y sin nuestro consentimiento. Es más, creo que todo el mundo piensa que el certificado sigue protegido por la contraseña, del mismo modo que es necesario introducirla para meterla en el contenedor.
En la página de la Agencia Tributaria ocurre casi lo mismo:
- Cuestión 2: ¿Puedo tener más de un certificado instalado en mi navegador? Respuesta: "Si, pero habrá que solicitar y descargar un certificado de la FNMT por cada declarante que vaya a presentar la declaración-liquidación por Internet desde dicho navegador."
Es decir, que me obligan a tenerlo instalado en el mismo contenedor si quiero declarar de forma conjunta, y no me dicen que es el error más grave que puedo cometer para comprometer mi seguridad. ¿Es que los expertos en seguridad de la FNMT y la AEAT no se dieron cuenta de este problema al establecer y publicar las operativas de firma?. No me lo puedo creer.
Durante este tiempo, algunos de los consultados me comentaron que esto no era preocupante y que con el e-dni esto que he comentado sería imposible, ya que el e-dni un contenedor de certificados que no permite instalar otros certificados adicionales. Pero desgraciadamente, yo no comparto esta afirmación de forma tan categórica; es más, que no se puedan instalar esos certificados habrá que verlo en el futuro, espero que nadie piense que es imposible simplemente por haber quitado la instrucción correspondiente en el sistema operativo de la tarjeta...
Desgraciadamente, en el e-dni subyace la misma filosofía de "comodidad frente a seguridad", que ha heredado del sistema PKI, y por ello se han tomado medidas tan peligrosas para el usuario como la de mantener la misma contraseña para el certificado de firma y de autentificación, lo que puede provocar que se firme algo cuando se está pensando que simplemente se está autentificando y, seamos prácticos, aplicaciones maliciosas y derivados del phishing puede haber mil gracias al e-dni y el desconocimiento de los usuarios.
La excusa para obrar de este modo tan poco ortodoxo con el e-dni era que, si se mantenían una contraseña para el contenedor y otras distintas para cada certificado, los usuarios se complicarían la vida y aparecería un maremagnum de pines y pukes. Es una forma de verlo, pero lo que está claro es que el usuario solamente se debería preocupar de no darle a nadie su e-dni con la contraseña y además, ¿para qué tanta historia con los pin y puk, si luego se deja un agujero de seguridad tan grave como el que se acaba de comentar?. Otro apunte, la mayoría de los usuarios actuales no serían capaces de saber si un documento que les llega ha sido firmado con un e-dni o con un certificado digital, lo que abre la puerta a otra serie de problemas, y algunos muy graves.
Toda la seguridad debe recaer en el sistema, no en las aplicaciones o en los conocimientos técnicos o de seguridad de los usuarios, que además pueden ser escasos en el caso del españolito medio. Al igual que en el caso que acabamos de comentar, simples errores de concepto en la definición del estándar, o situaciones no previstas, pueden provocar problemas graves con el e-dni. Un ejemplo poco pensado, podrían ser los derivados del cambio de sesión en un sistema multiusuario, con un e-dni insertado y activado en el lector. Pero doctores tiene la Iglesia.
Me gustaría recordar a los amigos del "molaware" algo importante. La Ley se ha escrito como si fuera imposible hacer lo que yo he demostrado que se puede hacer, y eso deja a los usuarios ante un serio problema. Si firmo lo que no debo a nombre de mi señora, el problema lo tendrá ella, y eso es grave, muy grave.
Con lo sencillo que hubiera sido asociar una firma a una clave y punto, como manifestación volitiva e incontestable de la voluntad de firma de un documento... Más sencillo imposible; pues no, decidieron tomar la calle del medio. No saben bien los que establecieron el estándar PKI en su momento el error que cometieron dando prioridad a la comodidad frente a la seguridad y dando por sentado cosas que puede que no se cumplieran, como de hecho ha ocurrido.
Molaware para todos... Invito yo, y al que le toque la china, que se fastidie.
Fernando Acero
"Copyleft 2006 Fernando Acero Martín. Verbatim copying, translation and
distribution of this entire article is permitted in any digital medium,
provided this notice is preserved".
--
No hay comentarios:
Publicar un comentario