Classificação do documento: Especificação técnica pública
Âmbito: Arquitetura criptográfica da camada de transporte
Política de revisão: Atualizado com a evolução dos padrões criptográficos
Documento formal de segurança
Arquitetura de transporte segmentado
pós-quântico
Visão geral da arquitetura
Fig. 1 — Enclave de transporte pós-quântico segmentado. Compatibilidade clássica na borda; aplicação estrita apenas PQ dentro do limite.
1.Terminologia e linguagem normativa
As palavras-chave MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT e MAY neste documento devem ser interpretadas conforme RFC 2119.
Secções normativas
Requisitos arquiteturais vinculativos
Secções informativas
Fundamentação de desenho e comentários operacionais
2.Classificação arquitetural
3.Requisitos normativos
3.1Protocolo de transporte
3.1.1Borda pública
- ▸MUST suportar apenas TLS 1.3
- ▸MUST NOT suportar TLS 1.2 ou anterior
- ▸MUST NOT ativar suites de cifra legacy
- ▸MAY suportar mecanismos clássicos de troca de chaves por compatibilidade
Fundamentação: limitações do ecossistema atual de navegadores impedem endpoints externos apenas PQ.
3.1.2Segmento interno pós-quântico
- ▸MUST operar exclusivamente em TLS 1.3
- ▸MUST impor ML-KEM (mlkem768) como único grupo de troca de chaves permitido
- ▸MUST NOT permitir X25519, P-256 ou qualquer grupo clássico
- ▸MUST exigir verificação de assinatura baseada em ML-DSA
- ▸MUST terminar o handshake em desajuste de grupo
- ▸MUST terminar o handshake em desajuste de assinatura
- ▸MUST terminar o handshake em tentativa de downgrade de protocolo
3.2Resistência ao downgrade
Dentro do enclave PQ:
- ▸Fallback clássico de troca de chaves MUST NOT existir
- ▸Negociação de suite de cifra MUST NOT incluir alternativas clássicas
- ▸Negociação de versão de protocolo MUST rejeitar qualquer versão que não TLS 1.3
- ▸Falha de handshake MUST ser registada e tratada como evento de segurança
3.3Limite criptográfico
O limite criptográfico SHALL é definido entre Edge (nginx) e PQ Gate. Todo o transporte através deste limite MUST cumprir a política de aplicação apenas PQ.
4.Modelo de ameaças (formalizado)
Capacidades
- •Interceção passiva
- •Arquivamento de tráfego
- •Tentativa futura de descriptografia quântica
Objetivo de mitigação
O transporte interno MUST ser protegido com ML-KEM para segredo em avanço resistente a quânticos.
Capacidades
- •Interferência na negociação TLS
- •Manipulação de cifra
- •Substituição de grupo
Objetivo de mitigação
Tentativas de downgrade MUST resultar em terminação do handshake.
Capacidades
- •Sniffing passivo
- •Acesso parcial à rede
Objetivo de mitigação
Todo o tráfego inter-componentes através do limite MUST permanecer cifrado sob transporte apenas PQ.
5.Secção informativa — Fundamentação de desenho
5.1Por que segmentação em vez de PQ completo
Em 2026, os navegadores mainstream não suportam ML-KEM e componentes do ecossistema (bases de dados, caches, camadas de malha de serviços) carecem de TLS nativo PQ. Um endpoint externo totalmente PQ resultaria em perda total de compatibilidade.
Aplicação operacional PQ
Compatibilidade com versões anteriores
Avaliação real de desempenho
Transição criptográfica controlada
6.Métricas de desempenho (observadas)
Valores representam comportamento medido na implementação atual; atualizados periodicamente.
6.1Sobrecarga de handshake
~8–15%
Aumento de latência vs X25519
~2–4×
Aumento do tamanho do certificado (ML-DSA vs ECDSA)
Nenhuma observada
Degradação do serviço sob carga
6.2Impacto na throughput
- ▸Desempenho de transferência em massa não afetado (AES-GCM simétrico inalterado)
- ▸Sobrecarga isolada à fase de handshake
- ▸Sobrecarga do transporte PQ é antecipada e amortizada em conexões persistentes
6.3Características de falha
- ▸Rejeição explícita do handshake em tentativa de grupo clássico
- ▸Falha explícita em desajuste de algoritmo de assinatura
- ▸Nenhum fallback silencioso observado
7.Anexo de configuração criptográfica
7.1Configuração do segmento PQ interno
Ativado
Desativado
7.2Resumo da configuração da borda
Ativado
Desativado
8.Estratégia de migração (formalizada)
Fase 1ATUAL
Borda pública híbrida + enclave PQ interno estrito
Estado operacional atual.
Fase 2
Suporte externo híbrido
Quando os navegadores implementarem KEM híbrido:
A borda externa SHOULD ativar KEM híbrido.
A aplicação PQ interna SHALL permanecer estrita.
Fase 3
Endpoint opcional apenas PQ
Quando o ecossistema de navegadores estabilizar:
Endpoint externo apenas PQ MAY pode ser introduzido.
Endpoint de compatibilidade MAY pode permanecer temporariamente.
Fase 4
Adoção PQ estendida
Quando suportado pelo ecossistema:
Transporte PQ serviço a serviço.
Conexões a bases de dados com capacidade PQ.
Malha de serviços consciente de PQ.
9.Princípios de governança de segurança
Sem alegações exageradas de imunidade quântica
Sem mecanismos de fallback silenciosos
Sem exceções híbridas não documentadas
Política explícita de downgrade
Definição explícita do limite de confiança
Aplicação criptográfica mensurável
10.Declaração de posicionamento arquitetural
Este sistema não alega exposição internet pós-quântica completa.
Opera um enclave de transporte pós-quântico aplicado em produção e resistente ao downgrade dentro de um ecossistema externo limitado por compatibilidade.
A arquitetura reflete estratégia deliberada de transição criptográfica, não alinhamento de marketing.
Histórico de versões
Descarregar
Mesmo conteúdo desta página, em formato PDF.
O PDF está disponível apenas em inglês.