El DNIe, la vulnerabilidad ROCA y los problemas heredados

El pasado día 13 de junio El Confidencial publicó una noticia con el título “CCOO alerta de un error que invalidaría los DNI expedidos entre 2015 y 2018” y en la entradilla de esa misma noticia, se aclaraba “Una modificación del ‘software’ que utiliza la dirección general de la Policía impediría renovar los certificados digitales e invalidaría unos 19 millones de DNI, según el sindicato”.

En el cuerpo del artículo se señalaba que la inutilización de esos 19 millones de DNIe, con un coste unitario de 7,053 euros más IVA, tendría un coste total aproximado de 134 millones de euros, que tendría que pagar la Administración, por suponer una sustitución por fallo del sistema y no una renovación por caducidad, lo que también podría suponer el colapso de las oficinas de expedición de los DNIe.

Pero ¿existe algún error? y ¿qué hay realmente detrás de esta noticia?

En el año 2005 escribí un artículo para el Observatorio de Voto Electrónico de la Universidad de León, sobre las consideraciones técnicas y operativas del DNIe y en dicho artículo señalaba, entre otros, los problemas de ciberseguridad y logísticos que se derivarían de un fallo en un algoritmo criptográfico incluido en el hardware del DNIe. Años después, ese escenario, que muchos calificaban de improbable y alarmista, se hizo realidad.

La vulnerabilidad ROCA en 19 millones de DNIe españoles

En el año 2017 se descubrió la vulnerabilidad ROCA (CVE-2017-15361) que afectaba a la librería RSA de la empresa Infineon, que es la que se utilizaba en algunos modelos de DNIe generados a partir de tarjetas inteligentes de la empresa Gemalto (básicamente los que tienen números de serie entre ASG160000 al BGA000000 y que suman unos 19 millones de dispositivos). Unas de las cuestiones más controvertidas de la vulnerabilidad ROCA es que existía en estos dispositivos de Infineon desde al menos el año 2012 y ello, a pesar de que estos chips contaban con certificaciones de seguridad NIST FIPS 140-2 y Common Criteria EAL 5+, que son de las más altas que se pueden obtener y que además, fueron otorgadas por varios países sin que nadie se percatarse del grave problema, pero lo cierto es que las certificaciones Common Criteria no entraban en esos aspectos.

El fondo del problema está en el hecho de que la generación de claves RSA de gran tamaño, implica la generación de dos números primos muy grandes de forma aleatoria, lo que consume mucho tiempo en dispositivos con una capacidad de cálculo reducida, como es el caso de las tarjetas inteligentes.

Por ello, se usa un algoritmo que genera unos números, que se denominan primos industriales, que es relativamente rápido y que no siempre genera números primos. Por ello, es necesario comprobar que realmente son primos mediante unos algoritmos denominados test de primalidad. El fallo estaba en que la librería RSA de Infineon solamente comprobaba la primalidad de unos primos que cumplían una determinada característica, dando por buenos el resto, aunque no fueran primos y se pudieran factorizar, lo que provocaba que las claves generadas con esos números no primos, no fueran seguras y se pudieran factorizar.

Hay que decir, que la vulnerabilidad de la Librería RSA de Infineon fue un auténtico desastre para la ciberseguridad ya que también afectó a otros dispositivos de seguridad, como tokens de autenticación, sistemas de firma de correo y de software o chips TPM (Trusted Platform Module), que se usan en los sistemas TIC para labores criptográficas, como la generación de números aleatorios, así como para, el arranque seguro, o la generación y almacenamiento de claves.

En virtud de la vulnerabilidad ROCA de la librería RSA, existía la posibilidad de realizar un ataque de factorización de la clave pública y obtener la clave privada. Es decir, usando la clave pública, que como su nombre indica está disponible para todo el mundo, se podía obtener la clave privada, la cual solamente la debe tener el usuario dueño de la misma, ya que es la que permite firmar, descifrar y autenticarse, con ello, suplantar su identidad digital, firmar documentos en su nombre o descifrar información sensible dirigida a él.

Según los investigadores, se podían obtener las claves privadas en un tiempo variable entre horas y días, con costes entre 1$ y 40.000$, dependiendo del tamaño de la clave, usando para ello, los recursos disponibles en la nube de Amazon AWS.

Lo primero que hizo la Dirección General de la Policía, fue paralizar todo el sistema de firma electrónica asociada al DNIe y posteriormente, revocar las claves afectadas. Pero en lugar cambiar los DNIe afectados, que es lo que hicieron países como Estonia, que también usaba DNIe con ese chip, lo que se hizo en aquel momento, posiblemente por problemas logísticos o económicos, fue generar una nueva pareja de claves (pública y privada), con una longitud de 1920 bits, que, al parecer, no estaban afectadas por la grave vulnerabilidad ROCA, en lugar de las claves de 2048 bits que usan normalmente los DNIe.

