Chaves RSA de 512 bits de uma CA dos anos 1990 foram fatoradas

O que aconteceu com as chaves RSA de uma CA dos anos 1990

Um experimento publicado em 7 de setembro de 2026 por Matthew McPherrin chamou atenção para uma lição antiga da segurança digital: o tamanho de uma chave criptográfica precisa ser avaliado de acordo com a capacidade computacional disponível hoje, e não com a capacidade da época em que ela foi criada. O pesquisador fatorou chaves RSA de 512 bits pertencentes a duas raízes da E-Certify, uma autoridade certificadora canadense já encerrada, que foram distribuídas com o Netscape 4.51 em 1999.

O caso não é um relato de invasão contra uma autoridade certificadora atualmente em operação. É uma demonstração histórica sobre raízes antigas que ainda podem ser encontradas em arquivos de software, máquinas virtuais, laboratórios e ambientes legados. Mesmo assim, a consequência técnica é importante: quando os fatores primos de uma chave RSA são descobertos, torna-se possível reconstruir a chave privada correspondente e emitir certificados que uma instalação antiga poderia aceitar.

O texto original também contextualiza o resultado com a fatoração recente de uma chave RSA-260 de 862 bits, descrita pelo autor como a maior fatoração de que ele tinha conhecimento naquele momento. A comparação não significa que uma chave RSA moderna de 2048 bits tenha sido quebrada. Ela mostra que tamanhos considerados grandes em décadas passadas não devem ser tratados como proteção suficiente para sistemas atuais.

A experiência foi feita em um ambiente controlado. O autor montou um servidor compatível com as limitações do Netscape 4.51, cuja pilha TLS não tem interseção prática com as pilhas modernas. O site de teste pode ser observado em e-certify.fly.dev, mas não deve ser interpretado como um serviço compatível com navegadores atuais.

Como funciona a fatoração de uma chave RSA

Uma chave pública RSA contém, entre outros valores, um módulo formado pela multiplicação de dois números primos grandes. A segurança do esquema depende da dificuldade de recuperar esses dois fatores a partir do módulo. Em chaves suficientemente grandes, a fatoração exige recursos que tornam o ataque impraticável dentro da vida útil esperada do segredo.

O problema aparece quando o módulo é pequeno. Uma chave RSA de 512 bits tem uma margem de segurança muito menor do que a esperada para sistemas contemporâneos. Com uma fatoração bem-sucedida, o atacante obtém os fatores primos e pode calcular os componentes matemáticos usados pela chave privada. Isso não é o mesmo que descobrir uma senha por tentativa e erro, nem significa que toda sessão TLS moderna possa ser descriptografada automaticamente.

Na prática, a reconstrução da chave privada permite assinar ou emitir certificados compatíveis com a autoridade representada pela chave. A aceitação ainda depende do dispositivo confiar naquela raiz, do certificado estar dentro de um período de validade aceito, do relógio do sistema e dos algoritmos suportados. Por isso, o experimento é especialmente relevante para software legado que mantém raízes antigas em seu armazenamento de confiança.

Para fazer as fatorações, McPherrin usou o CADO-NFS em um computador com processador Ryzen 9 5950X. O texto informa que a chave E-Certify RSA 512 Gold Server levou 32 horas e a chave E-Certify RSA 512 Gold Client levou 29 horas. O tempo é uma medida do experimento específico, não uma previsão universal: hardware, parâmetros, implementação e paralelismo mudam o custo.

O ponto defensivo é simples. O tamanho da chave aparece no certificado e pode ser inventariado sem acesso à chave privada. Uma organização não precisa reproduzir a fatoração para concluir que uma raiz RSA de 512 bits não deve permanecer em um ambiente de produção.

Quem foi afetado e para que serviam essas raízes

As raízes encontradas pelo autor eram certificados de autoridade certificadora distribuídos com o Netscape 4.51, lançado no período em que a Web ainda adotava padrões e requisitos bem diferentes dos atuais. Uma raiz E-Certify RSA 512 Gold Server era confiável para SSL, enquanto outra era usada para S/MIME. As duas pertenciam à E-Certify.

O texto relata que as raízes de 512 bits foram removidas do Netscape em 2002. Também observa que o Internet Explorer não parece ter distribuído raízes de 512 bits para SSL, o que limita o cenário histórico a uma janela específica do Netscape. A validade original também terminou: o autor menciona 16 de outubro de 2003 como a data de expiração dos certificados usados no laboratório.

