Go erhält die FIPS-140-3-Zertifizierung

• Certificate #5247 ist die CMVP-Zertifizierung für das Go Cryptographic Module und im Standard FIPS 140-3 mit dem Status Active registriert
• Das Go Cryptographic Module ist eine Softwarebibliothek, die kryptografische Funktionen für die Go-Standardbibliothek und andere Go-Anwendungen bereitstellt; das gesamte Sicherheitsniveau ist Level 1
• Die Zertifizierung gilt beim Betrieb im approved mode; als Sunset Date ist der 26. April 2031 angegeben
• Die Validierungshistorie lautet 27. April 2026 Initial, das Prüflabor ist Lightship Security, Inc.
• Als Anbieter ist Geomys LLC eingetragen, Ansprechpartner ist Filippo Valsorda; als zugehörige Datei wird die Security Policy bereitgestellt

---

Überblick über die Zertifizierung

• Certificate #5247 ist ein Zertifizierungseintrag des Cryptographic Module Validation Program (CMVP) für das Go Cryptographic Module
• Der Standard ist FIPS 140-3, der Status Active, das gesamte Sicherheitsniveau ist Level 1
• Als Sunset Date ist der 26. April 2031 angegeben
• Die Validierungshistorie lautet 27. April 2026 Initial, das Prüflabor ist Lightship Security, Inc.

Modulinformationen

• Das Go Cryptographic Module ist eine Softwarebibliothek, die kryptografische Funktionen für die Go-Standardbibliothek und andere Go-Anwendungen bereitstellt
• Der Module Type ist Software, die Embodiment-Klasse ist MultiChipStand
• Bei den Security Level Exceptions sind Physical security: N/A und Non-invasive security: N/A eingetragen

Betriebsbedingungen und Einschränkungen

• Die Zertifizierung gilt beim Betrieb im approved mode
• Für erzeugte SSPs, etwa Schlüssel, ist ausdrücklich keine Garantie einer Mindeststärke angegeben
• Für extern geladene SSPs, etwa Schlüssel und Bitfolgen, oder SSPs, die als extern geladene SSPs festgelegt sind, ist ausdrücklich keine minimale Sicherheitsgarantie angegeben

Anbieter und zugehörige Dateien

• Geomys LLC ist als Anbieter eingetragen; die Adresse lautet 9450 SW Gemini Dr PMB 52960, Beaverton, OR 97008, United States
• Als Ansprechpartner ist Filippo Valsorda angegeben
• Die Security Policy wird als zugehörige Datei bereitgestellt

[GN⁺]

Lobste.rs-Kommentare

• Das war ein ziemlich langer Weg. Details dazu gibt es im Beitrag vom letzten Jahr, und ein neuer Artikel zum Zertifikat soll bald erscheinen.
  Wie immer gilt: Wenn man nicht weiß, ob man FIPS 140-3 braucht, dann braucht man es wahrscheinlich nicht. Aber wenn man es wirklich braucht, bin ich ziemlich sicher, dass Go eine der einfachsten und sichersten Möglichkeiten ist, das zu erreichen. Besonders schwierig war es, die Regeln von FIPS 140-3 einzuhalten und zugleich die Sicherheit und Benutzerfreundlichkeit beizubehalten, die wir anderen Nutzern bisher geboten haben, aber ich denke, das ist ziemlich gut gelungen.

  • Ich arbeite mit groß angelegten Bring-your-own-Cloud-Deployments, bei denen in bestimmten Kundenumgebungen FIPS-Compliance erforderlich ist, und leider verwenden wir überhaupt kein Go. Diese Änderung könnte ein Anlass sein, Go einzuführen.

• Verwendet Go nicht BoringSSL? Ich frage mich, wie das FIPS-zertifiziert wurde.

  • Nein, das war die frühere Lösung. Der neue Ansatz ist eine reine Go-Implementierung, daher ist kein CGO erforderlich: https://go.dev/blog/fips140
  • Bisher war FIPS-Compliance möglich, indem man den BoringSSL-Source-Tree verwendet, aber passend zu OpenSSL kompiliert. OpenSSL ist konform, Red Hat macht das in RHEL so, und wir verlassen uns bei allen Workloads auf diesen Ansatz. Im Grunde ist das so wie bei https://github.com/golang-fips/go
    Dieser neue Ansatz ist vollständig natives Go. Es braucht weder OpenSSL noch andere Umwege, sondern wird einfach mit der Standardbibliothek gelöst.

• Ich frage mich, welche konkreten Folgen das haben wird. Wird Go jetzt für manche Unternehmen oder Organisationen attraktiver, oder ist das rein eine sicherheitsbezogene Änderung?

  • Aus Sicherheitssicht ist es ein Downgrade, aber es ermöglicht den Einsatz in einigen staatlichen Umgebungen.
  • Jetzt können Auftragnehmer des militärisch-industriellen Komplexes der USA mehr Go-Programmierer einstellen und auf dieser Basis Software liefern.
  • Insgesamt ist es für die Sicherheit wohl eher ein Nachteil. Moderne Chiffren wie (X)ChaCha20-Poly1305 können nämlich nicht verwendet werden.
  • Unser Unternehmen bietet sowohl kommerzielle Produkte als auch Produkte für Behörden an, und für Letztere ist FIPS eine zwingende Anforderung. Bei Go verlassen wir uns darauf, dass Red Hat das korrekt handhabt, und als Ergebnis erhalten wir Binärdateien, die in jeder Umgebung eingesetzt werden können.

• Gut so. Ich habe früher FIPS-Go-Builds von Red Hat für Deployments verwendet, und es hat mir nie gefallen, dass man zur Einhaltung von FIPS den gesamten Go-Stack in einer anderen Version verwenden musste.
  Für viele Produkte, die an die US-Regierung verkauft werden, ist die Verwendung von FIPS vorgeschrieben, und weil man keine getrennten FIPS- und Nicht-FIPS-Versionen bauen möchte, ist das ein großer Schritt dafür, dass Unternehmen Go einführen können.