Pero ¿qué implica reducir clave de 2048 bits a 1920 bits?

Debemos sabe que si se reduce el tamaño de una clave RSA en un único bit, lo que se hace realmente, es reducir su fortaleza en un 50%, al dividir por dos el número de claves disponibles. De esta forma, al pasar de una clave de 2048 bits a una de 1920, se está reduciendo el tamaño de la clave en 128 bits lo que es un número muy grande, más bien enorme, cuando vemos que hemos eliminado de un plumazo 2^128 = 3,402823 E38 claves del espacio de claves posibles.

Si consideramos que ese número son kilómetros y queremos recorrer esa distancia a la velocidad de la luz, tardaríamos unos 3,596761 E25 años en hacerlo. Para hacernos una idea de lo monstruoso del número, podemos considerar que el diámetro del universo conocido es de “solamente” unos 9,300 E10 años luz, o que en el universo conocido solamente hay 7 E22 estrellas. Sin duda estamos ante cifras gigantescas, que son complicadas de entender, incluso recurriendo a su comparación con las gigantescas cifras del universo.

Veamos ahora como queda la fortaleza real de una clave de 1920 bits en comparación de una de 2048 bits. Si consideramos que la fortaleza de una clave de 2048 bits es del 100% y vamos quitando bit a bit hasta llegar a quitar 128 bits, tenemos que tras quitar un bit tendremos que nos queda un 100/2^1 = 50% de fortaleza, tras quitar 2 bits tendremos un 100/2^2=25% de la fortaleza, tras quitar 3 tendremos un 100/2^3=12,5% de la fortaleza…… y así sucesivamente, hasta llegar a quitar 128 bits, que tendremos solamente un 100/2^128= 2,9387345 E-37% de la fortaleza inicial en relación a una clave de 2048 bis, que es un número muy, muy pequeño.

Por lo que podemos decir, sin mucho error a equivocarnos, que una clave de 1920 bits es infinitamente más débil que una clave de 2048 bits, aunque también es cierto, que una clave de 1920 bits todavía es una clave muy grande y que la podemos considerar relativamente segura según los estándares actuales, sobre todo, si pensamos que hasta hace unos pocos años, se usaban claves RSA de solamente 1024 bits.

Pero qué dice el CCN de todo este tema de las claves y sus tamaños. En el documento titulado Guía de Seguridad CCN-STIC 807 “Criptología de empleo en el Esquema Nacional de Seguridad”, en su revisión de 2017, se establece que, para sistemas sujetos al ENS de nivel bajo y medio, las claves del firmante deberían ser de como mínimo de 2024 bits.

Si se revisa documentación de otros países, como es el caso de los EEUU con la normativa elaborada por el NIST, se establecen tamaños idénticos de claves para ser usados en la Administración Federal de los EEUU, lo que aparece reflejado en el documento NIST Special Publication 800-57 Part 3 Revision 1 “Recommendation for Key Management Part 3: Application-Specific Key Management Guidance”.

Dicho lo anterior, esos DNIe con claves de 1920, en el mismo año que surge el problema, es decir, en el año 2017, ya tendrían claves con una longitud no apta para ser usadas en la administración electrónica según el Esquema Nacional de Seguridad y la documentación del CCN, por lo que había motivos para haber cambiado esos DNIe.

Por lo tanto y aunque con cuatro años de retraso, lo que pretende ahora la Dirección General de la Policía, y no por error como comenta El Confidencial, es subsanar el grave problema de la fortaleza de las claves RSA en poder de 19 millones de usuarios y forzar el cambio de esos DNIe vulnerables, por otros que no estén afectados por la vulnerabilidad ROCA. De esta forma, esos usuarios podrían usar claves de 2024 bits, evitando así, esa enorme diferencia en la seguridad de la firma electrónica, entre los usuarios que tenían un DNIe vulnerable a ROCA y los que no.

Sin embargo, considero, que al igual que se hizo en otros países, estos dispositivos se deberían haber cambiado en cuanto se detectó la vulnerabilidad en 2017 para evitar otro grave problema que voy a comentar seguidamente.

Actualizarlos ahora no resuleve el problema en el pasado

En España, salvo que nuestra aplicación de firma electrónica lo permita y configuremos voluntariamente un servidor de sellado de tiempos, no es obligatorio que, en la firma de documentos mediante certificados cualificados o reconocidos, que tiene la consideración de firma manuscrita, cuente con un sellado de tiempos y esto es un problema.

El sellado de tiempos consiste en que un tercero de confianza certifica la fecha y la hora en la que se firmó digitalmente un determinado documento, lo que implica que hagamos la firma con conexión a Internet para poder acceder al servidor de sellado de tiempos. Por ejemplo, Acrobat Reader DC, mediante la secuencia de mandatos Edición | Preferencias | Seguridad, nos permite configurar un servidor de marca de hora para la firma de nuestros documentos. Desgraciadamente, no todos los programas de firma electrónica, incluidos algunos proporcionados por la Administración, permiten configurar un servidor de tiempos.

