Module cryptographique GKI certifiable FIPS 140-3

Le noyau GKI inclut un module de noyau Linux appelé fips140.ko qui est conforme aux exigences de la norme FIPS 140-3 pour les modules logiciels de chiffrement. Ce module peut être soumis à la certification FIPS si le produit exécutant le noyau GKI l'exige.

Les exigences FIPS 140-3 suivantes doivent notamment être remplies avant que les routines de chiffrement puissent être utilisées :

• Le module doit vérifier sa propre intégrité avant de rendre les algorithmes cryptographiques disponibles.
• Le module doit exécuter et valider ses algorithmes cryptographiques approuvés à l'aide d'autotests à réponse connue avant de les rendre disponibles.

Pourquoi un module de noyau distinct ?

La validation FIPS 140-3 repose sur l'idée qu'une fois qu'un module logiciel ou matériel a été certifié, il n'est plus jamais modifié. Si vous le modifiez, vous devrez le faire certifier à nouveau. Cela ne correspond pas facilement aux processus de développement logiciel utilisés aujourd'hui. Par conséquent, les modules logiciels FIPS sont généralement conçus pour être aussi étroitement axés que possible sur les composants cryptographiques, afin de garantir que les modifications qui ne sont pas liées à la cryptographie ne nécessitent pas une réévaluation de la cryptographie.

Le noyau GKI est conçu pour être régulièrement mis à jour tout au long de sa durée de vie. Il est donc impossible que l'ensemble du noyau se trouve dans les limites du module FIPS, car un tel module devrait être recertifié à chaque mise à jour du noyau. Définir le "module FIPS" comme un sous-ensemble de l'image du noyau atténuerait ce problème, mais ne le résoudrait pas, car le contenu binaire du "module FIPS" continuerait de changer beaucoup plus souvent que nécessaire.

Avant la version 6.1 du noyau, une autre considération était que GKI était compilé avec LTO (Link Time Optimization) activé, car LTO était une condition préalable pour l'intégrité du flux de contrôle, qui est une fonctionnalité de sécurité importante.

Par conséquent, tout le code couvert par les exigences FIPS 140-3 est regroupé dans un module de noyau distinct fips140.ko qui ne repose que sur des interfaces stables exposées par la source du noyau GKI à partir duquel il a été créé. Cela signifie que le module peut être utilisé avec différentes versions GKI de la même génération et qu'il doit être mis à jour et renvoyé pour certification uniquement si des problèmes ont été résolus dans le code porté par le module lui-même.

Quand utiliser le module

Le noyau GKI lui-même contient du code qui dépend des routines de chiffrement également incluses dans le module de noyau FIPS 140-3. Par conséquent, les routines de chiffrement intégrées ne sont pas réellement déplacées hors du noyau GKI, mais plutôt copiées dans le module. Lorsque le module est chargé, les routines de chiffrement intégrées sont désenregistrées de la CryptoAPI Linux et remplacées par celles fournies par le module.

Cela signifie que le module fips140.ko est entièrement facultatif et qu'il n'est judicieux de le déployer que si la certification FIPS 140-3 est requise. Au-delà de cela, le module ne fournit aucune fonctionnalité supplémentaire. Le charger inutilement n'aura probablement qu'un impact sur le temps de démarrage, sans aucun avantage.

Déployer le module

Vous pouvez intégrer le module à la compilation Android en procédant comme suit :

• Ajoutez le nom du module à BOARD_VENDOR_RAMDISK_KERNEL_MODULES. Cela entraîne la copie du module dans le ramdisk du fournisseur.
• Ajoutez le nom du module à BOARD_VENDOR_RAMDISK_KERNEL_MODULES_LOAD. Cela entraîne l'ajout du nom du module à modules.load sur la cible. modules.load contient la liste des modules chargés par init au démarrage de l'appareil.

L'autotest d'intégrité