Isso reduz bastante o risco para a Web moderna. Um navegador atualizado não deve confiar nessas raízes e, mesmo em um ambiente antigo, vários outros requisitos precisam coincidir para que um certificado emitido com a chave recuperada seja aceito. O resultado, porém, é relevante para quem mantém sistemas industriais, aplicações embarcadas, imagens antigas de máquinas virtuais ou arquivos de confiança que nunca foram revisados.

O experimento ainda cita um caso adicional. O Internet Explorer 3.02 distribuía uma CA de assinatura de código de teste da VeriSign com uma chave RSA de 512 bits. Essa chave também foi fatorada, em cerca de uma hora, por Steve Weis usando um cluster de GPUs, segundo o artigo. Por ser uma CA de teste e não uma raiz de produção atual, o exemplo reforça a importância de separar material histórico de confiança operacional.

Não há no relato uma lista de vítimas atuais, nem uma indicação de que certificados fraudulentos tenham sido usados contra usuários modernos. A forma correta de comunicar o caso é como um alerta sobre criptografia legada e sobre o risco de confiar em certificados antigos sem inventário.

Como identificar e detectar o risco

O primeiro passo é descobrir quais certificados e raízes realmente estão instalados. Faça um inventário dos armazenamentos de confiança do sistema operacional, dos servidores web, dos proxies, dos dispositivos de rede, das aplicações Java, dos contêineres e das imagens de máquinas virtuais. Também verifique cópias mantidas dentro do próprio produto, porque uma aplicação pode ignorar o armazenamento de confiança do sistema.

Para examinar um certificado em formato PEM, uma equipe pode usar uma ferramenta local como openssl x509 -in certificado.pem -text -noout. Procure o algoritmo da chave pública e o tamanho efetivo. Em uma auditoria, registre o emissor, o assunto, as datas de validade, o uso permitido e o caminho de confiança. Não considere apenas o certificado apresentado pelo servidor: a raiz confiável pode estar em uma camada diferente.

Um indicador prioritário é encontrar RSA de 512 bits ou qualquer certificado de teste instalado em uma cadeia usada para autenticação, assinatura ou transporte de dados. Chaves de 1024 bits também exigem tratamento conforme a política de segurança e o suporte do fornecedor. O fato de um certificado estar expirado não elimina a necessidade de investigar, porque ele pode estar armazenado em uma imagem, ser aceito por um software antigo ou indicar que outras raízes antigas continuam presentes.

Na detecção operacional, procure conexões de clientes antigos, mudanças inesperadas no armazenamento de confiança, certificados emitidos por uma CA que deveria estar aposentada e falhas de negociação TLS que aparecem somente em dispositivos legados. Correlacione esses sinais com inventário e janela de manutenção. A presença de uma raiz antiga é um achado de configuração; sozinha, não prova que houve interceptação ou emissão fraudulenta.

Registre também as limitações do ambiente. Um sistema pode ter uma chave fraca instalada, mas estar isolado, sem rede, com o serviço desativado ou sem confiar na raiz durante o fluxo real. Essa distinção ajuda a priorizar a correção e evita transformar um achado histórico em uma afirmação falsa sobre um incidente atual.

Como se proteger e mitigar

Comece removendo raízes de teste, expiradas ou desnecessárias dos ambientes em que elas não têm função. A remoção deve ser planejada com inventário e validação, porque apagar uma CA legítima sem identificar dependências pode interromper integrações. Em ambientes legados que não podem ser atualizados imediatamente, registre a exceção, restrinja a rede e separe o sistema de dados e serviços que não precisam dele.

Substitua certificados e chaves fracas por material aprovado pela política atual da organização e pelo fornecedor da plataforma. Para RSA, o artigo destaca que o mundo usa pelo menos 2048 bits hoje, mas a escolha final deve considerar o ciclo de vida do serviço, a compatibilidade dos clientes e a orientação vigente da autoridade certificadora. Onde for suportado, avalie também algoritmos modernos que não dependem da fatoração de um módulo RSA.

Depois da troca, valide o caminho completo. Teste o servidor, o proxy, os clientes internos, os dispositivos móveis e os consumidores de API. Confirme que a nova cadeia não inclui a raiz antiga, que a chave privada não foi reutilizada e que a aplicação em execução carregou o arquivo correto. Uma troca no repositório sem reiniciar ou sem atualizar o contêiner efetivamente usado não resolve o risco.

