26 Abril 1999; actualizado el 10 Mayo 1999
Actualización: 6 Junio 1999


Bueno, tenía que ocurrir. Hacienda ha saltado al ciberespacio. Y no solamente con una bonita página donde se dan consejos y se facilita el programa Padre. La campaña de 1998 será la primera en la que los ciudadanos podremos presentar la declaración por Internet. Unos datos por aquí, un certificado digital por allá, y listo. Se acabaron las colas, no más papeles, larga vida a la ventanilla de veinticuatro horas. España se pone a la vanguardia de las nuevas tecnologías...

Bueno, vale, ya es suficiente. Esto comienza a sonar como una rueda de prensa del ministro Rato. Pero, ¿qué hay de verdad y qué no nos cuentan? ¿Es el sistema tan seguro como dicen? ¿Qué pasos hay que seguir? Aquí, en este humilde Taller de Criptografía, hemos realizado una evaluación rápida del proceso que hay que seguir. Si le pica la curiosidad suelte un rato la calculadora, olvídese de su base imponible y veamos qué nos depara la nueva Hacienda Virtual.


Certificación del usuario

La Agencia Tributaria, con la asistencia técnica de la Fábrica Nacional de Moneda y Timbre, se ha embarcado en el ambicioso proyecto de poner a disposición de todos los contribuyentes un sistema de comunicaciones seguras vía Internet. En anteriores Informes se explicaron las diferentes cualidades de los servidores seguros y su implantación en España (ver en particular el Informe 4). Veremos aquí el proceso particular que se ha de seguir para establecer una comunicación segura y autenticada con el servidor de la Agencia Tributaria. Este proceso está asimismo descrito aquí.

Recordemos que el usuario U pide al servidor S una comunicación segura. S envía una clave pública, junto con un certificado de una autoridad de certificación (AC). U comprueba dicho certificado mediante la clave de la AC que éste tiene en su navegador, y tras la verificación envía a S una clave de cifrado simétrico (clave de sesión) encriptada con la clave pública enviada por S. A partir de ese momento, la clave simétrica es usada para cifrar todas las comunicaciones de esa sesión.

Por ello, el primer paso consiste en obtener el certificado de la AC que dará fe de la transacción. Habitualmente dicho certificado se halla ya en su navegador, y corresponde a alguna de las AC más conocidas (Verisign, Thawte, RSA Data Security, IPS, ACE, etc). En este caso, Hacienda utiliza una nueva AC que está aún en período de pruebas: la de la Fábrica Nacional de Moneda y Timbre (FNMT).

¿Por qué la FNMT? Pues porque tiene asignadas las competencias 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 comunicaciones y documentos a través de técnicas y medios electrónicos informáticos y telemáticos (Ley 66/97 de 30 Diciembre de Medidas Fiscales, Administrativas y del Orden Social, B.O.E. num. 313 de 31 Diciembre 1997, pag. 38517). En virtud de esas competencias, la FNMT está en proceso de convertirse en Autoridad de Certificación. La campaña de la Renta 98 será su "bautismo de fuego."

Así pues, nuestra comunicación con la Agencia Tributaria estará certificada por la FNMT CA (lástima que no adopten en orden castellano AC, y prefieran optar por el anglosajón CA). ¿Cómo se obtiene el certificado de la FNMT CA? Muy sencillo: descargándolo en esta página de la FNMT (Obtener certificado de usuario). Aparecerán unas instrucciones sencillas que nos permiten configurar las opciones que deseamos: si deseamos aceptar esa autoridad para certificar direcciones de red, mensajes de correo electrónico, programadores, etc. Diga que sí a todo, no hay problema; si cambia de idea, luego podrá rectificar.

Si eso fuera todo lo que necesitamos, bastaría con pinchar en la dirección adecuada, en este caso https://aeat.es, sección "I.R.P.F. 98" y seguir las instrucciones para la cumplimentación de la declaración y el envío de los archivos correspondientes. Es decir, como una comunicación segura a un banco. Pero eso no basta en este caso, porque es necesario la autenticación y el no repudio. Es decir, Hacienda ha de saber con certeza que la declaración que se envía es la de usted, y no la de alguien que quiere jugarle una mala broma.

