Criptografia pós-quântica para provedores de pagamento e PSPs

Um provedor de serviços de pagamento (PSP) pode iniciar sua migração pós-quântica agora, nas partes que controla sozinho: TLS em endpoints públicos e voltados a parceiros, tráfego interno entre serviços, administração via SSH e o inventário criptográfico que o PCI DSS já exige. As partes que dependem de terceiros, como especificações das bandeiras de cartão, criptografia de chip EMV e contactless, módulos de segurança de hardware (HSMs) e terminais de pagamento, avançam no ritmo dos seus fornecedores. Separar os dois é todo o exercício: migre o que é seu, documente o que não é e mantenha ambos em um único inventário datado.

Por que a troca de chaves vem primeiro

RSA, ECDSA, EdDSA, ECDH e Diffie-Hellman de corpo finito são todos quebrados pelo algoritmo de Shor em um computador quântico suficientemente grande, qualquer que seja o tamanho da chave. Nenhuma data confiável para tal máquina é apresentada aqui. O que importa para pagamentos é a forma do risco, conhecida como harvest now, decrypt later (HNDL, coletar agora, decifrar depois): o tráfego capturado hoje é protegido apenas pela troca de chaves que gerou a chave de sessão, de modo que um atacante que o grave pode decifrá-lo mais tarde, quando essa troca de chaves se tornar vulnerável. Uma assinatura é diferente: falsificá-la só é útil enquanto a assinatura ainda é considerada confiável.

Por isso a troca de chaves híbrida vem primeiro e as assinaturas vêm depois. Para um PSP, o tráfego gravado é concreto: mensagens de autorização, chamadas à API de tokenização, arquivos de liquidação e conciliação, transferências em lote para adquirentes e processadoras e sessões administrativas no ambiente de dados do titular do cartão. Nosso artigo sobre harvest now, decrypt later detalha esse raciocínio. Um grupo híbrido combina uma troca de chaves clássica com o ML-KEM (Module Lattice Key Encapsulation Mechanism), publicado pelo NIST como FIPS 203 em 13 de agosto de 2024, de modo que a sessão permanece pelo menos tão robusta quanto hoje, mesmo que um dos dois componentes falhe.

O que um PSP pode migrar agora

• Endpoints HTTPS públicos: páginas de pagamento hospedadas, scripts de checkout, painéis de lojistas, receptores de webhooks e APIs públicas. O grupo híbrido X25519MLKEM768 (codepoint IANA 0x11EC, consulte o registro de parâmetros TLS) é oferecido por padrão pelas versões atuais de Chrome, Edge e Firefox, e os clientes que não o suportam negociam o grupo clássico.
• TLS entre serviços dentro do ambiente de dados do titular do cartão, onde você controla as duas pontas e pode atualizar as bibliotecas no seu próprio cronograma.
• Administração via SSH: o OpenSSH 9.9 (19 de setembro de 2024) adicionou mlkem768x25519-sha256, o OpenSSH 10.0 (9 de abril de 2025) o tornou o acordo de chaves padrão e o OpenSSH 10.1 (6 de outubro de 2025) emite um aviso quando uma conexão negocia um acordo de chaves não pós-quântico. Consulte as notas de versão do OpenSSH.
• Resquícios pré-padrão: qualquer grupo X25519Kyber768Draft00 remanescente (codepoint 0x6399) está obsoleto e deve ser substituído pelos grupos ML-KEM.
• O próprio inventário, que é um exercício de documentação e não um projeto de criptografia, e que costuma ser o primeiro entregável solicitado por um avaliador.

Verifique o que um endpoint negocia hoje antes de alterar qualquer coisa. O OpenSSL 3.5 ou posterior é necessário para os grupos ML-KEM:

openssl version
openssl s_client -connect api.example.com:443 -groups X25519MLKEM768 </dev/null 2>&1 | grep -i negotiated

No nginx compilado com OpenSSL 3.5 ou posterior, o grupo híbrido é habilitado listando-o antes dos clássicos, o que mantém o fallback:

ssl_protocols TLSv1.3 TLSv1.2;
ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1;

Os nomes das diretivas e dos grupos suportados variam entre servidores e distribuições, portanto confirme com a sua própria compilação. Teste primeiro em homologação e depois acompanhe as taxas de falha de handshake e o suporte dos clientes após cada mudança em produção. O compartilhamento de chave híbrido é maior que um clássico, o que pode ter impacto em links restritos e em middleboxes antigos que inspecionam o handshake. O acordo de chaves híbrido para TLS 1.3 é especificado na RFC 10024 (agosto de 2026).

O que depende das bandeiras, dos fabricantes de HSM e dos terminais

