Imagina que o cadeado do seu banco online fosse protegido por uma senha de um dígito. Agora imagina que esse dígito fosse o número 4. Parece piada, mas foi exatamente isso que aconteceu com a eMudhra, uma das maiores autoridades certificadoras da Índia, responsável por mais de 60 milhões de certificados digitais.

No sábado 17 de outubro de 2026, o pesquisador de segurança Scott Helme publicou uma descoberta que fez o mundo da criptografia tremer: oito certificados intermediários da eMudhra tinham chaves privadas tão fracas que qualquer pessoa com um laptop conseguia recuperá-las em menos de um segundo. Uma delas era, literalmente, o número 4.

O que é uma Autoridade Certificadora (e por que isso importa pra você)

Toda vez que você acessa um site com HTTPS, o famoso cadeado no navegador, existe uma cadeia de confiança por trás. No topo dessa cadeia estão as Autoridades Certificadoras (CAs), organizações que os navegadores e sistemas operacionais confiam para validar a identidade de sites.

Quando uma CA emite um certificado para o site do seu banco, ela está dizendo: “eu verifiquei, esse site é legítimo”. Seu navegador confia nessa CA, então confia no certificado, e a conexão é criptografada.

O problema? Se a chave privada de uma CA intermediária vaza, qualquer pessoa pode criar certificados falsos para qualquer domínio do mundo. Seu banco, seu e-mail, qualquer coisa. E o navegador vai mostrar o cadeado verde como se estivesse tudo bem.

8 bits de entropia onde deveriam existir 384

Para entender a gravidade do que aconteceu, vale uma explicação rápida de como funciona a criptografia de curvas elípticas.

A eMudhra usava o algoritmo P-384 (ECDSA) para gerar as chaves dos seus certificados intermediários. Uma chave privada P-384 é, essencialmente, um número aleatório de 384 bits. Isso significa que existem 2^384 combinações possíveis, um número com 115 dígitos. Para ter uma ideia, existem aproximadamente 10^80 átomos no universo observável. Uma chave P-384 tem mais combinações do que átomos no universo. Elevado à 35ª potência.

Então, qual era o tamanho real das chaves da eMudhra?

Sim, você leu certo. A chave privada do certificado EM OV TLS CA – G3C era o número 4. Dois bits de entropia. Uma criança de 6 anos com um ábaco conseguiria quebrar isso.

Na prática, todas as oito chaves eram números menores que 256. Isso significa que, em vez dos 47 bytes aleatórios que deveriam compor a chave, havia 47 bytes de zeros seguidos por um único byte com um valor qualquer.

Como quebrar uma CA em milissegundos

O ataque é ridiculamente simples. Com a chave pública disponível no certificado (informação pública por definição), basta calcular:

1 × G, 2 × G, 3 × G, ..., 255 × G

Onde G é o ponto gerador da curva P-384. Quando o resultado bate com a chave pública do certificado, você encontrou a chave privada. São, no máximo, 255 tentativas.

Para colocar em perspectiva: um ataque de força bruta contra uma chave P-384 legítima levaria mais tempo do que a idade do universo, mesmo usando todos os computadores do planeta em paralelo. Já contra as chaves da eMudhra, o Scott Helme recuperou todas as oito em menos de um segundo. No laptop dele.

# Pseudocódigo simplificado do ataque
from ecdsa import NIST384p, VerifyingKey

# Chave pública extraída do certificado (pública)
pub_key = extract_public_key(certificate)

G = NIST384p.generator
for d in range(1, 256):
    candidate = d * G
    if candidate == pub_key.pubkey.point:
        print(f"Chave privada encontrada: {d}")
        break
# Output: "Chave privada encontrada: 4"

Como isso aconteceu? A cerimônia de chaves que deu errado

A eMudhra publicou um relatório de incidente explicando o que aconteceu. Em abril de 2025, durante a “cerimônia de chaves” (o processo formal e auditado de geração de chaves criptográficas em um HSM, um Hardware Security Module), um bug no script de geração criou dois pares de chaves: um forte e um absurdamente fraco.

