Clasificación del documento: Especificación técnica pública
Alcance: Arquitectura criptográfica de la capa de transporte
Política de revisión: Actualizado con la evolución de estándares criptográficos
Documento formal de seguridad
Arquitectura de transporte segmentado
post-cuántico
Visión general de la arquitectura
Fig. 1 — Enclave de transporte post-cuántico segmentado. Compatibilidad clásica en el borde; aplicación estricta solo PQ dentro del límite.
1.Terminología y lenguaje normativo
Las palabras clave MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT y MAY en este documento se interpretan como se describe en RFC 2119.
Secciones normativas
Requisitos arquitectónicos vinculantes
Secciones informativas
Fundamento de diseño y comentarios operativos
2.Clasificación arquitectónica
3.Requisitos normativos
3.1Protocolo de transporte
3.1.1Borde público
- ▸MUST admitir solo TLS 1.3
- ▸MUST NOT admitir TLS 1.2 o anterior
- ▸MUST NOT habilitar suites de cifrado legacy
- ▸MAY admitir mecanismos clásicos de intercambio de claves por compatibilidad
Fundamento: las limitaciones del ecosistema actual de navegadores impiden endpoints externos solo PQ.
3.1.2Segmento interno post-cuántico
- ▸MUST operar exclusivamente con TLS 1.3
- ▸MUST imponer ML-KEM (mlkem768) como único grupo de intercambio de claves permitido
- ▸MUST NOT permitir X25519, P-256 ni ningún grupo clásico
- ▸MUST requerir verificación de firma basada en ML-DSA
- ▸MUST terminar el handshake ante desajuste de grupo
- ▸MUST terminar el handshake ante desajuste de firma
- ▸MUST terminar el handshake ante intento de downgrade de protocolo
3.2Resistencia al downgrade
Dentro del enclave PQ:
- ▸MUST NOT existir fallback clásico de intercambio de claves
- ▸La negociación de suite de cifrado MUST NOT incluir alternativas clásicas
- ▸La negociación de versión de protocolo MUST rechazar cualquier versión distinta de TLS 1.3
- ▸El fallo de handshake MUST registrarse y tratarse como evento de seguridad
3.3Límite criptográfico
El límite criptográfico SHALL se define entre Edge (nginx) y PQ Gate. Todo el transporte a través de este límite MUST cumplir la política de aplicación solo PQ.
4.Modelo de amenazas (formalizado)
Capacidades
- •Interceptación pasiva
- •Archivo de tráfico
- •Intento futuro de descifrado cuántico
Objetivo de mitigación
El transporte interno MUST protegerse con ML-KEM para garantizar secreto hacia adelante resistente a cuánticos.
Capacidades
- •Interferencia en negociación TLS
- •Manipulación de cifrado
- •Sustitución de grupo
Objetivo de mitigación
Los intentos de downgrade MUST dar lugar a la terminación del handshake.
Capacidades
- •Sniffing pasivo
- •Acceso parcial a la red
Objetivo de mitigación
Todo el tráfico entre componentes a través del límite MUST permanecer cifrado bajo transporte solo PQ.
5.Sección informativa — Fundamento de diseño
5.1Por qué segmentación en lugar de PQ completo
En 2026, los navegadores mayoritarios no admiten ML-KEM y componentes del ecosistema (bases de datos, cachés, capas de malla de servicios) carecen de TLS nativo PQ. Un endpoint externo totalmente PQ supondría una pérdida total de compatibilidad.
Aplicación operativa PQ
Compatibilidad con versiones anteriores
Evaluación real del rendimiento
Transición criptográfica controlada
6.Métricas de rendimiento (observadas)
Los valores representan el comportamiento medido en el despliegue actual; se actualizan periódicamente.
6.1Sobrecarga de handshake
~8–15%
Incremento de latencia frente a X25519
~2–4×
Incremento de tamaño de certificado (ML-DSA vs ECDSA)
Ninguna observada
Degradación del servicio bajo carga
6.2Impacto en el rendimiento
- ▸Rendimiento de transferencia masiva no afectado (AES-GCM simétrico sin cambios)
- ▸Sobrecarga aislada a la fase de handshake
- ▸La sobrecarga del transporte PQ es por adelantado y se amortiza en conexiones persistentes
6.3Características de fallo
- ▸Rechazo explícito del handshake ante intento de grupo clásico
- ▸Fallo explícito ante desajuste de algoritmo de firma
- ▸No se observa fallback silencioso
7.Anexo de configuración criptográfica
7.1Configuración del segmento PQ interno
Habilitado
Deshabilitado
7.2Resumen de configuración del borde
Habilitado
Deshabilitado
8.Estrategia de migración (formalizada)
Fase 1ACTUAL
Borde público híbrido + enclave PQ interno estricto
Estado operativo actual.
Fase 2
Soporte externo híbrido
Cuando los navegadores implementen KEM híbrido:
El borde externo SHOULD habilitar KEM híbrido.
La aplicación PQ interna SHALL permanecer estricta.
Fase 3
Endpoint opcional solo PQ
Cuando el ecosistema de navegadores se estabilice:
MAY introducirse un endpoint externo solo PQ.
El endpoint de compatibilidad MAY permanecer temporalmente.
Fase 4
Adopción PQ extendida
Cuando lo admita el ecosistema:
Transporte PQ servicio a servicio.
Conexiones a bases de datos con capacidad PQ.
Malla de servicios consciente de PQ.
9.Principios de gobernanza de seguridad
Sin afirmaciones exageradas de inmunidad cuántica
Sin mecanismos de fallback silenciosos
Sin excepciones híbridas no documentadas
Política explícita de downgrade
Definición explícita del límite de confianza
Aplicación criptográfica medible
10.Declaración de posicionamiento arquitectónico
Este sistema no afirma exposición internet post-cuántica completa.
Opera un enclave de transporte post-cuántico aplicado en producción y resistente al downgrade dentro de un ecosistema externo limitado por compatibilidad.
La arquitectura refleja una estrategia deliberada de transición criptográfica, no alineación de marketing.
Historial de versiones
Descargar
Mismo contenido que esta página, en formato PDF.
El PDF está disponible solo en inglés.