Module de chiffrement GKI certifié FIPS 140-3

Le noyau GKI comprend un Module de noyau Linux appelé fips140.ko et conforme à Configuration FIPS 140-3 pour les modules logiciels cryptographiques. Ce module peut être soumis pour la certification FIPS la certification si le produit exécutant le noyau GKI l'exige.

Les exigences FIPS 140-3 suivantes en particulier doivent être satisfaites avant les routines cryptographiques peuvent ê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'auto-tests à réponse connue avant de les mettre à disposition.

Pourquoi un module de noyau distinct

La certification FIPS 140-3 repose sur l'idée qu'une fois qu'un logiciel ou un matériel a été certifié, il n'est jamais modifié. En cas de modification, il doit s'agir à renouveler votre certification. Cela ne correspond pas facilement aux processus de développement logiciel de utiliser aujourd'hui et, en raison de cette exigence, les modules logiciels FIPS sont généralement conçu pour être aussi étroitement concentré sur les composants cryptographiques que possible, pour garantir que les modifications non liées à la cryptographie nécessitent une 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 pour l’ensemble du noyau d’entrer dans le cadre du programme FIPS limite de module : en tant que tel, un module doit être recertifié à chaque noyau mise à jour. 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 le code couvert par la norme FIPS 140-3 est empaqueté dans un module de noyau distinct, fips140.ko, qui ne repose que sur des fichiers interfaces exposées par la source du noyau GKI à partir duquel il a été créé. 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 noyau GKI lui-même porte du code qui dépend des routines cryptographiques qui sont également empaqueté dans le module du noyau FIPS 140-3. Par conséquent, la fonctionnalité de chiffrement intégrée ne sont pas réellement déplacées hors du noyau GKI, mais sont copiées dans dans le module. Une fois le module chargé, les routines cryptographiques intégrées désenregistrés de la Linux CryptoAPI et remplacés par ceux transmis par le de ce 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. Au-delà de cela, le module ne fournit aucune fonctionnalité supplémentaire, et son chargement inutile est ne risque d'affecter que le 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 lorsque le 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 du module Linux a ont déjà effectué les modifications habituelles, comme le processus de déplacement ELF des alternatives pour corriger les errata de CPU à 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.
• Tous les autres correctifs de code sont désactivés pour le module, y compris les clés statiques et par conséquent des tracepoints ainsi que des hooks de fournisseur.

Auto-tests à réponse connue

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

L'API CryptoAPI Linux repose sur la notion de priorités d'algorithme, où plusieurs des implémentations (par exemple, avec des instructions spéciales pour les chiffrements pour les CPU qui n'implémentent pas ces instructions) du même algorithme peuvent coexistent. 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 éléments android12-5.10, android13-5.10, android13-5.15, Branches de noyau android14-5.15, android14-6.1 et android15-6.6 les différences entre les versions de noyau sont 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 acceptées. Toutes les implémentations autres que l'implémentation de la bibliothèque peuvent être composées d'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é AES sont compatibles. 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 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é 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 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. Présent uniquement à partir de la version 6.6 du noyau.
sha3-256	sha3-256-generic	Oui	Identique à l'exemple précédent, 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 à l'exemple précédent, 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 à l'exemple précédent, 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	Code HMAC (keyed-Hash Message Authentication Code): le modèle hmac peut être composé avec n'importe quel algorithme SHA ou implémentation à 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 aux prédictions activée: les vérifications de l'é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 noyau, le DRBG ayant la priorité la plus élevée est drbg_nopr_hmac_sha256. À partir de la version 5.15 du noyau, 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 à partir de la version 5.15 du noyau.
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
  

• Compiler avec build.sh (ancienne version):

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

Ces commandes effectuent une compilation complète, y compris le noyau et le fips140.ko module avec le contenu de condensé 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. Cette opération est gérée automatiquement par Android. à l'aide du matériel de gestion de la mémoire dans le 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. Elle ne fonctionne 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

Les utilisateurs du module de noyau sont d’autres composants du 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é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 du test automatique, le module du noyau fait en sorte que le noyau panique et l'appareil ne continue pas à démarrer. En cas de redémarrage de l'appareil ne résout pas le problème, l'appareil doit démarrer en mode récupération pour en reflashant l'appareil.