Auditoria e Seleção de Dependências Criptográficas

A biblioteca criptográfica escolhida é uma das decisões de segurança mais importantes de um projeto. Mesmo desenvolvedores bem-intencionados que usam uma biblioteca inadequada podem produzir sistemas inseguros. Por outro lado, uma biblioteca bem projetada dificulta a ocorrência de erros catastróficos. O processo de seleção deve ser sistemático, avaliando o histórico de segurança, o projeto da API, o estado da manutenção e a adequação à finalidade.

Uma das primeiras perguntas sobre qualquer biblioteca criptográfica é quando ela foi auditada pela última vez de forma independente e o que essa auditoria abrangeu. Uma auditoria realizada há cinco anos na versão 1.0 oferece menos segurança para a versão 3.0 usada atualmente. Procure auditorias realizadas por empresas de segurança reconhecidas, como NCC Group, Trail of Bits, Quarkslab e Cure53, que cubram a funcionalidade específica que pretende utilizar. Algumas bibliotecas publicam os relatórios de auditoria; a ausência de qualquer auditoria é um fator de risco significativo.

Analise o histórico de CVEs da biblioteca no NVD (Banco de Dados Nacional de Vulnerabilidades). Verifique: quantas CVEs existem, suas classificações de gravidade, quais classes de vulnerabilidades elas representam, como erros de lógica, corrupção de memória ou fragilidades de algoritmos, e com que rapidez os mantenedores lançaram as correções. Uma biblioteca com CVEs ocasionais corrigidas prontamente demonstra uma manutenção responsiva. Uma biblioteca com muitas CVEs de alta gravidade ou correções lentas é um sinal de alerta.

Bibliotecas criptográficas sem manutenção são perigosas. Verifique a data da última alteração registrada, a frequência de lançamentos e se os avisos de segurança estão sendo tratados. Uma biblioteca cuja última alteração ocorreu há três anos pode ter vulnerabilidades conhecidas que nunca serão corrigidas. O tamanho da comunidade é importante para ampliar a revisão: bibliotecas amplamente utilizadas recebem mais atenção de pesquisadores de segurança do que projetos de nicho.

Uma superfície de API menor e mais opinativa é melhor para a segurança. Bibliotecas que expõem muitas opções de algoritmos e parâmetros de configuração criam oportunidades para configurações incorretas. Compare a libsodium, que oferece uma função por caso de uso com algoritmo fixo, com a OpenSSL EVP, na qual é preciso escolher separadamente a cifra, o modo, o tamanho da chave, o preenchimento e o tratamento do vetor de inicialização. Quanto mais difícil for usar uma biblioteca de forma incorreta, melhor ela será para projetos preocupados com a segurança.

Para operações que envolvem dados secretos, como comparação de chaves, descriptografia e verificação de assinaturas, a implementação deve usar algoritmos de tempo constante que não façam desvios nem acessem a memória com base em valores secretos. Verifique se a documentação da biblioteca declara explicitamente garantias de tempo constante para operações sensíveis ou se o código-fonte usa funções aprovadas de comparação em tempo constante. Bibliotecas sem essa garantia são vulneráveis a ataques de canal lateral baseados em tempo.

Uma boa biblioteca criptográfica deve oferecer suporte a algoritmos modernos e planejar a descontinuação dos que estão ultrapassados. Ela deve oferecer ChaCha20-Poly1305 ou AES-256-GCM para criptografia, Ed25519 ou ECDSA P-256 para assinaturas, X25519 para troca de chaves e Argon2id para derivação de chaves de senhas. Bibliotecas que oferecem apenas algoritmos antigos, como DES, RC4, MD5 e SHA-1, não são adequadas para novas implantações, independentemente de suas outras qualidades.

Avalie as dependências transitivas: de quais bibliotecas sua biblioteca criptográfica depende e qual é a postura de segurança delas? Uma biblioteca sem dependências externas, como a libsodium, apresenta risco mínimo para a cadeia de fornecimento. Uma biblioteca que depende de uma dúzia de pacotes npm, cada um com suas próprias dependências, tem uma grande superfície de ataque pela cadeia de fornecimento. Verifique se a biblioteca usa compilações reproduzíveis, permitindo confirmar que o binário distribuído corresponde ao código-fonte.

Setores regulamentados, como saúde, finanças e governo, frequentemente exigem módulos criptográficos validados segundo FIPS 140-2 ou 140-3. A validação FIPS é cara e demorada, portanto apenas uma parte das bibliotecas a possui. A OpenSSL com seu provedor FIPS, a BoringCrypto, usada em crypto/tls do Go, e algumas bibliotecas para HSM têm validação FIPS. Se sua implantação exigir conformidade com FIPS, esse requisito reduzirá significativamente suas opções de bibliotecas.

Os módulos de segurança de hardware (HSM) e os serviços KMS na nuvem frequentemente têm APIs proprietárias para operações com chaves. Acoplar estreitamente sua aplicação ao AWS KMS ou a um fornecedor específico de HSM cria risco de dependência. Avalie se a biblioteca fornece camadas de abstração, como a integração do Tink com KMS, que permitam trocar de provedor. Considere também que, se o fornecedor do HSM deixar de oferecer suporte ou aumentar os preços, os custos de migração poderão ser substanciais.

A regra mais importante ao selecionar dependências criptográficas é usar bibliotecas conhecidas e amplamente implantadas que implementem padrões estabelecidos, e nunca implementar primitivas criptográficas por conta própria. Independentemente de quão bem compreenda a teoria, implementar AES, RSA, operações de curvas elípticas ou criptografia autenticada corretamente em código de produção é extremamente difícil e quase nunca compensa o risco em comparação com o uso de uma biblioteca comprovada.

Lista de verificação para seleção de bibliotecas: verifique o escopo e o relatório de uma auditoria independente recente, analise o histórico de CVEs e o tempo de resposta às correções, confirme a manutenção ativa e o envolvimento da comunidade, prefira superfícies de API menores que resistam ao uso incorreto, confirme as garantias de tempo constante para operações sensíveis, assegure o suporte a algoritmos modernos, avalie as dependências da cadeia de fornecimento, verifique a validação FIPS quando o setor for regulamentado, considere o risco de dependência de fornecedores de KMS e use sempre bibliotecas estabelecidas em vez de implementar primitivas.