Conformité FIPS

Babel Licensing fonctionne sur les hôtes Linux en mode FIPS, et sa validation de licence ne repose sur aucun algorithme que FIPS interdit. Cette page explique le comportement de la bibliothèque sur ces hôtes, un problème de démarrage que vous pouvez rencontrer dans les conteneurs et la manière de le résoudre.

Contexte

De nombreux clients déploient sur des hôtes dont le système d’exploitation fonctionne en mode FIPS : sous Linux, cet état est exposé par /proc/sys/crypto/fips_enabled = 1. Dans ce mode, le fournisseur cryptographique de la plateforme (OpenSSL sous Linux) est censé traiter chaque opération cryptographique au moyen d’un module FIPS certifié.

Un problème courant survient lorsqu’un conteneur hérite de l’indicateur FIPS de l’hôte alors que son image de base ne contient pas de fournisseur FIPS OpenSSL certifié. OpenSSL 3 tente alors de passer en mode FIPS, ne parvient pas à charger le module du fournisseur FIPS et se retrouve dans un état défaillant où toutes les opérations de hachage et de chiffrement échouent, et pas seulement celles que FIPS interdirait normalement. L’erreur typique est la suivante :

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

Comment le problème se manifeste pendant la validation de licence

Comme toute la couche OpenSSL est inutilisable, l’échec apparaît à la première opération cryptographique effectuée au démarrage. Lorsqu’une licence comporte une date d’expiration, Babel Licensing ouvre un petit stockage local qui sert au suivi de l’expiration et à la détection d’un retour en arrière de l’horloge. Sur les versions modernes de .NET, l’initialisation de ce stockage calcule un hachage d’identité au moyen du fournisseur de la plateforme, qui lève une exception sur un hôte en mode FIPS défaillant. L’échec est signalé ainsi :

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

Résoudre le problème dans les conteneurs

Rendez OpenSSL utilisable dans le conteneur. L’une ou l’autre option corrige le symptôme lié à la validation de licence et toutes les autres opérations de votre processus qui reposent sur OpenSSL.

Option 1 : ne pas passer automatiquement en mode FIPS dans le conteneur

Sur les images .NET basées sur Ubuntu, OpenSSL tient compte de la variable d’environnement OPENSSL_FORCE_FIPS_MODE. Réglez-la sur 0 pour qu’OpenSSL ne tente pas de passer en mode FIPS avec un fournisseur que l’image ne contient pas.

Dans docker-compose.yml, ajoutez-la à l’environnement du service licensing :

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

ou dans un Dockerfile :

ENV OPENSSL_FORCE_FIPS_MODE=0

Utilisez cette option lorsque le conteneur lui-même n’a pas besoin d’être validé FIPS : l’hôte reste en mode FIPS et seul l’OpenSSL de ce conteneur renonce au passage automatique en mode FIPS, qui est défaillant.

Option 2 : utiliser une image de base dotée d’un fournisseur FIPS certifié

Si la conformité FIPS est exigée dans le conteneur, utilisez une image de base qui contient un fournisseur FIPS validé, afin que la couche cryptographique s’initialise correctement au lieu d’échouer :

• les images .NET Azure Linux 3.0 (mcr.microsoft.com/dotnet/aspnet:8.0-azurelinux3.0 et images similaires), qui contiennent le fournisseur SymCrypt de Microsoft, certifié FIPS,
• les images .NET basées sur Red Hat UBI 9 (registry.access.redhat.com/ubi9/dotnet-90 et images similaires), ou
• Ubuntu Pro avec les paquets OpenSSL certifiés FIPS.

Le Babel Licensing Service sur les hôtes FIPS

Le Babel Licensing Service fonctionne sur les hôtes en mode FIPS à condition que l’image contienne réellement un module de fournisseur FIPS. Le flux de travail de licence complet a été vérifié sur Azure Linux 3.0, dont les images .NET contiennent le fournisseur SymCrypt de Microsoft, certifié FIPS, avec le mode FIPS imposé :

• le service démarre et valide sa propre licence,
• les modèles de licence et les licences signées RSA sont créés,
• les clients activent et valident des licences par gRPC,
• la liaison à la machine, les jetons d’activation, les signaux de présence et la désactivation fonctionnent tous.

Ce qui se passe lorsque le module FIPS est absent

La distinction qui compte n’est pas « FIPS activé ou désactivé », mais la présence ou l’absence du module de fournisseur qu’exige le mode FIPS.

OpenSSL 3 n’implémente pas lui-même les algorithmes : il les charge depuis des fournisseurs enfichables. En mode FIPS, la configuration exige que chaque algorithme provienne du fournisseur FIPS certifié (le module fips.so). Si ce module n’est pas installé dans l’image, comme c’est le cas pour les images .NET Debian/Ubuntu standard, OpenSSL ne peut satisfaire aucune demande, de sorte que tous les algorithmes échouent, y compris ceux que FIPS lui-même autorise.

Comme .NET sous Linux délègue toute la cryptographie à OpenSSL, la panne ne se limite pas au hachage et au chiffrement :

Vérifier l’environnement

Une vérification rapide depuis l’intérieur du conteneur indique si OpenSSL est sain :

# Fails on a broken-FIPS host, succeeds once fixed
echo test | openssl dgst -sha1

• Échec avec error:03000086 (ou un message indiquant que fips.so ne peut pas être chargé) : OpenSSL est dans l’état défaillant ; appliquez l’option 1 ou 2.
• Une ligne SHA1(stdin)= ... normale : OpenSSL est sain et Babel Licensing fonctionne normalement.