AAVP — Estudio de Vulnerabilidades y Análisis de Seguridad

v0.12.1 — Documento de trabajo — Febrero 2026

Análisis exhaustivo de seguridad del Anonymous Age Verification Protocol. Para la especificación técnica, consultar PROTOCOL.md. Para una introducción accesible, consultar README.md.

Índice

• Resumen ejecutivo de vulnerabilidades
• 1. Supuestos de seguridad
• 2. Vectores de ataque no documentados
• 3. Análisis de esquemas criptográficos
• 4. Vulnerabilidades de la estructura del token
• 5. Modelo de implementación para plataformas (VG)
• 6. Protocolo de auditoría de implementaciones
• 7. Verificación de la segmentación de contenido
• 8. Escenarios de ataque compuestos
• 9. Recomendaciones y trabajo pendiente

Resumen ejecutivo de vulnerabilidades

[!IMPORTANT] Este documento es una hoja de ruta viva. AAVP está en fase de borrador (v0.x) y su modelo de seguridad evoluciona con cada iteración de la especificación. Las evaluaciones de esta sección se actualizan a medida que PROTOCOL.md incorpora mitigaciones. El objetivo no es declarar el protocolo “seguro” o “inseguro”, sino identificar con precisión dónde hay que trabajar.

Estado general de seguridad del protocolo

Distribución actual: 0 áreas en rojo, 2 en amarillo, 5 en verde. La estructura del token alcanza verde: formato binario fijo de 331 bytes, agilidad criptográfica, canonicalización implícita, eliminación de issued_at y APIs de CSPRNG del SO especificadas (6/6 vulnerabilidades resueltas). El modelo de confianza alcanza verde: auto-publicación de claves en dominio propio, claves de vida limitada (≤ 6 meses), revocación bilateral por VGs y endpoint .well-known/aavp-issuer especificado (4/4 vulnerabilidades resueltas). La gestión de sesiones alcanza verde: credencial de sesión autocontenida con descarte obligatorio del token, TTL corto, persistencia a nivel de cuenta y endpoint .well-known/aavp especificado (3/3 vulnerabilidades resueltas). La segmentación de contenido alcanza verde: SAF con SPD firmada (campo opcional ugc_handling), PTL, OVP con metodología de muestreo estratificado (sección 8.4.4) con requisitos estadísticos (IC 95%, tamaños de muestra) y métricas diferenciadas para contenido curado, algorítmico y UGC (V11 resuelta). La resistencia a análisis de tráfico alcanza verde: mitigaciones formalizadas en PROTOCOL.md sección 4.5 con pre-firma y desacoplamiento temporal, padding de mensajes a 2 KiB, jitter obligatorio 0-300s y OHTTP recomendado (V9 resuelta).

Esta tabla consolida todas las debilidades, vectores de ataque y carencias de especificación identificados en este documento. Para cada entrada se indica la sección donde se analiza en profundidad, las precondiciones necesarias para la explotación, la severidad y las mitigaciones propuestas.

Supuestos frágiles y carencias de especificación

Vectores de ataque

Vulnerabilidades de la estructura del token

Carencias del modelo de implementación

Escenarios de ataque compuestos

Debilidades criptográficas transversales

1. Supuestos de seguridad

Todo protocolo criptográfico descansa sobre un conjunto de supuestos. Si un supuesto falla, las garantías que dependen de él se desmoronan. Esta sección distingue entre supuestos que AAVP documenta explícitamente y supuestos que el protocolo asume de forma implícita sin declararlos.

1.1 Supuestos explícitos

Estos supuestos están documentados en PROTOCOL.md y constituyen las bases declaradas del modelo de seguridad.

S1. TLS 1.3 con Certificate Transparency protege los canales

Supuesto: Todos los canales del protocolo (DA-VG y DA-IM) están protegidos por TLS 1.3 o superior. La integridad de los certificados se respalda con Certificate Transparency (RFC 9162), que exige el registro público de todos los certificados emitidos.

Análisis de robustez:

• TLS 1.3 elimina suites de cifrado débiles y reduce la superficie de ataque del handshake respecto a versiones anteriores. Es el estándar de transporte mínimo aceptable en 2025+.
• Certificate Transparency (CT) ha reemplazado al certificate pinning (deprecado; Chrome lo eliminó en 2018, OWASP lo desaconseja salvo excepciones) como mecanismo principal de detección de certificados fraudulentos. CT no requiere mantenimiento de pines por parte del DA.
• En entornos corporativos o educativos con proxies TLS de inspección, la verificación de CT puede fallar, dejando al DA sin capacidad de presentar el token. Este escenario es análogo al fallo de pinning pero con menor frecuencia de falsos positivos.
• Si falla: Un atacante con posición de red privilegiada y un certificado fraudulento (no registrado en CT) podría interceptar el token durante el handshake. Dado que el token no contiene datos personales, el impacto directo es limitado, pero el atacante podría intentar un replay attack en otra sesión.

S2. Secure Enclave / TPM / StrongBox protegen las claves del DA

Supuesto: Las claves criptográficas del Device Agent se almacenan en hardware seguro resistente a extracción.

Análisis de robustez:

• La disponibilidad de hardware seguro varía significativamente entre dispositivos. Los dispositivos de gama baja pueden carecer de StrongBox o TEE adecuado.
• Existen ataques documentados contra implementaciones específicas de TEE (TrustZone): Clkscrew (2017), PLATYPUS (2020), ataques de glitching físico.
• Los emuladores y dispositivos rooteados pueden exponer un TEE emulado que no ofrece las mismas garantías.
• Si falla: Un atacante con acceso físico al dispositivo podría extraer las claves del DA, generar tokens arbitrarios con cualquier age_bracket y utilizarlos en plataformas compatibles. El impacto se limita a ese dispositivo concreto, pero es crítico para su usuario.

Estado: Parcialmente mitigada. PROTOCOL.md sección 4.4 define key attestation como mecanismo opcional para verificar que las claves del DA residen en hardware seguro. El IM puede diferenciar entre claves hardware-backed y software-only. La rotación semanal de claves del DA (sección 4.4.4) limita la ventana de explotación. Riesgo residual: dispositivos sin TEE y ataques a TEE específicos (TrustZone CVEs).

S3. Las firmas parcialmente ciegas impiden al IM vincular el token con el usuario

Supuesto: El protocolo de firma parcialmente ciega (RSAPBSSA-SHA384) garantiza que el Implementador firma el token conociendo los metadatos públicos (age_bracket, expires_at) pero sin poder vincular el token resultante con el DA que lo solicitó.

Análisis de robustez:

• Las firmas parcialmente ciegas (RSAPBSSA) tienen demostración matemática de la propiedad de ceguera parcial. El IM ve los metadatos públicos pero no el nonce. La garantía es fuerte siempre que el esquema se implemente correctamente.
• El IM conoce la franja de edad, lo que constituye una excepción controlada respecto a las firmas ciegas puras. Esta fuga es aceptable: la franja no es un dato personal y el VG también la conoce.
• El riesgo principal no es la criptografía sino la implementación: side-channel leaks durante el proceso de firma, logs del servicio de firma que capturen datos de la petición, o metadatos de red que el IM pueda correlacionar.
• Dentro de una misma franja, todos los tokens son indistinguibles para el IM. La unlinkability se preserva dentro de la franja.
• Si falla: Si la implementación del IM filtra la correlación entre la petición de firma y el token resultante, el IM podría vincular tokens con usuarios específicos, comprometiendo la privacidad y potencialmente la unlinkability.

S4. La rotación de tokens impide el rastreo longitudinal

Supuesto: La generación frecuente de tokens nuevos (TTL de 1-4 horas) impide que un observador correlacione la actividad del mismo usuario a lo largo del tiempo.

Análisis de robustez:

• La rotación es necesaria pero no suficiente para garantizar unlinkability. Si los tokens consecutivos se presentan desde la misma sesión TCP/IP, la dirección IP y las cookies de sesión ya proporcionan un mecanismo de correlación independiente del token.
• El momento de la rotación es en sí mismo una señal: si un VG observa que un token nuevo aparece exactamente cuando otro expira, puede inferir que ambos pertenecen al mismo usuario.
• Si falla: Un observador pasivo con acceso a los logs del VG podría reconstruir cadenas de sesiones, reduciendo la unlinkability efectiva del sistema.

S5. Las plataformas gestionan sesiones de forma segura tras el handshake

Supuesto: Una vez que el VG valida el token y establece una sesión interna con age_bracket, la plataforma gestiona esa sesión con las mismas garantías de seguridad que cualquier otra sesión autenticada.

Análisis de robustez:

• AAVP delega completamente la gestión de sesiones post-handshake a la plataforma. Esto es una decisión de diseño deliberada (separación de responsabilidades) pero introduce un punto ciego en el modelo de seguridad.
• Si la plataforma almacena el token completo en la sesión (en lugar de solo age_bracket), podría estar creando un identificador persistente inadvertidamente.
• Las sesiones web tienen vulnerabilidades conocidas: session fixation, session hijacking via XSS, CSRF.
• Si falla: Un atacante que comprometa la sesión post-handshake podría suplantar la franja de edad del usuario o, peor, acceder a contenido restringido con la sesión de un adulto.

