Taller de Criptografía

Taller de Criptografía - Informe 18
La alternativa "key escrow" III: España es así

Fecha: 16 Diciembre 1999

Si hay algo que en el pasado caracterizó las batallas de los depósitos de claves (DC) es que aquí podíamos ver los toros desde la barrera. Terceras partes de confianza, agentes de recuperación, chips Clipper y Fortezza ... todo eran invenciones que nos resultaban ajenas. Ya no. En un intento de recuperar el tiempo perdido, España está saltando al tren del "key escrow" con toda premura ... sin darse cuenta de que los demás países han abandonado ya dicho tren, y que, si la locomotora se mueve, es por pura inercia. Veamos en este tercer Informe de la "trilogía key escrow" cuál es el estado del DC en esta nuestra piel de toro. Puesto que el asunto está en pleno desarrollo, no me extrañaría tener que realizar actualizaciones en breve. De momento, esto es lo que tenemos.

El artículo 52

Hasta hace un par de años las reglamentaciones o leyes sobre criptografía en España brillaban por su ausencia. Existía el acuerdo de Wassenaar regulando ciertos tipos de exportaciones (entre las que se encuentran las de productos de cifrado), y las restricciones ITAR norteamericanas a la exportación. Prácticamente lo único de lo que debíamos cuidarnos era de no descargar programas de cifrado desde servidores norteamericanos, no fuese que al agente Mulder y su pandilla les diera por hacernos una visita. Pero poco más.

Eso comenzó a cambiar en 1998. Más concretamente, el 8 de abril de ese año, fecha en la que se aprobó la Ley General de Telecomunicaciones (LGT). Su artículo 52 regulaba el uso del cifrado en las redes y servicios de comunicaciones. El punto polémico es el 52.2. Dice así (el subrayado es mío):

2. El cifrado es un instrumento de seguridad de la información. Entre sus condiciones de uso, cuando se utilice para proteger la confidencialidad de la información, se podrá imponer la obligación de notificar bien a un órgano de la Administración General del Estado o a un organismo público, los algoritmos o cualquier procedimiento de cifrado utilizado, a efectos de su control de acuerdo con la normativa vigente. Esta obligación afectará a los fabricantes que incorporen el cifrado en sus equipos o aparatos, a los operadores que lo incluyan en las redes o dentro de los servicios que ofrezcan y, en su caso, a los usuarios que lo empleen.

La parte subrayada, por su vaguedad e imprecisión, resulta la más delicada. ¿Qué significa exactamente "los algoritmos y procedimientos de cifrado"? En un mundo lógico, debiera ser algo del tipo "algoritmos RSA de 1024 bits para clave asimétrica, IDEA de 128 bits para clave simétrica y MD5 para firma digital." Pero, ¿puede el concepto "procedimiento" abarcar la propia clave privada? O, dicho de otro modo, ¿se podría usar el artículo 52.2 para imponer sistemas de cifrado con depósito o recuperación de claves? De esa opinión es, por ejemplo, Fronteras Electrónicas España, que en Julio lanzó un comunicado contra el Artículo 52.

En los casi dos años que la LGT ha estado en vigor no ha habido -hasta donde yo sé- normas de desarrollo o aplicación con restricciones o condiciones de cualquier tipo para el uso de la criptografía. El artículo 52 está ahí, si bien no ha sido puesto en práctica hasta ahora. ¿Se convertirá en papel mojado o será puesto en vigor mediante normas de desarrollo? No lo sé.

1999 y los decretos

Llegamos a 1999, y en él somos testigos de la "explosión criptográfica" por parte del gobierno español (además de las explosiones secundarias de la empresa privada, que dejaremos para otro día). Lo primero que nos encontramos es la campaña Renta98 con sucursal en el ciberespacio: por primera vez, puede realizarse una declaración (de la Renta, claro) por Internet. Los interesados pueden darle un repaso a mi Informe correspondiente.

Alentados por el éxito de esta experiencia piloto, la Fábrica Nacional de Moneda y timbre recibe nuevos "poderes" para ofrecer una serie de servicios de seguridad: generación y gestión de claves, emisión y revocación de certificados de clave pública, etc. ¿Por qué la FNMT? Bueno, se supone que si son capaces de emitir documentos tales como DNI, pasaportes y billetes de curso legal, se le podrá confiar tareas similares en el ciberespacio. Para ello se apoya en dos textos legales previos:

