Criptografia pós-quântica no Spring Boot: quatro padrões que o dev Java já pode usar

Um artigo publicado na InfoQ por Pankaj Sharma e revisado por Michael Redlich detalha quatro padrões concretos para aplicar criptografia pós-quântica (PQC) em aplicações Spring Boot. O ponto central é que boa parte disso já é possível hoje, sem esperar TLS pós-quântico chegar ao provedor de nuvem, e que times em setores regulados (bancos, fintechs, seguradoras) têm motivos para começar agora.

O que já está disponível no JDK

Segundo o artigo, se sua aplicação já roda em JDK 24, dá para usar o Module-Lattice-Based Key-Encapsulation Mechanism (ML↳Machine learning39 conteúdosClassificador de Sentimentos – Azure MLData · abr 2019Inteligência Artificial e Machine Learning: O que você precisa saberAI · fev 2024Inteligência Artificial: seminário online da USP debate o futuro do aprendizado de máquinaGestão Dev & TI · jun 2021Ver tudo em AI →-KEM) e o Module-Lattice-Based Digital Signature Algorithm (ML-DSA) pela própria API do Java Cryptography Extension (JCE), sem biblioteca externa. Esses algoritmos entraram no provedor SunJCE via JEP 496 e JEP 497, correspondendo aos padrões FIPS 203 e FIPS 204 que o NIST finalizou em agosto de 2024.

O código nativo é direto:

// JDK 24+, sem Bouncy Castle
KeyPairGenerator kpg = KeyPairGenerator.getInstance("ML-KEM-768");
KeyPair kyberPair = kpg.generateKeyPair();

Signature signer = Signature.getInstance("ML-DSA-65");
signer.initSign(dilithiumPrivateKey);
signer.update(message);
byte[] sig = signer.sign();

Para quem ainda está em JDK 11 ou 17, o artigo aponta o Bouncy Castle (bcprov-jdk18on) como caminho compatível, com mais flexibilidade de parâmetros. A recomendação é: se o banco já planeja subir para o JDK 24, vale ir pela via nativa, que tem zero dependências e é para onde as ferramentas Java alinhadas ao NIST estão convergindo.

A ameaça: colher agora, decifrar depois

O artigo é enfático em separar o risco real do hype. RSA e ECDSA se apoiam na dificuldade de fatorar números grandes e resolver logaritmos discretos em computadores clássicos. O algoritmo de Shor rodando em um computador quântico resolve os dois em tempo polinomial. IBM, Google e laboratórios nacionais já têm processadores quânticos, mas nenhum na escala necessária para quebrar RSA-2048. A maioria dos especialistas coloca esse cruzamento entre 2030 e 2035.

O que não pode esperar é o ataque Harvest Now, Decrypt Later (HNDL): adversários interceptam e armazenam tráfego TLS cifrado hoje, junto com a troca de chaves RSA, para decifrar depois. Um CPF, dado de KYC ou registro de transação capturado agora continuará útil em 2035.

O segundo problema sem volta são documentos assinados de vida longa. Um contrato de empréstimo assinado hoje com RSA terá assinatura falsificável por volta de 2035, e bancos arquivam esses documentos por sete a trinta anos, dependendo da jurisdição. Não dá para reassinar retroativamente contratos arquivados.

Os quatro padrões

O texto usa como cenário uma plataforma de microsserviços bancária em Spring Boot, com um Transaction Service enviando instruções de pagamento a um Core Banking Service, dados PII e KYC em PostgreSQL↳PostgreSQL11 conteúdosPostgreSQL via SSL com GolangData · abr 20195 itens legais sobre data types do PostgreSQLData · mar 20195 serviços gratuitos na cloud para bancos de dados PostgresData · fev 2025Ver tudo em Data →, contratos arquivados no S3 e tokens OAuth2 em pipelines regulatórios. Os padrões usam uma biblioteca chamada PqcStarterLib, que expõe três beans autoconfiguráveis (PqcEncryptionService, PqcSignatureService e PqcKeyPairGenerator).