Los bancos suelen arreglar ese problema otorgando al titular de la cuenta un número o código de identificación que ha de introducir durante la conexión segura. Es como sacar dinero de un cajero. Se supone que quien introduce la tarjeta y su PIN es el propietario, pero ¿y si su tarjeta ha sido robada y el número adivinado, reventado u obtenido mediante violencia?

La solución consiste en otorgar Certificados de Usuario (CU). Esto funciona como el certificado de la AC, pero al revés. Si en el paso anterior vd. puede verificar la identidad de la Agencia Tributaria, ellos podrán hacer lo mismo con la identidad de usted gracias al CU. De ese modo estarán seguros de que usted es usted. El CU será una especie de DNI digital. Estará residente en el navegador de su ordenador, y mediante una contraseña solamente vd. podrá activarlo.

Para conseguirlo, ha de pedir a la FNMT un CU. Simplemente, pinche aquí (Solicitar certificado de usuario) y siga las instrucciones. Se recomienda un certificado de "grado alto" (1024 bits). Esa será la longitud de la clave (asimétrica) que se generará en el proceso. La clave privada asociada permanece en su ordenador. La pública es enviada, junto con su número de DNI, a la FNMT CA para su certificación; así, cualquier entidad que confíe en esa CA aceptará dicha clave pública como perteneciente a vd. En poco tiempo podrá descargar su certificado. "Certificado" significa: la clave pública de vd, certificada por la AC. Si esto fuese PGP, dicha certificación sería una firma digital.

Pero hay un problema. Para pedir el certificado, usted solamente ha de introducir su número de DNI. Esto significa que su guasón compañero de trabajo puede pedir dicho certificado por usted. De hecho, cualquiera podría hacerlo. O usted podría suministrar un DNI falso. Si la FNMT CA certifica a tontas y a locas sin verificar los datos, mala AC resultará ser.

Se precisa una acreditación de identidad. Para ello, tras solicitar el certificado de usuario tiene usted que pasarse por una oficina de la Agencia Tributaria e identificarse. Esto es, presentar el DNI y otra cosa más. Esa cosa es un "número de petición" que la FNMT le asigna, y que vd. obtiene cuando solicita el certificado de usuario. Con eso, la Agencia Tributaria sabrá que fue usted quien pidió precisamente ese certificado. Tras la identificación, ha de firmar una solicitud de certificado (esta vez, en papel), donde vd. consigna sus datos personales. Con ello, Hacienda tendrá un registro escrito en el que vd. declara conocer y aceptar las condiciones de uso de este sistema.

Una vez hecho eso, la Agencia Tributaria comunicará a la FNMT CA que tal certificado de usuario fue efectivamente solicitado por tal persona. Ahora la FNMT CA sí tiene ahora una verificación fiable, y puede por fin emitir el certificado de usuario. Es decir, usted se identifica, la Agencia Tributaria comprueba esa verificación y la FNMT firma el certificado. En circunstancias normales, sería la propia FNMT CA la que ejercería las funciones de comprobación, pero ahora mismo carece de una red de oficinas adecuadas, por lo que solicita dicho servicio de apoyo a la Agencia Tributaria.

El resto del proceso (cómo rellenar la declaración, enviarla, pagar, etc) se apoya en la comunicación segura que se establece entre declarante y Agencia, comunicación que se autentifica mediante el Certificado de Usuario, por un lado, y el servidor seguro de la Agencia por otro. ¿Y qué pasa si el contribuyente quiere echarse atrás y presentar su declaración en la ventanilla de siempre? Sin problema: el certificado de usuario puede ser revocado. Y hay que tener en cuenta que este es un certificado de carácter limitado: solamente podrá utilizarse para la presentación de la declaración de la Renta 98, y caduca el 1 de Enero del año 2000.


Y ahora, el mundo real

