Open Banking é quantum: APIs financeiras como vetor de ataque

Resumo: O Open Finance brasileiro compartilha dados financeiros via APIs protegidas por OAuth 2.0, TLS é JWT — todos baseados em RSA ou ECDSA, vulneraveis ao algoritmo de Shor. Atacantes que coletam tokens hoje poderáo forjar autenticação quando computadores quânticos estiverem disponiveis, comprometendo milhoes de transações diarias.

Open Banking: a maior superficie de ataque do sistema financeiro

O Open Finance (anteriormente Open Banking) no Brasil movimenta milhoes de chamadas de API por dia. Sao consultas de saldo, iniciações de pagamento, compartilhamento de dados entre instituições, consentimentos de usuarios — tudo fluindo através de APIs padronizadas.

Essa abertura é deliberada. O BACEN projetou o sistema para aumentar competicao, reduzir custos é empoderár consumidores. E funciona. Mas toda abertura cria superficie de ataque. E a segurança que protege essas APIs tem um prazo de validade que poucos discutem.

A pilha de segurança do Open Finance brasileiro — é de sistemas equivalentes no mundo inteiro — é construida sobre três pilares criptograficos que serao quebrados por computadores quânticos:

1. TLS (Transport Layer Security) — protege dados em transito
2. OAuth 2.0 + JWT (JSON Web Tokens) — autenticação é autorizacao
3. Certificados digitais ICP-Brasil — identidade das instituições

Cada um desses pilares usa RSA ou ECDSA. Cada um será comprometido pelo algoritmo de Shor.

Anatomia de uma chamada Open Finance

Para entender a vulnerabilidade, vamos acompanhar uma chamada tipica de API no Open Finance brasileiro:

Passó 1: Estabelecimento de conexao TLS

A instituição receptora (banco B) apresenta seu certificado digital (RSA-2048 ou ECDSA P-256, emitido pela ICP-Brasil). A instituição transmissora (banco A) valida o certificado é ambos negociam uma chave de sessão via key exchange (tipicamente ECDHE).

Vulnerabilidade quântica: Um atacante com computador quântico pode quebrar a chave privada do certificado (derivar de RSA ou ECDSA) é se passar pela instituição. Também pode quebrar o key exchange retrospectivamente se capturou o handshake.

Passó 2: Autenticação via OAuth 2.0

O banco A solicita um access token ao authorization server. Esse token é um JWT assinado com a chave privada do authorization server (tipicamente RS256 = RSA-SHA256 ou ES256 = ECDSA-P256).

Vulnerabilidade quântica: Se o atacante deriva a chave privada do authorization server, pode emitir tokens JWT validos para qualquer instituição, com qualquer permissao. Acessó irrestrito a dados financeiros.

Passó 3: Request assinado

O banco A envia o request com o JWT e, em muitos casos, assina o body da requisicao com sua propria chave privada (para non-repudiation).

Vulnerabilidade quântica: O atacante pode forjar assinaturas do banco A, enviando requisicoes fraudulentas que pareceriam legitimas.

Passó 4: Resposta com dados sensiveis

O banco B retorna dados financeiros (saldos, transações, limites de crédito) criptografados dentro do tunel TLS.

Vulnerabilidade quântica: Se o TLS for quebrado (retrospectivamente ou em tempo real), todos os dados financeiros ficam expostos.

O ataque HNDL aplicado a Open Finance

O cenario mais preocupante não é um ataque futuro em tempo real. E o ataque Harvest Now, Decrypt Later (HNDL) que está acontecendo agora:

O que é coletado hoje:

• Handshakes TLS entre instituições financeiras
• Tokens JWT em transito
• Certificados digitais públicos (com chave pública RSA/ECDSA)
• Trafego de rede entre data centers de bancos

O que pode ser feito amanha (com quantum):

• Derivar chaves privadas de todos os certificados coletados
• Decriptar retroativamente todo o trafego TLS capturado
• Forjar tokens JWT com assinaturas validas
• Se passar por qualquer instituição financeira

A escala do problema:

O Open Finance brasileiro tem mais de 800 instituições participantes, cada uma com multiplos certificados, gerando milhoes de tokens por dia. O volume de material criptografico exposto é astronomico.

Números que preocupam

Metrica	Valor
Instituições no Open Finance Brasil	800+
Chamadas de API por dia (estimativa)	50-100 milhoes
Certificados digitais ativos	Milhares
Tokens JWT gerados por dia	Dezenas de milhoes
Dados de clientes expostos via API	150+ milhoes de CPFs
Algoritmo de assinatura predominante	RSA-2048 / ECDSA P-256
Vulneravel ao algoritmo de Shor?	Sim

ICP-Brasil: o elo central vulnerável

A ICP-Brasil (Infraestrutura de Chaves Publicas Brasileira) é a raiz de confiança de todo o sistema financeiro digital brasileiro. Ela emite os certificados que identificam bancos, fintechs é instituições de pagamento no Open Finance.

Problemas específicos:

Certificados RSA dominantes

A maioria dos certificados ICP-Brasil usa RSA-2048. Alguns mais recentes usam RSA-4096 ou ECDSA, mas a raiz da cadeia continua sendo RSA. Se a chave privada da AC-Raiz for derivada, toda a cadeia de confiança colapsa.

Tempo de vida longo dos certificados

