Go recebe certificação FIPS 140-3

• Certificate #5247 é a certificação CMVP para o Go Cryptographic Module e está registrado como Active no padrão FIPS 140-3
• O Go Cryptographic Module é uma biblioteca de software que fornece recursos criptográficos para a biblioteca padrão do Go e outras aplicações Go, e o nível geral de segurança é Level 1
• A certificação se aplica quando operado em approved mode, e a Sunset Date está indicada como 26 de abril de 2031
• O histórico de validação é 27 de abril de 2026 Initial, e o laboratório de testes é Lightship Security, Inc.
• O fornecedor é Geomys LLC, o contato responsável é Filippo Valsorda, e o arquivo relacionado Security Policy é fornecido

---

Visão geral da certificação

• Certificate #5247 é um item de certificação do Cryptographic Module Validation Program (CMVP) para o Go Cryptographic Module
• O padrão é FIPS 140-3, o status é Active e o nível geral de segurança está registrado como Level 1
• A Sunset Date está indicada como 26 de abril de 2031
• O histórico de validação é 27 de abril de 2026 Initial, e o laboratório de testes é Lightship Security, Inc.

Informações do módulo

• Go Cryptographic Module é uma biblioteca de software que fornece recursos criptográficos para a biblioteca padrão do Go e outras aplicações Go
• O Module Type é Software e o Embodiment está indicado como MultiChipStand
• As exceções de nível de segurança estão registradas como Physical security: N/A, Non-invasive security: N/A

Condições operacionais e limitações

• A certificação se aplica quando operado em approved mode
• Para SSPs gerados, como chaves, está especificado que não há garantia mínima de robustez
• Para SSPs carregados externamente, como chaves e cadeias de bits, ou SSPs configurados como SSPs carregados externamente, está especificado que não há garantia mínima de segurança

Fornecedor e arquivos relacionados

• Geomys LLC está registrada como fornecedora, e o endereço é 9450 SW Gemini Dr PMB 52960, Beaverton, OR 97008, United States
• O contato responsável está indicado como Filippo Valsorda
• Security Policy é fornecido como arquivo relacionado

[GN⁺]

Comentários do Lobste.rs

• Foi uma jornada bem longa. Dá para ver os detalhes neste post do ano passado, e um novo post sobre o certificado deve sair em breve
  Como sempre, se você não sabe se precisa de FIPS 140-3, então não precisa; mas, se realmente precisa, estou bem confiante de que Go é uma das formas mais fáceis e seguras de chegar lá. Foi especialmente difícil manter a segurança e a praticidade oferecidas aos outros usuários ao mesmo tempo em que se seguiam as regras do FIPS 140-3, mas acho que isso foi feito muito bem

  • Estamos lidando com implantações grandes de bring-your-own-cloud em ambientes de clientes específicos que exigem conformidade com FIPS, mas infelizmente não usamos Go de forma alguma. Essa mudança pode acabar sendo um motivo para adotar Go

• Go não usa BoringSSL? Fico curioso sobre como isso foi certificado para FIPS

  • Não, essa era a solução anterior. O novo método é uma implementação pura em Go, então não precisa de CGO: https://go.dev/blog/fips140
  • Hoje, era possível ter conformidade com FIPS usando a árvore de código-fonte do BoringSSL, mas compilando de forma compatível com OpenSSL. O OpenSSL está em conformidade, a Red Hat faz isso no RHEL e nós também dependemos desse método em todas as cargas de trabalho. Basicamente, é algo como https://github.com/golang-fips/go
    Esse novo método é totalmente nativo em Go. Não é mais OpenSSL nem outro tipo de gambiarra; agora isso é resolvido simplesmente pela biblioteca padrão

• Fico curioso sobre que resultados isso vai trazer na prática. Será que agora Go vira uma opção mais atraente para algumas empresas ou organizações, ou isso é apenas uma mudança ligada à segurança?

  • Em termos de segurança, é um retrocesso, mas permite uso em alguns ambientes governamentais
  • Agora, contratadas do complexo industrial-militar dos EUA podem contratar mais programadores Go e entregar software com essa base
  • No geral, eu diria com cautela que isso é mais negativo do que positivo para a segurança. É porque não dá para usar cifras modernas como (X)ChaCha20-Poly1305
  • Nossa empresa fornece produtos comerciais e também produtos para o governo, e para estes últimos o FIPS é uma exigência obrigatória. Do lado de Go, dependemos de a Red Hat fazer isso corretamente, e o resultado é um binário que pode ser usado em qualquer ambiente

• Ótimo. Já fiz implantações antes usando builds de Go com FIPS da Red Hat, e eu nunca gostei do fato de que, para atender ao FIPS, era preciso usar uma versão diferente de toda a stack Go
  Muitos produtos vendidos ao governo dos EUA exigem uso de FIPS, e como as empresas não querem criar versões separadas com FIPS e sem FIPS, isso tem grande importância para viabilizar a adoção de Go por elas