Não copie as chaves privadas recuperadas no experimento para um ambiente real. Elas foram publicadas como parte de uma demonstração histórica e devem ser tratadas como comprometidas. Se a equipe precisar reproduzir o cenário para pesquisa, use uma rede isolada, dados descartáveis e uma máquina virtual sem acesso a credenciais de produção.

Por fim, automatize o inventário. Uma verificação no pipeline e uma rotina periódica de certificados conseguem identificar tamanhos de chave proibidos, CAs aposentadas e datas próximas do vencimento antes que o problema chegue a uma auditoria ou a uma interrupção.

Comparação com casos e alternativas anteriores

O contraste mais direto no artigo é com o RSA-155, uma chave de 512 bits que foi fatorada ainda em 1999. Naquele momento, o resultado já indicava que certos módulos eram pequenos demais para uma autoridade certificadora. A recuperação das raízes E-Certify mostra que a decisão de manter chaves antigas pode continuar produzindo material vulnerável décadas depois, mesmo quando o software original quase desapareceu.

RSA de 1024 bits ocupou por muito tempo uma posição intermediária. Foi mais resistente do que 512 bits, mas deixou de ser uma escolha aceitável para novos certificados de longa duração. A comparação não deve ser usada para criar um número mágico: o tamanho mínimo depende do uso, da validade, dos requisitos do cliente e da política de criptografia. O importante é evitar algoritmos e comprimentos que já estejam fora da linha de segurança do ecossistema.

Algoritmos de curvas elípticas usam propriedades matemáticas diferentes e não são quebrados pelo mesmo processo de fatoração. Isso não significa que sejam automaticamente seguros: implementação, geração de aleatoriedade, escolha de curva, bibliotecas e validação continuam importantes. A migração deve ser feita com suporte real dos clientes e com testes de interoperabilidade.

Também existe uma diferença entre uma CA histórica com uma chave fraca e o comprometimento de uma CA atual. No primeiro caso, o problema está no material antigo e no conjunto de confiança que ainda o aceita. No segundo, pode haver impacto em certificados de serviços modernos e necessidade de revogação coordenada. Misturar os dois cenários gera alarmismo e atrapalha a resposta técnica.

O artigo menciona ainda a possibilidade de computadores quânticos mudarem o horizonte de segurança de RSA no futuro. Essa observação não é evidência de que um computador quântico tenha quebrado as chaves analisadas. Ela reforça que a gestão de criptografia precisa considerar o tempo de proteção exigido pelos dados, a migração gradual e a possibilidade de novas famílias de algoritmos.

Análise técnica das chaves fracas

O caso E-Certify reúne quatro pontos técnicos que merecem ser separados. O primeiro é o tamanho do módulo: 512 bits não oferece uma margem compatível com a segurança atual. O segundo é a posição da chave na hierarquia: uma raiz de CA pode assinar certificados para outros nomes, portanto o impacto potencial é maior do que o de uma chave usada por um único servidor.

O terceiro ponto é a reconstrução matemática. Ao fatorar o módulo público, o pesquisador obteve os dois primos necessários para reconstruir a chave privada. O artigo não apresenta isso como um defeito específico em uma implementação do RSA. O problema está na escolha de um tamanho de chave que se tornou viável para fatoração com recursos acessíveis a uma pesquisa individual.

O quarto ponto é a compatibilidade. Para demonstrar o resultado, o autor precisou construir um servidor TLS antigo em Go, porque não existe sobreposição suficiente entre o Netscape 4.51 e as bibliotecas modernas. Isso mostra que possuir uma chave privada recuperada não equivale a atacar qualquer navegador ou servidor atual. A cadeia de confiança, o relógio, a validade, os algoritmos e o protocolo precisam aceitar o fluxo.

O autor informa 32 horas de processamento para a raiz Server e 29 horas para a raiz Client em seu Ryzen 9 5950X com CADO-NFS. O exemplo adicional da CA de teste da VeriSign levou cerca de uma hora com um cluster de GPUs, segundo o texto. Esses números ajudam a dimensionar a demonstração, mas não devem ser convertidos em uma estimativa para RSA de 2048 bits.

Também é importante notar o que o caso não demonstra. Ele não apresenta uma vulnerabilidade com identificador CVE, não mostra uma falha em uma CA moderna e não afirma que uma sessão HTTPS atual foi interceptada. É uma análise experimental de chaves antigas, com material público e uma reprodução restrita a software histórico.

Impacto e consequências