O erro humano veio na sequência. Na hora de gerar o CSR (Certificate Signing Request), o operador selecionou o par de chaves errado. O fraco. E ninguém percebeu.

Esses certificados intermediários foram então cross-signed pela Sectigo (uma das maiores CAs do mundo) em maio de 2025 e distribuídos para todos os navegadores e sistemas operacionais do planeta. Ficaram ativos por 17 meses antes que alguém notasse.

17 meses. Com chaves que qualquer pessoa poderia ter quebrado olhando o certificado por 1 segundo.

A resposta de emergência (em tempo recorde)

Quando o alerta chegou aos programas de raiz dos navegadores no sábado à noite, a reação foi rápida:

Nas primeiras horas:

• O Chrome deployou uma atualização de CRLSet bloqueando os certificados na noite de 17 de outubro
• O Mozilla bloqueou os intermediários via OneCRL em questão de horas
• A Apple atualizou suas listas de revogação

Nos dias seguintes:

• O Firefox lançou uma atualização do NSS em 20 de outubro removendo a raiz eMudhra completamente
• O Chrome confirmou a remoção da raiz na versão 43
• O Go lançou as versões 1.26.10 e 1.27.3 com uma denylist no crypto/x509 (CVE-2026-111943)
• Python, Rust e Node.js seguiram com patches similares

A Cloudflare publicou um post detalhado explicando como atualizou seus trust stores, imagens base e deployments de containers em todos os seus produtos (CDN, Developer, Zero Trust). Segundo eles, não encontraram evidências de exploração ativa.

O buraco que ninguém está olhando: clientes não-browser

Aqui é onde a situação fica realmente assustadora. Todo mundo ficou aliviado quando Chrome e Firefox bloquearam os certificados em horas. Mas a internet não é feita só de navegadores. Longe disso.

Navegadores modernos têm múltiplas camadas de proteção:

• Certificate Transparency (CT): Chrome, Firefox e Safari exigem que certificados sejam registrados em logs públicos
• CRLSets e OneCRL: mecanismos de revogação rápida que não dependem do protocolo OCSP
• Atualizações automáticas: navegadores se atualizam sozinhos

Nenhum certificado falso usando essas chaves apareceu nos logs de CT. Então, para quem usa navegador atualizado, o risco foi mitigado.

Mas pensa em tudo que faz requisições HTTPS sem ser um navegador:

• curl, wget nos seus scripts de deploy
• pip, npm, cargo baixando pacotes
• git clonando repositórios via HTTPS
• Python requests, Node.js axios, Go net/http em APIs server-to-server
• IoT e dispositivos embarcados com trust stores congelados
• CI/CD pipelines que carregam credenciais de cloud

Esses clientes geralmente não verificam Certificate Transparency. Muitos não checam revogação por padrão. E dispositivos IoT com firmware congelado podem continuar confiando nesses certificados até 2039 (a data de expiração original).

Pensa no cenário real: um atacante com a chave privada da eMudhra poderia gerar um certificado válido para pypi.org, montar um proxy MITM na rede de uma empresa, e interceptar todo pacote Python baixado por pip install. O pip não checa CT. O pip confia no trust store do sistema. Se o trust store do sistema não foi atualizado, o pip aceita o certificado falso sem reclamar.

O mesmo vale para npm install, cargo build, go get, git clone. Toda a cadeia de supply chain de software passa por HTTPS e confia cegamente nas mesmas CAs. Um certificado comprometido nessa cadeia é o vetor de ataque perfeito: silencioso, escalável e praticamente indetectável.

Como o Scott Helme colocou: “A chave era efetivamente pública desde o dia em que o certificado existiu. Qualquer pessoa que olhou para um desses certificados, em qualquer momento desde abril de 2025, poderia ter recuperado a chave em milissegundos em hardware comum. São 17 meses de janela e não há como saber se alguém fez isso.”

O que você precisa fazer agora

Se você administra servidores, pipelines de CI/CD ou qualquer infraestrutura que faz requisições HTTPS:

1. Atualize seus trust stores:

# Ubuntu/Debian
sudo apt update && sudo apt upgrade ca-certificates

# Alpine (comum em containers Docker)
apk update && apk upgrade ca-certificates

# CentOS/RHEL
sudo yum update ca-certificates

2. Atualize seus runtimes:

# Go (verifique se está em 1.26.10+ ou 1.27.3+)
go version

# Python
pip install --upgrade certifi

# Node.js (atualize para a versão mais recente)
node --version

# Rust
rustup update

3. Reconstrua seus containers Docker:

Se você usa imagens base que não são atualizadas há semanas, elas ainda podem confiar nos certificados comprometidos. Faça rebuild.

docker build --no-cache -t sua-imagem .

4. Verifique dispositivos IoT e embarcados:

Se você tem dispositivos com firmware que não recebe atualizações OTA, esse é o cenário mais crítico. Considere atualizar o firmware ou isolar esses dispositivos em redes separadas.

O problema sistêmico: trust stores estáticos

O incidente da eMudhra expõe uma fragilidade fundamental na infraestrutura de confiança da internet. Trust stores, as listas de CAs que seu sistema confia, são essencialmente arquivos estáticos. Quando uma CA é comprometida, a revogação depende de cada aplicação, runtime e sistema operacional distribuir uma atualização.

A Cloudflare mencionou em seu post sobre o incidente que está trabalhando em soluções como “upki”, que permitiriam atualizações dinâmicas de trust stores, indo além de listas estáticas de certificados raiz para uma infraestrutura mais responsiva.

Isso não é um problema novo. Em 2011, a DigiNotar foi comprometida e usada para espionar cidadãos iranianos. Em 2015, a CNNIC emitiu certificados não autorizados para domínios do Google. Cada incidente reforça que o modelo atual de “confiar em centenas de CAs ao redor do mundo” tem falhas estruturais. São mais de 100 organizações que seu sistema confia por padrão. Basta uma delas cometer um erro para comprometer toda a cadeia.

Mas o caso da eMudhra é único na sua absurdidade. Não foi um hacker sofisticado, não foi uma vulnerabilidade zero-day, não foi engenharia social. Foi um script bugado e um operador que escolheu a chave errada. A chave era o número 4.

Lições para devs (que vão além de certificados)

Eu tiro três lições dessa história:

Cerimônias de chaves precisam de validação automática. Se o script tivesse uma verificação simples do tipo “a entropia dessa chave está dentro do esperado?”, nada disso teria acontecido. Um if d < 2**128: raise ValueError("chave absurdamente fraca") teria salvado meses de dor de cabeça.

Nunca confie em camadas únicas de segurança. Os navegadores se saíram bem porque têm CT, CRLSets e atualizações automáticas. Aplicações server-side geralmente têm zero dessas proteções. Se você faz chamadas HTTPS em produção, considere pinning de certificado ou pelo menos monitoramento de mudanças nos certificados dos seus endpoints críticos.

Teste o que parece óbvio. Ninguém testou se as chaves geradas eram realmente fortes. Parecia óbvio demais. “Claro que o HSM vai gerar uma chave forte, é o trabalho dele.” Pois é. Não gerou.

Essa última lição vale para qualquer sistema. O bug mais devastador geralmente mora na suposição que ninguém questionou.

A eMudhra emitiu mais de 60 milhões de certificados. É uma empresa listada na bolsa indiana, com clientes governamentais e corporativos. E mesmo assim, um script bugado passou pela cerimônia de chaves, pela cross-signing da Sectigo, pela distribuição para todos os root stores do mundo. Nenhuma dessas etapas validou que a chave tinha entropia suficiente. Nenhuma.

Se isso aconteceu com uma CA auditada e regulada, o que está acontecendo em sistemas internos de empresas que geram certificados self-signed para comunicação entre microserviços? Quantos clusters Kubernetes estão rodando com certificados TLS gerados por scripts que ninguém auditou desde 2019? Fica a reflexão.

Fonte de inspiração: Eight Bits of Trust: eMudhra’s CA keys cracked in milliseconds por Scott Helme