Obras son amores, y no buenas razones. Y, puesto que no hay mejor maestro que el profesor Experiencia, seguí todos los pasos que acabo de describir. Solicité mi certificado de usuario y me dirigí a la oficina de la Agencia Tributaria de mi ciudad para acreditarme y obtener mi certificado digital. Tras una cola de media hora en la ventanilla de información, me informaron de que aún no es posible realizar dicha acreditación ("acaba de llegarnos el B.O.E, aún no sabemos cómo va a ser, le llamaremos esta semana..."). Bueno, la burocracia es la burocracia. Es una molestia -lo ideal sería poder acreditarse sobre la marcha y sin demoras-, pero todo proyecto nuevo arranca con fallos, así que seremos comprensivos.

Al cabo de un par de días pude realizar tal acreditación. Basta el número de solicitud y el del DNI, y la impresora escupió la Solicitud de Usuario (con el número de petición que se me asignó en el momento de pedir el certificado de usuario por Internet). Dicha solicitud incluía todos mis datos personales, junto con un código adicional de treinta y tres dígitos (a saber para qué sirve), y solamente faltaba mi firma.

Solamente un pequeño fallo. No fue hasta que firmé la Solicitud cuando me di cuenta de que nadie me pidió el Documento Nacional de Identidad. Incluso cuando advertí del detalle a los dos funcionarios que me atendían (muy atenta y amablemente, es de justicia decirlo) y saqué mi DNI se limitaron a mirarlo someramente desde un par de metros de distancia. Probablemente pensaron que nadie tendría la desfachatez de presentarse allí en mi lugar.

Pero ese sencillo gesto de confianza hacia mí supuso una interrupción del proceso lógico que lleva desde una persona a su certificado digital. Una acreditación de identidad defectuosa resulta inútil. Con todo, un ejemplo aislado no puede servir para valorar la validez o no del proceso de certificación digital. Si hubiese sucedido lo mismo en la oficina de expedición de pasaportes, ¿cabría decir que el pasaporte es un documento inválido y poco fiable en general? Evidentemente, no. Así que tomémoslo como una mera anécdota, y sigamos adelante.

El siguiente paso consiste en esperar un par de días, tiempo necesario para que la FNMT reciba la solicitud y emita el Certificado de Usuario; en mi caso fueron cinco días, pero no quiero pecar de quejica, y además había un fin de semana por medio. El aviso de que el Certificado está listo puede recibirse mediante correo electrónico, y la descarga de dicho certificado es cuestión de segundos. Puesto que el certificado pertenece al usuario, su navegador le pedirá una contraseña para protegerlo. Así, nadie más podrá alterarlo o exportarlo (se puede exportar, y posteriormente importar en un navegador de otro ordenador, cualidad valiosa para los que se conecten a Internet por más de un ordenador habitualmente).

Tras analizar todos los pasos del proceso, he aquí mi opinión personal: interesante pero insuficiente. Si bien el concepto en general es adecuado y bien organizado, hay algunos inconvenientes que le quitan validez. No se trata de que Hacienda haya hecho una chapuza total. Más bien al contrario, le honra la calidad del esfuerzo realizado. Pero hacen falta algunos retoques. Veamos los detalles.

En primer lugar, hay que tener en cuenta que la comunicación segura solamente se admite con los navegadores Netscape Navigator (versión 4.06 y posteriores) e Internet Explorer (versión 4 y posteriores).

Hay algunas cláusulas de "letra pequeña" que pueden resultar levemente discutibles. Por ejemplo, la FNMT afirma que no facilitará información sobre los procesos técnicos de producción y expedición de certificados, lo que puede molestar a algún alma curiosa, pero poco más. Asimismo, la FNMT podrá negarse a expedir un certificado, o a revocar uno ya emitido "en los supuestos de fuerza mayor." Especificar, siquiera someramente, cuáles pueden ser esos supuestos constituiría una buena política de cara al usuario. Hasta ahora, detalles sin importancia.

Hay un pequeño fallo de seguridad a la hora de descargar el certificado de la FNMT AC (el primer paso), ya que esa descarga se realiza mediante una conexión no segura. Por supuesto, sin dicho certificado no se puede comprobar si una conexión es segura. Es como si la policía llamase a su puerta. Usted no quiere abrir la puerta hasta que se identifiquen, pero para eso han de entrar y mostrarles la placa. Tenemos un círculo vicioso: si no se identifican usted no abre, pero si no abre ¿cómo pueden identificarse?

