Struktur der FIPS 140-2- und FIPS 140-3-Implementierungen in der kryptografischen Standardbibliothek von Go

FIPS 140 ( Federal Information Processing Standard Publication 140 )

FIPS 140 ist ein vom US-amerikanischen NIST erlassener Standard für die Sicherheitszertifizierung von Kryptografiemodulen. Dieser Standard bewertet, ob ein bestimmtes Kryptografiemodul oder eine bestimmte Kryptobibliothek die vom NIST definierten Sicherheitsanforderungen erfüllt. Folglich bedeutet das Bestehen der FIPS 140-Zertifizierung, dass das entsprechende Modul über offiziell vertrauenswürdige Sicherheit verfügt und in sicherheitskritischen Bereichen wie dem Finanzwesen, dem Gesundheitswesen und der Verteidigung eingesetzt werden kann.

Seit seiner Erstveröffentlichung im Jahr 1994 wurde FIPS 140 im Jahr 2001 zu FIPS 140-2 und im Jahr 2019 zu FIPS 140-3 revidiert. Bis heute fordern zahlreiche Systeme und Anwendungen die Zertifizierung nach FIPS 140-2 oder FIPS 140-3.

FIPS 140 und Programmiersprachen

Aus diesem Grund werden nach FIPS 140 zertifizierte Kryptografiemodule in verschiedenen Programmiersprachen und Umgebungen wie ein De-facto-Standard verwendet. Repräsentative Beispiele hierfür sind OpenSSL, BoringSSL, LibreSSL und NSS, bei denen es sich um die am weitesten verbreiteten Module in sicherheitskritischen Anwendungen handelt.

Die Mehrheit der FIPS 140-zertifizierten Module ist in C oder C++ geschrieben. Aus diesem Grund konfigurieren Sprachen wie PHP, Python und Javascript die FIPS-Umgebung nicht durch direkte Verwendung dieser Module, sondern durch die Anbindung über externe Provider-Module. Dieser Ansatz birgt jedoch einige Einschränkungen.

• Versionsinkonsistenz

  Die FIPS 140-Zertifizierung wird nur für bestimmte Versionen vergeben. Um folglich die neueste Version eines Moduls zu verwenden, muss der Zertifizierungsprozess erneut durchlaufen werden, wobei es zu einer Versionsinkonsistenz zwischen dem von der Anwendung verwendeten Modul und dem FIPS-zertifizierten Modul kommen kann. Werden nicht autorisierte Versionen verwendet, gilt die betreffende Umgebung nicht länger als FIPS-zertifizierte Umgebung.

• Dynamisches Laden und Leistungseinbußen

  Die meisten Sprachen laden und verwenden FIPS 140-zertifizierte Module in Form dynamischer Bibliotheken. Diese Methode kann während der Initialisierungs- und Ausführungsphase zu Leistungseinbußen führen, und es besteht das Risiko, dass sich auftretende Laufzeitprobleme direkt auf die Stabilität der gesamten Anwendung auswirken.

• Sicherheitslücken

  Wie bereits erwähnt, besteht bei Strukturen, die externe Module wie den OpenSSL-Provider einbinden, das Risiko, dass Sicherheitslücken dieser Module direkt auf die Anwendung übertragen werden. Darüber hinaus stellt die Kommunikationsschicht selbst zwischen der Anwendung und dem externen Modul eine zusätzliche Angriffsfläche dar, weshalb eine separate Sicherheitsschicht zu deren Schutz erforderlich ist. Dies erhöht die Komplexität und kann unerwartete Schwachstellen hervorrufen.

FIPS 140 und Golang

Aus diesen Gründen verfolgte Golang eine andere Strategie. Go entschied sich für einen Ansatz, bei dem die FIPS 140-Zertifizierung nicht von externen Werkzeugen abhängig ist, sondern direkt von der offiziellen Kryptografiebibliothek unterstützt wird. Daher müssen Entwickler kein separates Provider-Modul installieren oder konfigurieren; sie können stattdessen das Standard-Crypto-Paket unverändert verwenden und lediglich den FIPS-Zertifizierungsmodus (GOFIPS=1) aktivieren. Bei diesem Prozess entfällt die Kommunikationsgrenze zu externen Modulen, wodurch die Sicherheit erhöht wird, und da nur ein statisch kompilierter Binärcode bereitgestellt werden muss, vereinfacht sich auch der Betrieb.

FIPS 140-2 und Golang

Zu diesem Zweck hat Golang das von BoringSSL abgeleitete BoringCrypto-Modul in die Go-Laufzeitumgebung integriert und die FIPS 140-2-Zertifizierung erlangt. BoringCrypto kann ab der Go-Version 1.19 in bestimmten Distributionen aktiviert werden, wodurch Go-Anwendungen eine FIPS 140-2-zertifizierte Umgebung ohne separate externe Module konfigurieren können.

Da BoringCrypto jedoch auf OpenSSL basiert, besteht nach wie vor eine C-Sprachabhängigkeit. Folglich werden Go-Anwendungen nicht als vollständig unabhängige Binärdateien erstellt, und es bestanden Einschränkungen hinsichtlich der gemeinsamen Bereitstellung der erforderlichen C-Bibliotheken.

FIPS 140-3 und Golang

Um diese Einschränkungen zu überwinden, hat das Go-Team die bestehende Go-Standard-Crypto-Bibliothek entsprechend den Spezifikationen von FIPS 140-3 verbessert. Dieses optimierte Modul ist seit Go-Version 1.21 experimentell verfügbar, und die Zertifizierungsprüfung für FIPS 140-3 durch das NIST ist derzeit im Gange.Liste der Module im Zertifizierungsprozess für NIST FIPS 140-3

Dies demonstriert den Reifeegrad der Go-Kryptografiebibliothek, wodurch Go in der Lage ist, eine FIPS 140-3-zertifizierte Umgebung als vollständig unabhängige, einzelne Binärdatei bereitzustellen.

Darüber hinaus hat das Go-Team nicht nur die FIPS 140-3-Standards erfüllt, sondern auch die eigene Sicherheit gestärkt.

• Fail Fast

  Der FIPS-Modus von Go wendet das Sicherheitsmodell „Fail Fast“ an und stoppt die Ausführung bei Aufruf eines nicht zertifizierten Algorithmus sofort durch einen Panic. Im Gegensatz zu Provider-basierten Modellen anderer Sprachen, die die Möglichkeit eines Fallbacks offenlassen, bietet dies eine strengere und eindeutigere Gewährleistung hinsichtlich Sicherheit und regulatorischer Compliance.

• Hedged Signature

  Der FIPS 140-3-Standard empfiehlt die Methode nach RFC6979 für ECDSA-Signaturen. Go führt darüber hinaus jedoch die Hedged-Methode ein, um noch wirksamer auf Seitenkanalangriffe zu reagieren, die während des Signaturprozesses auftreten können.

• Verbesserter Zufallszahlengenerator

  Der Zufallszahlengenerator von Go verwendet einen deterministischen Zufallszahlengenerator im Benutzerraum (User-Space DRBG) und speist gleichzeitig zusätzliche Entropie aus dem Betriebssystemkernel ein, wodurch qualitativ hochwertige Zufallszahlen nicht nur im Benutzerraum, sondern auch im Kernelraum generiert werden. Dadurch wird die Sicherheit des Zufallszahlengenerators weiter erhöht.?