Estado: Fortalecido. PROTOCOL.md sección 7 define una credencial de sesión autocontenida con descarte obligatorio del token, TTL máximo igual al TTL del token AAVP (recomendado 15-30 minutos), renovación con token criptográficamente independiente y modelo aditivo con persistencia a nivel de cuenta (las restricciones de franja menor persisten aunque el DA desaparezca; solo una credencial OVER_18 las retira). Esto reduce significativamente la superficie de ataque de la gestión de sesiones, aunque las vulnerabilidades de sesión web estándar (session fixation, XSS) siguen siendo responsabilidad de la implementación de cada plataforma.

S6. La auditoría de código abierto previene implementadores maliciosos

Supuesto: El código abierto y la auditoría independiente son suficientes para garantizar que los Implementadores cumplen la especificación.

Análisis de robustez:

• El código abierto es necesario pero no suficiente. La historia de la seguridad informática demuestra que vulnerabilidades críticas pueden persistir en código abierto durante años (Heartbleed en OpenSSL, 2 años sin detección).
• No hay garantía de que el código publicado sea el mismo que se ejecuta en producción. Un IM podría publicar código conforme pero ejecutar una versión modificada.
• Las auditorías independientes son costosas y puntuales. Un IM podría pasar una auditoría y modificar su comportamiento después.
• Si falla: Un IM malicioso podría registrar correlaciones entre peticiones de firma y tokens, comprometiendo la privacidad de todos los usuarios que utilicen su servicio.

S7. PIN parental o protección a nivel de SO impide la desactivación por el menor

Supuesto: El menor no puede desactivar el Device Agent ni modificar la franja de edad configurada por los padres.

Análisis de robustez:

• La efectividad de esta protección depende enteramente del vehículo de implementación del DA. Un componente nativo del SO (como Screen Time en iOS) ofrece mayor resistencia que una aplicación de terceros.
• Técnicas conocidas de evasión: shoulder surfing del PIN, restauración de fábrica del dispositivo, uso de un segundo dispositivo, social engineering para obtener el PIN de los padres.
• En dispositivos Android, la diversidad de fabricantes y versiones de SO dificulta una protección uniforme.
• Si falla: El menor puede configurar la franja como OVER_18 y acceder sin restricciones a todo el contenido. Este es uno de los vectores más probables en la práctica.

1.2 Supuestos implícitos

Estos supuestos son necesarios para que el protocolo funcione correctamente pero no están documentados en PROTOCOL.md.

S8. El dispositivo no está comprometido a nivel de SO (root / jailbreak)

Descripción: AAVP asume que el sistema operativo del dispositivo es íntegro y que los mecanismos de seguridad del SO (sandboxing, permisos, almacenamiento seguro) funcionan correctamente.

Análisis:

• En un dispositivo con root (Android) o jailbreak (iOS), el atacante tiene control total sobre el espacio de usuario y potencialmente sobre el TEE.
• Un dispositivo rooteado puede interceptar las llamadas del DA al almacenamiento seguro, modificar la franja de edad en memoria antes de la generación del token, o inyectar tokens fabricados.
• Según datos de la industria, entre el 2% y el 5% de los dispositivos Android en circulación están rooteados. El porcentaje es menor en iOS pero no despreciable.
• Impacto si falla: Compromisión total del DA en ese dispositivo. El atacante puede generar tokens con cualquier age_bracket.

[!IMPORTANT] La detección de root/jailbreak es un juego del gato y el ratón. Las soluciones existentes (SafetyNet/Play Integrity en Android, DeviceCheck en iOS) requieren verificación remota contra servidores del fabricante del SO, lo que introduce una dependencia centralizada en conflicto con los principios de AAVP.

Estado: Documentado y parcialmente mitigado. PROTOCOL.md sección 1.3 documenta explícitamente este supuesto como limitación reconocida del protocolo. La sección 4.4 define device attestation opcional (key attestation + señales de integridad del dispositivo) como mitigación parcial. Key attestation opera a nivel DA-IM (relación bilateral) sin introducir centralización. Root/jailbreak permanece como limitación inherente: en un dispositivo completamente comprometido, todas las garantías del DA son anulables.

S9. El canal entre DA e IM es confidencial e íntegro

Descripción: La comunicación entre el Device Agent y el Implementador para la firma parcialmente ciega se produce sobre un canal seguro que impide la interceptación o modificación de los mensajes.

Análisis:

• PROTOCOL.md especifica TLS 1.3 para ambos canales (DA-VG y DA-IM), respaldado por Certificate Transparency (RFC 9162).
• Si el canal DA-IM no está protegido, un atacante podría interceptar el token enmascarado (blinded) y, aunque no puede descifrarlo (por la ceguera), podría bloquear la firma, forzando un fallo en la generación del token.
• Un atacante activo podría sustituir la respuesta del IM con una firma inválida, causando un denial of service selectivo.
• Impacto si falla: Denegación de servicio (bloqueo de firma) o, en el peor caso, correlación de metadatos de red entre la petición de firma y el uso posterior del token.
• Estado: Resuelta en PROTOCOL.md v0.5.0. El canal DA-IM requiere TLS 1.3 con verificación de cadena de certificados respaldada por Certificate Transparency (RFC 9162). OHTTP (RFC 9458) se recomienda como medida opcional para ocultar la IP del DA al IM. La fuga de metadatos de red (IP, TLS fingerprint, patrones temporales) se documenta como riesgo residual aceptable para el alcance mínimo del protocolo.

S10. Los relojes del DA y el VG están razonablemente sincronizados

Descripción: El campo expires_at del token depende de una noción compartida del tiempo. Si los relojes del DA y el VG divergen significativamente, la validación se vuelve incoherente. Con la eliminación de issued_at, el VG solo valida expires_at contra su propio reloj.

Análisis:

• Los dispositivos móviles típicamente sincronizan su reloj vía NTP con los servidores del fabricante. Sin embargo, un dispositivo comprometido o sin conectividad puede tener un reloj manipulado.
• Un usuario podría adelantar el reloj del dispositivo para generar tokens con un expires_at en el futuro lejano, extendiendo artificialmente su validez.
• El VG necesita definir una tolerancia (clock skew) aceptable, pero PROTOCOL.md no especifica este valor.
• La precisión gruesa de expires_at (redondeo a la hora) simplifica la validación pero no elimina la necesidad de una tolerancia definida.
• Impacto si falla: Tokens prematuramente rechazados (si el DA está adelantado) o tokens que deberían haber expirado aceptados (si el DA está atrasado o el VG es tolerante en exceso).
• Estado: Resuelta en PROTOCOL.md v0.5.0. Se define una tolerancia asimétrica: 300 segundos para tokens recién expirados (clock skew del DA por detrás) y 60 segundos para tokens del futuro (clock skew del DA por delante). La asimetría se justifica porque las distribuciones de clock skew no son simétricas (RFC 8446) y un token del futuro es más sospechoso que uno recién expirado. El redondeo a la hora de expires_at limita el riesgo de fingerprinting por reloj.

S11. El registro de Implementadores es resistente a manipulación

Estado: Resuelta. PROTOCOL.md define un modelo de auto-publicación: cada IM publica claves en su propio dominio sobre TLS 1.3 + CT. No existe un registro centralizado que comprometer.

Descripción: PROTOCOL.md define un modelo de auto-publicación donde cada Implementador publica sus claves en su propio dominio. No existe un registro centralizado. El supuesto se transforma: ya no se evalúa la integridad de un registro común, sino la integridad del dominio individual del IM.

Análisis:

• El modelo de auto-publicación elimina el registro centralizado como punto único de fallo. Un atacante ya no puede comprometer un solo recurso para afectar a todos los VGs.
• El compromiso de un dominio de IM individual solo afecta a los VGs que confían en ese IM concreto.
• La integridad de las claves publicadas se respalda por TLS 1.3 y Certificate Transparency (RFC 9162).
• Las claves tienen vida limitada (≤ 6 meses), acotando la ventana de exposición ante un compromiso.
• Riesgo residual: Compromiso del dominio de un IM individual. Mitigado por claves de vida corta, CT y revocación bilateral por VGs.

S12. Las plataformas implementan correctamente la política de segmentación

Estado: Mitigada. El Segmentation Accountability Framework (SAF) en PROTOCOL.md sección 8 define mecanismos de declaración, transparencia y verificación de políticas de segmentación. Riesgo residual: la verificación de contenido dinámico (feeds algorítmicos, UGC) no puede ser exhaustiva.

Descripción: AAVP entrega una señal de age_bracket fiable, pero asume que la plataforma la utiliza correctamente para restringir el contenido inapropiado.

Análisis:

• PROTOCOL.md sección 8 define el SAF con cuatro componentes: (1) Segmentation Policy Declaration (SPD) como compromiso público firmado y máquina-legible, (2) Policy Transparency Logs (PTL) para trazabilidad append-only de las políticas, (3) Open Verification Protocol (OVP) para verificación descentralizada del cumplimiento, y (4) señal de cumplimiento en el handshake para que el DA informe al usuario.
• Las plataformas tienen incentivos económicos para maximizar el engagement, lo que puede entrar en conflicto con una segmentación restrictiva. La SPD pública hace observable cualquier relajación de la política.
• Los PTL proporcionan trazabilidad histórica: una plataforma no puede cambiar su política retroactivamente sin que quede registrado.
• El OVP permite a cualquier parte verificar el cumplimiento de una plataforma con su SPD declarada.
• Riesgo residual: La verificación de contenido dinámico (feeds algorítmicos, recomendaciones personalizadas, UGC) no puede ser exhaustiva. Una plataforma puede declarar una política restrictiva y no implementarla completamente. Este riesgo es detectable vía OVP pero no prevenible por el protocolo. La imposición efectiva corresponde a los marcos regulatorios (DSA, AADC, OSA, COPPA).