Para romper ese círculo vicioso, la descarga del certificado de la FNMT AC debería hacerse mediante una conexión segura que usase otro certificado digital (de Thawte o Verisign, por ejemplo). De lo contrario, un atacante podría aprovecharse de ello. Bastaría con redirigir la conexión no segura, de manera que vd. realmente descargaría un certificado de una falsa FNMT AC (posible y factible: recordemos que no hace mucho unos hackers consiguieron redirigir la dirección de la Guardia Civil hacia una página erótica). En ese caso, cuando vd. intentase la conexión segura a la Agencia Tributaria para enviar la declaración, el navegador no podría reconocer la certificación de la FNMT verdadera, y la conexión segura no tendría lugar. Resultaría entonces detectable el engaño. Usted habría perdido algo de tiempo, y Hacienda quedaría en ridículo, pero todo quedaría en una molestia.

Más grave me parece el tema de la seguridad. Como sabrán los lectores habituales de estos Informes, la seguridad de la navegación por Red descansa en la longitud de la clave (clave simétrica de sesión). En la actualidad se consideran como totalmente seguras las claves de 128 bits. Esto se debe a que un atacante que tuviese que probar todas las clave posibles tendría ante sí nada menos que 2^128 combinaciones, un número demasiado grande sean cuales fuesen los recursos del atacante. El venerable algoritmo DES, aún muy usado en todo el mundo, tiene claves de 56 bits, que pueden ser (y han sido) reventadas en pocas horas con un coste en equipo informático de algunos millones de pesetas; agencias como la norteamericana NSA, con recursos masivos, podrían leer mensajes cifrados con DES casi en tiempo real. Las claves de 40 bits podrían detener a un pirata informático de medio pelo, pero no a una entidad con recursos.

El Secretario de Estado de Hacienda, Juan Costa, ha afirmado al respecto que es imposible decodificar los datos que viajan a través de la red, porque la conexión mediante Internet está protegida por un sistema de claves de alta seguridad, que el Gobierno de Estados Unidos no deja utilizar a personas privadas, para evitar actos ilícitos, y sí a las Administraciones Públicas de otros países ( ver p. ej. IDEAL de Granada, 20 de Abril). Confiado en ello, pruebo la conexión segura de la Agencia Tributaria. Y el cifrado es ... !clave DES de 56 bits!

¿Para eso tanta publicidad? Hay bancos en España que ofrecen a sus clientes cifrado totalmente seguro, con clave de 128 bits. Y resulta que la Agencia Tributaria se apunta a un código de cifrado que está de capa caída por su limitada longitud de clave y que el propio gobierno norteamericano va a sustituir por otro más robusto. ¿Por qué nuestro gobierno no puede ponerse a la altura? Cierto, DES es lo más que se permite exportar desde EEUU para usuarios (bancos y otras empresas pueden optar a software de cifrado más robusto). Pero un estado soberano, aliado militar de EEUU, debería poder obtener un tratamiento más preferente. Ni siquiera me molestaré en hablar de servidores no-norteamericanos que incorporan cifrado fuerte, como los conocidos servidores Apache.

Y no les he contado lo más divertido: la Autoridad de Certificación no es la FNMT, sino la RSA Data Security. O sea, que tras pedir certificados digitales, acreditar identidad y todo lo demás, nos quedamos con una conexión de seguridad media, certificada por una AC extranjera. ¿Para qué sirve entonces la FNMT AC en nuestro navegador, si no certifica nada?

Bueno sí hay ocasiones en que la certificación de la FNMT AC entra en acción: cuando se establece una conexión segura para solicitar el certificado de usuario, y posteriormente cuando el CU es descargado (una vez que la FNMT ha verificado nuestros datos). Es una transferencia importante, ya que ese certificado de usuario será lo que nos acredite digitalmente ante la Agencia Tributaria. Pues bien, dicha conexión segura, certificada por la FNMT AC, tiene una clave de tipo RC4, !de 40 bits! Menos mal que, por lo menos, utilizan el protocolo SSL v3 en lugar del más inseguro SSL v2.

