eIDAS2, la cartera europea de identidad digital y el RGPD (II)

Foto de NordWood Themes en Unsplash.

En esta publicación se analiza cómo podrían materializarse diferentes amenazas de vinculación contra las carteras de identidad digital, lo que implicaría incumplir el requisito de no vinculación (unlinkability) que recoge eIDAS2. Esto se debe principalmente al uso de identificadores únicos (firmas) y a los mecanismos de revocación de credenciales obligatorios.

El reglamento eIDAS2 tiene como objetivo garantizar la protección de datos y la privacidad cuando se usen las carteras de identidad digital de la UE. Aun así, el nuevo escenario plantea una serie de cuestiones, tales como:

1. Si uso mi cartera cuando compro productos o accedo a servicios privados o públicos, ¿el emisor de la credencial (gubernamental o privado) puede obtener información sobre mis actividades? ¿Incluso en tiempo real?
2. Si uso mi cartera para revelar de forma anónima que soy estudiante, con edad suficiente para acceder a servicios para adultos, miembro de una asociación o cualquier otra condición, ¿es posible rastrear mi actividad porque todos mis accesos se pueden vincular? Y, por lo tanto, ¿es posible vigilarme o perfilarme? ¿Quién podría hacerlo?

eIDAS obliga a garantizar la propiedad de no vinculación, de manera que sea imposible asociar diferentes datos o acciones a un sujeto de datos específico. Esta propiedad es crucial porque impide el seguimiento y la correlación de las actividades del interesado, evitando la elaboración de perfiles y la vigilancia, incluso cuando se producen brechas de datos o diferentes partes involucradas en el tratamiento de datos personales colaboran entre ellas.

El Architecture and Reference Framework (ARF) es el conjunto de normas comunes, especificaciones técnicas y mejores prácticas, que los Estados miembros deben seguir para implementar las carteras. La falta de un enfoque global para la propiedad de no vinculación en este ARF resulta preocupante. A pesar del mandato de eIDAS2 en cuanto a la utilización de técnicas que preserven la privacidad, la situación actual es que no tenemos detalles sobre cómo se logrará técnicamente la no vinculación, lo que deja espacio para implementaciones que podrían no proteger adecuadamente los datos personales de los usuarios. Sin embargo, el ARF aún está en desarrollo, para completarlo se están discutiendo 23 puntos diferentes (denominados temas) hasta finales de 2025. Bastantes de ellos abordan este problema.

La respuesta a la pregunta 1 antes planteada depende de las decisiones que se tomen en la versión definitiva del ARF y de cómo (y hasta qué nivel) garantice la no vinculación con respecto a los emisores de credenciales. Estos emisores no deben ser capaces de saber o aprender nada sobre cuándo, dónde y a qué proveedores de servicios, como partes usuarias (Relying Parties o RPs), un interesado presenta sus credenciales mediante la cartera. A esto a menudo se le llama inobservabilidad (unobservability). Supongamos que el emisor de una credencial de mayoría de edad almacena todos los valores de elementos únicos (salts, hashes, clave pública, valor de firmas) de todas las credenciales emitidas. Si una o más RP comparten con el emisor el valor de cualquiera de los elementos únicos de una credencial que han recibido (aunque sea de manera indirecta, por ejemplo, a través del mecanismo de revocación), el emisor puede vincular la transacción al sujeto de datos correspondiente, rastrear en qué RP ha presentado sus credenciales (sitios web para adultos, plataformas de apuestas, tiendas de alcohol, etc.) y construir un perfil de sus hábitos. Esto es justo lo que se debe evitar.

La respuesta a la pregunta 2 depende de nuevo del ARF y de si garantiza la no vinculación con respecto a las RP (proveedores de servicios) en diferentes presentaciones. Supongamos que el usuario presenta una credencial a una RP en diferentes sesiones o transacciones.  En ese caso, la RP no debería ser capaz de saber o aprender (mediante datos o información adicionales como metadatos, datos no revelados explícitamente por el usuario o conjuntos de datos adicionales) que estas transacciones corresponden al mismo usuario. Además, si el usuario presenta una misma credencial en diferentes RP, no deberían poder saber o aprender que todas estas transacciones corresponden al mismo usuario. A esto a menudo se le llama no vinculación multi-presentación (multi-show unlikability). Supongamos que un usuario desea participar en un programa de descuentos o fidelidad empleando para ello su cartera. Los valores de elementos únicos de dicho usuario pueden permitir a todas las partes que participan en ese programa vincular todas las transacciones con el interesado, que puede estar sujeto a un perfilado de su comportamiento o a precios diferenciados. De nuevo, esto es algo que se debe evitar.