S13. El menor no tiene acceso a un segundo dispositivo sin DA

Descripción: AAVP protege el acceso desde el dispositivo donde el DA está instalado. Si el menor accede desde otro dispositivo sin DA, el protocolo no puede intervenir.

Análisis:

• En hogares con múltiples dispositivos (tablets, ordenadores, smart TVs, consolas), es probable que no todos tengan un DA configurado.
• Un menor con motivación puede acceder a contenido restringido desde el dispositivo de un amigo, un ordenador público o cualquier dispositivo no controlado.
• PROTOCOL.md reconoce esta limitación (“AAVP protege las puertas, no las ventanas”), pero no la cuantifica.
• Impacto si falla: Evasión trivial del protocolo sin necesidad de ningún ataque técnico.

S14. La revocación de Implementadores se propaga a tiempo

Estado: Resuelta. PROTOCOL.md define claves de vida limitada (≤ 6 meses) como mitigación primaria y revocación bilateral: cada VG gestiona su propio trust store de forma independiente.

Descripción: Cuando un IM es comprometido o detectado como fraudulento, las plataformas deben dejar de aceptar sus tokens. El modelo bilateral de confianza implica que cada VG toma esta decisión de forma independiente.

Análisis:

• Las claves de vida limitada (≤ 6 meses) acotan la ventana de exposición: una clave comprometida deja de ser válida al expirar, sin necesidad de coordinación.
• La revocación bilateral permite que cada VG retire a un IM de su trust store en cualquier momento, sin depender de un mecanismo centralizado de propagación.
• Si un IM detecta un compromiso, retira la clave de su endpoint. Los VGs que refrescan su caché periódicamente (recomendado: cada 24 horas) detectan la retirada.
• No existe un punto único de fallo para la propagación: la velocidad depende de la política de refresco de cada VG individual.
• Riesgo residual: Un VG que no refresque su caché puede aceptar tokens de una clave retirada durante un máximo de 24 horas (si sigue la recomendación) o hasta la expiración natural de la clave.

1.3 Tabla resumen de supuestos

2. Vectores de ataque no documentados

PROTOCOL.md documenta 8 amenazas con sus mitigaciones. Esta sección amplía el modelo de amenazas con vectores adicionales no contemplados.

2.1 Suplantación de age_bracket

Descripción: Un Device Agent comprometido (por root/jailbreak, malware o manipulación del usuario) genera tokens con age_bracket = OVER_18 para un menor.

Precondiciones:

• Control sobre el DA a nivel de software (root, debug mode, modificación del binario).
• O bien: acceso al PIN/contraseña parental para reconfigurar la franja.

Impacto: Crítico. El menor accede sin restricciones a contenido para adultos. La plataforma no tiene forma de distinguir un token legítimo de uno con franja suplantada, ya que la firma parcialmente ciega es válida en ambos casos (el IM firma lo que el DA le solicita si la franja es coherente con la configuración).

Mitigaciones propuestas:

• Atestación remota del dispositivo (device attestation) para verificar la integridad del DA. Conflicto: introduce una dependencia en el fabricante del SO.
• Verificación periódica de la integridad del DA vía hash del binario publicado por el IM. Limitación: no protege contra modificación en memoria.
• Detección de anomalías estadísticas: si un IM observa un cambio repentino en la distribución de franjas solicitadas, podría señalar un problema. Conflicto: requiere que el IM tenga visibilidad sobre las franjas, lo que viola la ceguera de las firmas.

Mitigación parcial (Partially Blind RSA): Con la adopción de firmas parcialmente ciegas, el IM puede verificar la coherencia del age_bracket con la configuración del DA durante el proceso de firma. Esto añade una segunda barrera: el IM rechaza solicitudes de firma cuya franja no coincida con la configuración establecida. Sin embargo, esta mitigación no protege contra un DA comprometido que modifique tanto la franja como la solicitud de firma.

Riesgo residual: Alto (reducido parcialmente). La adopción de Partially Blind RSA mitiga el caso de manipulación en memoria del token post-generación, pero no protege contra un dispositivo rooteado que reemplace completamente el DA. La protección depende en última instancia de la integridad del dispositivo (supuesto S8).

2.2 Colusión entre múltiples Implementadores

Descripción: Varios Implementadores comparten metadatos de sus servicios de firma (timestamps, direcciones IP de origen, patrones de peticiones) para correlacionar usuarios a través de distintos IMs.

Precondiciones:

• Al menos dos IMs con acuerdos de intercambio de datos.
• Usuarios que cambien de IM o utilicen dispositivos con distintos IMs.

Impacto: Alto. Aunque las firmas ciegas impiden que un IM individual vincule un token con un usuario, la correlación de metadatos de red entre múltiples IMs podría reducir significativamente el anonimato.

Mitigaciones propuestas:

• Exigir que el protocolo de firma ciega se realice sobre una capa de anonimización de red (tipo Tor o oblivious HTTP — OHTTP, RFC 9458). Coste: latencia adicional, complejidad de implementación.
• Establecer en la especificación que los IMs no deben retener logs de peticiones de firma más allá de lo estrictamente necesario para la operación. Limitación: no es verificable técnicamente.
• Diseñar el protocolo para que un DA solo necesite contactar con un IM una vez (en la configuración inicial), minimizando las interacciones correlacionables.

Riesgo residual: Medio. La mitigación depende de la honestidad de los IMs y de mecanismos de auditoría externos.

2.3 Timing side-channels

Descripción: Un observador pasivo (plataforma, ISP, entidad de red) correlaciona tokens de un mismo usuario analizando los patrones temporales de emisión, renovación y presentación.

Precondiciones:

• Acceso a los timestamps de presentación de tokens al VG (disponible para la plataforma).
• Múltiples sesiones del mismo usuario observables.

Impacto: Medio. No compromete el contenido del token, pero puede degradar la unlinkability entre sesiones.

Análisis detallado:

• Si el DA rota tokens a intervalos regulares (ej: cada 2 horas exactas), el patrón de rotación es un identificador de hecho.
• Si el DA rota basándose en actividad del usuario (ej: al abrir la app), el patrón de uso se convierte en señal.
• La precisión gruesa de expires_at (redondeo a la hora) agrupa los tokens temporalmente, lo que incrementa el anonymity set y dificulta la correlación.

Mitigaciones propuestas:

• Especificar que la rotación debe producirse en momentos aleatorios dentro de una ventana, no en intervalos fijos.
• La precisión gruesa de expires_at (adoptada en PROTOCOL.md) mitiga la correlación por timestamps.
• Las plataformas (VG) no deben loguear el timestamp exacto de validación de cada token.

Riesgo residual: Bajo con mitigaciones implementadas. Medio sin ellas.

2.4 Compromiso del dominio del Implementador

Reclasificado. Este vector se denominaba anteriormente “Ataque al registro de IMs”. La adopción del modelo de auto-publicación elimina el registro centralizado, transformando el vector en un compromiso de dominio individual.

Descripción: Un atacante compromete el dominio de un Implementador para modificar las claves publicadas, insertando una clave bajo su control. Esto le permitiría firmar tokens que serían aceptados por los VGs que confían en ese IM.

Precondiciones:

• Compromiso de la infraestructura del dominio del IM (certificados TLS, credenciales de hosting, DNS del dominio).
• El VG debe confiar en el IM comprometido y no haber detectado el compromiso.

Impacto: Medio. A diferencia del modelo anterior (registro centralizado), el compromiso solo afecta a los VGs que confían en el IM comprometido, no a todo el ecosistema. El atacante no puede inyectar claves en los dominios de otros IMs.

Mitigaciones (especificadas en PROTOCOL.md):

• Claves de vida limitada (≤ 6 meses): Una clave comprometida expira naturalmente, acotando la ventana de explotación.
• TLS 1.3 + Certificate Transparency (RFC 9162): Los VGs verifican la cadena de certificados y la presencia en logs CT antes de aceptar claves. Un certificado TLS fraudulento sería detectado por los monitores de CT.
• Key pinning por VGs: Cada VG puede mantener un historial de claves conocidas del IM y alertar si cambian inesperadamente.
• Revocación bilateral: Si un VG detecta anomalías en las claves de un IM, puede retirarlo de su trust store unilateralmente, sin depender de coordinación con otros VGs.
• Aislamiento del impacto: El compromiso de un dominio no afecta a otros IMs ni a los VGs que no confían en el IM comprometido.

Riesgo residual: Bajo. El modelo de auto-publicación distribuye el riesgo y elimina el punto único de fallo del registro centralizado.

2.5 Exfiltración de claves del DA

Descripción: Extracción de las claves criptográficas del Device Agent del almacenamiento seguro del dispositivo.

Precondiciones:

• Acceso físico al dispositivo o control remoto con privilegios elevados (root/jailbreak).
• Vulnerabilidad en la implementación del TEE/Secure Enclave del dispositivo específico.

Impacto: Alto. Con las claves del DA, el atacante puede generar tokens arbitrarios desde cualquier otro dispositivo, suplantando al usuario original.

Análisis detallado:

• Los TEE modernos (Apple Secure Enclave, Android StrongBox con certificación strongbox) están diseñados para que las claves privadas nunca abandonen el hardware. Las operaciones criptográficas se realizan dentro del enclave.
• Sin embargo, el DA necesita generar el token, enmascararlo y presentarlo al IM y al VG. Si la generación del token ocurre fuera del enclave (en espacio de usuario), las claves o los tokens en claro son accesibles para un atacante con privilegios suficientes.
• Ataques documentados contra TEE específicos: TrustZone de Qualcomm (CVE-2015-6639, CVE-2016-2431), Checkm8 en procesadores Apple A5-A11.

