Skip to Content
Neue Version 12 verfügbar 🎉
LicensingFIPS-Konformität

FIPS-Konformität

Babel Licensing läuft auf Linux-Hosts im FIPS-Modus, und die Lizenzvalidierung verwendet keinen Algorithmus, den FIPS nicht zulässt. Diese Seite erklärt, wie sich die Bibliothek auf solchen Hosts verhält, welches Startproblem in Containern auftreten kann und wie Sie es beheben.

Hintergrund

Viele Kunden stellen auf Hosts bereit, deren Betriebssystem im FIPS-Modus läuft. Unter Linux ist das an /proc/sys/crypto/fips_enabled = 1 zu erkennen. In diesem Modus soll der Kryptografieanbieter der Plattform (OpenSSL unter Linux) jede kryptografische Operation über ein zertifiziertes FIPS-Modul ausführen.

Ein häufiges Problem entsteht, wenn ein Container das FIPS-Flag des Hosts erbt, sein Basisimage aber keinen zertifizierten OpenSSL-FIPS-Anbieter enthält. OpenSSL 3 versucht dann, in den FIPS-Modus zu wechseln, kann das Modul des FIPS-Anbieters nicht laden und gerät in einen fehlerhaften Zustand, in dem jede Hash- und Verschlüsselungsoperation fehlschlägt, nicht nur die, die FIPS normalerweise nicht zulässt. Der typische Fehler lautet:

Interop+Crypto+OpenSslCryptographicException: error:03000086:digital envelope routines::initialization error

Das ist ein Zustand der Umgebung, kein Fehler in Babel Licensing. Er ist unabhängig von Babel dokumentiert, siehe dotnet/dotnet-docker#5849  und dotnet/runtime#87884 . Er betrifft jede auf OpenSSL gestützte .NET-Kryptografie im Prozess, einschließlich TLS (HttpClient, gRPC), nicht nur die Lizenzvalidierung.

Wie sich das Problem bei der Lizenzvalidierung zeigt

Weil die gesamte OpenSSL-Schicht unbrauchbar ist, tritt der Fehler bei der ersten kryptografischen Operation auf, die beim Start ausgeführt wird. Hat eine Lizenz ein Ablaufdatum, öffnet Babel Licensing einen kleinen lokalen Speicher, mit dem es den Ablauf überwacht und eine zurückgestellte Systemuhr erkennt. Unter modernem .NET berechnet die Initialisierung des Speichers über den Anbieter der Plattform einen Identitätshash, und das löst auf einem Host mit defektem FIPS eine Ausnahme aus. Der Fehler wird so gemeldet:

Babel.Licensing.BabelLicenseException: Internal error ---> ...OpenSslCryptographicException: error:03000086:...

Härtung (Babel Licensing 11.7.x und höher). Der Lizenzspeicher wurde überarbeitet, sodass ein fehlerhafter Kryptografie-Stack der Plattform die Lizenzvalidierung nicht mehr scheitern lässt: Der Speicher weicht selbsttätig auf eine vollständig verwaltete Implementierung aus, und die Lizenzvalidierung arbeitet eingeschränkt weiter, statt fehlzuschlagen. Auf intakten Hosts bleibt das Verhalten unverändert. Wenden Sie bei früheren Builds die unten beschriebene Korrektur der Umgebung an.

Lösung in Containern

Machen Sie OpenSSL im Container nutzbar. Jede der beiden Optionen behebt das Symptom bei der Lizenzvalidierung und das Problem bei jeder anderen auf OpenSSL gestützten Operation in Ihrem Prozess.

Option 1: FIPS im Container nicht automatisch aktivieren

In .NET-Images auf Basis von Ubuntu beachtet OpenSSL die Umgebungsvariable OPENSSL_FORCE_FIPS_MODE. Setzen Sie sie auf 0, damit OpenSSL nicht versucht, mit einem Anbieter in den FIPS-Modus zu wechseln, den das Image nicht enthält.

Fügen Sie sie in docker-compose.yml zur Umgebung des Dienstes licensing hinzu:

environment: # Do not auto-enter FIPS mode using a provider the image doesn't ship OPENSSL_FORCE_FIPS_MODE: 0

oder in einem Dockerfile:

ENV OPENSSL_FORCE_FIPS_MODE=0