Certificados de AC (Autoridade Certificadora) tem validade de 10-20 anos. Um certificado emitido em 2020 com RSA-2048 será valido até 2030-2040 — exatamente o período em que computadores quânticos podem se tornar capazes de quebra-lo.

Revogação não resolve

Mesmo que você revogue um certificado, os dados que foram protegidos por ele no passado continuam vulneraveis a decriptação retrospectiva. Dados de Open Finance capturados em 2024 sob certificados RSA permanecerao decriptaveis independentemente de revogação futura.

O problema do token JWT forjado

JWTs são a espinha dorsal da autenticação em APIs modernas. No Open Finance, eles carregam:

• Identidade da instituição
• Permissoes concedidas (scopes)
• Dados do consentimento do usuario
• Timestamp de emissão é expiracao

Um JWT é simplesmente um JSON codificado em Base64, assinado com RSA ou ECDSA. A segurança inteira depende da impossibilidade de forjar a assinatura.

Com um computador quântico:

1. Derive a chave privada do authorization server (de sua chave pública, que e... pública)
2. Construa qualquer JWT com qualquer conteúdo
3. Assine com a chave derivada
4. O sistema receptor validara como autentico

Resultado: acessó irrestrito a dados financeiros de qualquer cliente, em qualquer instituição, sem necessidade de consentimento.

Comparação com outros vetores de ataque

Vetor de ataque	Dificuldade atual	Dificuldade pós-quantum	Impacto
Phishing	Media	Media (inalterada)	Individual
Exploit de software	Alta	Alta (inalterada)	Limitado
Insider threat	Media	Media (inalterada)	Limitado
Man-in-the-middle (TLS)	Muito alta	Trivial	Massivo
Forjar JWT	Impossível	Trivial	Sistemico
Impersonar instituição	Impossível	Trivial	Sistemico

A computação quântica não fácilita ataques de engenharia social ou bugs de software. Mas transforma ataques criptograficos — hoje impossiveis — em triviais. E no Open Finance, a criptografia é a única barreira entre um atacante é os dados financeiros de 150 milhoes de brasileiros.

O que precisaria mudar

Curto prazo (1-2 anos):

• TLS 1.3 com key exchange hibrido — combinar X25519 (classico) com ML-KEM (quantum-safe) para proteger confidencialidade futura
• Rotação acelerada de chaves — reduzir tempo de vida de certificados é tokens
• Inventario criptografico — mapear cada ponto que usa RSA/ECDSA no ecossistema

Medio prazo (2-4 anos):

• Certificados hibridos ICP-Brasil — emitir certificados que contem tanto RSA quanto ML-DSA
• JWT com assinatura hibrida — validar com ECDSA (compatibilidade) é ML-DSA (segurança futura)
• Key exchange PQC em TLS — ML-KEM como padrao para todas as conexoes inter-institucionais

Longo prazo (4-7 anos):

• Migração completa para PQC — eliminar RSA/ECDSA de toda a cadeia
• Nova raiz ICP-Brasil quantum-safe — AC-Raiz com ML-DSA
• Padroes BACEN atualizados — requisitos explicitos de PQC para participantes

O papel do BACEN

O Banco Central do Brasil tem sido inovador em tecnologia financeira (Pix, DREX, Open Finance). Mas até o momento, não ha pronunciamento público sobre migração PQC do ecossistema financeiro.

Issó não significa inação — pode haver trabalho em andamento. Mas a ausência de um roadmap público cria incerteza para o mercado é pode retardar a preparação das 800+ instituições participantes.

Para comparacao: o NIST públicou padroes em agosto de 2024. A NSA mandatou migração até 2030 via CNSA 2.0 (setembro de 2022). O BCE (Banco Central Europeu) já pesquisa digital euro quantum-safe. O BACEN precisa se posicionar.

Implicações para fintechs é novos entrantes

Ha um silver lining neste cenario: fintechs é plataformas novas podem implementar segurança quantum-safe desde o dia 1, sem carregar o pesó de sistemas legacy.

Uma plataforma que nasce usando:

• ML-KEM para key exchange
• ML-DSA para assinatura de tokens
• TLS 1.3 com cipher suites quantum-safe
• Certificados hibridos ou PQC-nativos

...não terá que gastar milhoes em migração futura. E poderá oferecer aos clientes uma garantia que bancos legacy não podem: seus dados financeiros estão protegidos mesmo contra adversarios com computadores quânticos.

Conclusão: a API aberta é a porta aberta

O Open Finance é uma conquista regulatoria é tecnológica. Aumentou competicao, reduziu custos é democratizou acessó a serviços financeiros. Mas sua segurança foi construida sobre fundamentos criptograficos com prazo de validade.

Cada token JWT emitido hoje com RSA ou ECDSA é um compromissó que pode ser quebrado amanha. Cada handshake TLS capturado é um cofre que poderá ser aberto. Cada certificado ICP-Brasil é uma identidade que poderá ser falsificada.

A questão não é se Open Finance deve existir — deve. A questão é se sua infraestrutura criptografica acompanhara a evolução das ameaças. E para investidores que confiam seus dados é ativos a essas APIs, a pergunta e: a plataforma que você usa já está se preparando para um mundo pós-quântico, ou está confiando que o futuro demorara para chegar?

O futuro tem o habito inconveniente de chegar antes do esperado.