Go obtiene la certificación FIPS 140-3

• El Certificado #5247 es una certificación CMVP para el Go Cryptographic Module y está registrado con estado Active bajo el estándar FIPS 140-3
• Go Cryptographic Module es una biblioteca de software que proporciona funciones criptográficas a la biblioteca estándar de Go y a otras aplicaciones de Go, y su nivel general de seguridad es Level 1
• La certificación aplica cuando se opera en approved mode, y la fecha de vencimiento figura como 26 de abril de 2031
• El historial de validación indica 27 de abril de 2026 Initial, y el laboratorio de pruebas es Lightship Security, Inc.
• El proveedor es Geomys LLC, el contacto responsable es Filippo Valsorda, y se ofrece como archivo relacionado la Security Policy

---

Resumen de la certificación

• El Certificado #5247 es una entrada de certificación del Cryptographic Module Validation Program (CMVP) para el Go Cryptographic Module
• El estándar es FIPS 140-3, el estado es Active y el nivel general de seguridad está registrado como Level 1
• La fecha de vencimiento figura como 26 de abril de 2031
• El historial de validación indica 27 de abril de 2026 Initial, y el laboratorio de pruebas es Lightship Security, Inc.

Información del módulo

• El Go Cryptographic Module es una biblioteca de software que proporciona funciones criptográficas a la biblioteca estándar de Go y a otras aplicaciones de Go
• El tipo de módulo es Software y el embodiment figura como MultiChipStand
• Las excepciones del nivel de seguridad están registradas como Physical security: N/A, Non-invasive security: N/A

Condiciones y limitaciones de operación

• La certificación aplica cuando se opera en approved mode
• Se especifica que no hay garantía mínima de resistencia para los SSP generados, por ejemplo las claves
• Se especifica que no hay garantía mínima de seguridad para los SSP cargados externamente, por ejemplo claves y cadenas de bits, o para los SSP configurados como SSP cargados externamente

Proveedor y archivos relacionados

• Geomys LLC está registrado como proveedor, y la dirección es 9450 SW Gemini Dr PMB 52960, Beaverton, OR 97008, United States
• El contacto responsable figura como Filippo Valsorda
• La Security Policy se ofrece como archivo relacionado

[GN⁺]

Comentarios en Lobste.rs

• Fue un camino bastante largo. Los detalles están en la publicación del año pasado, y pronto debería salir una nueva entrada sobre el certificado.
  Como siempre, si no sabes si necesitas FIPS 140-3, entonces probablemente no lo necesitas; pero si de verdad lo necesitas, estoy bastante seguro de que Go es una de las formas más fáciles y seguras de lograrlo. Fue especialmente difícil mantener la seguridad y la facilidad de uso que ofrecíamos a los demás usuarios mientras también cumplíamos con las reglas de FIPS 140-3, pero creo que lo resolvieron bastante bien

  • Manejo despliegues grandes de bring-your-own-cloud donde se requiere cumplimiento de FIPS en ciertos entornos de clientes y, por desgracia, no usamos Go en absoluto. Este cambio podría convertirse en el motivo para adoptarlo

• ¿Go no usa BoringSSL? Me da curiosidad cómo certificaron eso para FIPS

  • No, esa era la solución anterior. El nuevo enfoque es una implementación pura en Go, así que no necesita CGO: https://go.dev/blog/fips140
  • Hasta ahora, el cumplimiento de FIPS era posible usando el árbol de fuentes de BoringSSL pero compilándolo para que coincidiera con OpenSSL. OpenSSL sí está en cumplimiento, Red Hat lo hace así en RHEL y nosotros dependemos de ese método para todas las cargas de trabajo. Básicamente es como https://github.com/golang-fips/go
    Este nuevo enfoque es completamente Go nativo. Ya no depende de OpenSSL ni de otros rodeos; simplemente se resuelve con la biblioteca estándar

• Me pregunto qué efectos reales va a tener esto. ¿Ahora Go se vuelve una opción más atractiva para algunas empresas u organizaciones, o es un cambio puramente relacionado con seguridad?

  • Desde el punto de vista de la seguridad es un retroceso, pero permite usarlo en algunos entornos gubernamentales
  • Ahora los contratistas del complejo militar-industrial de EE. UU. podrán contratar a más programadores de Go y entregar software construido sobre esa base
  • En general, con cautela diría que es algo negativo para la seguridad. No se pueden usar cifrados modernos como (X)ChaCha20-Poly1305
  • Nuestra empresa ofrece tanto productos comerciales como productos para gobierno, y para estos últimos FIPS es un requisito obligatorio. En el lado de Go dependemos de que Red Hat lo resuelva correctamente, y el resultado es un binario que puede usarse en cualquier entorno

• Bien. Antes desplegué usando el build de Go con FIPS de Red Hat, y nunca me gustó que para cumplir con FIPS hubiera que usar una versión distinta de toda la pila de Go
  Muchos productos que se venden al gobierno de EE. UU. requieren usar FIPS, y como no quieren crear versiones separadas con y sin FIPS, esto tiene mucho peso para que las empresas puedan adoptar Go