Mitigaciones propuestas:

• La especificación debe requerir que toda operación criptográfica del DA (generación de nonce, construcción del token, enmascaramiento) se realice dentro del enclave seguro cuando esté disponible.
• Key attestation: el DA puede demostrar que sus claves residen en hardware seguro, lo que permite al IM rechazar peticiones de firma desde dispositivos sin TEE verificable. Conflicto: introduce una barrera de acceso para dispositivos de gama baja.
• Rotación de claves del DA: las claves locales deben rotarse periódicamente (ej: semanalmente), limitando la ventana de utilidad de claves exfiltradas.

Riesgo residual: Medio. La seguridad está limitada por el hardware del dispositivo, que está fuera del control del protocolo.

2.6 Degradación de protocolo

Descripción: Un actor (menor, malware, proxy de red) fuerza un fallback a sesión sin verificación de edad para evadir las restricciones.

Precondiciones:

• La plataforma permite sesiones no verificadas (que es el comportamiento actual de la mayoría de plataformas y la posición por defecto si AAVP no es obligatorio).
• El atacante puede bloquear selectivamente la comunicación del DA con el VG o el IM.

Impacto: Alto. El menor accede sin restricciones simplemente impidiendo que el handshake AAVP se complete.

Análisis detallado:

• Un menor técnicamente sofisticado podría utilizar un firewall local, un proxy o un DNS sinkhole para bloquear las conexiones del DA sin afectar al resto de la navegación.
• En redes con inspección TLS (corporativas, educativas), la verificación de Certificate Transparency puede fallar legítimamente, creando un escenario de degradación no malicioso pero con el mismo efecto.

Mitigaciones propuestas:

• Las plataformas que implementen AAVP deben definir una política para sesiones no verificadas. La recomendación mínima: aplicar las restricciones de la franja más restrictiva (UNDER_13) a sesiones sin token.
• El protocolo debe especificar un mecanismo de señalización inversa: la plataforma informa al usuario de que la verificación de edad no se completó y que el contenido está restringido.
• Fail-closed vs. fail-open: la especificación debe recomendar fail-closed (contenido restringido por defecto) pero reconocer que la decisión final es de cada plataforma.

Riesgo residual: Alto. La mitigación depende enteramente de la política de cada plataforma, que está fuera del control del protocolo.

2.7 Análisis de tráfico

Descripción: Un observador de red (ISP, proxy, entidad estatal) correlaciona sesiones del mismo usuario analizando patrones de tráfico (dirección IP, tamaños de paquete, timing, volumen) sin necesidad de comprometer ningún componente del protocolo.

Precondiciones:

• Posición de red privilegiada (ISP, backbone, red local).
• Capacidad de observar el tráfico entre DA-IM y DA-VG.

Impacto: Medio. El contenido del token permanece protegido (cifrado por TLS), pero la correlación de tráfico puede revelar qué usuarios utilizan AAVP y potencialmente vincular sesiones.

Análisis detallado:

• El tamaño del handshake AAVP es distinto del tráfico HTTP regular. Un observador puede identificar que se está usando AAVP por el patrón de paquetes, incluso sin descifrar el contenido.
• Si el DA contacta al IM inmediatamente antes de presentar el token al VG, la secuencia temporal (petición al IM → petición al VG) es una señal correlacionable.
• La dirección IP del DA es visible tanto para el IM como para el VG (a menos que se use una capa de anonimización).

Mitigaciones (especificadas en PROTOCOL.md sección 4.5):

• Pre-firma con desacoplamiento temporal (sección 4.5.1): el DA obtiene tokens en momentos independientes del acceso a plataformas. Ventana mínima de 5 minutos entre obtención y presentación.
• Padding de mensajes a 2 KiB (sección 4.5.2): el handshake AAVP es indistinguible en tamaño de otros intercambios HTTP estándar.
• Jitter obligatorio (sección 4.5.3): retardo uniforme 0-300s antes de la primera presentación a un nuevo VG.
• OHTTP recomendado (sección 4.5.4): Oblivious HTTP (RFC 9458) para el canal DA-IM, interponiendo un relay que oculte la IP del DA.

Riesgo residual: Bajo. Las mitigaciones están especificadas en PROTOCOL.md sección 4.5. El riesgo residual se limita a adversarios con capacidad de vigilancia masiva (estados, ISPs) que observen simultáneamente tráfico de múltiples nodos de la red.

2.8 Token harvesting

Descripción: Interceptación masiva de tokens para análisis estadístico. Incluso sin poder descifrar tokens individuales, un corpus grande permite identificar patrones.

Precondiciones:

• Acceso a un gran volumen de tokens (ej: operador de una plataforma popular que actúe como VG para millones de usuarios).
• Capacidad de análisis estadístico.

Impacto: Medio. El análisis estadístico de un corpus grande podría revelar distribuciones de age_bracket por hora, zona geográfica (via IP) o plataforma, lo que constituye información de inteligencia sobre la demografía de los usuarios.

Mitigaciones propuestas:

• El token cifrado en tránsito (TLS) impide la interceptación por terceros. El riesgo se limita al propio VG, que legítimamente recibe los tokens.
• Definir en la especificación que el VG debe destruir el token tras extraer age_bracket y no almacenar ni retransmitir el token completo.
• Considerar que el token sea de un solo uso (one-time token) con un mecanismo de invalidación tras la primera validación.

Riesgo residual: Bajo con la política de destrucción del token. Medio si los VGs retienen tokens.

2.9 Manipulación del reloj del dispositivo

Descripción: El usuario manipula el reloj del dispositivo para generar tokens con un expires_at en el futuro lejano, extendiendo artificialmente la validez del token.

Precondiciones:

• Capacidad de modificar la hora del sistema (posible en la mayoría de SO sin privilegios especiales).

Impacto: Medio. Un token con TTL extendido reduce la frecuencia de rotación, degradando la unlinkability. En combinación con otros vectores, podría servir para mantener una identidad persistente.

Mitigaciones propuestas:

• El VG debe validar expires_at contra su propio reloj. Un expires_at demasiado lejano en el futuro debe rechazarse. Se propone rechazar tokens cuyo expires_at exceda el tiempo actual del VG en más del TTL máximo permitido (ej: 4 horas + tolerancia).
• La precisión gruesa de expires_at (redondeo a la hora) limita la granularidad de la manipulación: el atacante solo puede extender el token en incrementos de 1 hora.
• La especificación debe definir estos valores de tolerancia para garantizar un comportamiento uniforme entre VGs.

Riesgo residual: Bajo con validación del VG implementada.

2.10 Social engineering parental

Descripción: El menor manipula psicológicamente a los padres o tutores para obtener el PIN de configuración del DA, la contraseña del sistema de control parental o el consentimiento para modificar la franja de edad.

Precondiciones:

• Relación de confianza con los padres (inherente).
• Capacidad persuasiva del menor (variable pero frecuente).

Impacto: Alto. El menor reconfigura su franja como OVER_18 de forma legítima para el protocolo (la autenticación parental fue exitosa), pero ilegítima en intención.

Análisis detallado:

• Este vector es común en todos los sistemas de control parental. No es específico de AAVP pero afecta directamente a su eficacia.
• Variantes: shoulder surfing, pregunta directa (“¿cuál es el PIN?”), invención de excusas (“necesito cambiarlo para una tarea del colegio”).
• La biometría parental (huella, cara) para la autenticación del DA reduciría este vector pero introduce datos biométricos, en tensión con el minimalismo de datos.

Mitigaciones propuestas:

• La especificación debe recomendar que los cambios de franja de edad requieran una autenticación fuerte del padre/tutor (biometría del SO, no un simple PIN).
• Cooldown tras cambio de franja: un cambio de UNDER_13 a OVER_18 podría requerir un periodo de espera (ej: 24 horas) durante el cual el padre recibe una notificación.
• Notificaciones proactivas: el DA notifica al padre/tutor cada vez que se intenta modificar la franja.

Riesgo residual: Medio. Ninguna solución técnica elimina completamente la ingeniería social dentro de una familia.

2.11 Tabla resumen de vectores de ataque

3. Análisis de esquemas criptográficos

PROTOCOL.md lista esquemas criptográficos candidatos para firmas ciegas y ZKP sin una evaluación comparativa detallada. Esta sección proporciona ese análisis.

3.1 Firmas ciegas

3.1.1 RSA Blind Signatures (RFC 9474)

Descripción: Esquema clásico de firma ciega basado en RSA. Formalizado en RFC 9474 (RSA Blind Signatures), publicado en 2023.

Ventajas:

• Esquema más estudiado y auditado de los tres candidatos.
• RFC 9474 proporciona una especificación formal directamente utilizable.
• Amplia disponibilidad de librerías: blind-rsa-signatures (Rust, sigue RFC 9474), Cloudflare blind-rsa (TypeScript), BoringSSL/ring (RSA-PSS base).
• Rendimiento adecuado para dispositivos móviles.

Desventajas:

• Tamaño de firma relativamente grande (256-512 bytes).
• No soporta agregación de firmas.
• Sin resistencia post-cuántica. Requiere plan de migración a largo plazo.

Evaluación para AAVP: Candidato principal por madurez y disponibilidad. El tamaño de firma es aceptable dado que el token solo se transmite una vez por sesión.

