Infraestrutura de pagamentos pós-quântica: por que bancos podem substituir em vez de adaptar trilhos legados
As primitivas criptográficas que autenticam hoje cada pagamento de atacado em produção — RSA, ECDSA, ECDH — têm data de validade. O Quantum Computing Cybersecurity Preparedness Act ⧉ dos EUA inscreveu essa validade na lei federal de aquisições no final de 2022. O BIS Working Paper No. 1208 ⧉ levou a mesma validade ao enquadramento supervisório dos bancos centrais. O NIST FIPS 203 ⧉ e o FIPS 204 ⧉ publicaram as substituições em agosto de 2024.
A infraestrutura de pagamentos ainda não absorveu o que isso significa.
Este artigo é o argumento de engenharia para substituição em vez de adaptação. Foi escrito para arquitetos que já dominam os algoritmos e precisam decidir o que fazer com SWIFT MT, mensagens ISO 20022 pacs e pain, interfaces RTGS, parques de HSM e as hierarquias de certificados que sustentam tudo isso.
Sumário executivo / Pontos-chave
- Colher-agora-decifrar-depois (HNDL) é a ameaça operacional. Adversários gravam tráfego de pagamentos cifrado em 2026 para decifrá-lo quando existir um computador quântico criptanaliticamente relevante (CRQC). O tráfego capturado inclui instruções de liquidação, dados de beneficiários e material de autenticação com sensibilidade de longo prazo.
- O NIST padronizou as substituições. ML-KEM (FIPS 203) para encapsulamento de chave e ML-DSA (FIPS 204) para assinaturas digitais são os padrões. SLH-DSA (FIPS 205) cobre o fallback sem estado baseado em hash.
- O delta de tamanho quebra as premissas legadas. Chaves públicas e assinaturas são 5–20× maiores que os equivalentes RSA-2048. Isso colide com a MTU em redes de pagamento, com premissas de buffer fixo nos handlers de mensagens MT e com o throughput criptográfico da frota instalada de HSMs.
- O híbrido (clássico + PQC) é o veículo de migração, não o destino. TLS híbrido e X.509 híbrido compram dois a três anos de interoperabilidade enquanto os trilhos de produção são substituídos. Não resolvem o problema de capacidade subjacente.
- A PKI é a parede estrutural. Uma autoridade certificadora cujo algoritmo de assinatura se torna falsificável invalida cada certificado abaixo dela. A exposição institucional do banco está na cadeia, não em um único endpoint.
- Cripto-agilidade é a propriedade arquitetural a projetar. Identificadores de algoritmo, formatos de chave, envelopes de assinatura e partições de HSM precisam ser todos parametrizáveis. Qualquer coisa fixada em RSA em tempo de compilação é dívida técnica que vencerá simultaneamente.
Colher agora, decifrar depois: o modelo de ameaça que retira a opção de esperar #
O HNDL inverte a linha do tempo criptográfica habitual. A avaliação convencional de risco pergunta quando a ameaça se materializa. O HNDL pergunta quando os dados capturados hoje se tornam úteis ao adversário. Para mensagens de pagamento — identidades de beneficiários, números de conta, dados estruturados de remessa, cargas de triagem de sanções, instruções de liquidação intrabancárias — a janela de sensibilidade é de anos a décadas. Boa parte desse tráfego já está gravada em algum lugar agora.
O cronograma CNSA 2.0 da NSA ⧉ dá aos sistemas de segurança nacional até 2035 para completar a transição. Os supervisores financeiros andam mais rápido — as expectativas da PRA sobre resiliência operacional ⧉ tratam a agilidade criptográfica como risco de concentração de terceiros. A expectativa em 2026 é que os trilhos de pagamento materiais publiquem seu plano de migração PQC na autoatestação de resiliência.
O adversário HNDL não precisa de um CRQC hoje. O adversário precisa de:
- Posição na rede. Grampos em cabos submarinos, captura no nível de ISP e middleboxes comprometidos estão todos no escopo. O tráfego de pagamentos de atacado concentra-se em um número pequeno de caminhos de rede.
- Armazenamento. Um petabyte de dados estruturados de pagamento é um arquivo gerenciável em 2026.
- Paciência. A captura nada custa por mensagem interceptada. O retorno chega depois.
O argumento de migração, portanto, não é "computadores quânticos podem chegar em 2035". É "qualquer sessão TLS que se encerre hoje à noite com troca de chaves RSA-2048 fica exposta enquanto os dados em seu interior permanecerem sensíveis".
O problema de tamanho é o problema de engenharia #
O debate público sobre migração PQC costuma se concentrar na seleção de algoritmo. O problema mais difícil é dimensional.
| Primitiva | Chave pública | Assinatura / cifragem |
|---|---|---|
| RSA-2048 | 256 bytes | 256 bytes (assinatura) |
| ECDSA P-256 | 64 bytes | 64 bytes (assinatura) |
| ML-KEM-768 | 1.184 bytes | 1.088 bytes (cifragem) |
| ML-DSA-65 | 1.952 bytes | 3.309 bytes (assinatura) |
| SLH-DSA-128f | 32 bytes | 17.088 bytes (assinatura) |
Esses números mapeiam diretamente em modos de falha para os quais a infraestrutura de pagamentos legada nunca foi projetada:
- Fragmentação de pacotes no caminho. Um ClientHello que carrega ML-KEM-768 híbrido somado a X25519 clássico ultrapassa a MTU Ethernet típica de 1.500 bytes. Middleboxes entre dois endpoints de pagamento fragmentam, descartam ou reescrevem o handshake. A falha aparece como erros TLS intermitentes que se confundem com ruído de rede transitório.
- Premissas de buffer em handlers MT. Muitas integrações SWIFT MT carregam envelopes assinados dimensionados para ECDSA. Insira uma assinatura ML-DSA no mesmo envelope e o parser ou trunca ou rejeita.
- Throughput do HSM. A assinatura ML-DSA em uma frota instalada de HSMs é 3–10× mais lenta que ECDSA por operação, em hardware cujo orçamento de chaves por segundo já roda quente nas janelas de batch de fim de dia.
- Peso da cadeia de certificados. Uma hierarquia de CA de quatro níveis reemitida com assinaturas ML-DSA cresce de cerca de 6 KB para cerca de 60 KB. Cada handshake TLS ao trilho paga esse preço.
A trajetória de adaptação trata essas restrições uma a uma — buffers maiores aqui, HSMs mais rápidos ali, tolerância à fragmentação nos middleboxes. É uma ponte defensável de seis meses. Não é uma arquitetura.
Adaptação versus substituição: a decisão que define o programa #
O enquadramento honesto: a adaptação é um plano de migração controlado com vida útil curta, e a substituição é o único destino estável. A decisão é qual delas o banco financia primeiro, e por quanto tempo a janela de adaptação fica aberta antes de virar gambiarra permanente.
Adaptação significa:
- TLS híbrido (ML-KEM + X25519) terminado na fronteira atual do trilho.
- Certificados duplamente assinados (RSA primário, ML-DSA secundário) emitidos por uma CA subordinada capaz de PQC.
- Buffers MT maiores e política de MTU mais estrita nas VPNs de pagamento.
- Atualizações de firmware do HSM onde os fornecedores suportam primitivas PQC; substituição completa do HSM onde não suportam.
Esse trabalho é factível. Não resolve o problema subjacente: SWIFT MT e muitas implementações ISO 20022 codificam o envelope criptográfico dentro de um formato de mensagem que fixa o algoritmo. A próxima transição de algoritmo — e haverá uma, quando o ML-KEM mostrar fraqueza ou um novo padrão o substituir — refaz a mesma migração sobre os mesmos trilhos.
Substituição significa aceitar que a camada criptográfica não é propriedade do formato da mensagem. É propriedade de um serviço de envelope separável que o formato da mensagem invoca. Em termos concretos:
- A fronteira de segurança de transporte se desloca para um service mesh ou sidecar que termina o TLS híbrido e apresenta a mensagem em claro ao trilho por uma interface estável.
- As assinaturas em nível de mensagem são produzidas por um serviço de assinatura dedicado, cuja escolha de algoritmo é um parâmetro de configuração, não premissa codificada.
- Os certificados são emitidos por uma CA cujo próprio algoritmo de assinatura é rotacionável.
- As partições de HSM são endereçadas por propósito (transporte, assinatura, encapsulamento de chave) em vez de por formato de mensagem.
O desenho de substituição sobrevive à próxima troca de algoritmo sem retocar o trilho.
A arquitetura cripto-ágil, camada por camada #
As camadas de infraestrutura que importam para a migração PQC não são as camadas de negócio de "dados, controle, economia" que servem a uma narrativa bancária genérica. As camadas que importam são criptográficas.
| Camada | O que faz | A pergunta PQC | Diretriz arquitetural |
|---|---|---|---|
| HSM / gestão de chaves | Gera, armazena e opera material de chave sob isolamento de hardware | O firmware do HSM instalado suporta ML-KEM, ML-DSA e uma API de encapsulamento de chave híbrido? Qual é o delta de throughput de assinatura versus ECDSA no mesmo hardware? | Inventarie cada partição de HSM por suporte a algoritmo e capacidade por segundo. Descomissione qualquer coisa fixada em RSA sem caminho de firmware. Provisione partições PQC dedicadas antes do cutover de produção. |
| PKI / autoridade certificadora | Emite, revoga e encadeia confiança via certificados X.509 | A CA consegue assinar com ML-DSA hoje? Existe um processo testado para rotacionar a raiz e reemitir a cadeia? Os respondedores CRL e OCSP estão dimensionados para o peso de assinatura ML-DSA? | Trate a stack de CA como parede estrutural. Estabeleça uma subordinada capaz de PQC agora. Programe a rotação de raiz pela dependência de certificado de vida mais longa, não pela conveniência. |
| Transporte / rede | Termina TLS, IPsec e MACsec entre endpoints de pagamento | O load balancer, o WAF e o caminho de middlebox toleram handshakes híbridos que excedem a MTU legada? Os tickets de retomada de sessão estão dimensionados para chaves PQC? | Mova a terminação TLS para uma fronteira cripto-ágil (sidecar ou mesh). Eleve a política de MTU nas VPNs de pagamento. Teste o caminho completo com fragmentação induzida deliberadamente. |
| Aplicação / carga de mensagem | Carrega mensagens SWIFT MT, ISO 20022 pacs / pain / camt e seus envelopes criptográficos | O handler de mensagens do trilho tolera envelopes assinados do tamanho de ML-DSA? Os parsers intermediários conhecem o algoritmo ou truncam por comprimento? | Separe envelope de carga. Assine numa fronteira de serviço, não dentro do handler de formato de mensagem. Trate identificadores de algoritmo como dado, não como esquema. |
| Auditoria / evidência | Produz a cadeia criptográfica de custódia da qual supervisores e clientes dependem | Os registros assinados históricos seguem verificáveis quando o algoritmo de assinatura for depreciado? Existe um plano de assinatura de arquivamento de longo prazo? | Contra-assine os arquivos com uma primitiva baseada em hash (SLH-DSA) para uma garantia que sobrevive a qualquer quebra de algoritmo isolada. Trate a cadeia de auditoria como artefato regulado, não como subproduto de build. |
A disciplina é tornar toda escolha de algoritmo um valor de configuração em cada camada. A instituição que fixa RSA-2048 em qualquer dessas camadas herda um evento coordenado de fim de vida quando aquele algoritmo cair.
O que isso significa por tipo de banco #
O perfil de exposição varia por instituição. As diretrizes variam na mesma medida.
Bancos globais #
Bancos globais operam as maiores frotas de HSM instaladas, as cadeias de certificados mais longas e os caminhos de rede mais complexos entre contrapartes. O risco dominante não é a seleção de algoritmo — é o custo de coordenação para mudar de algoritmos em centenas de serviços internos e dezenas de contrapartes externas simultaneamente.
A diretriz é financiar a CA capaz de PQC, a fronteira de transporte cripto-ágil e o serviço de assinatura parametrizado por algoritmo como trabalho de 2026, antes de qualquer trilho ser adaptado. A adaptação vira então mudança rotineira de produção dentro de um arcabouço conhecido. Sem o arcabouço, cada adaptação de trilho relitiga as mesmas decisões arquiteturais.
Bancos regionais #
Bancos regionais têm menor superfície algorítmica, mas proporcionalmente menos pessoal especialista. O risco dominante é o aprisionamento ao fornecedor de HSM em algoritmos que o fornecedor não se comprometeu a suportar.
A diretriz é escrever o suporte a PQC — especificamente ML-KEM e ML-DSA, com um caminho testado de atualização de firmware — em cada renovação de contrato de HSM a partir de 2026. Bancos sem essa cláusula herdam substituição forçada de hardware no calendário do fornecedor, não no próprio.
Fintechs e PSPs #
Provedores de serviços de pagamento e fintechs costumam ficar entre uma contraparte bancária e um sistema de comerciante ou usuário final. A exposição criptográfica deles é a fronteira de API dos dois lados.
A diretriz é publicar uma interface TLS híbrida — clássica somada a ML-KEM — no lado voltado para o banco como condição mínima nas conversas comerciais de 2026. A fintech que chega com interoperabilidade PQC já demonstrada vence ciclos de integração contra a fintech que ainda não começou.
Tesoureiros corporativos #
Tesoureiros não operam infraestrutura criptográfica diretamente. Eles a consomem — cada API bancária, cada transferência segura de arquivo, cada confirmação assinada depende da PKI do banco.
A diretriz é adicionar três perguntas a cada RFP bancário em 2026: quais algoritmos PQC o banco usa hoje no TLS voltado ao cliente, qual o plano do banco para confirmações de pagamento assinadas com ML-DSA, e como o banco pretende preservar a verificabilidade dos registros assinados históricos quando o RSA for depreciado. Bancos que não conseguem responder essas perguntas estão sinalizando algo sobre o próprio preparo de engenharia.
O que acontece a seguir #
A primeira onda de implantação de PQC em pagamentos será invisível para o usuário final. TLS híbrido aparece no handshake, cadeias de certificados crescem, a latência de assinatura do HSM sobe alguns milissegundos e os trilhos continuam operando. Esse é o caminho de sucesso.
As falhas visíveis serão guiadas por adaptação: um trilho que não aceita um envelope assinado por ML-DSA sem truncar, uma CA cujo ponto de distribuição de CRL engasga com o novo peso de assinatura, um middlebox que fragmenta handshakes híbridos em ClientHellos reordenados. Essas falhas vão aterrissar em produção ao longo de 2027.
A decisão arquitetural em 2026 é financiar a infraestrutura de substituição que torna a adaptação irrelevante, ou financiar uma sequência de correções específicas por trilho que individualmente parecem mais baratas e agregam uma migração mais longa e mais cara. O banco que escolhe o primeiro caminho roda operações mais quietas durante a transição. O banco que escolhe o segundo passa o resto da década explicando relatórios de incidente aos supervisores.
PQC não é um problema de criptografia disfarçado de problema de infraestrutura. É um problema de infraestrutura que a criptografia simplesmente iniciou.
Perguntas frequentes #
Existe um prazo que obriga esse trabalho?
Os prazos regulatórios rígidos são jurisdicionais. O Quantum Computing Cybersecurity Preparedness Act ⧉ dos EUA vincula sistemas federais. O cronograma CNSA 2.0 da NSA ⧉ aponta 2035 para sistemas de segurança nacional. A publicação do BIS Project Leap ⧉ e o programa de trabalho do FSB puxam esse horizonte adiante para a infraestrutura de pagamentos sistêmica. O HNDL significa que o relógio operacional começou a correr bem antes de qualquer uma dessas datas nominais.
Por que ML-KEM é o encapsulamento de chave recomendado em vez de algo mais rápido?
ML-KEM (a versão padronizada do CRYSTALS-Kyber) reuniu a combinação mais forte de cifragens e chaves pequenas entre os candidatos baseados em retículos, com implementações maduras e endurecimento contra canais laterais. O NIST o publicou como FIPS 203 ⧉. Candidatos mais rápidos existem, mas carregam tamanho maior ou intervalos de confiança mais fracos sobre os parâmetros de segurança.
Por que não usar SLH-DSA em toda parte em vez de ML-DSA?
SLH-DSA (a versão padronizada do SPHINCS+) é baseado em hash e portanto depende apenas da segurança da função de hash, que é a premissa mais conservadora disponível. Suas assinaturas são 5–20× maiores que as do ML-DSA. Isso é aceitável para contra-assinatura de arquivamento, mas inviável para assinatura transacional onde o tamanho importa por mensagem. O padrão é ML-DSA para assinatura de produção e SLH-DSA para garantia de arquivamento.
Um banco pode simplesmente esperar até os trilhos publicarem perfis PQC?
Um banco que espera herda a janela de migração que o trilho publica, mais curta que o ciclo interno de mudança do próprio banco. Quando SWIFT, o operador local de RTGS e as CCPs relevantes cada um publicarem seu perfil PQC, a janela de migração será de doze a vinte e quatro meses. Bancos que não pré-construíram a capacidade de CA, transporte e HSM não vão cumpri-la sem atalhos operacionais.
Qual é o item de maior alavancagem a financiar primeiro?
Uma autoridade certificadora subordinada capaz de PQC, integrada à PKI existente, que possa emitir certificados de algoritmo duplo (RSA mais ML-DSA) sem interromper a confiança em produção. Isso estabelece a primitiva de rotação. Todo o resto — upgrades de transporte, planejamento de partição de HSM, mudanças de envelope de mensagem — pode ser agendado em torno dela.
Referências #
- Congress.gov, (2022). H.R. 7535 — Quantum Computing Cybersecurity Preparedness Act ⧉.
- NIST, (2024). FIPS 203 — Module-Lattice-Based Key-Encapsulation Mechanism Standard ⧉.
- NIST, (2024). FIPS 204 — Module-Lattice-Based Digital Signature Standard ⧉.
- NIST, (2024). FIPS 205 — Stateless Hash-Based Digital Signature Standard ⧉.
- NSA, (2022). Commercial National Security Algorithm Suite 2.0 ⧉.
- BIS, (2024). Working Paper No. 1208 — Project Leap: Quantum-proofing the financial system ⧉.
- Bank of England (PRA), (2024). SS1/21 — Operational resilience: Impact tolerances for important business services ⧉.
Última revisão .
Última revisão .