No puedo ocultar mi desilusión al ver lo cerca que ha estado la Agencia Tributaria española de establecer un sistema de entrega informatizada de declaraciones de Renta prácticamente modélico, y cómo lo ha echado a perder en el último momento. Con todo, resulta un sistema que a primera vista parece bueno. Habrá que vér cómo resiste la prueba de fuego real, con grandes cantidades de usuarios, expedición de certificados a gran escala, ataques de posibles hackers, etc.

Finalmente, mi recomendación. Si usted está dispuesto a usar claves de seguridad media a cambio de una mayor comodidad a la hora de entregar la declaración (horario de 24 horas, sin colas), puede probar suerte y utilizar el nuevo servicio que el Estado pone a nuestra disposición; a fin de cuentas, dichas claves sólo serán inseguras frente a atacantes con grandes recursos informáticos. Personalmente, prefiero esperar a disponer de sesiones de conexión auténticamente seguras (con claves de 128 bits) y exigir a Hacienda el mismo rigor que exigimos a los bancos y empresas (ver p. ej Informe 5). Como he declarado en alguna ocasión, la seguridad ha de respaldarse con algo más que palabras. Cuando tengamos conexiones en clave de 128 bits, creeré a pies juntillas las declaraciones sobre decodificación imposible o claves de alta seguridad. Mientras tanto, y con el permiso del señor Costa, me quedaré con mis impresos de colores y mi declaración por triplicado. ¿O era por duplicado? Siempre se me olvida...

Actualización: 6 Junio 1999

Desde las últimas líneas he recibido algunos mensajes que hacen adecuada una actualización, incluso antes de acabar la campaña de la Renta de este año. Principalmente son buenas noticias. Pero dejaré lo mejor para el final.

En primer lugar, rompamos una lanza en favor de las minorías. Las instrucciones de la FNMT dicen se usen navegadores Netscape Navigator o Internet Explorer. Sin embargo, es en principio posible el uso de otros, con tal que admitan las normas X.509 sobre certificados digitales. Un corresponsal me avisa que ha podido usar el navegador Opera satisfactoriamente (excepto por que no pudo recoger su certificado digital, lo que puede deberse a una leve tardanza por parte del emisor). De hecho, afirma haber podido generar una clave pública de 2048 bits, más allá de lo que -según la FNMT- podría hacerse.

[Para los no iniciados, un inciso. Los navegadores usan una clave simétrica, o clave de sesión, para cifrar los mensajes electrónicos. Esa clave simétrica, a su vez, es cifrada con una clave asimétrica, o certificado de clave pública; esto permite enviar la clave simétrica al usuario sin que sea interceptada por terceros. Las claves simétricas suelen ser del tipo RC4, de 40 o 128 bits, o bien DES de 56 bits; las claves asimétricas, en los navegadores, son del tipo RSA, con clave de entre 512 y 2048 bits, según el caso. Se consideran seguras las claves simétricas de 128 bits y las asimétricas de 1024 bits].

Este interlocutor también me expone un detalle en el que yo no había caído. Los navegadores habilitados para la exportación tienen limitado el tamaño de clave a 40 bits para la simétrica, y certificados con clave pública de 512 bits. Entonces, ¿como puede generarse con dicho navegador una clave pública que tenga 1024 bits (e incluso 2048, como es su caso)? Álvaro de la Escalera, del equipo de FNMT, me detalla en un amable mensaje que se decidió dejar la generación de claves de 512 bits (para los navegadores "domésticos" con cifrado débil) y asumir el riesgo (que existe en claves asimétricas de 512 bits, si bien requiere enormes recursos informáticos), en lugar de instalar software adicional para generar claves "fuertes" (128 bits simétrica, 1024 bits asimétrica). Si bien no es una solución ideal, creo que resulta aceptable. Afirma también que la FNMT está a la espera de conseguir unos certificados Global Server ID que les permitiría "disparar" la seguridad de la comunicación incluso a navegadores "domésticos" con un cifrado débil. No tengo claro cómo se consigue tal cosa, aunque recordemos que incluso los navegadores domésticos (habilitados para la exportación) permiten cifrado con clave RC4 de 128 bits "cuando esté permitido." Cuando lo consigan será excelente, aunque puede que tarde algo. Seamos pacientes.

