Quando uma entidade local assina um documento online ou verifica a identidade de um agente em um portal interno, ela se apoia em blocos de software muitas vezes invisíveis. O CAPICOM foi por muito tempo um desses blocos, integrado em aplicações Windows sem que os usuários finais suspeitassem de sua existência. Seu papel: gerenciar certificados digitais, criptografar dados e aplicar assinaturas eletrônicas através de algumas linhas de código.
O problema é que a Microsoft oficialmente descontinuou o CAPICOM e parou todas as atualizações, colocando as administrações locais diante de um ponto cego técnico.
Assinatura eletrônica e certificados: o que o CAPICOM fazia concretamente
Antes de falar sobre substituição, um desvio pelo funcionamento ajuda a entender a magnitude do assunto. O CAPICOM é uma biblioteca COM (Component Object Model) que permitia aos desenvolvedores integrar funções criptográficas em aplicações Windows sem manipular diretamente as camadas de baixo nível do sistema.
Na prática, isso proporcionava três capacidades principais:
- Validar e gerenciar certificados digitais armazenados no repositório do Windows, por exemplo, para autenticar um agente acessando um teleserviço.
- Assinar eletronicamente documentos ou fluxos de dados, garantindo sua integridade e a identidade do signatário.
- Criptografar e descriptografar informações sensíveis trocadas entre serviços, como documentos de estado civil transmitidos entre uma prefeitura e uma delegacia.
Para uma entidade, essas funções afetavam processos concretos: desmaterialização de contratos públicos, transmissão de documentos para os serviços do Estado, autenticação em portais de negócios. O CAPICOM frequentemente era executado através de controles ActiveX no Internet Explorer, o que explica por que seu uso permaneceu invisível por muito tempo nos navegadores modernos.
Numerosos recursos detalham capicom e seus usos na Coletividade Digital, o que permite medir o quanto essa biblioteca se entrelaçou em cadeias aplicativas variadas.
Obsolescência do CAPICOM: riscos reais para as entidades locais
A Microsoft não distribui mais o CAPICOM nas versões recentes do Windows e recomenda explicitamente a migração para CryptoAPI, CNG (Cryptography API: Next Generation) ou as classes .NET. Não se trata de uma simples mudança de versão: é uma interrupção definitiva do suporte.
Por que isso representa um verdadeiro problema para as entidades? Porque uma biblioteca sem correções de segurança se torna uma porta de entrada para ataques. Cada vulnerabilidade descoberta após o fim do suporte permanece aberta, sem patch.
Conformidade regulatória fragilizada
As entidades manipulam dados pessoais de cidadãos (estado civil, assistência social, tributação local). Utilizar um componente criptográfico obsoleto fragiliza a conformidade com o RGPD, uma vez que o regulamento exige medidas técnicas adequadas ao estado da arte. Uma ferramenta abandonada por seu editor não atende mais a essa exigência.
Os referenciais da ANSSI e a doutrina de nuvem do Estado seguem na mesma direção: as soluções digitais dos serviços públicos devem se basear em componentes mantidos, auditados e, se possível, soberanos. O CAPICOM não atende mais a nenhum desses critérios.
Dependência do Internet Explorer
Muitas implementações do CAPICOM passavam por controles ActiveX, tecnologia vinculada ao Internet Explorer. No entanto, a Microsoft encerrou o suporte ao Internet Explorer. As entidades que ainda não migraram suas aplicações web internas se encontram com uma dupla obsolescência: navegador e biblioteca criptográfica.
Migração para CryptoAPI e .NET: por onde começar
A migração não é uma simples substituição de arquivo DLL. Ela pressupõe identificar todas as aplicações que chamam o CAPICOM e, em seguida, reescrever as partes de código envolvidas. Aqui estão as etapas concretas que isso implica.
Começar com um inventário completo das aplicações. Cada serviço (urbanismo, finanças, recursos humanos) pode utilizar softwares de negócios que incorporam o CAPICOM sem que o serviço de TI tenha conhecimento. Pesquisar as chamadas à DLL capicom.dll no parque de aplicações é o ponto de partida.
Em seguida, a escolha da tecnologia de substituição depende do contexto:
- CryptoAPI é adequada para aplicações C/C++ que permanecem em ambiente Windows nativo. Ela oferece acesso direto ao repositório de certificados do sistema.
- CNG (Cryptography API: Next Generation) traz algoritmos mais recentes e uma arquitetura modular. É a opção recomendada para novos desenvolvimentos.
- As classes System.Security.Cryptography do .NET são adequadas para aplicações desenvolvidas em C# ou VB.NET, frequentemente o caso das ferramentas de negócios internas das entidades.
Cada substituição deve ser testada em um ambiente isolado antes do deployment, pois a mudança da biblioteca criptográfica pode modificar o formato das assinaturas geradas e tornar ilegíveis documentos já assinados.
Alternativas soberanas e suítes digitais públicas
A questão não se limita à substituição técnica do CAPICOM. Nos últimos anos, as políticas públicas francesas incentivam a adoção de soluções digitais livres ou controladas para as entidades. A DINUM propõe LaSuite, um ecossistema de aplicações colaborativas baseado em softwares livres, hospedados na França.
LaSuite não substitui diretamente o CAPICOM (não é uma biblioteca criptográfica), mas ilustra a direção tomada: priorizar ferramentas cujo código fonte é auditável e a hospedagem é soberana. Para a camada de assinatura eletrônica, prestadores qualificados pela ANSSI oferecem serviços em conformidade com o regulamento eIDAS, sem depender de componentes proprietários abandonados.
As entidades que aproveitam a migração para repensar sua arquitetura de assinatura ganham em dois aspectos: eliminam uma dívida técnica e se alinham aos referenciais atuais de segurança.
A descontinuação do CAPICOM não é um incidente menor. Para as entidades que ainda o utilizavam, cada mês sem migração aumenta a exposição a falhas não corrigidas. O inventário das aplicações continua sendo a primeira ação útil, mesmo antes de escolher entre CryptoAPI, CNG ou .NET. E, uma vez que o quadro regulatório francês empurra em direção a soluções abertas e soberanas, é também a oportunidade de não reproduzir a mesma dependência de um único editor.