3.1.2 Blind BLS Signatures

Descripción: Firmas BLS (Boneh-Lynn-Shacham) con extensión de ceguera, basadas en pairing-based cryptography sobre curvas elípticas.

Ventajas:

• Firmas extremadamente cortas (48 bytes vs. 256 de RSA).
• Soporta agregación: múltiples firmas pueden combinarse en una sola, útil para futuros escenarios de multi-IM.
• Threshold signatures nativas: la clave de firma puede distribuirse entre N partes, de modo que se necesiten M para firmar.

Desventajas:

• El pairing criptográfico es computacionalmente costoso, especialmente en dispositivos móviles de gama baja.
• Menor disponibilidad de librerías auditadas. Principales: blst (C/assembly + Rust/Go/Python/JS bindings, Supranational, con optimización ARM), noble-bls12-381 (JavaScript, auditada), arkworks (Rust).
• Las curvas de pairing son más complejas de implementar correctamente. Mayor superficie de ataque por errores de implementación.
• Sin RFC publicado todavía (draft en IRTF).

Evaluación para AAVP: Candidato alternativo. Las firmas cortas son atractivas para minimizar el tamaño del token, pero la madurez y el rendimiento en móvil son inferiores a RSA.

3.1.3 Partially Blind Signatures (esquema adoptado)

Descripción: Variante de las firmas ciegas donde parte del mensaje es visible para el firmante (la parte “pública”) mientras el resto permanece oculto. En AAVP, los metadatos públicos son age_bracket y expires_at, y el contenido oculto es el nonce.

Esquema adoptado: RSAPBSSA-SHA384 (RSA Partially Blind Signature Scheme with Appendix), basado en RFC 9474 y draft-irtf-cfrg-partially-blind-rsa.

Ventajas:

• Permite al IM verificar que la franja de edad en el token es legítima sin ver el nonce. Esto mitiga parcialmente el vector de suplantación de age_bracket (sección 2.1).
• El IM puede implementar políticas (ej: solo firmar tokens cuya franja coincida con la configuración del DA) sin comprometer la unlinkability del usuario.
• La derivación de clave por metadato (HKDF) vincula criptográficamente los metadatos a la firma.

Desventajas:

• El IM conoce la franja de edad del token, lo que es una fuga de información respecto a las firmas ciegas puras.
• La combinación de la franja visible con metadatos de red podría permitir correlación (ej: “IP X solicita firma para UNDER_13” → probablemente un menor).

Justificación de la adopción: La fuga de age_bracket al IM es aceptable porque: (1) la franja no es un dato personal, es la señal que el protocolo transmite; (2) el VG también la conoce; (3) el IM no puede vincular un token con un DA concreto dentro de la misma franja; (4) permite al IM actuar como segunda barrera de validación.

[!IMPORTANT] La elección de firmas parcialmente ciegas sobre firmas ciegas puras es una decisión arquitectónica deliberada. La fuga controlada de age_bracket al IM se justifica por la mitigación parcial de V-2.1 (suplantación de franja) y por el hecho de que la franja es la señal mínima del protocolo, no un dato personal.

3.2 Pruebas de conocimiento cero (ZKP)

3.2.1 zk-SNARKs (Groth16 / PLONK)

Descripción: Succinct Non-interactive Arguments of Knowledge. Permiten demostrar una afirmación sin revelar información adicional, con pruebas de tamaño constante y verificación rápida.

Trusted setup: punto de fallo crítico

El trusted setup es el principal riesgo de los zk-SNARKs para AAVP:

• Groth16 requiere un trusted setup específico para cada circuito. Si los parámetros del setup son comprometidos, un atacante puede generar pruebas falsas indistinguibles de las legítimas. El protocolo pierde toda garantía.
• PLONK requiere un setup universal (Structured Reference String) reutilizable para múltiples circuitos. El riesgo es menor pero no nulo.
• Las ceremonias de trusted setup (como la de Zcash “Powers of Tau”) requieren que al menos un participante sea honesto. La coordinación de la ceremonia introduce complejidad logística y un punto de confianza social.

Rendimiento en móvil:

• La generación de pruebas (proving) es la operación más costosa. Para un circuito simple (~10K constraints, demostrar que una fecha pertenece a una franja), Groth16 con rapidsnark (C++/ARM assembly) tarda 100-500 ms en un procesador ARM moderno. Con snarkjs (JavaScript/WASM), 5-15x más lento.
• 100-500 ms es aceptable para la rotación de tokens. Para circuitos más complejos (~1M constraints), el tiempo sube a 2-5 segundos.

Librerías disponibles:

• rapidsnark (C++/ARM assembly): rendimiento optimizado para móvil (Android NDK, iOS).
• snarkjs (JavaScript/WASM): funcional en browser/React Native pero lento.
• circom (DSL): compilador de circuitos, ecosistema maduro.
• arkworks (Rust): framework modular, compilable para móvil vía FFI.
• IMP1 (Ingonyama, C++/CUDA): hasta 3x más rápido que rapidsnark en iOS/Android.

Evaluación para AAVP: Los zk-SNARKs son adecuados para la verificación inicial de edad (ej: demostrar que la fecha de nacimiento de un documento pertenece a una franja) pero no para la generación rutinaria de tokens. El trusted setup es un riesgo aceptable si se usa un esquema universal (PLONK) y se realiza una ceremonia pública verificable.

3.2.2 zk-STARKs

Descripción: Scalable Transparent Arguments of Knowledge. Similar a SNARKs pero sin trusted setup. Seguridad basada en funciones hash, no en criptografía de curvas elípticas.

Ventajas:

• Sin trusted setup: eliminan el principal riesgo de los SNARKs.
• Resistencia post-cuántica: basados en funciones hash (SHA-256, BLAKE2/3), que se consideran resistentes a ataques cuánticos con la duplicación del tamaño de hash.
• Escalabilidad: el tiempo de verificación crece logarítmicamente con el tamaño del circuito.

Desventajas:

• Tamaño de prueba entre 100x y 1000x mayor que SNARKs. Para AAVP, una prueba de 40-200 KB en cada handshake es problemática en conexiones móviles lentas.
• Verificación más lenta que SNARKs (50-100 ms vs. 5-10 ms).
• Menor ecosistema de herramientas y librerías fuera del mundo blockchain.

Librerías disponibles:

• S-two (Rust, StarkWare): optimizado para móvil, Circle STARK protocol.
• winterfell (Rust): framework STARK de propósito general.
• Stone (C++, StarkWare): prover de producción, no optimizado para móvil.
• Miden VM (Rust): VM con proving STARK integrado.

Evaluación para AAVP: Los STARKs son atractivos por la ausencia de trusted setup y la resistencia post-cuántica, pero el tamaño de la prueba los hace inadecuados como mecanismo principal de cada handshake. Podrían usarse para la verificación inicial de edad (evento puntual donde el tamaño es tolerable).

3.2.3 Bulletproofs

Descripción: Sistema de range proofs sin trusted setup, diseñado específicamente para demostrar que un valor se encuentra en un rango determinado — exactamente lo que AAVP necesita para franjas de edad.

Ventajas:

• Diseñados para range proofs: “la edad está entre X e Y” es el caso de uso ideal.
• Tamaño de prueba razonable (672 bytes), mucho menor que STARKs.
• Sin trusted setup.
• Rendimiento de generación aceptable para rotación de tokens (100-500 ms en ARM moderno).

Desventajas:

• Sin resistencia post-cuántica.
• Verificación no constante (crece logarítmicamente con el rango).
• Menores garantías de zero-knowledge en comparación con SNARKs (la prueba es honest-verifier zero-knowledge, no full zero-knowledge sin transformaciones adicionales).

Librerías disponibles:

• dalek-bulletproofs (Rust, dalek-cryptography): implementación de referencia, auditada, usa Ristretto.
• secp256k1-zkp (C): extensión de libsecp256k1, usada en Monero/Mimblewimble.
• Bulletproofs+ (Tari, Rust): versión mejorada con menor tiempo de verificación.

Evaluación para AAVP: Los Bulletproofs son el candidato más natural para ZKP en AAVP si se decide usar ZKP para la verificación de franja. El tamaño de prueba y el rendimiento son compatibles con uso en cada handshake.

3.3 Análisis transversal

3.3.1 Resistencia post-cuántica

[!NOTE] Ninguno de los esquemas de firma ciega candidatos es post-cuántico. Los estándares NIST PQC finalizados (FIPS 203 ML-KEM, FIPS 204 ML-DSA, FIPS 205 SLH-DSA — agosto 2024) cubren cifrado y firmas digitales estándar, pero no incluyen firmas ciegas. La especificación debe incluir un mecanismo de algorithm agility que permita la transición cuando se estandaricen esquemas post-cuánticos de firma ciega.

3.3.2 Rendimiento en hardware móvil

Mediciones estimadas para ARM Cortex-A78 (gama media-alta). Los dispositivos de gama baja (ARM Cortex-A55) pueden ser 2-3x más lentos. Fuentes: rapidsnark, blst, dalek-bulletproofs benchmarks.

3.3.3 Tamaño de firma/prueba y su impacto en el handshake

Todos los esquemas excepto STARKs tienen un impacto en latencia de red despreciable. El overhead de STARKs es significativo en conexiones lentas.

3.4 Recomendación