El Real Decreto 263/1996, de 16 de febrero, por el que se regula la utilización de técnicas electrónicas, informáticas y telemáticas por la Administración General del Estado (B.O.E. de 29 febrero 1996, pp. 7.942-7.946)
La Ley 66/97, de 30 diciembre, de Medidas Fiscales, Administrativas y de Orden Social (B.O.E. de 31 diciembre 1997) que en su artículo 81 (pag. 385.87) faculta a la FNMT para la prestación de los servicios técnicos y administrativos necesarios para garantizar la seguridad, validez y eficacia de la emisión y recepción de técnicas y medios electrónicos, informáticos y telemáticos entre personas y la Administración, o entre órganos de la Administración.

Así, el 10 de agosto de 1999 nace el Real Decreto 1290/1999, de 23 de julio (B.O.E. de 10 agosto 1999, pp. 29.452-39.457), que desarrolla el artículo 81 de la Ley 66/97 anteriormente mencionada. Poco después, en un loable afán por situarnos en vanguardia del comercio electrónico en Europa, aparece su primo el Real Decreto-Ley 14/1999, de 17 de septiembre (B.O.E. de 18 septiembre 1999, pp. 33.593-33.601), que regula la firma electrónica. Son dos leyes cuya lectura muestra lo seriamente que se toma el tema en España.

Antes de seguir adelante, considero muy importante señalar una cosa. Los servicios que presta el R.D. 1290/1999 no se aplican a todos los usuarios en general, sino solamente a las transmisiones entre a) los órganos de la Administración General del Estado (AGE) y otros organismos (de la propia Administración u otros dependientes y/o vinculados), b) personas físicas/jurídicas con la AGE y/u otros organismos, c) Comunidades Autónomas, entidades locales, entidades bajo convenio, etc. Es decir, sólo entre organismos del Estado, y entre ellos y los ciudadanos. Los servicios NO incluyen transmisiones y recepciones de documentos entre particulares, empresas, etc.

Y ahora, la letra pequeña

El R.D. 1290/1999 (en adelante, simplemente "el R.D.") distingue entre claves de autenticidad (firma) y claves de confidencialidad (cifrado), de manera análoga a como lo hacen las versiones más modernas de PGP (6.5.x), aunque en esta ocasión de forma separada: es decir, se generan un par de claves (pública/privada) de cifrado y otro par de claves (pública/privada) de firmado. La pareja de claves pública/privada de autenticidad (firma) serán entregadas al usuario, y quien guardarlas con cuidado, ya que no habrá más copia de esa clave privada que la del propio usuario. La seguridad criptográfica vendrá dada tanto por la longitud de clave y los algoritmos utilizados (en principio, RSA con clave de 1024 bits mínimo) como por la seguridad de la tarjeta en la que las claves quedarán almacenadas.

Ahora bien, se admite que la clave privada de confidencialidad podrá ser almacenada por la FNMT. En el anexo del R.D. 1290/1999, apartado 4, se detalla una serie de servicios que prestará la Fábrica Nacional de Moneda y Timbre en una primera fase. Entre ellos se menciona un "servicio de recuperación de claves de soporte de confidencialidad." Esto es, la FNMT actuará como agente de depósito de claves (key escrow agent, o KEA) para las claves de cifrado que genere. Con ello parece que España cierra el círculo del depósito de claves: lo inventan los Estados Unidos, lo intentan implantar a nivel mundial, fracasan, se abandona el sistema ... y nosotros tomamos el relevo.

Si bien el R.D. está fechado en 23 de julio y publicado con fecha 10 agosto, existe información en la Red sobre el proyecto CERES desde abril por lo menos. CERES es un proyecto de la FNMT para dar los servicios anteriormente mencionados. En concreto, se mencionan cinco grupos de servicios:

1 - Servicios de certificación de claves (emisión, revocación y archivo de certificados; generación, archivo de claves; registro de eventos).
2 - Servicios de registro de usuarios (registros de emisión y revocación de certificados)
3 - Servicios de publicación (de políticas y normas, de certificados, de listas de revocación y de directorio seguro de certificados).
4 - Servicios de certificación de documentos (certificaciones temporales, de contenido, de envío, de entrega y de recepción).
5 - Servicios de recuperación

Es decir, cumple con las misiones de una Autoridad de Certificación y Tercera Parte de Confianza, pero también con la de agente de depósito.