Otro mensaje de la FNMT, esta vez de su director de Sistemas Informáticos. Al parecer, coincidimos en muchas cosas, aunque no en todo. Me informa, en primer lugar, que el hecho de que, aunque la conexión segura con la Agencia Tributaria esté certificada por RSA Data Security, se cambiará (por un certificado de la propia FNMT AC, supongo) en un futuro próximo. También me comenta que el uso de Javascript es necesario para poder detectar el navegador, ya que cada uno genera los certificados y claves de manera levemente distinta. Reconozco aquí mi ignorancia, y acepto la explicación tal cual.

Discrepamos acerca de la necesidad o conveniencia de publicar el certificado de la FNMT en una dirección certificada por otra AC. Cierto es, como me indica, que ninguna de las AC habituales (Thawte, Verisign, RSA) permiten comprobar las huellas [fingerprints] de firma segura, aunque el problema es menor para éstas puesto que los navegadores incorporan "de serie" los certificados de estas y otras AC (en Netscape puede verse mediante Seguridad/Certificados/Firmantes). El uso de una nueva AC requeriría que el usuario recibiese el certificado de dicha AC (en nuestro caso, FNMT Clase 2 AC) de una forma que asegurase la integridad/autenticidad del envío, lo que implicaría una conexión segura.

A la espera de que se solucione ese problema potencial de seguridad, recuerdo lo que dije anteriormente: en el peor de los casos -si descargásemos un certificado de FNMT falso, cortesía de nuestro vecino el hacker travieso- no habría mayores problemas, ya que no podríamos usarlo para enviar los archivos con nuestra declaración a la Agencia Tributaria. En cualquier caso, se puede comprobar la huella de dicho certificado en la dirección https://aeat.es/r98cert.html. Debí haberla incluido yo mismo en la versión original del Informe, pero se me olvidó, y pido disculpas por ello. Aparecen allí dos huellas, según sea el procedimiento hash usado por el navegador de cada ordenador en particular.

También me avisa de que mi comentario sobre que el certificado de la FNMT "no certifica nada" puede inducir al usuario a borrarlo. No lo borre. Dicho certificado sí que certifica. Como dije posteriormente a ese comentario (antepenúltimo párrafo del Informe original), sirve para certificar la conexión a la hora de obtener el certificado de usuario, y posteriormente cuando se vaya a enviar la información sobre la declaración a la Agencia Tributaria. Aunque claro, si siguen usando una conexión con clave de cifrado simétrico de 40 bits... Pero un momento, ¿qué sucede aquí? Cuando accedemos a la dirección https://aeat.es:8000/renta98/irpf128.html aparece un mensaje que nos indica cómo "continuar con cifrado a 128 bits" ¿Es que la Agencia Tributaria se ha puesto las pilas de repente?

Eso parece. Existe ya la opción de conectar con cifrado simétrico de 128 bits, nuestro preferido para las conexiones de alta seguridad. Dicha opción no estaba disponible desde el comienzo de la campaña Renta98, pero ya está habilitada. Para ello, hay que usar el navegador Netscape (4.06 o posterior), con la opción "Cifrado RC4 con una clave de 128 bits y un MD5 MAC" activada (ver Seguridad/Navigator/Activar SSL/Configuar SSL v3. Bien por la Agencia Tributaria, y gracias a Sistemas Informáticos de la FNMT por hacerme notar este hecho. Con esto sí que puedo recomendar el uso del sistema de declaración de la Renta por Internet.

A fecha 31 de Mayo, la FNMT ha recibido más de 20.000 solicitudes, se han emitido más de 10.000 certificados y se han presentado más de 5.000 declaraciones. Y lo que es mejor, se ha agilizado mucho la tramitación de las devoluciones. Esto es lo que me afirman desde la FNMT, y me ha sido confirmado por un declarante que me asegura haber recibido la devolución de su declaración !el 19 de Mayo! Esto sí que debería usarse como publicidad para la combinación Renta-Internet. Si le sale a devolver, tendrá una "paga extra" para el verano. Y sin usar pegatinas fiscales. Toda una tentación...