Le module de noyau FIPS 140-3 prend le condensé HMAC-SHA256 de ses propres sections .code et .rodata au moment du chargement du module, et le compare au condensé enregistré dans le module. Cela se produit après que le chargeur de module Linux a déjà apporté les modifications habituelles à ces sections, telles que le traitement de la relocalisation ELF et le correctif des alternatives pour les errata du processeur. Les étapes supplémentaires suivantes sont effectuées pour s'assurer que le résumé peut être reproduit correctement :

• Les relocations ELF sont conservées dans le module afin de pouvoir être appliquées en sens inverse à l'entrée du HMAC.
• Le module inverse tous les correctifs de code apportés par le noyau pour la pile d'appels fantômes dynamiques. Plus précisément, le module remplace toutes les instructions qui insèrent ou retirent des éléments de la pile d'appels fantôme par les instructions de code d'authentification du pointeur (PAC) qui étaient présentes à l'origine.
• Tous les autres correctifs de code sont désactivés pour le module, y compris les clés statiques et, par conséquent, les points de trace ainsi que les hooks du fournisseur.

Les auto-tests avec réponse connue

Tous les algorithmes implémentés couverts par les exigences FIPS 140-3 doivent effectuer un autotest de réponse connue avant d'être utilisés. Selon la section 10.3.A du guide d'implémentation FIPS 140-3, un seul vecteur de test par algorithme utilisant l'une des longueurs de clé compatibles suffit pour les algorithmes de chiffrement, à condition que le chiffrement et le déchiffrement soient testés.

La CryptoAPI Linux a une notion de priorités d'algorithme, où plusieurs implémentations (telles qu'une utilisant des instructions de chiffrement spéciales et une solution de repli pour les processeurs qui n'implémentent pas ces instructions) du même algorithme peuvent coexister. Il est donc nécessaire de tester toutes les implémentations du même algorithme. Cela est nécessaire, car la CryptoAPI Linux permet de contourner la sélection basée sur la priorité et de sélectionner un algorithme de priorité inférieure.

Algorithmes inclus dans le module

Tous les algorithmes inclus dans le module FIPS 140-3 sont listés ci-dessous. Cela s'applique aux branches du noyau android12-5.10, android13-5.10, android13-5.15, android14-5.15, android14-6.1 et android15-6.6, bien que les différences entre les versions du noyau soient indiquées le cas échéant.