Esquema adoptado: RSAPBSSA-SHA384 (RSA Partially Blind Signature Scheme with Appendix, basado en RFC 9474 + draft-irtf-cfrg-partially-blind-rsa). Fundamento: máxima madurez del esquema base, RFC publicado, rendimiento adecuado, amplia disponibilidad de librerías. El tamaño de firma (256 bytes) es aceptable. Los metadatos públicos (age_bracket, expires_at) permiten al IM actuar como segunda barrera de validación.

Esquema secundario (opcional, para ZKP de verificación inicial): Bulletproofs para range proofs sobre la fecha de nacimiento. Fundamento: diseñados para este caso de uso, rendimiento compatible con móvil, sin trusted setup.

Plan de migración post-cuántica: El campo token_type (uint16) en el token permite identificar el esquema criptográfico y facilita la migración futura a esquemas basados en retículos (lattice-based blind signatures) cuando estén estandarizados.

4. Vulnerabilidades de la estructura del token

PROTOCOL.md define la estructura del token AAVP con cinco campos, pero la especificación deja aspectos críticos sin definir. Esta sección analiza cada carencia y su impacto en la seguridad.

4.1 Formato de codificación no definido

Estado: Resuelta. PROTOCOL.md define un formato binario fijo de 331 bytes con offsets determinísticos.

Estado anterior: PROTOCOL.md describía los campos del token pero no especificaba cómo se codifican en bytes. Sin un formato de codificación definido, dos implementaciones podían generar representaciones binarias diferentes del mismo token lógico.

Análisis de opciones (histórico):

Resolución: Se adoptó un formato binario ad hoc de tamaño fijo. Justificación:

• AAVP tiene exactamente 6 campos con tamaños conocidos. No necesita la flexibilidad de CBOR o Protobuf.
• Un formato fijo elimina la variabilidad de codificación, lo que es crítico para la prevención de fingerprinting (todos los tokens tienen idéntico tamaño).
• La ausencia de metadatos de codificación (tags, longitudes variables) reduce la superficie de ataque de parsing.
• Un formato simple es más fácil de auditar y de implementar correctamente en todos los lenguajes.

Formato adoptado:

Offset  Tamaño  Campo                Visibilidad
0       2       token_type           Público
2       32      nonce                Cegado (oculto al IM durante emisión)
34      32      token_key_id         Público
66      1       age_bracket          Metadato público (0x00-0x03)
67      8       expires_at           Metadato público (uint64 BE, precisión 1h)
75      256     authenticator        Firma parcialmente ciega (RSAPBSSA-SHA384)
---
Total: 331 bytes (fijo)

4.2 Tamaño fijo no especificado

Estado: Resuelta. PROTOCOL.md especifica 331 bytes exactos como tamaño fijo del token.

Estado anterior: PROTOCOL.md afirmaba que “Todos los tokens tienen idéntico tamaño en bytes” como medida anti-fingerprinting, pero no especificaba el tamaño.

Problema original: Sin un tamaño definido, la promesa era un principio de diseño sin verificabilidad. Diferentes implementaciones podían producir tokens de distinto tamaño, rompiendo la garantía.

Resolución: El tamaño exacto del token es 331 bytes. Todas las implementaciones conformes deben producir tokens de este tamaño exacto. Un token de tamaño diferente es inválido y debe ser rechazado por el VG.

4.3 Versionado del algoritmo

Estado: Resuelta. El campo token_type (2 bytes) identifica el esquema criptográfico del token.

Estado anterior: La estructura del token no incluía un campo de versión del algoritmo criptográfico. No había mecanismo para migrar de un esquema a otro.

Problema original: Cuando AAVP necesitase migrar a un esquema post-cuántico, ¿cómo distinguiría el VG qué algoritmo se usó para firmar un token dado?

Riesgos analizados (histórico):

Resolución: El campo token_type (uint16, 2 bytes) identifica el esquema criptográfico. Reglas:

• El VG solo acepta token_type en su lista blanca (configurable).
• Los esquemas deprecated se rechazan con un periodo de transición definido.
• token_type forma parte del contenido firmado: modificarlo invalida la firma.
• El campo supera el test de minimalismo: es necesario para la migración post-cuántica, su valor es idéntico para todos los tokens del mismo esquema (no permite fingerprinting), y no contiene información del usuario.

4.4 Canonicalización

Estado: Resuelta. El formato binario fijo de 331 bytes con offsets determinísticos implica canonicalización por definición.

Estado anterior: No se definía un orden de campos ni un método de canonicalización.

Problema original: Sin canonicalización, la misma estructura lógica podía codificarse de múltiples formas, y la verificación de firma fallaría si el verificador reconstruía la representación binaria de forma diferente al firmante.

Resolución: El formato binario fijo adoptado en 4.1 resuelve la canonicalización de forma implícita: los campos tienen offsets fijos y no hay ambigüedad de codificación. La representación binaria es la concatenación de los campos en el orden especificado, sin separadores ni padding adicional.

4.5 Precisión del timestamp y jitter

Estado: Resuelta. El campo issued_at ha sido eliminado del token. expires_at utiliza precisión gruesa (redondeo a la hora completa).

Estado anterior: PROTOCOL.md especificaba que issued_at llevaba “ruido aleatorio” (jitter) para evitar correlación por momento de emisión. No se especificaba la distribución ni la magnitud del jitter.

Problemas originales:

• Magnitud del jitter no cuantificada.
• Distribución predecible como señal de fingerprinting.
• Interacción entre issued_at con jitter y expires_at sin él.

Resolución: Se adoptó un enfoque diferente que elimina la complejidad del jitter:

1. issued_at eliminado: La frescura del token se gestiona exclusivamente con expires_at. Un timestamp de emisión con jitter era una superficie innecesaria de fingerprinting.
2. expires_at con precisión gruesa: El valor se redondea a la hora completa más cercana. Todos los tokens emitidos en la misma hora comparten el mismo valor de expiración, lo que incrementa el anonymity set.
3. Validación simplificada: El VG valida expires_at contra su propio reloj. No necesita calcular expires_at - issued_at ni gestionar tolerancias de jitter.

4.6 Espacio del nonce: análisis de birthday attack

Estado actual: El nonce del token AAVP es de 32 bytes (256 bits). PROTOCOL.md lo describe como “valor aleatorio criptográficamente seguro” pero no analiza si el espacio es suficiente.

Análisis:

El birthday paradox establece que la probabilidad de colisión entre N valores aleatorios de B bits es aproximadamente:

P(colisión) ≈ N² / (2 × 2^B)

Para un nonce de 256 bits (B = 256):

Conclusión: 32 bytes (256 bits) es un espacio de nonce más que suficiente. Incluso generando mil millones de tokens por segundo durante la vida útil del universo, la probabilidad de colisión es astronómicamente baja.

Riesgo real: El riesgo no es la colisión del nonce, sino la calidad de la fuente de aleatoriedad. Si un DA usa un PRNG débil o mal inicializado (seeded), el espacio efectivo del nonce puede ser mucho menor que 256 bits. Un PRNG con 32 bits de entropía real produce nonces de 256 bits pero con solo 2^32 valores posibles, haciendo las colisiones probables tras ~2^16 tokens.

Recomendación: La especificación debe requerir que el nonce se genere usando la API de aleatoriedad criptográfica del SO (/dev/urandom, SecRandomCopyBytes, getentropy()). Incluir un test vector que verifique la entropía de los nonces generados (ej: test de Kolmogorov-Smirnov sobre una muestra de 10,000 nonces).

Estado: Resuelta. PROTOCOL.md sección 2 (subsección “Generación del nonce”) especifica las APIs de CSPRNG obligatorias por plataforma (SecRandomCopyBytes, SecureRandom, getrandom(2), BCryptGenRandom, crypto.getRandomValues()), prohíbe fuentes débiles (Math.random(), rand(), derivación de timestamps/IDs) y define tests de conformidad con NIST SP 800-22.

5. Modelo de implementación para plataformas (VG)

PROTOCOL.md describe las responsabilidades del Verification Gate a alto nivel. Esta sección detalla los aspectos prácticos de implementación que una plataforma real necesita resolver.

5.1 Descubrimiento del servicio

Mecanismos propuestos en PROTOCOL.md:

• Endpoint HTTP: .well-known/aavp
• Registro DNS: _aavp

Análisis comparativo:

Ataques específicos a cada mecanismo:

• .well-known/aavp: Un proxy TLS malicioso podría modificar la respuesta para indicar que la plataforma no soporta AAVP, provocando degradación (sección 2.6). Mitigación: servir el endpoint sobre TLS 1.3 con certificados verificables via Certificate Transparency.
• DNS _aavp: El envenenamiento de caché DNS (Kaminsky attack y variantes) podría redirigir al DA a un VG falso. Mitigación: DNSSEC. Limitación: la adopción de DNSSEC es parcial (~30% de dominios a nivel global).

Recomendación: Usar .well-known/aavp como mecanismo primario y DNS como mecanismo de descubrimiento complementario. El DA debe implementar ambos con la siguiente prioridad:

1. Cache local de plataformas conocidas (con TTL configurable).
2. .well-known/aavp sobre HTTPS.
3. DNS _aavp TXT como fallback.

[!NOTE] El formato JSON de .well-known/aavp y .well-known/aavp-issuer está ahora especificado en PROTOCOL.md secciones 5.3 y 5.2.3 respectivamente. Los endpoints utilizan accepted_token_types (referencia al registro de token_type en sección 5.4) en lugar de nombres de algoritmo como identificadores.

5.2 Gestión de sesiones post-handshake