1. Criptografia de payload entre serviços. Cifrar o corpo HTTP com Kyber + AES-256-GCM antes de enviar, independente do TLS. Como o TLS é frequentemente terminado em gateways e service meshes (deixando o salto interno em claro), essa camada dupla protege mesmo se o TLS for removido. O artigo alerta: chaves públicas Kyber-768 têm cerca de 1.184 bytes (ok no corpo, não em headers) e assinaturas Dilithium-3 chegam a 3.300 bytes, o que pesa em claims JWT ou envelopes ISO 20022.

2. Criptografia de campo para PII e KYC. Cifrar cada campo sensível (CPF, identificação fiscal, data de nascimento) antes da persistência com Jakarta Persistence, guardando um blob base64 na coluna e marcando o valor em claro como @Transient.

3. Assinatura de documentos de vida longa. Assinar contratos e trilhas de auditoria com Dilithium na criação. Uma assinatura feita hoje continua criptograficamente válida em 2045, e o mesmo padrão vale para assinar artefatos de CI/CD↳CI/CD23 conteúdosCI/CD Mobile: o caos invisível que separa times comuns de times de alta performanceDev (Back & Front) · abr 2026Lambda: implementando com GitLab CI/CD e Terraform para Integração SFTP, S3 e Databricks em GoDev (Back & Front) · nov 2023Publicando sua aplicação Web Python no WebApp do Azure e configurando o CI/CD da sua aplicaçãoDevSecOps · abr 2019Ver tudo em DevSecOps →, com o gate de deploy verificando a assinatura antes de qualquer kubectl apply.

4. Assinatura de tokens OAuth2 para service accounts. Tokens de sessão de cliente que expiram em quinze minutos são baixo risco; já tokens de service account de Core Banking, detecção de fraude e conectores SWIFT vivem meses ou anos, e por isso são alvo prioritário de HNDL.

O ponto que trava tudo: gestão de chaves

O artigo é honesto sobre o que não vai direto para produção. Cifrar um campo com uma chave Kyber é a parte fácil. O difícil é garantir que a chave privada não viva no heap da JVM. No exemplo de campo, masterKeyPair.getPrivate() é uma chave Kyber na memória, e isso cria três problemas que reprovam em qualquer auditoria: um restart sem key store persistente torna todos os registros cifrados ilegíveis para sempre; um heap dump expõe a chave mestra de todos os CPFs do banco; e não há rotação de chaves, exigida por GLBA, PCI-DSS e SOC 2.

A correção, segundo o texto, é rotear todas as operações de chave por AWS KMS ou HashiCorp Vault, de modo que a aplicação nunca segure a chave privada bruta e cada decrypt seja uma chamada logada e auditável. Isso é uma frente de engenharia separada da criptografia em si e precisa estar pronta antes de qualquer campo cifrado chegar perto de produção. Sem isso, o que existe é uma prova de conceito, não um sistema implantável.

O que muda para quem constrói software no Brasil

A recomendação prática do artigo se traduz bem ao contexto local. A LGPD trata dados como CPF e informações de KYC como pessoais e sensíveis, com as mesmas consequências de exposição que o texto cita para GDPR, CCPA e GLBA. Times de bancos, fintechs, meios de pagamento e o ecossistema Pix lidam justamente com dados de vida longa e mensagens de liquidação, exatamente o perfil que o texto classifica como alvo de HNDL.

O conselho central é priorizar a migração pelos dados que vivem mais tempo, não pela camada de autorização que parece mais familiar: contratos e registros de KYC assinados com RSA hoje terão assinaturas falsificáveis por volta de 2035, sem chance de correção posterior. Para o dev Java brasileiro que já planejava subir de versão de JDK, a mensagem é que o próprio upgrade para JDK 24 destrava a jornada de PQC, já que ML-KEM e ML-DSA passam a estar na biblioteca padrão.

Fica em aberto o ecossistema em torno disso: o TLS pós-quântico ainda está sendo distribuído entre provedores de nuvem, a integração de KMS/Vault com operações de chave Kyber é trabalho de engenharia adicional, e o PqcStarterLib citado é uma biblioteca de exemplo do artigo, não um padrão oficial. Para produção, o caminho nativo do JDK combinado a um serviço de gestão de chaves é a fundação mais sólida indicada pelo texto.

Fonte: InfoQ