Por lo tanto, si no se configura un servidor de sellado de tiempos, la fecha y la hora de la firma del documento, se corresponderá con la que tenga el ordenador en el que se realiza la firma y ese dato, que en algunos casos es vital para considerar la validez de la firma, se puede cambiar muy fácilmente, con enormes repercusiones legales y de seguridad. Desde mi punto de vista y a tenor de lo que voy a comentar seguidamente, creo que no se debería considerar equivalente a una firma manuscrita, la firma digital de ningún documento, aunque se realice con un certificado reconocido o cualificado según el Reglamento europeo eIDAS, si no dispone de sellado de tiempos.

Supongamos ahora, que una persona dispone de un documento de otra persona, que llamaremos víctima, firmado con un DNIe vulnerable a ROCA antes de que se descubriera la vulnerabilidad, por ejemplo, en el año 2015, por lo que el primero tiene acceso a la clave pública vulnerable a ROCA de la víctima, aunque puede que todavía no sepa que es vulnerable.

Supongamos también, que esa misma persona recibe un documento firmado con el DNIe de la víctima, pero con una clave de 1920 bits, lo que le indica de forma clara, por si no lo sabía hasta ese momento, que la víctima tuvo en su momento una clave posiblemente vulnerable al ataque ROCA. Es decir, que el uso de claves de 1920 empeora el escenario, al macar a las posibles víctimas como vulnerables a ROCA en el pasado.

Ahora, el atacante puede coger la clave pública presente en el documento firmado en 2015 por la víctima, contratar los servicios que sean necesarios en la nube de Amazon y tras unos días de computación intensiva y un precio más o menos asequible en función de los factores presentes, obtener la clave privada de la víctima. De hecho, el proceso no sería muy complicado, puesto que internet hay disponibles varias implementaciones funcionales de este ataque.

Seguidamente, con esa clave privada de la víctima y modificando la fecha y la hora del ordenador adecuadamente para fijarla en una fecha anterior a la fecha de revocación de las claves en 2017, el atacante podría firmar un documento, que en teoría y añadiendo algunos requisitos más, tendría la misma validez que una firma manuscrita de la víctima. De esta forma tan simple, el atacante podría generar, por ejemplo, un documento firmado digitalmente con la clave privada de la víctima, con la cesión, o la venta, por un valor muy inferior al del mercado, del domicilio de la víctima, y posteriormente, reclamar su propiedad.

Y esto es un problema muy grave para la víctima, ya que este escenario no se contempla como muy probable en la legislación en vigor y por ello, si se impugna una firma electrónica cualificada o reconocida la carga de la prueba cae en el que impugna la firma, por lo que el art.3.8 de la LFE establece que: “Si dichas comprobaciones obtienen un resultado positivo, se presumirá la autenticidad de la firma electrónica reconocida con la que se haya firmado dicho documento electrónico, siendo las costas, gastos y derechos que origine la comprobación exclusivamente a cargo de quien hubiese formulado la impugnación.” Es decir, que la carga de la prueba cae en la persona que impugna la firma electrónica.

Es evidente que esta situación quiebra gravemente la confianza en el sistema de firma electrónica del DNIe, al menos, en lo que respecta a los usuarios con un DNIe vulnerable a ROCA. De esta forma, un usuario de un DNIe vulnerable a ROCA podría repudiar una firma realizada por él antes de 2017 diciendo que él no la ha efectuado y que le deben haber hackeado su clave privada. Asimismo, cualquier receptor de un documento firmado con un DNIe vulnerable a ROCA y con fecha anterior a 2017, podría poner en duda la validez legal del documento recibido en base a los mismos motivos.

En esta situación pocas soluciones quedan, pero una de ellas podría ser el proceder a la refirma de documentos firmados antes de 2017 con claves vulnerables, antes de otorgarles una plena validez legal en la actualidad. Aunque puede que no todo el mundo esté dispuesto a refirmar un documento, si considera que le perjudica de algún modo y tiene ocasión de repudiarlo, como, por ejemplo, si se trata de la escritura de una hipoteca por varios cientos de miles de euros.

Quizás, lo que nos libra en este caso, es que desgraciadamente el DNIe lo usa muy poca gente en este país y que, en ese escenario, puede que sea complicado que aparezca una atacante con, la oportunidad y la capacidad técnica y económica necesarias, así como con el acceso a una clave pública vulnerable a ROCA de una víctima, en una situación que le sea económicamente rentable llevar a cabo el ataque.

Pero, aunque consideremos que el escenario es improbable, hay que considerar que es posible y que el resultado, de materializarse la amenaza, tendría consecuencias catastróficas para la víctima.

Col. (R) Fernando Antonio Acero Martín
CISO de Acero Abogados y Consultor de Ciberseguridad e Inteligencia