O impacto direto para uma organização moderna tende a ser baixo quando nenhuma raiz antiga está instalada e os serviços rejeitam certificados obsoletos. O impacto pode subir rapidamente em redes que preservam estações antigas, appliances sem atualização, terminais industriais ou aplicações que carregam um arquivo próprio de CAs. Nesses casos, uma chave fatorada pode ajudar a produzir certificados que o cliente legado reconhece como legítimos.

Um certificado falsificado em um ambiente que o aceita pode permitir personificação de um serviço, interceptação de conexões ou assinatura de conteúdo. A consequência depende do que o cliente protege, de como válida o certificado e de quais dados trafegam no canal. Não é correto afirmar que esses efeitos ocorreram no caso publicado sem evidência de um ambiente afetado.

Há também consequências de governança. Uma organização que não sabe quais raízes confia não consegue responder rapidamente quando uma CA é aposentada ou quando uma biblioteca muda sua política. O inventário de certificados deve fazer parte do gerenciamento de ativos, da continuidade e da resposta a incidentes, não ficar restrito ao time que renova certificados manualmente.

O resultado pode ainda expor dependências ocultas. A equipe pode descobrir que um dispositivo de teste usa a mesma imagem de uma estação produtiva, que uma aplicação embute certificados de uma década atrás ou que uma exceção de compatibilidade nunca foi revisada. Cada descoberta deve ser classificada pelo alcance real, com evidências de configuração e de uso.

A melhor consequência do experimento é transformar uma história curiosa em uma ação mensurável: localizar chaves fracas, eliminar confiança desnecessária, atualizar clientes e manter registros que provem qual cadeia está em produção.

Dicas práticas e boas práticas

Use o checklist abaixo para revisar criptografia legada sem interromper serviços de forma imprevista:

1. Liste certificados, chaves públicas e armazenamentos de confiança de servidores, proxies, aplicações, contêineres e appliances.
2. Identifique o tamanho e o algoritmo de cada chave, separando folhas, intermediárias e raízes.
3. Priorize RSA de 512 bits, CAs de teste e material expirado que ainda esteja instalado ou referenciado.
4. Confirme quais clientes realmente usam cada cadeia antes de remover uma raiz.
5. Planeje a troca por chaves e certificados compatíveis com a política atual e com o ciclo de vida do serviço.
6. Valide a cadeia no ambiente em execução, incluindo reinício, proxy, balanceador e consumidores de API.
7. Restrinja ou isole sistemas legados que não possam receber atualização imediata.
8. Trate chaves privadas publicadas em pesquisas como comprometidas, mesmo quando o contexto é histórico.
9. Adicione uma verificação automática para bloquear novos certificados fora do padrão aprovado.
10. Registre exceções, responsáveis, prazo de retirada e evidências de cada validação.

Na prática, a auditoria pode começar com relatórios do inventário de TLS e com a inspeção dos arquivos de certificado. Em seguida, compare os emissores encontrados com a lista de autoridades aprovadas. Não confie apenas na data de expiração: uma raiz antiga pode permanecer carregada e ser reativada por um software legado, e um certificado novo pode ter sido emitido com uma cadeia inesperada.

O repositório ancientroots, citado pelo autor, é útil para entender como o experimento foi organizado, mas qualquer reprodução deve ser feita em laboratório. A equipe não precisa baixar ou manipular chaves privadas históricas para corrigir sua infraestrutura. Basta provar que o ambiente não depende delas e substituir o material de confiança que não atende aos requisitos atuais.

Conclusão: o que fazer agora

A fatoração das chaves E-Certify de 512 bits não representa a quebra da criptografia RSA moderna. Ela demonstra, de forma concreta, que raízes antigas criadas para uma Web dos anos 1990 podem ser fatoradas com recursos de pesquisa disponíveis hoje. O exemplo do Netscape 4.51 é histórico, mas o padrão de risco continua presente sempre que uma organização mantém confiança legada sem saber onde ela é usada.

O próximo passo é fazer um inventário dos certificados e das raízes instaladas. Se aparecer RSA de 512 bits, CA de teste ou material expirado em um fluxo real, trate o achado como uma prioridade de hardening: confirme o impacto, substitua a cadeia, remova a confiança desnecessária e valide os clientes. Em ambientes que não podem ser atualizados, isole o serviço e documente uma data de retirada.

Segurança criptográfica não é apenas escolher um algoritmo no momento da implantação. É acompanhar o aumento da capacidade computacional, revisar os armazenamentos de confiança, retirar exceções antigas e confirmar que o artefato em execução corresponde ao que foi aprovado. A lição das chaves RSA de 512 bits é simples: confiança histórica não deve ser confundida com segurança atual.