As áreas a seguir não são decisão do PSP. Nenhuma data pós-quântica é apresentada aqui para elas, pois este site publica apenas fontes primárias datadas, e as bandeiras, a EMVCo e os fabricantes de HSM são as únicas autoridades sobre seus próprios planos.

• Criptografia de chip EMV e contactless, incluindo a autenticação offline de dados, que se baseia em chaves RSA e de curvas elípticas fixadas pela especificação.
• Interfaces de rede das bandeiras de cartão e as hierarquias de chaves que impõem a adquirentes e processadoras.
• Firmware de HSM, configurações certificadas e suporte PKCS#11 a ML-KEM e ML-DSA (Module Lattice Digital Signature Algorithm, FIPS 204).
• Formatos de key block e criptografia relacionada a PIN.
• Hardware de terminais de pagamento, cujo ciclo de substituição é medido em anos.

Interpretação, não um requisito: dê a cada uma dessas dependências uma linha no inventário, com um responsável interno, a posição publicada pelo fornecedor, se houver, e uma data de revisão. Quando surgir um boletim de bandeira ou uma nota de versão de HSM, essa linha muda e o histórico mostra quando você tomou conhecimento. Os questionários a fornecedores na renovação de contratos são a outra alavanca: solicite um roadmap por escrito em vez de presumir que ele existe.

O PCI DSS 12.3.3 já é a espinha dorsal

O requisito 12.3.3 do PCI DSS v4.0.1 exige que as cipher suites e os protocolos em uso sejam documentados e revisados pelo menos uma vez a cada 12 meses. Ele tem três partes: um inventário atualizado que indique a finalidade de cada algoritmo e onde é utilizado, o monitoramento da viabilidade contínua do que está em uso e uma estratégia documentada para responder a mudanças previstas nas vulnerabilidades criptográficas. É obrigatório desde 31 de março de 2025, tendo sido uma boa prática antes dessa data; a norma está disponível na biblioteca de documentos do PCI SSC. Nosso guia sobre o inventário criptográfico do PCI DSS 12.3.3 aborda a estrutura, e a página de referência do PCI DSS v4.0.1 mantém os marcos datados.

Leia a terceira parte com atenção. Mudanças previstas nas vulnerabilidades criptográficas é onde o pós-quântico se encaixa. Interpretação: a vulnerabilidade quântica da troca de chaves RSA e de curvas elípticas é uma dessas mudanças previstas, de modo que a estratégia 12.3.3 de um PSP pode mencionar a troca de chaves híbrida, indicar quais endpoints já foram migrados e listar as dependências de bandeiras e HSMs com seus responsáveis. O requisito 12.3.3 não exige ML-KEM hoje.

DORA: o que o texto exige das entidades financeiras da UE

O Regulamento Delegado (UE) 2024/1774 da Comissão, as normas técnicas de regulamentação sobre gestão do risco de TIC no âmbito do DORA, aplica-se às entidades financeiras da UE, incluindo instituições de pagamento e de moeda eletrônica. O Art. 6 exige uma política de criptografia e controles criptográficos que inclua disposições para atualizar ou alterar a tecnologia criptográfica com base na evolução da criptoanálise. O Art. 7 exige a gestão de chaves ao longo de todo o ciclo de vida e um registro de certificados para os ativos de TIC que suportam funções críticas ou importantes. Ambos estão resumidos com seus marcos na página de referência do DORA.

O texto não menciona nenhum algoritmo nem fixa uma data pós-quântica. Interpretação: o Art. 6 é atendido por uma política com um gatilho definido e um fluxo de aprovação para a troca de um algoritmo, e o Art. 7 por um registro de certificados que já registre algoritmo e tamanho de chave, o que o torna o lugar natural para ver o que ainda é RSA ou ECDSA. O NIS2 Art. 21(2)(h) pede políticas e procedimentos sobre o uso de criptografia em termos semelhantes, por meio da transposição nacional. Este artigo é informativo e não constitui aconselhamento jurídico.

Do requisito à evidência

Datas oficiais para o planejamento

Nenhuma delas é específica de pagamentos, e nenhuma é um prazo legal para um PSP, a menos que a última coluna o indique. Mantenha as ressalvas ao citá-las internamente.

Comece pelos endpoints que você consegue ver

O passo útil mais rápido é medir o que seus endpoints públicos de pagamento negociam hoje e então definir a ordem do trabalho: analise seu domínio com o PQC Status para verificar o suporte a ML-KEM híbrido, as versões de TLS e a cadeia de certificados. Execute a análise separadamente no domínio de checkout, no host da API e no host de webhooks, pois eles costumam ficar atrás de terminadores diferentes. Registre cada resultado no inventário 12.3.3 com sua data, adicione as dependências de bandeiras, HSMs e terminais como linhas em aberto com responsáveis e marque a próxima revisão para no máximo doze meses depois.