Algorithme	Implémentations	Approuvable	Définition
aes	aes-generic, aes-arm64, aes-ce, bibliothèque AES	Oui	Algorithme de chiffrement par blocs AES simple, sans mode de fonctionnement : toutes les tailles de clé (128, 192 et 256 bits) sont acceptées. Toutes les implémentations autres que l'implémentation de la bibliothèque peuvent être composées avec un mode de fonctionnement via un modèle.
cmac(aes)	cmac (modèle), cmac-aes-neon, cmac-aes-ce	Oui	AES-CMAC : toutes les tailles de clés AES sont acceptées. Le modèle cmac peut être composé avec n'importe quelle implémentation de aes à l'aide de cmac(<aes-impl>). Les autres implémentations sont autonomes.
ecb(aes)	ecb (modèle), ecb-aes-neon, ecb-aes-neonbs, ecb-aes-ce	Oui	AES-ECB : toutes les tailles de clés AES sont acceptées. Le modèle ecb peut être composé avec n'importe quelle implémentation de aes à l'aide de ecb(<aes-impl>). Les autres implémentations sont autonomes.
cbc(aes)	cbc (modèle), cbc-aes-neon, cbc-aes-neonbs, cbc-aes-ce	Oui	AES-CBC : toutes les tailles de clés AES sont acceptées. Le modèle cbc peut être composé avec n'importe quelle implémentation de aes à l'aide de ctr(<aes-impl>). Les autres implémentations sont autonomes.
cts(cbc(aes))	cts (modèle), cts-cbc-aes-neon, cts-cbc-aes-ce	Oui	AES-CBC-CTS ou AES-CBC avec vol de texte chiffré : la convention utilisée est CS3. Les deux derniers blocs de texte chiffré sont échangés sans condition. Toutes les tailles de clés AES sont acceptées. Le modèle cts peut être composé avec n'importe quelle implémentation de cbc à l'aide de cts(<cbc(aes)-impl>). Les autres implémentations sont autonomes.
ctr(aes)	ctr (modèle), ctr-aes-neon, ctr-aes-neonbs, ctr-aes-ce	Oui	AES-CTR : toutes les tailles de clés AES sont acceptées. Le modèle ctr peut être composé avec n'importe quelle implémentation de aes à l'aide de ctr(<aes-impl>). Les autres implémentations sont autonomes.
xts(aes)	xts (modèle), xts-aes-neon, xts-aes-neonbs, xts-aes-ce	Oui	AES-XTS : toutes les tailles de clés AES sont compatibles avec la version 6.1 du noyau et les versions antérieures. Seules les clés AES-128 et AES-256 sont compatibles avec la version 6.6 du noyau et les versions ultérieures. Le modèle xts peut être composé avec n'importe quelle implémentation de ecb(aes) à l'aide de xts(<ecb(aes)-impl>). Les autres implémentations sont autonomes. Toutes les implémentations implémentent la vérification des clés faibles requise par FIPS. Autrement dit, les clés XTS dont les première et deuxième moitiés sont égales sont refusées.
gcm(aes)	gcm (modèle), gcm-aes-ce	Non1	AES-GCM : toutes les tailles de clés AES sont acceptées. Seuls les vecteurs d'initialisation de 96 bits sont acceptés. Comme pour tous les autres modes AES de ce module, l'appelant est responsable de la fourniture des vecteurs d'initialisation. Le modèle gcm peut être composé avec n'importe quelle implémentation de ctr(aes) et ghash à l'aide de gcm_base(<ctr(aes)-impl>,<ghash-impl>). Les autres implémentations sont autonomes.
sha1	sha1-generic, sha1-ce	Oui	Fonction de hachage cryptographique SHA-1
sha224	sha224-generic, sha224-arm64, sha224-ce	Oui	Fonction de hachage cryptographique SHA-224 : le code est partagé avec SHA-256.
sha256	sha256-generic, sha256-arm64, sha256-ce, bibliothèque SHA-256	Oui	Fonction de hachage cryptographique SHA-256 : une interface de bibliothèque est fournie à SHA-256 en plus de l'interface CryptoAPI standard. Cette interface de bibliothèque utilise une implémentation différente.
sha384	sha384-generic, sha384-arm64, sha384-ce	Oui	Fonction de hachage cryptographique SHA-384 : le code est partagé avec SHA-512.
sha512	sha512-generic, sha512-arm64, sha512-ce	Oui	Fonction de hachage cryptographique SHA-512
sha3-224	sha3-224-generic	Oui	Fonction de hachage cryptographique SHA3-224. Uniquement présent dans le noyau version 6.6 et ultérieure.
sha3-256	sha3-256-generic	Oui	Identique à la précédente, mais avec une longueur de condensé de 256 bits (SHA3-256). Toutes les longueurs de condensé utilisent la même implémentation Keccak.
sha3-384	sha3-384-generic	Oui	Identique à la précédente, mais avec une longueur de condensé de 384 bits (SHA3-384). Toutes les longueurs de condensé utilisent la même implémentation Keccak.
sha3-512	sha3-512-generic	Oui	Identique à la précédente, mais avec une longueur de condensé de 512 bits (SHA3-512). Toutes les longueurs de condensé utilisent la même implémentation Keccak.
hmac	hmac (modèle)	Oui	HMAC (keyed-hash message authentication code) : le modèle hmac peut être composé avec n'importe quel algorithme ou implémentation SHA à l'aide de hmac(<sha-alg>) ou hmac(<sha-impl>).
stdrng	drbg_pr_hmac_sha1, drbg_pr_hmac_sha256, drbg_pr_hmac_sha384, drbg_pr_hmac_sha512	Oui	HMAC_DRBG instancié avec la fonction de hachage nommée et la résistance à la prédiction activée : les vérifications de l'état sont incluses. Les utilisateurs de cette interface disposent de leurs propres instances DRBG.
stdrng	drbg_nopr_hmac_sha1, drbg_nopr_hmac_sha256, drbg_nopr_hmac_sha384, drbg_nopr_hmac_sha512	Oui	Identique aux algorithmes drbg_pr_*, mais avec la résistance à la prédiction désactivée. Le code est partagé avec la variante résistante aux prédictions. Dans la version 5.10 du noyau, le DRBG de priorité la plus élevée est drbg_nopr_hmac_sha256. Dans la version 5.15 du noyau et les versions ultérieures, il s'agit de drbg_pr_hmac_sha512.
jitterentropy_rng	jitterentropy_rng	Non	Jitter RNG, version 2.2.0 (noyau version 6.1 et antérieure) ou version 3.4.0 (noyau version 6.6 et ultérieure). Les utilisateurs de cette interface disposent de leurs propres instances Jitter RNG. Ils ne réutilisent pas les instances utilisées par les DRBG.
xcbc(aes)	xcbc-aes-neon, xcbc-aes-ce	Non
xctr(aes)	xctr-aes-neon, xctr-aes-ce	Non	Présent uniquement dans la version 5.15 du noyau et les versions ultérieures.
cbcmac(aes)	cbcmac-aes-neon, cbcmac-aes-ce	Non
essiv(cbc(aes),sha256)	essiv-cbc-aes-sha256-neon, essiv-cbc-aes-sha256-ce	Non

Compiler le module à partir de la source

Pour Android 14 et versions ultérieures (y compris android-mainline), compilez le module fips140.ko à partir de la source à l'aide des commandes suivantes.

• Compiler avec Bazel :

  tools/bazel run //common:fips140_dist

• Créer avec build.sh (ancienne) :

  BUILD_CONFIG=common/build.config.gki.aarch64.fips140 build/build.sh

Ces commandes effectuent une compilation complète, y compris le noyau et le module fips140.ko avec le contenu du résumé HMAC-SHA256 intégré.

Conseils pour les utilisateurs finaux

Conseils pour le responsable du chiffrement

Pour faire fonctionner le module du noyau, le système d'exploitation doit être limité à un seul mode de fonctionnement de l'opérateur. Cette opération est gérée automatiquement par Android à l'aide du matériel de gestion de la mémoire du processeur.

Le module du noyau ne peut pas être installé séparément. Il est inclus dans le micrologiciel de l'appareil et chargé automatiquement au démarrage. Il ne fonctionne que dans un mode de fonctionnement approuvé.

Le responsable de la cryptographie peut exécuter les autotests à tout moment en redémarrant l'appareil.

Conseils aux utilisateurs

Les utilisateurs du module de noyau sont d'autres composants de noyau qui doivent utiliser des algorithmes cryptographiques. Le module du noyau ne fournit pas de logique supplémentaire dans l'utilisation des algorithmes et ne stocke aucun paramètre au-delà du temps nécessaire pour effectuer une opération cryptographique.

L'utilisation des algorithmes à des fins de conformité FIPS est limitée aux algorithmes approuvés. Pour répondre à l'exigence "indicateur de service" de la norme FIPS 140-3, le module fournit une fonction fips140_is_approved_service qui indique si un algorithme est approuvé.

Erreurs de test automatique

En cas d'échec de l'auto-test, le module du noyau provoque un plantage du noyau et l'appareil ne poursuit pas le démarrage. Si le redémarrage de l'appareil ne résout pas le problème, l'appareil doit démarrer en mode Recovery pour le corriger en le reflashant.