¿En qué condiciones funcionará dicho depósito? Ni el R.D. ni la documentación pública del proyecto CERES son muy explícitas. El propio jefe del proyecto, Álvaro de la Escalera, me hace notar que, "aunque conociese los detalles no te los podría decir, de la misma manera que no te podría comentar las medidas de seguridad del taller del DNI"... lo que, bien pensado, no deja de ser un loable ejercicio de responsabilidad. Se supone que cuando el depósito de claves (DC) comience a funcionar se publicarán los detalles, al menos los que permitan al usuario conocer cómo se operará con el nuevo servicio.

La única información adicional sobre el funcionamiento del DC indica que "las claves privadas de confidencialidad se archivarán cifradas." ¿Significa eso que se limitarán a almacenarlas de forma segura y "tirar la llave"? Evidentemente no. Para empezar, el servicio de almacenamiento se ofrece como una ventaja para el usuario: "este procedimiento le será de utilidad en el caso de que quiera descifrar mensajes cifrados y su tarjeta de usuario haya sido extraviada o deteriorada" (Información General del proyecto CERES). Esto significa que cada vez que un usuario pierda su clave tendrá que solicitar una copia, lo que implica acceso al depósito.

En segundo lugar, parece que se proyectan otros usos para el DC. Alguien del proyecto CERES (no diré nombres) me sugiere que las claves podría ser recuperadas a petición del usuario o bajo orden judicial. Esto último está en el aire, ya que depende de lo que dicte la legislación (de momento no ha dictado nada al respecto), pero de implantarse significaría que ya no sería el usuario el único en acceder a su clave privada. Incluso suponiendo un comportamiento irreprochable y libre de errores por parte de todos los jueces de España, estamos en un caso que vulnera una premisa de la seguridad criptográfica: solamente el usuario (o quien él designe) debe tener acceso a su clave.

Todavía puede haber más. En el boletín 133 de Kriptopolis aparecen los primeros reparos a este servicio de recuperación. Posteriormente Victoria Villén, de la FNMT, replicó en el boletín 136 con una serie de ejemplos demostrativos de lo útil que podría ser ese servicio (el lector interesado puede leer las críticas a esos ejemplos en el boletín 137). Por ejemplo, menciona el siguiente caso: "supongamos que un ciudadano deposita un documento con sus últimas voluntades, cifrado con su clave privada ante un notario, para que sea leído tras su fallecimiento.... Si ese fuese el caso, la FNMT podría aportarla [la clave privada del testador] a la autoridad judicial." Dejemos aparte el hecho de que existen soluciones mucho más sencillas que no requieran el uso de una recuperación de claves (simplemente, cifrar con la clave pública del notario). El hecho es que personas de la FNMT ya están planteándose la posible entrega de claves de cifrado para actividades notariales. Las posibilidades son muchas. ¿Dónde acabarán?

Conclusión (por ahora)

Imagínese el lector que el ministro del Interior presenta una propuesta de ley que obligase a los ciudadanos a entregar una copia de las llaves de su casa en la comisaría más cercana. Imagínese que la obligación se ofrece como un servicio a los ciudadanos ("por si acaso usted pierde las llaves de su casa alguna vez..."). Imagínese que la propia policía no supiese siquiera cómo guardar de forma segura tantas llaves, y que ningún otro cuerpo policial del mundo pudiese ayudarle con su experiencia. Imagínese que cualquier agente de policía, con una orden judicial en el bolsillo, pudiese coger la copia y presentarse en su casa. ¿Cuántas cabezas rodarían? Bien, pues sea sencilla frase "servicios de recuperación de claves de soporte de confidencialidad" no es sino la misma propuesta a nivel digital, una nueva "ley Corcuera" del ciberespacio.

Cabe preguntarnos si es necesario arriesgarse tanto con un sistema inseguro y peligroso que, en la práctica, solamente beneficiará a las autoridades policiales (y si no, al tiempo). Cabe preguntarnos si los beneficios potenciales serán mayores que los posibles perjuicios. Y, sobre todo, cabe preguntarnos por qué nuestros legisladores y gobernantes no nos permiten opinar en un debate inexistente, presentándonos soluciones imperfectas en la forma de hechos consumados.

Señor Presidente: el esquema de depósito de claves es peligroso. Si España sigue por ese camino, lo hará sola, ya que ningún otro país lo contempla ya como alternativa seria. ¿Se ha preguntado por qué? Yo sí. Y la respuesta me asusta.

Vuelta a la sección Informes del Taller de Criptografía