O risco quântico que já exige ação hoje
Computadores quânticos suficientemente poderosos ainda não existem, mas a ameaça que eles representam para a criptografia convencional já é real — e precisa ser endereçada agora. O motivo é um vetor de ataque chamado coleta agora, decifra depois (HNDL — Harvest Now, Decrypt Later): adversários capturam tráfego cifrado hoje e guardam para decifrar no futuro, quando tiverem acesso a hardware quântico capaz de quebrar os algoritmos assimétricos tradicionais.
É dentro desse contexto que a AWS vem executando seu plano de migração para criptografia pós-quântica (PQC). Parte central desse plano é garantir que os clientes consigam atualizar o lado cliente de suas cargas de trabalho para suportar confidencialidade resistente a computadores quânticos — e a AWS reconhece que essa é uma responsabilidade compartilhada, descrita no modelo de responsabilidade compartilhada de PQC.
O que mudou no AWS Secrets Manager
O AWS Secrets Manager utiliza SSL/TLS para comunicação com recursos AWS, suportando TLS 1.2 e 1.3 em todas as regiões. A novidade é que o serviço agora habilita e prefere, por padrão, a troca de chaves híbrida pós-quântica nas conexões TLS iniciadas pelos clientes que suportam essa capacidade.
A abordagem híbrida pós-quântica combina criptografia tradicional (como X25519) com algoritmos pós-quânticos (ML-KEM) para estabelecer conexões TLS. Isso garante proteção tanto contra ataques clássicos atuais quanto contra ameaças futuras de computadores quânticos.
Vale destacar: os segredos em repouso já estavam protegidos por chaves gerenciadas pelo AWS Key Management Service (AWS KMS). A criptografia simétrica, quando bem implementada, é considerada resistente a computadores quânticos. A vulnerabilidade quântica recai sobre a criptografia assimétrica — exatamente o que é usado na troca de chaves TLS. Para aprofundar o tema, a AWS disponibilizou a sessão AWS re:Inforce 2025 – Post-Quantum Cryptography Demystified.
Quais clientes já suportam a troca de chaves híbrida por padrão
A AWS anunciou que os seguintes clientes do Secrets Manager já habilitam e preferem a troca de chaves pós-quântica ao iniciar conexões:
- Secrets Manager Agent (v2.0.0 ou superior)
- AWS Lambda extension (versão 19 ou superior)
- Secrets Manager CSI Driver (v2.0.0 ou superior)
Para clientes baseados em SDK, a troca de chaves híbrida pós-quântica está disponível nas versões listadas abaixo. Os requisitos variam por linguagem, versão e sistema operacional:
- AWS SDK for Rust: habilitado por padrão em versões lançadas após 29 de agosto de 2025
- AWS SDK for Go: habilitado por padrão no Go v1.24 ou superior
- AWS SDK for Node.js: habilitado por padrão no Node.js v22.20 e v24.9.0 ou superior
- AWS SDK for Kotlin: habilitado por padrão no Linux (v1.5.78 ou superior)
- AWS SDK for Python: depende do OpenSSL fornecido pelo sistema operacional — exige OpenSSL 3.5 ou superior instalado
- AWS SDK for Java v2: requer o cliente HTTP AWS CRT com a flag
postQuantumTlsEnabledconfigurada comotrue
As bibliotecas de cache do Secrets Manager são construídas sobre os SDKs e herdam o comportamento de TLS deles. Para Java, tanto a flag do driver JDBC quanto a flag de cache Java precisam ser habilitadas para ativar a troca de chaves híbrida.
Quando o endpoint do serviço Secrets Manager detecta que o cliente anuncia suporte à troca de chaves pós-quântica durante o handshake TLS, ele a seleciona automaticamente. Atualizar para as versões listadas é a única ação necessária.
Como verificar se suas conexões estão usando a troca de chaves híbrida
Para a maioria dos clientes, não será necessário monitoramento contínuo após a atualização. No entanto, equipes de segurança e compliance podem querer confirmar que as chamadas de API do Secrets Manager estão de fato negociando a troca de chaves híbrida. A verificação pode ser feita tanto no lado servidor, via AWS CloudTrail, quanto no lado cliente, com ferramentas como Wireshark ou as ferramentas de desenvolvedor dos navegadores.
Fonte
Protecting your secrets from tomorrow’s quantum risks (https://aws.amazon.com/blogs/security/protecting-your-secrets-from-tomorrows-quantum-risks/)
Leave a Reply