Module cryptographique GKI certifiable FIPS 140-3

Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

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 à certification FIPS si le produit exécutant le noyau GKI l'exige.

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

• Le module doit vérifier sa propre intégrité avant de créer des algorithmes cryptographiques disponibles.
• Le module doit tester et vérifier ses algorithmes cryptographiques approuvés à l'aide d'autotests à réponse connue avant de les mettre à disposition.

Pourquoi un module de noyau distinct

La validation FIPS 140-3 repose sur l'idée qu'une fois qu'un module basé sur un logiciel ou un matériel a été certifié, il ne change jamais. En cas de modification, il doit s'agir à renouveler votre certification. Cela ne correspond pas facilement aux processus de développement logiciel actuellement utilisés. En raison de cette exigence, les modules logiciels FIPS sont généralement conçus pour être aussi étroitement axés que possible sur les composants cryptographiques, afin de s'assurer que les modifications qui ne sont pas liées à la cryptographie ne nécessitent pas de réévaluation de la cryptographie.

Le noyau GKI est conçu pour être mis à jour régulièrement pendant toute la durée durée de vie. Il est donc impossible que l'ensemble du noyau se trouve dans la limite du module FIPS, car un tel module devrait être recertifié à chaque mise à jour du noyau. Définition du "module FIPS" comme un sous-ensemble de l'image du noyau, ce problème, mais sans le résoudre, car le contenu binaire du "Module FIPS" changeaient encore beaucoup plus fréquemment 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 le LTO était une condition préalable au contrôle l'intégrité du flux, qui est une fonctionnalité de sécurité importante.

Par conséquent, tout code couvert par les exigences FIPS 140-3 est empaqueté dans un module de kernel fips140.ko distinct, qui ne s'appuie que sur des interfaces stables exposées par la source du kernel GKI à partir de laquelle il a été compilé. Ce signifie que le module peut être utilisé avec différentes versions de GKI génération, et qu'elle doit être mise à jour et renvoyée uniquement pour certification si des problèmes ont été résolus dans le code transporté par le module lui-même.

Quand utiliser le module

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

Cela signifie que le module fips140.ko est entièrement facultatif et qu'il ne fait de le déployer si la certification FIPS 140-3 est une exigence. En outre, le module ne fournit aucune fonctionnalité supplémentaire, et le charger inutilement ne risque que d'affecter le temps de démarrage, sans aucun avantage.

Déployer le module

Vous pouvez intégrer le module au build Android en procédant comme suit:

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

Autocontrôle de l'intégrité

Le module de noyau FIPS 140-3 utilise le condensé HMAC-SHA256 de son propre .code et .rodata au moment du chargement du module, et le compare au condensé vus dans le module. Cela se produit une fois que le chargeur de module Linux a déjà effectué les modifications habituelles, telles que le traitement de la relocation ELF et le correctif des alternatives pour les erreurs du processeur dans ces sections. Les éléments suivants : des mesures supplémentaires sont prises pour s'assurer que le récapitulatif peut être reproduit correctement:

• Les déplacements ELF sont conservés à l'intérieur du module pour pouvoir être appliqués l'inverse à l'entrée du HMAC.
• Le module inverse tous les correctifs de code réalisés par le noyau pour les Pile d'appel fantôme. Plus précisément, il remplace les instructions Push ou pop-up depuis la pile d'appel fantôme avec le code d'authentification du pointeur (PAC) qui étaient présentes à l'origine.
• Tout autre correctif de code est désactivé pour le module, y compris les clés statiques et donc les points de trace, ainsi que les hooks du fournisseur.

Auto-tests à réponse connue

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

La CryptoAPI Linux comporte une notion de priorités d'algorithmes, où plusieurs implémentations (par exemple, une utilisant des instructions de cryptographie spéciales et une solution de secours pour les processeurs qui n'implémentent pas ces instructions) du même algorithme peuvent coexister. Par conséquent, il est nécessaire de tester toutes les implémentations du même algorithme. Cela est nécessaire, car l'API Linux CryptoAPI autorise la priorité basée sur une sélection basée sur l'utilisateur et qu'un algorithme de priorité inférieure sélectionné à la place.

Algorithmes inclus dans le module

Tous les algorithmes inclus dans le module FIPS 140-3 sont énumérés ci-dessous. Cela s'applique aux branches de 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 de noyau soient indiquées le cas échéant.