Además, en este caso hay que tener en cuenta una propiedad de no vinculación diferente cuando las RP y los emisores de credenciales cooperan, comparten información, o un tercero logra comprometer a ambas partes (por ejemplo, en el caso de una brecha de datos en la RP y el emisor). En este caso, el emisor que proporcione credenciales al usuario no debe poder saber ni aprender nada sobre el usuario a partir de la información obtenida de la RP. Y al contrario. Esto a menudo se denomina no vinculación total (full unlikability) o falta de trazabilidad, ya que implica que los emisores de credenciales y las RP no tienen posibilidad de rastrear el uso de las credenciales de un usuario y sus transacciones. Si volvemos al ejemplo de la credencial de mayoría de edad, una o más RPs podrían colaborar con el emisor de credenciales, cruzar información y vincular transacciones a sujetos de datos específicos para construir perfiles. O ambas partes podrían sufrir una brecha de datos y cualquier persona con acceso a su información podría combinarla y construir esos mismos perfiles.

Como se ha observado en los ejemplos, en general, una amenaza de vinculación puede materializarse directamente a través de identificadores únicos o indirectamente mediante la combinación de diferentes datos sobre el interesado o la elaboración de perfiles de su comportamiento.

El reglamento eIDAS2 promueve la propiedad de no vinculación. Sin embargo, el ARF actual propone el uso de los formatos ISO mDL (Mobile Driver's License) y SD-JWT (Selective Disclosure JSON Web Token) para las credenciales, que podrían no ser suficiente para garantizar esta propiedad  porque  se basan en firmas para su validación.

Estas firmas son identificadores únicos que permiten reconocer la firma de un interesado en concreto en múltiples presentaciones, incluso si sólo se revela información contenida en las credenciales de manera selectiva. Si un emisor de credenciales emite un carné de conducir digital que contiene atributos como el nombre, la fecha de nacimiento y la dirección, las RP y el emisor de credenciales con la ayuda de estas, podrían rastrear las presentaciones del sujeto de datos de este carné en la misma RP y en diferentes RP a través de la firma, incluso si el usuario solo revela su edad o dirección cada vez. En este caso no es posible garantizar las propiedades de multi-show unlikability o full unlikability. Lo mismo ocurriría con otros posibles identificadores únicos persistentes, explícitos o implícitos (dentro de los metadatos, por ejemplo, las direcciones IP).

Un ejemplo diferente, que ya se ha adelantado, implicaría materializar la amenaza de vinculación aprovechando los mecanismos de revocación obligatorios para las credenciales según eIDAS2. Si el mecanismo de revocación requiere que la RP se ponga en contacto con el emisor de credenciales o con una autoridad central para comprobar la validez de una credencial, esta interacción podría facilitar el seguimiento. La RP podría inferir que varias presentaciones con el mismo estado de revocación o marca de tiempo, se originaron en el mismo sujeto de datos, incluso si los atributos divulgados son diferentes en cada presentación. Por otro lado, los mecanismos de revocación que involucran al emisor de la credencial en el proceso de validación también pueden ser un problema desde su punto de vista. Incluso si el emisor solo se entera del estado de revocación y no de los atributos específicos que se presentan, se puede rastrear el hecho de que el sujeto de datos interactúe con la RP en un momento y lugar determinados. Esto crea un rastro de la actividad del interesado que el emisor puede correlacionar con otra información.

La amenaza de vinculación más grave surge cuando el mecanismo de revocación de credenciales permite que tanto el emisor como la RP recojan información sobre la actividad del interesado. Si ambas partes pueden acceder al estado de revocación, las marcas de tiempo u otros identificadores asociados con la credencial, pueden cooperar entre ellas para rastrear al usuario en diferentes transacciones y proveedores (RPs).

El ARF, los reglamentos de ejecución y las diferentes propuestas de la comunidad sugieren reducir el alcance o la frecuencia de las interacciones potencialmente vinculables. Por ejemplo, emitir credenciales de corta duración o lotes de credenciales para unos pocos usos o para un único uso. Además, limitar las comprobaciones relacionadas con la revocación de credenciales exclusivamente a los atributos que tengan un período de validez superior a 24 horas. Sin embargo, estas soluciones pueden causar problemas de usabilidad debido, por ejemplo, a que necesitan que el interesado solicite, almacene y gestione un gran número de credenciales. También podrían causar costes operativos significativos para los emisores, y hay que tener en cuenta que no evitan todas las amenazas mencionadas.

El mejor enfoque podría ser confiar en técnicas criptográficas como las firmas aleatorias o ciegas, pruebas de conocimiento cero (por ejemplo, para demostrar la validez de una credencial sin revelar ninguna información de tipo identificador a la RP o al emisor), credenciales anónimas o mecanismos de revocación basados en acumuladores, por mencionar sólo algunos ejemplos. La pregunta sería: ¿existen diseños e implementaciones efectivas y seguras de estas técnicas, soportadas por hardware, que puedan ser estandarizadas, certificadas y aprobadas por los estados miembros? Es necesario seguir investigando, desarrollando y colaborando para crear soluciones que preserven la privacidad y que se alineen con los objetivos del reglamento eIDAS2. 

En futuras publicaciones se analizarán e ilustrarán otras amenazas diferentes a las de vinculación. Esta entrada está relacionada con otros materiales publicados por la División de Innovación y Tecnología de la AEPD, tales como:

• eIDAS2, la cartera europea de identidad digital y el RGPD (I) [enero 2025]
• La identidad como derecho [junio 2024]