Estrutura das implementações FIPS 140-2 e FIPS 140-3 na biblioteca criptográfica padrão do Go

FIPS 140 ( Federal Information Processing Standard Publication 140 )

FIPS 140 é um padrão de certificação de segurança de módulos criptográficos estabelecido pelo NIST dos Estados Unidos. Este padrão avalia se um módulo criptográfico ou biblioteca específica atende aos requisitos de segurança definidos pelo NIST. Portanto, ser aprovado na certificação FIPS 140 significa que o módulo em questão possui segurança oficialmente confiável, e que ele pode ser utilizado em áreas onde a segurança é crítica, como finanças, saúde e defesa.

Desde o seu estabelecimento inicial em 1994, o FIPS 140 foi revisado para o FIPS 140-2 em 2001 e para o FIPS 140-3 em 2019. Até o momento, muitos sistemas e aplicações continuam exigindo a certificação FIPS 140-2 ou FIPS 140-3.

FIPS 140 e linguagens de programação

Por esta razão, os módulos criptográficos certificados pelo FIPS 140 são utilizados como um padrão de fato em várias linguagens de programação e ambientes. Entre os exemplos representativos estão OpenSSL, BoringSSL, LibreSSL e NSS, sendo estes os módulos mais amplamente utilizados em aplicações sensíveis à segurança.

A maioria dos módulos certificados pelo FIPS 140 é escrita em C ou C++. Por esse motivo, em linguagens como PHP, Python e Javascript, em vez de usar esses módulos diretamente, o ambiente FIPS é configurado por meio de módulos Provider externos. No entanto, essa abordagem apresenta algumas limitações.

• Problema de discrepância de versões

  A certificação FIPS 140 é concedida apenas para versões específicas. Portanto, para usar a versão mais recente de um módulo, é necessário passar pelo processo de certificação novamente, e, durante esse processo, pode ocorrer uma discrepância de versões entre o módulo utilizado pela aplicação e o módulo certificado pelo FIPS. Se uma versão não autorizada for utilizada, o ambiente em questão deixa de ser considerado um ambiente certificado pelo FIPS.

• Carregamento dinâmico e degradação de desempenho

  A maioria das linguagens carrega e utiliza os módulos certificados pelo FIPS 140 na forma de bibliotecas dinâmicas. Esse método pode causar degradação de desempenho durante os processos de inicialização e execução, além de apresentar o risco de afetar diretamente a estabilidade geral da aplicação caso ocorra algum problema em tempo de execução.

• Vulnerabilidades de segurança

  Como mencionado anteriormente, na estrutura de integração de módulos externos, como o OpenSSL Provider, existe o risco de que as vulnerabilidades de segurança desses módulos sejam propagadas diretamente para a aplicação. Além disso, a própria camada de comunicação entre a aplicação e o módulo externo torna-se uma superfície de ataque adicional, exigindo uma camada de segurança separada para protegê-la. Isso aumenta a complexidade e pode gerar vulnerabilidades inesperadas.

FIPS 140 e Golang

Por esses motivos, o Golang adotou uma estratégia diferente. O Go optou por um método em que o suporte ao FIPS 140 é fornecido diretamente por sua biblioteca criptográfica oficial, sem depender de ferramentas externas. Portanto, os desenvolvedores não precisam instalar ou configurar um Provider separado; basta utilizar o pacote crypto padrão e ativar o modo de certificação FIPS (GOFIPS=1). Nesse processo, o limite de comunicação com módulos externos é removido, o que reforça a segurança, e a operação é simplificada, pois apenas um único binário compilado estaticamente precisa ser distribuído.

FIPS 140-2 e Golang

Para isso, o Golang integrou o módulo BoringCrypto, derivado do BoringSSL, no runtime do Go para obter a certificação FIPS 140-2. O BoringCrypto pode ser ativado em distribuições específicas a partir da versão Go 1.19, permitindo que aplicações Go configurem um ambiente com certificação FIPS 140-2 sem a necessidade de módulos externos adicionais.

No entanto, como o BoringCrypto é baseado no OpenSSL, ainda existe uma dependência da linguagem C. Consequentemente, as aplicações Go não são construídas como binários totalmente independentes, havendo a restrição de que as bibliotecas C necessárias devem ser distribuídas juntamente com a aplicação.

FIPS 140-3 e Golang

Para superar essas limitações, a equipe do Go aprimorou a biblioteca crypto padrão existente para atender às especificações do FIPS 140-3. Este módulo aprimorado começou a ser disponibilizado de forma experimental a partir da versão Go 1.21, e a avaliação para a certificação FIPS 140-3 pelo NIST está atualmente em Andamento.Lista de módulos em processo de avaliação FIPS 140-3 do NIST

Isso demonstra a maturidade da biblioteca criptográfica do Go, permitindo que a linguagem forneça um ambiente certificado pelo FIPS 140-3 por meio de um único binário totalmente independente.

Além disso, a equipe do Go não se limitou a cumprir o padrão FIPS 140-3, tendo também fortalecido a segurança por iniciativa própria.

• Fail Fast

  O modo FIPS do Go aplica o modelo de segurança Fail Fast, interrompendo a execução imediatamente com um panic caso um algoritmo não certificado seja chamado. Ao contrário dos modelos baseados em Provider de outras linguagens, que deixam a possibilidade de fallback, isso oferece uma garantia mais rigorosa e clara em termos de segurança e conformidade regulatória.

• Hedged Signature

  O padrão FIPS 140-3 recomenda o método RFC6979 ao realizar assinaturas ECDSA. No entanto, o Go vai além ao introduzir o método Hedged, oferecendo uma resposta mais robusta contra ataques de canal lateral que podem ocorrer durante o processo de assinatura.

• Gerador de números aleatórios aprimorado

  O gerador de números aleatórios do Go utiliza um DRBG (Deterministic Random Bit Generator) em espaço de usuário, injetando adicionalmente entropia do kernel do sistema operacional. Com isso, gera números aleatórios de alta qualidade tanto no espaço de usuário quanto no espaço do kernel. Isso reforça ainda mais a segurança do gerador de números aleatórios.