Autenticación FIDO2 y Zero Trust con Criptografía Post-Cuántica

1.1.1 Funcionamiento interno

• Base matemática: problema Module Learning With Errors (M-LWE) sobre Z_q[X]/(X²⁵⁶+1), con q = 3329 y n = 256.
• NTT: multiplicación polinómica en el dominio de la transformada de números teóricos, O(n·log n).
• Transformada de Fujisaki–Okamoto: convierte un PKE determinista en un KEM resistente a CCA. La versión final emplea explicit rejection con el hash J(z‖c).
• Fallos de descapsulación: probabilidad < 2⁻¹³⁹; sin fallo explícito para entradas bien formadas.
• Almacenamiento por semilla: las claves pueden conservarse como semillas de 32/64 bytes (d, z).
• Las propiedades de uso de KEM se recogen en SP 800-227 [1].

1.1.2 Parámetros y tamaños

Parámetros: k = 2/3/4, η₁ = 2–3, η₂ = 2, d_u = 10–11, d_v = 4–5. Referencia comparativa: una clave pública ECDH P-256 ocupa 65 bytes, de modo que ML-KEM-768 resulta ~18× mayor; su coste computacional, en cambio, es comparable o inferior al de X25519.

1.2.1 Los tres algoritmos

1. ML-DSA.KeyGen() — genera (pk, sk) a partir de la semilla ξ (32 B); la matriz  se expande con SHAKE-128.
2. ML-DSA.Sign(sk, M, ctx, rnd) — firma σ. Rejillas y compresión (hint) para reducir tamaño; aleatoriedad externa opcional rnd (32 B) o modo determinista; contexto ctx ≤ 255 bytes para separación de dominios.
3. ML-DSA.Verify(pk, M, σ, ctx) — verificación booleana de la ecuación Az − c·t̂ ≈ w₁·2ᵈ comprimida.

HashML-DSA: variante pre-hash con dominio separado, prevista para módulos que ya calculan el hash del mensaje (HSM/TPM) con mensajes de gran tamaño.

Las claves admiten representación por semilla ξ; el precálculo de  acelera firma y verificación.

1.2.2 Parámetros y tamaños

Comparativa: una firma ECDSA P-256 (ES256) ocupa ≈64 B y su clave pública 65 B; la firma ML-DSA-65 es, por tanto, ~52× mayor. Este sobrecoste es el principal obstáculo de integración en FIDO2 (tamaños CBOR, almacenamiento de credenciales, latencia).

2.1 Arquitectura del protocolo

+-----------+  WebAuthn JS (HTTPS)  +---------+  CTAP2 (CBOR)  +---------------+
|  Relying  | --------------------->| Cliente | -------------->| Autenticador  |
|  Party RP | <---------------------| (naveg.)| <--------------| (plataf./roam)|
+-----------+  attestation/assertion +---------+  USB·NFC·BLE   +---------------+

• WebAuthn define la API: navigator.credentials.create() (registro) y .get() (acceso). El nivel 3 es ya Recomendación W3C (2026) y el nivel 4 está en elaboración [8].
• CTAP2 es el protocolo binario navegador↔llave, serializado en CBOR (RFC 8949): comandos authenticatorMakeCredential y authenticatorGetAssertion.
• El RP ID (dominio efectivo) vincula la credencial al origen: el autenticador firma siempre el hash del RP ID, lo que confiere inmunidad frente a phishing.

2.2 Las dos ceremonias

1. Registro (attestation). El RP emite un challenge; el autenticador genera el par de claves del credencial y devuelve {fmt, authData, attStmt}. El RP verifica firma, origin, challenge y, opcionalmente, la cadena de atestación (FIDO MDS, AAGUID) [9].
2. Autenticación (assertion). El autenticador firma authData ‖ SHA-256(clientDataJSON) con la clave privada del credencial. El RP comprueba el contador (anti-clonación), los indicadores UP/UV, el origen y el challenge de un solo uso.

clientDataJSON: {type, challenge, origin, crossOrigin}. authData: rpIdHash (32 B) ‖ flags (UP 0x01, UV 0x04, AT 0x40, ED 0x80) ‖ contador (4 B) ‖ [AAGUID 16 B ‖ L 2 B ‖ credId ‖ COSE_Key].