Problema central: AAVP define qué ocurre hasta la validación del token. Lo que ocurre después es responsabilidad de la plataforma, pero las decisiones que tome la plataforma afectan directamente a la eficacia del sistema.

5.2.1 ¿Qué almacena la plataforma tras la validación?

Recomendación: La especificación debe exigir que el VG descarte el token completo tras extraer age_bracket. Almacenar solo la franja de edad en la sesión interna.

5.2.2 Duración de la sesión interna vs. TTL del token

Recomendación: La duración de la sesión interna no debe exceder el TTL del token que la originó. Cuando el DA rota el token, el VG debe revalidar y renovar la sesión interna.

5.2.3 Escenarios de borde

• Usuario borra cookies durante sesión activa: La plataforma pierde la referencia de sesión. En la siguiente interacción, debe solicitar un nuevo handshake AAVP. El DA genera un nuevo token (no correlacionable con el anterior). La experiencia del usuario es transparente.
• Sesión expira sin revalidación: La plataforma debe transicionar a estado “no verificado” y aplicar la política correspondiente (idealmente, restricciones de la franja más conservadora).
• Múltiples pestañas/ventanas: Cada pestaña puede tener su propia sesión. El DA debe poder gestionar múltiples handshakes concurrentes sin reutilizar tokens.

[!NOTE] Resolución parcial. PROTOCOL.md sección 7 define la credencial de sesión autocontenida, el descarte obligatorio del token (sección 7.2), el TTL máximo de la credencial (sección 7.4), la persistencia de restricciones a nivel de cuenta (sección 7.7) y los escenarios de borde (sección 7.8). Las recomendaciones de esta sección de SECURITY-ANALYSIS.md están incorporadas en la especificación. Las vulnerabilidades de sesión web estándar (session fixation, XSS, CSRF) siguen siendo responsabilidad de cada implementación.

5.3 Política de contenido no verificado

El problema: PROTOCOL.md declara que la política para sesiones no verificadas es “decisión exclusiva de cada plataforma”. Esta neutralidad es problemática: sin directrices, las plataformas tomarán el camino de menor resistencia (no restringir nada), anulando el propósito del protocolo.

Propuesta de políticas mínimas recomendadas (lenguaje RFC 2119):

[!IMPORTANT] Esta recomendación no contradice la descentralización de AAVP. No establece una autoridad que imponga políticas, sino directrices que las plataformas adoptan voluntariamente al implementar el estándar. Análogo: HTTP especifica códigos de estado pero cada servidor decide cuándo usarlos.

5.4 Integración con sistemas existentes

5.4.1 Compatibilidad con CDNs

Las plataformas modernas sirven contenido a través de CDNs (Cloudflare, Fastly, Akamai). El handshake AAVP debe ser compatible con esta arquitectura.

Problema: El VG necesita recibir y validar el token en el edge. Si el VG está en el origin server y el CDN cachea la respuesta, el contenido segmentado podría servirse incorrectamente a usuarios con diferente franja.

Recomendación:

• El endpoint del VG (/aavp/verify) debe marcarse como Cache-Control: no-store para evitar cacheo en el CDN.
• Las respuestas de contenido segmentado deben incluir Vary: AAVP-Age-Bracket (o equivalente) para que el CDN distinga las variantes.
• El VG puede implementarse como un middleware en el edge (Cloudflare Workers, Fastly Compute) para evitar la latencia del round-trip al origen.

5.4.2 Impacto en latencia

Estimación del impacto del handshake AAVP en la latencia de carga de la plataforma:

Para la primera sesión, el handshake añade 200-900 ms. En conexiones lentas (3G), puede superar 1 segundo. Para rotaciones, el descubrimiento se omite (cacheado), reduciendo el overhead a 150-700 ms.

Optimización: Pre-firmar tokens. El DA puede solicitar la firma ciega al IM en momentos de inactividad (background) y almacenar tokens pre-firmados para uso inmediato cuando se necesiten. Esto reduce el handshake a la presentación al VG (~50-200 ms).

5.4.3 Compatibilidad con SPAs, apps nativas y PWAs

6. Protocolo de auditoría de implementaciones

[!NOTE] Esta sección contiene el análisis de seguridad preliminar que motivó la formalización del marco de conformidad. Los requisitos normativos se encuentran en PROTOCOL.md sección 9. Las checklists y tests descritos a continuación han sido incorporados como requisitos numerados (DA-01 a DA-12, VG-01 a VG-14, IM-01 a IM-11) en la especificación.

Para que AAVP sea creíble, las implementaciones de sus tres roles (DA, VG, IM) deben ser verificables. Esta sección define el análisis que fundamenta el framework de auditoría formalizado en PROTOCOL.md sección 9.

6.1 Auditoría de Implementadores (IM)

El Implementador es el actor con mayor poder potencial para comprometer la privacidad (es quien firma los tokens). Su auditoría es prioritaria.

Checklist de conformidad

Verificación de ceguera (IM-1)

Test de caja negra para verificar que las firmas son realmente ciegas:

1. Generar N pares (token, token_enmascarado) con diferentes valores de enmascaramiento.
2. Enviar los tokens enmascarados al IM para firma, en orden aleatorio.
3. Desenmascarar las firmas.
4. Verificar que el IM no puede emparejar las peticiones de firma con los tokens resultantes con probabilidad mejor que el azar.

Verificación de no-retención de logs (IM-2)

• Auditoría del código de logging del servicio de firma.
• Verificación de que las peticiones de firma no se escriben en base de datos, ficheros de log ni sistemas de telemetría.
• Test forense: tras una ronda de firmas, verificar que no quedan trazas en disco, memoria o swap.
• Recomendación: el servicio de firma debe ejecutarse en un entorno efímero (contenedor sin volúmenes persistentes) y la memoria debe limpiarse (zeroing) tras cada operación.

6.2 Auditoría del Device Agent (DA)

Verificación de ausencia de metadatos ocultos

El token debe contener exactamente los 6 campos especificados. Test:

1. Generar 10,000 tokens con el DA bajo prueba.
2. Verificar que todos tienen exactamente el tamaño especificado (331 bytes).
3. Verificar que no existen patrones estadísticos en los bytes que sugieran metadatos ocultos (steganography): test de chi-cuadrado sobre los bytes del nonce y la firma.

Verificación de unlinkability

Test de que dos tokens consecutivos del mismo DA no son correlacionables:

1. Generar N pares de tokens consecutivos del mismo DA.
2. Generar N pares de tokens de DAs diferentes.
3. Un clasificador estadístico no debe poder distinguir los pares “mismo DA” de los pares “diferente DA” con probabilidad mejor que 0.5 + epsilon (con epsilon < 0.01).

Test vectors

La especificación debe incluir un conjunto de test vectors para validar implementaciones del DA:

6.3 Auditoría del Verification Gate (VG)

Verificación de extracción mínima

El VG solo debe extraer age_bracket del token. Test:

1. Presentar tokens válidos con diferentes nonces, timestamps y firmas pero la misma franja.
2. Verificar que la sesión resultante es idéntica en todos los casos (misma política de contenido).
3. Verificar que el VG no almacena el token completo: inspeccionar la base de datos de sesiones y verificar que solo contiene age_bracket.

Verificación de rechazo correcto

Resistencia a timing attacks

El VG debe verificar los tokens en tiempo constante para evitar que un atacante infiera información sobre el contenido del token midiendo el tiempo de respuesta.

Test:

1. Medir el tiempo de verificación de 10,000 tokens válidos y 10,000 tokens inválidos (con diferentes tipos de invalidez).
2. La diferencia de tiempo medio entre tokens válidos e inválidos no debe exceder el 5%.
3. No debe existir correlación entre el valor de age_bracket y el tiempo de verificación.

7. Verificación de la segmentación de contenido

AAVP entrega una señal de edad fiable. Pero la eficacia del sistema depende de que las plataformas utilicen esa señal para segmentar efectivamente el contenido. PROTOCOL.md sección 8 define el Segmentation Accountability Framework (SAF) como respuesta formalizada a esta brecha. Esta sección analiza el problema, la solución adoptada y el riesgo residual.

7.1 El problema de la “última milla”

AAVP controla las fases A y B con garantías criptográficas. La fase C-D está fuera de su control directo. La señal de edad puede ser:

• Ignorada: La plataforma recibe age_bracket pero no modifica su contenido.
• Mal aplicada: La plataforma bloquea contenido inocuo o permite contenido inapropiado.
• Aplicada selectivamente: La plataforma segmenta ciertas secciones pero no otras (ej: bloquea contenido explícito en búsqueda pero no en feeds algorítmicos).

Este es un problema estructural, no técnico. AAVP no puede forzar la segmentación correcta, pero puede proporcionar infraestructura de accountability (detección), análoga a Certificate Transparency para certificados TLS.

7.2 Solución adoptada: Segmentation Accountability Framework (SAF)

PROTOCOL.md sección 8 define el SAF con cuatro componentes:

El framework define además tres niveles de conformidad (Básico, Intermedio, Avanzado) verificables por cualquier parte sin autoridad central de certificación.

7.3 Análisis de la mitigación

Fortalezas del SAF:

