La primera vulnerabilidad: convertir una prueba de edad en un identificador persistente
El diseño correcto sería:
identidad → proveedor de edad → credencial anónima → plataforma
y que la plataforma sólo sepa:
>15 = sí
El diseño peligroso sería:
identidad → credencial única → plataforma
porque entonces el mismo identificador podría aparecer repetidamente en TikTok, una tienda de aplicaciones, un videojuego, un chatbot, etc.
Segunda: una actualización maliciosa de la aplicación
Un atacante podría intentar comprometer:
el servidor que distribuye actualizaciones,
la cadena de firma de software,
la infraestructura de compilación,
una biblioteca utilizada por la aplicación,
el sistema operativo que la ejecuta,
o las credenciales utilizadas para firmar una actualización.
Éste es el clásico problema de
supply-chain attack.
Una versión aparentemente legítima de la aplicación podría, en un escenario comprometido, recopilar información adicional mientras mantiene exactamente la misma interfaz.
Y aquí aparece una diferencia importante:
criptografía perfecta + software comprometido = sistema comprometido.
La prueba criptográfica puede ser impecable, pero si el dispositivo que genera o presenta esa prueba está ejecutando código manipulado, la protección teórica deja de ser suficiente.
Tercera: transformar la aplicación de “prueba de edad” en un sensor de actividad
Por ejemplo, una implementación abusiva podría intentar observar:
qué aplicaciones están abiertas,
cuándo se realizan verificaciones,
qué dominios solicitan la prueba,
cuántas veces se utiliza,
cuándo se utiliza el dispositivo.
Cuarta: correlación entre plataformas
Imagina esta secuencia:
10:02 → verificación para una red social.
10:14 → verificación para un videojuego.
10:31 → verificación para un chatbot.
11:06 → verificación para otro servicio.
una infraestructura intermedia que registra:
usuario X → plataforma A → hora
usuario X → plataforma B → hora
usuario X → plataforma C → hora
Quinta: convertir la verificación en una condición para acceder a Internet
una infraestructura potencialmente reutilizable.
Hoy:
¿>18?
Mañana:
¿>15?
Después:
¿residente en X?
¿tiene determinada credencial?
¿posee determinada autorización?
La cuestión es de
potencial técnico: una infraestructura de credenciales digitales suficientemente extendida puede utilizarse para muchas finalidades diferentes de aquella para la que nació.
Es el conocido problema de
function creep: una infraestructura construida para A acaba utilizándose también para B, C y D.
Sens: malware convencional en el teléfono
Y aquí ni siquiera necesitamos imaginar una conspiración estatal.
Un teléfono comprometido por:
un spyware comercial,
un troyano bancario,
una aplicación maliciosa,
un exploit del sistema operativo,
podría observar el proceso desde fuera.
Por ejemplo, el malware podría registrar cuándo se abre la aplicación, capturar tráfico que no esté correctamente protegido, obtener metadatos del dispositivo o simplemente observar qué servicios se utilizan.
La criptografía del protocolo no necesariamente puede solucionar un problema que ocurre
antes o después del protocolo.
Es el viejo principio de seguridad informática:
(mensaje citado en revisión)
Séptima: servidores centrales
Otra cuestión es dónde se concentra la confianza.
La Comisión plantea un ecosistema con:
emisores de credenciales,
soluciones de verificación,
listas de proveedores confiables,
aplicaciones,
carteras digitales,
plataformas receptoras.
(
Estrategia Digital Europea)
Cada componente adicional introduce una superficie de ataque.
Un atacante que comprometiera un
emisor de credenciales podría intentar falsificar edades.
Uno que comprometiera un
servicio de validación podría intentar aceptar pruebas fraudulentas.
Uno que comprometiera infraestructura de distribución podría intentar introducir software manipulado.
Y uno que comprometiera registros o telemetría podría intentar realizar correlación masiva.
Por eso el modelo de amenaza no debería limitarse a:
(mensaje citado en revisión)
La pregunta correcta es mucho más amplia:
(mensaje citado en revisión)
Octava: una “puerta trasera” legal no necesita parecer una puerta trasera técnica
Ésta es probablemente la distinción más interesante.
Una backdoor clásica sería:
entrada secreta → acceso secreto
Pero existe una versión mucho más sutil:
facultad legal → acceso excepcional → mecanismo técnico
Por ejemplo,
una norma futura podría exigir que determinadas entidades puedan obtener información adicional bajo determinadas circunstancias.
Eso no requeriría introducir un agujero clandestino. Podría convertirse en una
funcionalidad oficial del sistema.
Novena: el ataque más peligroso puede ser precisamente modificar una especificación
Supongamos que inicialmente la credencial sólo contiene:
over_15 = true
y no contiene identidad.
Un cambio posterior podría introducir:
over_15 = true
issuer = X
credential_id = 893...
device_id = ...
Quizá nadie haya añadido una “puerta trasera” en sentido clásico. Simplemente se ha cambiado el
modelo de datos.
Y una vez que una infraestructura está desplegada en toda Europa, modificarla posteriormente puede resultar mucho más fácil políticamente que construirla desde cero.