Algorithme	Implémentations	Approuvée	Définition
aes	aes-generic, aes-arm64, aes-ce, bibliothèque AES	Oui	Chiffrement par bloc AES standard, sans mode de fonctionnement: toutes les tailles de clé (128, 192 et 256 bits) sont prises en charge. Toutes les implémentations autres que l'implémentation de la bibliothèque peuvent être composées avec un mode de fonctionnement à l'aide d'un modèle.
cmac(aes)	cmac (modèle), cmac-aes-neon, cmac-aes-ce	Oui	AES-CMAC : toutes les tailles de clé 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é 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é AES sont compatibles. 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é AES sont prises en charge. 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é AES sont compatibles. 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: à partir de la version 6.1 du noyau, toutes les tailles de clé AES sont compatibles. dans les versions 6.6 et ultérieures du noyau, seuls les protocoles AES-128 et AES-256 sont compatibles. 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 mettent en œuvre la vérification faible des clés requise par la norme FIPS. c'est-à-dire que les clés XTS dont la première et la deuxième moitiés sont égales sont rejetées.
gcm(aes)	gcm (modèle), gcm-aes-ce	Non1	AES-GCM: toutes les tailles de clé AES sont acceptées. Seuls les vecteurs d'initialisation 96 bits sont pris en charge. Comme pour tous les autres modes AES de ce module, l'appelant est chargé de fournir les IV. 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. Présent uniquement dans la version 6.6 du kernel ou ultérieure.
sha3-256	sha3-256-generic	Oui	Même que précédemment, 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 méthode 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 méthode 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 avec la résistance à la prédiction activée : les vérifications d'état sont incluses. Les utilisateurs de cette interface obtiennent leurs propres instances DRBG.
stdrng	drbg_nopr_hmac_sha1, drbg_nopr_hmac_sha256, drbg_nopr_hmac_sha384, drbg_nopr_hmac_sha512	Oui	Identiques aux algorithmes drbg_pr_*, mais avec la résistance aux prédictions désactivée. Le code est partagé avec la variante résistante aux prédictions. Dans la version 5.10 du kernel, le DRBG de priorité la plus élevée est drbg_nopr_hmac_sha256. Dans les versions de kernel 5.15 et ultérieures, il s'agit de drbg_pr_hmac_sha512.
jitterentropy_rng	jitterentropy_rng	Non	Jitter RNG, version 2.2.0 (version du noyau 6.1 et versions antérieures) ou version 3.4.0 (version 6.6 ou ultérieure du noyau). Les utilisateurs de cette interface obtiennent 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 kernel ou ultérieure.
cbcmac(aes)	cbcmac-aes-neon, cbcmac-aes-ce	Non
essiv(cbc(aes),sha256)	essiv-cbc-aes-sha256-neon, essiv-cbc-aes-sha256-ce	Non

Créer le module à partir de la source

Pour Android 14 ou version ultérieure (y compris android-mainline), compilez le module fips140.ko à partir de la source à l'aide de la méthode les commandes suivantes.

• Compiler avec Bazel:

  tools/bazel run //common:fips140_dist

• Compilation 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écapitulatif HMAC-SHA256 intégré.

Conseils pour les utilisateurs finaux

Conseils pour les agents de chiffrement

Pour faire fonctionner le module de noyau, le système d’exploitation doit être restreint à un mode de fonctionnement à un seul opérateur. Android gère automatiquement cela à l'aide du matériel de gestion de la mémoire du processeur.

Le module de noyau ne peut pas être installé séparément ; il est inclus dans le et se charge automatiquement au démarrage. Il ne fonctionne que dans un mode de fonctionnement approuvé.

L'agent de chiffrement peut exécuter les tests automatiques à tout moment en redémarrant l'appareil.

Conseils aux utilisateurs

L'utilisateur du module du noyau est un autre composant du noyau qui doit utiliser des algorithmes de cryptographie. 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écessaires pour effectuer une opération cryptographique.

L'utilisation des algorithmes à des fins de conformité FIPS est limitée algorithmes. Conformité avec la norme FIPS 140-3 "Indicateur de service" cette exigence, la module fournit une fonction fips140_is_approved_service qui indique si un algorithme est approuvé.

Erreurs du test automatique

En cas d'échec de l'autotest, le kernel module provoque une panique du kernel et l'appareil ne continue pas le démarrage. Si un redémarrage de l'appareil ne résout pas le problème, l'appareil doit démarrer en mode récupération pour corriger le problème en flashant de nouveau l'appareil.