A chave privada era literalmente 4. O Firefox confiava nela. No ICP-Brasil, não confia.

Uma autoridade certificadora reconhecida pelos principais navegadores do mundo teve oito de suas chaves privadas comprometidas. Até aí, infelizmente, não seria a primeira vez que algo assim acontece.

O detalhe absurdo é que uma dessas chaves privadas era literalmente o número 4.

Não estou falando de uma senha de quatro caracteres, nem de uma chave criptográfica de quatro bytes. Estou falando do inteiro 4, representável com apenas 3 bits.

E a situação fica ainda mais curiosa quando lembramos que a ICP-Brasil, a infraestrutura oficial de certificação digital brasileira, tenta há anos conseguir reconhecimento nativo no repositório de certificados confiáveis da Mozilla.

O que aconteceu com a eMudhra?

No dia 20 de outubro de 2026, a Mozilla publicou um comunicado informando que oito certificados de autoridades certificadoras intermediárias da empresa indiana eMudhra, operadora da marca emSign, tiveram suas chaves privadas comprometidas.

O incidente havia sido comunicado em 17 de outubro por um pesquisador identificado como Wayne, que demonstrou possuir as chaves assinando uma mensagem com cada uma delas.

Os certificados pertenciam a seis autoridades intermediárias destinadas à emissão de certificados TLS e duas destinadas à assinatura de código.

O problema é que essas autoridades estavam vinculadas a cadeias de certificação reconhecidas pelos principais programas de confiança, incluindo Mozilla, Google, Apple e Microsoft.

Em condições normais, uma autoridade intermediária de TLS possui capacidade para emitir certificados válidos para diferentes domínios da internet, dependendo das restrições aplicáveis à sua cadeia.

Isso significa que o comprometimento de sua chave privada pode permitir a emissão de certificados fraudulentos para sites que o atacante não controla, viabilizando ataques de interceptação de conexões HTTPS.

A chave privada era o número 4

A parte mais inacreditável apareceu quando pesquisadores começaram a analisar as chaves comprometidas.

Os certificados utilizavam criptografia de curvas elípticas, especificamente a curva NIST P-384 (secp384r1).

Nesse sistema, a chave pública é calculada aproximadamente pela operação:

Q = d × G

Onde:

d é a chave privada;
G é um ponto gerador conhecido da curva;
Q é a chave pública.

A segurança do sistema depende da dificuldade de recuperar d conhecendo apenas Q e G.

Uma chave privada gerada corretamente na curva P-384 possui aproximadamente 384 bits de entropia. Isso torna inviável descobrir seu valor por força bruta com a tecnologia atual.

Mas, no caso da autoridade intermediária EM OV TLS CA - G3C, o valor de d era simplesmente:

d = 4

E não foi um caso isolado.

As oito chaves privadas comprometidas correspondiam aos seguintes números:

Sim. Todas cabiam em apenas um byte.

Em vez de um espaço de busca com aproximadamente 2^384 possibilidades, bastaria testar 255 valores positivos para recuperar qualquer uma dessas chaves.

O tamanho anunciado de 384 bits da curva continuava aparecendo nos certificados, mas a entropia efetiva das chaves era praticamente inexistente.

A descoberta foi documentada por pesquisadores e também noticiada pela Ars Technica.

Até o momento, não está completamente esclarecido como essas chaves foram geradas dessa maneira. Portanto, é importante distinguir uma chave criptograficamente recuperável de um vazamento convencional por invasão dos servidores da certificadora.

Como os navegadores reagiram?

A Mozilla informou que recebeu o alerta em 17 de outubro e, em menos de três horas, concluiu a distribuição de bloqueios aos usuários do Firefox com configurações padrão, utilizando o OneCRL.

Também anunciou atualizações emergenciais do Firefox e a remoção da raiz envolvida do NSS, biblioteca criptográfica utilizada pelo Firefox e por outras aplicações.

O Chrome também bloqueou as intermediárias afetadas, e a Apple adotou medidas de proteção.

O incidente provocou atualizações emergenciais em componentes e ecossistemas como Go, distribuições Linux e pacotes de certificados confiáveis.

Há uma particularidade importante: segundo informações divulgadas pelo Chrome Root Program, não havia certificados TLS emitidos pelas seis intermediárias comprometidas registrados nos logs públicos de Certificate Transparency antes do bloqueio. Isso reduziu a possibilidade de exploração nos navegadores que exigem esse registro.

Não há, até o momento, comprovação pública de exploração maliciosa dessas chaves.

Ainda assim, a gravidade do incidente não deve ser subestimada, principalmente para aplicações que utilizam repositórios de confiança próprios ou não verificam adequadamente a revogação de certificados.

E onde entra a ICP-Brasil nessa história?

Aqui está a ironia.

A ICP-Brasil foi instituída em 2001 pela Medida Provisória nº 2.200-2, sendo administrada em sua raiz pelo Instituto Nacional de Tecnologia da Informação (ITI).

Ela é responsável por uma infraestrutura amplamente utilizada no Brasil para assinaturas digitais, certificados e-CPF, e-CNPJ e diversas aplicações governamentais e privadas.

Entretanto, uma coisa é uma autoridade certificadora possuir reconhecimento jurídico nacional. Outra, completamente diferente, é ser considerada confiável pelos navegadores para emissão de certificados HTTPS.

Para isso, é necessário que a autoridade raiz seja incluída nos chamados root stores, os repositórios de autoridades certificadoras confiáveis dos navegadores e sistemas operacionais.

E é justamente aí que a ICP-Brasil enfrenta dificuldades.

Em 2020, foi aberta uma solicitação à Mozilla para incluir a Autoridade Certificadora Raiz Brasileira v10, uma raiz desenvolvida especificamente para emissão de certificados SSL/TLS.

Durante a análise, participantes da comunidade Mozilla apontaram problemas envolvendo certificados emitidos fora dos requisitos da WebPKI, nomes DNS inválidos e questões relacionadas à extensa hierarquia de autoridades subordinadas brasileiras.

Apesar dos esforços, a raiz brasileira ainda não foi incluída no Mozilla Root Store.

Em outubro de 2026, uma nova solicitação apareceu no Bugzilla, mas recebeu uma resposta indicando que o pedido havia sido aberto por um terceiro e que as questões discutidas no processo anterior continuavam relevantes.

Vale destacar que a situação não é universal: a Microsoft incluiu a AC Raiz Brasileira v10 em seu programa de confiança em agosto de 2020, conforme seu comunicado oficial.

O problema é a ausência de reconhecimento nativo generalizado nos demais programas, especialmente no da Mozilla.

Isso significa que a ICP-Brasil é mais segura que a eMudhra?

Não necessariamente.

Seria incorreto concluir que a ICP-Brasil possui controles superiores simplesmente porque a eMudhra protagonizou um incidente gravíssimo.

A própria infraestrutura brasileira já foi questionada publicamente por problemas de conformidade na emissão de certificados.

Além disso, os programas de confiança não avaliam apenas a qualidade dos algoritmos criptográficos. Exigem auditorias independentes, conformidade com os requisitos do CA/Browser Forum, documentação, transparência, controles operacionais e gerenciamento adequado de toda a hierarquia de certificação.

Mas o incidente levanta uma discussão pertinente sobre a diferença entre ser considerado confiável e efetivamente operar de maneira segura.

A inclusão de uma autoridade certificadora em um repositório de confiança não pode ser tratada como uma garantia permanente de segurança.

E, inversamente, a ausência dessa inclusão não significa automaticamente que toda a infraestrutura excluída seja insegura.

Uma reflexão sobre o modelo de confiança da internet

A WebPKI depende de um conjunto relativamente restrito de organizações capazes de determinar quais autoridades certificadoras serão reconhecidas por bilhões de dispositivos.

Isso cria uma estrutura de confiança centralizada, ainda que formada por diferentes programas independentes.

Quando uma autoridade certificadora é incluída nesses programas, ela passa a participar de uma infraestrutura cuja segurança afeta potencialmente usuários do mundo inteiro.

O caso da eMudhra demonstra que as consequências de falhas operacionais podem ultrapassar enormemente a organização responsável.

E a situação da ICP-Brasil mostra que a entrada nesse ecossistema pode ser um processo complexo e demorado, mesmo para uma infraestrutura nacional consolidada.

Não estou defendendo que a ICP-Brasil deva ser incluída automaticamente, sem cumprir os requisitos internacionais. Muito pelo contrário: exigências rigorosas e auditorias independentes são fundamentais.

Mas é difícil não perceber a ironia:

Uma autoridade certificadora que chegou a possuir reconhecimento internacional emitiu certificados intermediários protegidos pelo número 4, enquanto a infraestrutura brasileira continua tentando conquistar essa mesma confiança.

No fim, o episódio deixa algumas perguntas interessantes:

Os mecanismos de auditoria das autoridades certificadoras deveriam verificar de forma mais rigorosa a geração e a qualidade das chaves criptográficas?
Os programas de confiança deveriam ampliar seus processos de fiscalização contínua, em vez de depender tanto de auditorias e notificações de terceiros?
O que falta para a ICP-Brasil conseguir atender satisfatoriamente às exigências do Mozilla Root Store?
E até que ponto o atual modelo de confiança da WebPKI é sustentável?

Gostaria de saber a opinião da comunidade, especialmente de quem trabalha com criptografia, PKI, TLS e segurança da informação.