Comprometimento da CA Intermediária da eMudhra

Artigo original ↗ Discussão no Hacker News ↗

Uma autoridade certificadora indiana, a eMudhra, emitiu múltiplos certificados intermediários de TLS e assinatura de código cujas chaves privadas de curva elíptica eram trivialmente adivinháveis (valores de um byte, como “4”), permitindo na prática que qualquer pessoa falsificasse certificados para domínios arbitrários até que navegadores e fornecedores de sistemas operacionais os revogassem. Comentadores observam que os mecanismos de revogação e de Certificate Transparency dos principais navegadores limitaram o risco para usuários da web, mas enormes quantidades de clientes não navegadores e dispositivos IoT que embutem seus próprios stores de CA podem permanecer vulneráveis por anos. O incidente reacende críticas ao modelo Web PKI — no qual qualquer CA confiável pode atestar qualquer domínio — e alimenta o debate sobre alternativas como DNSSEC/DANE, restrições de nome mais rígidas e uma infraestrutura de revogação mais centralizada ou auditada.

Visão Geral do Incidente

  • Chaves privadas para oito CAs intermediárias da eMudhra/emSign foram encontradas como trivialmente recuperáveis.
  • Eram chaves ECC P-384 cujos escalares privados eram inteiros minúsculos (<256); uma chave era literalmente “4”.
  • As intermediárias foram coassinadas por outra grande CA, então encadeavam até raízes amplamente confiáveis.
  • As intermediárias afetadas cobriam TLS (incluindo DV) e pelo menos duas CAs de assinatura de código confiáveis pela Microsoft.

Causa Raiz Técnica (conforme discutido)

  • O relatório de incidente da eMudhra atribui a culpa a uma falha em um script de cerimônia de geração de chaves usado com HSMs da Ultimaco.
  • As chaves normais supostamente eram geradas no HSM, mas um caminho de teste de wrap/unwrap produziu chaves secundárias fracas.
  • Devido a rótulos semelhantes, a equipe usou por engano as chaves fracas para criar CSRs que depois foram assinados tanto pela raiz da eMudhra quanto pela CA coassinadora.
  • As CRLs foram inicialmente assinadas com as chaves “corretas”, falharam na validação e então foram novamente assinadas com as chaves fracas, o que muitos veem como uma grande falha de processo.

Impacto de Segurança

  • Qualquer pessoa com os certificados públicos das intermediárias pode derivar as chaves privadas e emitir certificados finais aparentemente válidos.
  • Isso permite MITM indetectável para clientes que:
    • Confiam nas cadeias afetadas, e
    • Não impõem Certificate Transparency (CT).
  • Navegadores que exigem CT rejeitariam uso indevido não registrado, e não foram vistos certificados finais pré-incidente dessas intermediárias nos logs de CT.
  • TLS fora do navegador (curl, IoT, VPNs, sistemas embarcados/industriais) fica fortemente exposto porque muitos não fazem CT e raramente atualizam trust stores.

Revogação e Resposta do Ecossistema

  • Principais navegadores usaram mecanismos centralizados (estilo CRLSet/OneCRL/CRLite) para bloquear rapidamente as intermediárias; muitas vezes os usuários não precisaram de atualizações de software.
  • Sistemas operacionais e bibliotecas variam: o Windows pode bloquear centralmente; Linux/Unix normalmente só distribuem bundles PEM, então Go, rustls, Homebrew, certifi do Python, Electron etc. estão lançando atualizações emergenciais que bloqueiam rigidamente as intermediárias.
  • Muitos projetos incorporam seus próprios bundles de CA, tornando a remediação completa do ecossistema lenta e desigual.
  • Alguns usuários relatam bloqueio inconsistente no Firefox mobile até que as atualizações de CRL se propaguem.

Debate sobre Web PKI vs Alternativas

  • Crítica forte de que qualquer CA confiável pode emitir para qualquer domínio, tornando a segurança dependente da CA mais fraca.
  • Propostas e contrapontos:
    • DNSSEC/DANE: defensores gostam do alinhamento da autenticação com a hierarquia DNS; críticos apontam fragilidade operacional, incapacidade de “matar” TLDs problemáticos e mecanismos mais fracos de monitoramento/expulsão do que a Web PKI.
    • Restrições de nome e CAA: vistas como subutilizadas ou difíceis de implantar (NCs), e o CAA apenas restringe emissão, não a aceitação pelo cliente.
    • Web-of-trust: alguns argumentam que é mais natural para humanos; outros apontam falhas históricas do PGP e o surgimento de autoridades centrais de facto.
  • Vários კომენტadores defendem o modelo de “pena de morte” da Web PKI: navegadores podem e de fato expulsam CAs; não é prático expulsar um TLD.

Consequências para a eMudhra e as CAs

  • Muitos esperam que as raízes da eMudhra sejam removidas dos principais programas de root; comparações são feitas com casos passados de “pena de morte” para CAs.
  • Alguns observam o papel da eMudhra em ecossistemas de certificados de universidades dos EUA por meio de uma marca relacionada, levantando preocupações de cadeia de suprimentos.
  • O incidente destaca fraquezas percebidas na auditoria de CAs e em permitir intermediárias destinadas à exportação de chaves e uso amplo.

Lições Mais Amplas (IoT, Ferramentas, Trust Stores)

  • IoT e outros dispositivos não atualizáveis ou raramente atualizados podem confiar nessas intermediárias até expirarem (~2039), tornando-os alvos de MITM de longo prazo.
  • Alguns veem um “lado positivo” na facilitação de MITM benigno para engenharia reversa de dispositivos bloqueados.
  • O incidente expõe o custo de ter muitas trust stores fragmentadas e stacks TLS personalizados em vez de um mecanismo de plataforma consistentemente atualizável.
  • Várias ferramentas e projetos (por exemplo, upki, overlays Nix) são discutidos como formas de melhorar a revogação centralizada e automatizada para software não navegador.