• La SPD firmada convierte la política de segmentación en un compromiso público verificable, no una declaración de intenciones.
• Los PTL proporcionan trazabilidad histórica: una plataforma no puede relajar su política retroactivamente sin que quede registrado.
• El OVP descentralizado permite a cualquier organización o individuo auditar el cumplimiento.
• La señal de cumplimiento en el handshake permite al DA informar al usuario sobre la transparencia de la plataforma.
• Los tres niveles de conformidad son verificables sin autoridad central, coherente con el principio de descentralización.
• El OVP define una metodología de muestreo estratificado con requisitos estadísticos (intervalos de confianza, tamaños de muestra), coherente con las prácticas establecidas en la industria (YouTube VVR, ISO 2859).
• La SPD puede declarar opcionalmente el enfoque de moderación de UGC (ugc_handling), siguiendo el patrón de ESRB “Interactive Elements”.

Debilidades residuales:

• El SAF mide declaraciones y su cumplimiento observable, pero no puede forzar la implementación correcta. La imposición efectiva corresponde a los marcos regulatorios.
• El muestreo estadístico del OVP cubre contenido curado, algorítmico y UGC con métricas diferenciadas, pero el riesgo residual es inherente a la personalización (el contenido algorítmico depende del historial de cada usuario).

7.4 Riesgo residual documentado

Contenido dinámico

Los feeds algorítmicos y los sistemas de recomendación generan contenido personalizado difícil de auditar. La metodología de muestreo del OVP (PROTOCOL.md sección 8.4.4) aborda este riesgo con muestreo estratificado del contenido algorítmico, requiriendo múltiples perfiles, momentos y contextos de observación. El riesgo residual es verificable con muestreo estadístico, pero inherente a la personalización: el contenido mostrado depende del historial de interacciones del usuario, que no existe para un verificador OVP.

Contenido generado por usuarios

La clasificación exhaustiva de UGC en tiempo real es inviable. El OVP mide el cumplimiento de UGC como tiempo de actuación ante contenido no conforme, coherente con el campo ugc_handling.response_target de la SPD (PROTOCOL.md sección 8.2.2). Los sistemas de moderación (ML, filtros de contenido) tienen tasas de error inherentes que el OVP documenta estadísticamente. AAVP proporciona la señal de edad y la infraestructura de accountability; la imposición efectiva corresponde a los marcos regulatorios.

Equilibrio entre segmentación y censura

• Una segmentación excesivamente agresiva puede privar a los menores de contenido educativo, informativo o de salud.
• La segmentación no debe ser un mecanismo de censura sino de adaptación: el contenido se adapta, no se elimina.
• La taxonomía mínima del SAF (6 categorías) no pretende ser exhaustiva; es extensible con prefijo x- para legislaciones locales.

8. Escenarios de ataque compuestos

Los vectores individuales de la sección 2 pueden combinarse para crear ataques más sofisticados. Esta sección analiza cuatro escenarios compuestos.

8.1 Escenario A: IM comprometido + plataforma cómplice

Narrativa: Un Implementador y una plataforma acuerdan cooperar para rastrear menores. El IM registra metadatos de las peticiones de firma (IP, hora, tamaño). La plataforma registra metadatos de la presentación del token (IP, hora, age_bracket). Ambos correlacionan los datos por timestamp e IP.

Probabilidad: Baja. Requiere colusión activa entre dos entidades independientes.

Impacto: Crítico. El IM y la plataforma pueden construir un perfil de “IP → franja de edad” que compromete la privacidad del menor.

Mitigaciones existentes:

• Las firmas ciegas impiden al IM conocer el contenido del token firmado. Pero no impiden la correlación de metadatos de red.

Mitigaciones propuestas:

• Desacoplar temporalmente la firma del uso: pre-firmar tokens y usarlos horas después, rompiendo la correlación temporal.
• Capa de anonimización de red (OHTTP) para el canal DA-IM, de modo que el IM no vea la IP real.
• Auditorías cruzadas: verificar que IMs y plataformas no comparten datos.

Riesgo residual: Medio. La mitigación completa requiere anonimización de red, que añade latencia y complejidad.

8.2 Escenario B: Dispositivo rooteado + replay de tokens

Narrativa: Un menor rootea su dispositivo Android. Con privilegios de root, extrae las claves del DA del TEE emulado (que ya no ofrece protección real). Genera tokens con age_bracket = OVER_18. Utiliza esos tokens para acceder a contenido para adultos.

Probabilidad: Media. El rooteo de dispositivos Android es accesible para adolescentes con conocimientos técnicos moderados.

Impacto: Crítico para ese usuario. El menor elude completamente las restricciones de AAVP.

Mitigaciones existentes:

• El almacenamiento seguro (Secure Enclave/StrongBox) resiste la extracción de claves. Pero en un dispositivo rooteado, un TEE emulado no ofrece esta garantía.

Mitigaciones (especificadas en PROTOCOL.md sección 4.4):

• Key attestation (sección 4.4.2): el IM verifica que las claves del DA residen en hardware seguro real (no emulado). Un TEE emulado en un dispositivo rooteado no produce una cadena de attestation válida.
• Señales de integridad del dispositivo (sección 4.4.3): el DA puede detectar root/jailbreak localmente y negarse a operar. Autocomprobación que no se transmite a terceros.
• Rotación semanal de claves del DA (sección 4.4.4): fuerza re-attestation periódica, limitando la ventana de explotación.
• Key attestation opera a nivel DA-IM (relación bilateral), resolviendo la tensión con la descentralización.

Riesgo residual: Medio-Alto. La key attestation detecta TEE emulados, pero un dispositivo completamente comprometido puede evadir detecciones de root/jailbreak. Limitación reconocida del protocolo (PROTOCOL.md sección 1.3, S8).

8.3 Escenario C: Compromiso de dominio de IM + phishing parental

Narrativa: Un atacante compromete el dominio de un Implementador legítimo y sustituye sus claves por claves bajo su control. Simultáneamente, distribuye una aplicación de “control parental” falsa que actúa como DA pero configura age_bracket = OVER_18 para todos los usuarios. Los padres instalan la app creyéndola legítima. El atacante firma los tokens con la clave fraudulenta publicada en el dominio comprometido. Los VGs que confían en ese IM y refrescan su caché aceptan los tokens.

Probabilidad: Baja. Requiere comprometer el dominio de un IM Y distribuir malware de forma convincente. El modelo de auto-publicación limita el impacto al IM comprometido.

Impacto: Medio. Solo afecta a familias que usan la app falsa Y plataformas que confían en el IM comprometido. No tiene impacto a escala como el registro centralizado anterior.

Mitigaciones (especificadas en PROTOCOL.md):

• Claves de vida limitada (≤ 6 meses): la clave fraudulenta expira naturalmente.
• TLS 1.3 + Certificate Transparency: un certificado TLS fraudulento para el dominio del IM sería detectado por monitores de CT.
• Key pinning por VGs: cambios inesperados de clave generan alertas.
• App signing y verificación: los DA distribuidos en tiendas de apps (App Store, Google Play) están sujetos a revisión del fabricante.
• Revocación bilateral: los VGs que detecten anomalías retiran al IM de su trust store.

Riesgo residual: Bajo. El aislamiento del impacto y las claves de vida corta limitan significativamente el alcance del ataque.

8.4 Escenario D: Análisis de tráfico + correlación temporal

Narrativa: Un adversario con capacidad de vigilancia de red (ISP, entidad estatal) observa el tráfico entre el DA y el IM, y entre el DA y el VG. Sin necesidad de comprometer ningún componente, correlaciona ambos flujos por IP de origen y timing para determinar qué usuarios utilizan AAVP, qué plataformas visitan y, por inferencia estadística, su franja de edad probable.

Probabilidad: Media-Alta para adversarios con capacidad de vigilancia masiva (estados, ISPs).

Impacto: Medio. No compromete el token ni la criptografía, pero degrada significativamente la privacidad del usuario frente a observadores de red.

Análisis detallado:

• La secuencia “petición al IM → petición al VG” en un intervalo corto (~100-500 ms) es una señal fuerte de uso de AAVP.
• La dirección IP del usuario es visible en ambas conexiones (a menos que se use VPN/Tor/OHTTP).
• Un adversario que observe el tráfico del IM y del VG puede correlacionar sesiones con alta probabilidad.

Mitigaciones (especificadas en PROTOCOL.md sección 4.5):

• Pre-firma con desacoplamiento temporal (sección 4.5.1): el DA obtiene tokens en momentos independientes del acceso a plataformas. Ventana mínima de 5 minutos entre obtención y presentación.
• Padding de mensajes a 2 KiB (sección 4.5.2): el handshake AAVP es indistinguible del tráfico HTTP regular en tamaño.
• Jitter obligatorio (sección 4.5.3): retardo uniforme 0-300s antes de la primera presentación a un nuevo VG.
• OHTTP recomendado (sección 4.5.4): Oblivious HTTP (RFC 9458) para el canal DA-IM, interponiendo un relay que oculte la IP del DA.

Riesgo residual: Bajo. Las mitigaciones están formalizadas en PROTOCOL.md sección 4.5. El riesgo residual se limita a adversarios con capacidad de vigilancia masiva que observen simultáneamente tráfico de múltiples nodos de la red.

8.5 Tabla resumen de escenarios compuestos

9. Recomendaciones y trabajo pendiente

9.1 Cambios necesarios en PROTOCOL.md (corto plazo)

Estas son especificaciones que faltan en PROTOCOL.md y que deben definirse antes de avanzar hacia el Internet-Draft.

9.2 Especificaciones adicionales para el Internet-Draft (medio plazo)

9.3 Líneas de investigación abiertas (largo plazo)

9.4 Tabla resumen de severidad

Clasificación de las vulnerabilidades identificadas por severidad, inspirada en CVSS v4.0 pero adaptada al contexto de un protocolo (no software).