eIDAS2, la cartera europea de identidad digital y el RGPD (III)
El reglamento eIDAS2 trae consigo importantes retos en materia de protección de datos, especialmente en lo que se refiere a la implementación de las carteras de identidad digital. Tales desafíos se hacen más patentes al intentar conciliar aspectos como la funcionalidad, la seguridad y la privacidad. En esta publicación se analiza cómo podrían materializarse diferentes amenazas de identificación contra las carteras de identidad digital.
Foto de Brett Jordan en Unsplash.
El reglamento eIDAS2 incluye entre sus objetivos garantizar la protección de datos y la privacidad de las carteras de identidad digital de la UE. Sin embargo, surge una pregunta esencial: ¿Puedo usar mi cartera para probar de forma anónima atributos específicos, como ser estudiante, ser mayor de edad o ser miembro de una asociación, sin revelar mi identidad? Si no es así, ¿quién tiene la capacidad de identificarme y con qué medios?
En el contexto de las carteras, las amenazas de identificación surgen cuando actores del ecosistema como los emisores de credenciales, las partes usuarias (Relying Parties o RP) o los proveedores de carteras conocen de manera inapropiada o innecesaria la identidad real de un usuario. Esto se vuelve particularmente relevante según el caso de uso. Por ejemplo, ciertos escenarios, como el cruce de fronteras o los sistemas de pago, requieren una identificación y autenticación seguras del usuario. Por el contrario, otros escenarios, como la verificación de edad, solo requieren la prueba de un atributo específico y deben preservar el anonimato del usuario. La amenaza de identificación, a veces denominada sobreidentificación, puede materializarse directa o indirectamente (como resultado de un fallo al desacoplar los atributos de identidad de un usuario de sus transacciones seudónimas o no identificables).
Con los casos directos, una RP solicita al usuario que se identifique cuándo no es necesario que lo haga. Las salvaguardias deben garantizar que una RP no pueda solicitar la identificación del usuario a menos que sea estrictamente necesaria, y que la cartera dé soporte al uso de seudónimos para ayudar a evitar la sobreidentificación.
Las RP que tienen la intención de utilizar las carteras deben registrarse en el Estado miembro en el que estén establecidas. Durante el registro deben especificar el uso previsto para la cartera, incluidos los datos exactos que solicitarán y las razones para hacerlo. Las RP no pueden solicitar ningún dato adicional de los usuarios más allá de lo que han registrado. Este proceso evita prácticas como que una RP solicite el nombre completo de un usuario cuando sólo se requiere que verifique su edad, y sirve para implementar el principio de minimización de datos, lo que permite evitar las amenazas de identificación.
El marco de la cartera mejora la transparencia al hacer que la información de registro de las RP esté disponible públicamente en línea en un formato fácil de usar. La cartera debe leer el uso previsto por parte de la RP en este registro y alertar al usuario si se solicita información adicional (datos que no estaban previstos, por ejemplo, para identificar al usuario), dándole al usuario la opción de rechazar la transacción. Esto permite a los usuarios aceptar o rechazar presentaciones de credenciales y evitar la sobreidentificación.
Además, la cartera debe permitir a los usuarios crear y administrar sus propios seudónimos. Las RP no pueden rechazar estos seudónimos a menos que lo exija la ley. La minimización de datos y la protección de datos desde el diseño y por defecto se pueden lograr utilizando seudónimos como opción predeterminada, revelando la identidad sólo cuando sea estrictamente necesario. Los datos de identificación se deben tratar sólo cuando es necesario, generalmente para necesidades legales de Know Your Customer (KYC).
Para asegurarse de que el uso de un seudónimo no se convierta en un mecanismo de seguimiento, la cartera debe generar seudónimos locales para cada parte usuaria (diferentes para cada RP, específicos y no compartidos). Esto garantiza que el uso de un seudónimo con una RP no se pueda vincular al uso del mismo seudónimo con otra RP diferente, evitando así la correlación entre RPs. Además, los seudónimos no deben poder vincularse a la identidad del usuario por parte de las diferentes RP y de otros actores que participan en el ecosistema.
Con los casos indirectos, surge un escenario particularmente crítico cuando actores como RP y emisores de credenciales confabulan para combinar su conocimiento e inferir datos de identidad más allá de lo que cada parte sabe de forma independiente. Esto se agrava si también se materializan amenazas de vinculación (linking).
Supongamos que un usuario utiliza su cartera en dos casos de uso diferentes: uno que requiere anonimato (como la verificación de la edad) y otro que requiere una identificación completa (como registrarse en un servicio en línea regulado). En este escenario, el usuario posee un permiso de conducir digital (un PID) emitido por una autoridad gubernamental, que incluye atributos como nombre, fecha de nacimiento y dirección postal. La autoridad emisora almacena todos los valores de elementos únicos (incluidos salts, hashes y valores de firma) asociados a cada credencial que emite.
La RP A es un sitio privado de contenido para adultos en línea que solo necesita la prueba de que el usuario es "mayor de 18 años" (una prueba anónima). La RP B es un servicio financiero regulado (como un banco o un servicio de intercambio de criptomonedas) que necesita una identificación completa de tipo KYC, incluido el nombre completo del usuario y posiblemente otra información, según lo exija la ley.
El usuario accede a la RP A y utiliza la revelación selectiva en su permiso de conducir digital para mostrar sólo que es "mayor de 18 años". Incluso con la revelación selectiva, la presentación a la RP A incluye elementos únicos y persistentes de la credencial que se utiliza para la transacción, como la firma del emisor y las “huellas” criptográficas (salts o hashes estáticos) necesarias para la validación.
A continuación, el usuario se registra en la RP B, el servicio financiero, que requiere una identificación completa, incluido el nombre y la fecha de nacimiento. El usuario presenta el mismo permiso de conducir digital (o una unidad del mismo lote de credenciales) a la RP B, revelando completamente sus datos de identidad. Esta presentación contiene los mismos identificadores únicos y persistentes o elementos criptográficos que la que se ha realizado en la RP A.
La RP A y/o la RP B se confabulan con el emisor de credenciales, con el que comparten los elementos únicos que recibieron (por ejemplo, el valor de firma específico o el valor del salt). Dado que el emisor almacena todos los valores de elementos únicos asociados con la verdadera identidad del usuario en el momento de la emisión, y la RP A/RP B proporcionan el elemento que permite realiza la vinculación, el emisor puede correlacionar la transacción anónima en RP A con la transacción identificada en RP B. Las partes en connivencia vinculan con éxito la identidad completa del usuario en el mundo real con su actividad anónima (consumo de contenido para adultos). El perfil del usuario ha derivado en algo más completo que lo que conocían explícitamente la RP A (que solo sabía "mayor de 18") o el emisor de credenciales (que no debería saber dónde se ha utilizado la credencial). Este escenario conduce a la vigilancia y la elaboración de perfiles no autorizados a través de la identificación única del interesado.
La expectativa de privacidad del usuario, basada en el uso de revelación selectiva de atributos, se viola cuando se exponen datos no deseados. Este resultado demuestra que la revelación selectiva, por sí sola, no protege suficientemente la privacidad sin otras medidas adicionales como las garantías de no vinculación.
Las decisiones sobre otros aspectos de la cartera también pueden afectar a las amenazas de identificación. Estos aspectos incluyen los logs de transacciones (que pueden contener datos que permitan identificar al usuario), las políticas de divulgación incorporadas (EDP, mecanismo para controlar la presentación de atributos desde la cartera a las RP), la vinculación de las credenciales (al dispositivo o al titular), la autenticación o la presentación combinada de credenciales. El ARF de las carteras está en desarrollo todavía. Veintitrés puntos, denominados temas de discusión, se debatirán hasta finales de 2025. Todas las salvaguardas técnicas y de gobernanza mencionadas, junto con otros requisitos de alto nivel, deben integrarse en este ARF para garantizar que las futuras carteras mitigan las amenazas de identificación y cumplen con los principios y requisitos del GDPR.
En futuras publicaciones se analizarán e ilustrarán otras amenazas. Esta entrada está relacionada con otros materiales publicados por la División de Innovación y Tecnología de la AEPD, tales como:
