Module de chiffrement GKI certifié FIPS 140-3

Le noyau GKI comprend un module de noyau Linux appelé fips140.ko qui est conforme aux exigences FIPS 140-3 pour les modules logiciels cryptographiques. 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 en particulier être remplies avant que les routines de chiffrement puissent être utilisées :

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

Pourquoi un module de noyau séparé

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 jamais modifié. En cas de modification, il doit être recertifié. Cela ne correspond pas facilement aux processus de développement de logiciels utilisés aujourd'hui et, en raison de cette exigence, les modules logiciels FIPS sont généralement conçus pour être aussi étroitement concentrés que possible sur les composants cryptographiques, afin de garantir que les modifications qui ne sont pas liées à la cryptographie soient prises en compte. ne nécessite pas une réévaluation de la cryptographie.

Le noyau GKI est destiné à être régulièrement mis à jour pendant toute sa durée de vie prise en charge. Cela rend 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 étant 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 » changerait 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 LTO était une condition préalable à 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 repose uniquement sur des interfaces stables exposées par la source du noyau GKI à partir de laquelle il a été construit. Cela garantit que le module peut être utilisé avec différentes versions de GKI de la même génération et qu'il doit être mis à jour et soumis à nouveau 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 intégrées au module du noyau FIPS 140-3. Par conséquent, les routines de chiffrement intégrées ne sont pas réellement déplacées du noyau GKI mais sont plutôt copiées dans le module. Lorsque le module est chargé, les routines de chiffrement intégrées sont désenregistrées de Linux CryptoAPI et remplacées par celles portées par le module.

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

Comment déployer le module

Le module peut être intégré à la version Android en suivant les étapes suivantes :

• Ajoutez le nom du module à BOARD_VENDOR_RAMDISK_KERNEL_MODULES . Cela provoque la copie du module sur le disque virtuel 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 du périphérique.

L’autocontrôle d’intégrité

Le module du noyau FIPS 140-3 prend le résumé HMAC-SHA256 de ses propres sections .code et .rodata au moment du chargement du module et le compare au résumé enregistré dans le module. Cela a lieu après que le chargeur de module Linux a déjà apporté les modifications habituelles telles que le traitement de la relocalisation ELF et les correctifs alternatifs pour les errata CPU dans ces sections. Les étapes supplémentaires suivantes sont prises pour garantir que le résumé peut être reproduit correctement :

• Les relocalisations ELF sont conservées à l'intérieur du module afin qu'elles puissent être appliquées à l'envers à l'entrée du HMAC.
• Tous les autres correctifs de code sont désactivés pour le module, y compris les clés statiques et donc les points de trace ainsi que les hooks du fournisseur.

Les autotests à réponse connue

Tous les algorithmes implémentés qui sont couverts par les exigences FIPS 140-3 doivent effectuer un autotest à réponse connue avant d'être utilisés. Selon le guide de mise en œuvre FIPS 140-3 10.3.A , un seul vecteur de test par algorithme utilisant l'une des longueurs de clé prises en charge est suffisant pour les chiffrements, à condition que le chiffrement et le déchiffrement soient testés.

La Linux CryptoAPI a une notion de priorités d'algorithme, dans laquelle plusieurs implémentations (telles qu'une utilisant des instructions de chiffrement spéciales et une solution de secours 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 Linux CryptoAPI permet de contourner la sélection basée sur la priorité et de sélectionner à la place un algorithme de priorité inférieure.

Algorithmes inclus dans le module

Tous les algorithmes inclus dans le module FIPS 140-3 sont répertoriés comme suit. Cela s'applique aux branches du noyau android12-5.10 , android13-5.10 , android13-5.15 , android14-5.15 et android14-6.1 , bien que les différences entre les versions du noyau soient notées le cas échéant.

Algorithme	Implémentations	Approuvable	Définition
aes	aes-generic , aes-arm64 , aes-ce , bibliothèque AES	Oui	Chiffrement par bloc AES simple, sans mode de fonctionnement : toutes les tailles de clé (128 bits, 192 bits 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 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 prises en charge. Le modèle cmac peut être composé avec n'importe quelle implémentation d' aes en utilisant 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 prises en charge. Le modèle ecb peut être composé avec n'importe quelle implémentation d' aes en utilisant 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 prises en charge. Le modèle cbc peut être composé avec n'importe quelle implémentation d' aes en utilisant 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 prises en charge. Le modèle cts peut être composé avec n'importe quelle implémentation de cbc en utilisant 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 prises en charge. Le modèle ctr peut être composé avec n'importe quelle implémentation d' aes en utilisant 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é AES sont prises en charge. Le modèle xts peut être composé avec n'importe quelle implémentation de ecb(aes) en utilisant 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 ; c'est-à-dire que les clés XTS dont la première et la seconde moitié sont égales sont rejetées.
gcm(aes)	gcm (modèle), gcm-aes-ce	Non 1	AES-GCM : toutes les tailles de clé AES sont prises en charge. Seuls les IV 96 bits sont pris en charge. Comme pour tous les autres modes AES de ce module, l'appelant est responsable de fournir les IV. Le modèle gcm peut être composé avec n'importe quelle implémentation de ctr(aes) et ghash en utilisant 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 au SHA-256 en plus de l'interface CryptoAPI traditionnelle. 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
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 utilisant 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 de prédiction activée : les contrôles de santé sont inclus. 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	Identique aux algorithmes drbg_pr_* , mais avec la résistance de 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 ayant la priorité la plus élevée est drbg_nopr_hmac_sha256 . Dans la version 5.15 et ultérieure du noyau, il s'agit de drbg_pr_hmac_sha512 .
jitterentropy_rng	jitterentropy_rng	Non	Version 2.2.0 du Jitter RNG : 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 et ultérieure 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

Construire le module à partir des sources

Pour Android 14 ou version ultérieure (y compris android-mainline ), créez le module fips140.ko à partir des sources à l'aide des commandes suivantes.

• Construire avec Bazel :

  tools/bazel run //common:fips140_dist
  

• Construire avec build.sh (hérité) :

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

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

Conseils à l'utilisateur final

Conseils du responsable de la cryptographie

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

Le module 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 fonctionne uniquement dans un mode de fonctionnement approuvé.

Le Crypto Officer peut provoquer l'exécution des autotests à tout moment en redémarrant l'appareil.

Conseils d'utilisation

Les utilisateurs du module noyau sont d'autres composants du noyau qui doivent utiliser des algorithmes cryptographiques. Le module 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 satisfaire à l'exigence FIPS 140-3 « indicateur de service », le module fournit une fonction fips140_is_approved_service qui indique si un algorithme est approuvé.

Erreurs d'auto-test

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