Verwenden Sie diese Option, wenn der Container selbst nicht FIPS-validiert sein muss: Der Host bleibt im FIPS-Modus, und nur OpenSSL in diesem Container verzichtet auf den fehlerhaften automatischen Wechsel in den FIPS-Modus.

Option 2: Basisimage mit zertifiziertem FIPS-Anbieter verwenden

Wenn die FIPS-Konformität im Container verlangt wird, verwenden Sie ein Basisimage mit einem validierten FIPS-Anbieter, damit die Kryptografieschicht korrekt initialisiert wird und nicht fehlschlägt:

  • .NET-Images für Azure Linux 3.0 (mcr.microsoft.com/dotnet/aspnet:8.0-azurelinux3.0 und ähnliche), die den FIPS-zertifizierten Anbieter SymCrypt von Microsoft enthalten,
  • .NET-Images auf Basis von Red Hat UBI 9 (registry.access.redhat.com/ubi9/dotnet-90 und ähnliche) oder
  • Ubuntu Pro mit den FIPS-zertifizierten OpenSSL-Paketen.

Babel Licensing Service auf Hosts im FIPS-Modus

Der Babel Licensing Service läuft auf Hosts im FIPS-Modus, sofern das Image tatsächlich ein Modul des FIPS-Anbieters enthält. Der gesamte Lizenz-Workflow wurde unter Azure Linux 3.0 mit erzwungenem FIPS geprüft. Die .NET-Images dieser Distribution enthalten den FIPS-zertifizierten Anbieter SymCrypt von Microsoft:

  • der Dienst startet und validiert seine eigene Lizenz,
  • Lizenzvorlagen und RSA-signierte Lizenzen werden erstellt,
  • Clients aktivieren und validieren Lizenzen über gRPC,
  • Gerätebindung, Aktivierungstoken, Lebenszeichen und Deaktivierung funktionieren.

Was geschieht, wenn das FIPS-Modul fehlt

Entscheidend ist nicht, ob „FIPS ein oder aus“ ist, sondern ob das Anbietermodul vorhanden ist, das der FIPS-Modus verlangt.

OpenSSL 3 implementiert die Algorithmen nicht selbst: Es lädt sie aus Anbietern, die als Plugins eingebunden werden. Im FIPS-Modus verlangt die Konfiguration, dass jeder Algorithmus aus dem zertifizierten FIPS-Anbieter stammt (dem Modul fips.so). Ist dieses Modul nicht im Image installiert, wie bei den Standard-.NET-Images für Debian und Ubuntu, kann OpenSSL keine Anfrage erfüllen. Dann schlägt jeder Algorithmus fehl, auch die, die FIPS selbst zulässt.

Da .NET unter Linux die gesamte Kryptografie an OpenSSL delegiert, fällt damit mehr aus als nur Hashing und Verschlüsselung:

.NET-OperationErgebnis, wenn fips.so fehlt
SHA256 / SHA1error:03000086 ...initialization error
Aeserror:0308010C ...unsupported
RandomNumberGeneratorerror:12000090 ...unable to fetch drbg

Weil selbst die Erzeugung von Zufallszahlen fehlschlägt, kann eine ASP.NET-Core-Anwendung überhaupt nicht starten, wenn sie auf einem solchen Host läuft: Sie benötigt beim Start Zufallswerte (Datenschutzschlüssel, TLS). Das betrifft jede ASP.NET-Core-Anwendung, nicht nur den Babel Licensing Service, und es ist eine Fehlkonfiguration der Umgebung: FIPS wird von einem Image verlangt, das es nicht bereitstellen kann. Beheben Sie das Problem mit Option 1 oder Option 2 oben.

Umgebung prüfen

Eine kurze Prüfung im Container zeigt, ob OpenSSL intakt ist:

# Fails on a broken-FIPS host, succeeds once fixed echo test | openssl dgst -sha1
  • Ein Fehler mit error:03000086 (oder eine Meldung, dass fips.so nicht geladen werden kann): OpenSSL ist im fehlerhaften Zustand. Wenden Sie Option 1 oder 2 an.
  • Eine normale Zeile SHA1(stdin)= ...: OpenSSL ist intakt, und Babel Licensing läuft normal.

Auch mit der Härtung der Lizenzvalidierung empfehlen wir, die OpenSSL-Umgebung trotzdem zu korrigieren: Andernfalls schlagen andere auf OpenSSL gestützte Operationen in Ihrem Prozess weiterhin fehl, vor allem TLS zum Babel Licensing Service.

Last updated on