2.4 Impacto PQC en FIDO2

• Tamaño: claves públicas de 1 312–2 592 B y firmas de 2 420–4 627 B frente a los ~64–256 B clásicos; los mensajes CBOR crecen, así como la memoria flash requerida en el token.
• Ausencia de hardware nativo: no existen aún SE/TPM/TEE con soporte ML-DSA (2026); los borradores exigen cifrar las credenciales con AES-256-GCM y almacenar claves en almacenamiento seguro [13].
• Transporte CTAP: los mensajes CTAP2 de >1 KB requieren fragmentación; la hibridación clásico+PQC se propone como vía de transición.
• Hoja de ruta de la FIDO Alliance [14]: transición «seamless», seguimiento activo de NIST/ISO y alineación de los grupos de trabajo (WebAuthn L4 y CTAP 2.3+ incorporarán PQC).

2.5 Precedentes experimentales (estado del arte)

• sandbox-quantum/pqc-fido2-impl, con Nitrokey y SoloKeys (framework Trussed): FIDO2 extremo a extremo con Dilithium3 y Kyber768 mediante PQClean y liboqs [16].
• The Qey [17]: llave ARM con ML-DSA-44/65 vía OQS sobre CTAP-HID, con medición de rendimiento frente a ES256; emplea los identificadores −48/−49.
• Hoja de ruta PQC de Chromium [18]: cuatro etapas hacia una PKI post-cuántica (certificados Merkle Tree, claves TLS ML-DSA); contexto de transición del ecosistema.
• Nitrokey 3 [19]: firmware Rust (Trussed) actualizable; plataforma candidata para la fase extendida del TFG.

3.1 Los siete principios aplicados al proyecto

1. Verificación continua: ninguna petición confía por su ubicación; todo el tráfico interno exige mTLS con identidad criptográfica del servicio.
2. Privilegio mínimo: cada microservicio solo puede invocar los endpoints que necesita (política declarativa, estilo OPA).
3. Microsegmentación: la red Docker se divide por planos (edge, dominio, datos) con rutas explícitas únicamente.
4. Consciencia de recursos: el motor de políticas decide con identidad y estado (contador de firmas, revocación).
5. Autenticación y autorización explícitas por sesión: sesiones cortas en Redis con TTL.
6. Recolección continua de información: métricas, registros estructurados y trazas (OpenTelemetry).
7. Dinamismo: política evaluable en caliente; punto de aplicación (PEP) en la pasarela.

3.2 Componentes ZTA (SP 800-207)

• PE — Policy Engine: decide el acceso; en el proyecto, módulo de autorización de la pasarela con reglas declarativas.
• PA — Policy Administrator: establece y revoca sesiones; emite tokens de servicio.
• PEP — Policy Enforcement Point: aplica las decisiones (proxy de entrada + middleware mTLS).
• Fuentes de datos: registro de credenciales FIDO2 (PostgreSQL) y estado de sesión (Redis).

MVP: mTLS clásico interno con certificados de servicio de vida corta y CA propia. Fase extendida: hibridación X25519MLKEM768 en los mismos túneles.

3.3 Flujo de una aserción ML-DSA (MVP)

1. GET /login/begin → session-svc crea challenge (Redis, TTL 60 s)
2. Emulador: navigator.credentials.get({challenge, rpId})
   → CTAP2 getAssertion: firma ML-DSA-65 de
     authData ‖ SHA256(clientDataJSON)
3. POST /login/finish → api-gateway (PEP, mTLS)
4. rp-fido2: valida origin, rpIdHash, flags (UP/UV), contador
5. crypto-svc: ML-DSA.Verify(pk_COSE(−49), M, σ) vía CIRCL
6. Si es correcto → sesión emitida (PA) · métricas → OTLP

3.4 Diseño experimental de la evaluación

Metodología: go test -bench junto a carga HTTP con k6/vegeta; tres ejecuciones por configuración, proceso repetible en CI. Los resultados conformarán el capítulo de evaluación de la memoria.