Module de chiffrement GKI certifié FIPS 140-3

Le noyau GKI inclut un module de noyau Linux appelé fips140.ko, conforme à la norme FIPS 140-3 relative aux modules logiciels cryptographiques. Ce module peut être envoyé pour obtenir la certification FIPS si le produit exécutant le noyau GKI l'exige.

Les exigences FIPS 140-3 suivantes en particulier doivent être satisfaites pour que les routines cryptographiques puissent être utilisées:

  • Le module doit vérifier sa propre intégrité avant de mettre des algorithmes cryptographiques à disposition.
  • Le module doit tester et vérifier ses algorithmes cryptographiques approuvés à l'aide d'auto-tests de réponses connues 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 module logiciel ou matériel est certifié, il n'est jamais modifié. En cas de modification, elle doit être de nouveau certifiée. Cela ne correspond pas facilement aux processus de développement logiciel en cours d'utilisation. Par conséquent, les modules logiciels FIPS sont généralement conçus pour être aussi étroitement ciblés que possible sur les composants cryptographiques, afin de garantir que les modifications non liées à la cryptographie ne nécessitent pas de réévaluation de la cryptographie.

Le noyau GKI est destiné à être mis à jour régulièrement pendant toute sa durée de vie. Il est donc impossible pour l'ensemble du noyau de se trouver dans la limite 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 limiterait 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, il fallait tenir compte du fait 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 de la norme FIPS 140-3 est empaqueté dans un module de noyau distinct fips140.ko qui ne repose que sur des interfaces stables exposées par la source de noyau GKI à partir de laquelle il a été créé. Cela garantit que le module peut être utilisé avec différentes versions GKI de la même génération, et qu'il ne doit être mis à jour et renvoyé pour certification que si des problèmes ont été résolus dans le code transmis par le module lui-même.

Quand utiliser le module

Le noyau GKI contient du code qui dépend des routines cryptographiques également empaquetées 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 copiées dans le module. Une fois le module chargé, les routines cryptographiques intégrées sont désenregistrées de Linux CryptoAPI et remplacées par celles diffusées par le module.

Cela signifie que le module fips140.ko est entièrement facultatif et qu'il n'est pertinent de le déployer que si la certification FIPS 140-3 est une exigence. En outre, le module ne fournit aucune fonctionnalité supplémentaire, et son chargement inutile risque seulement d'affecter le temps de démarrage, sans apporter 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 la copie du module sur 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.

Autocontrôle de l'intégrité

Le module de noyau FIPS 140-3 extrait 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. Cette opération a lieu une fois que le chargeur de module Linux a déjà effectué les modifications habituelles, telles que le traitement de la relocalisation ELF et l'application de correctifs alternatifs pour les errata de processeur à ces sections. Les étapes supplémentaires suivantes permettent de s'assurer que le condensé peut être reproduit correctement:

  • Les réinstallations ELF sont conservées à l'intérieur du module afin qu'elles puissent être appliquées à l'inverse de l'entrée du HMAC.
  • Le module inverse tous les correctifs de code créés par le noyau pour Dynamic Shadow Call Stack. Plus précisément, le module remplace toutes les instructions qui transfèrent ou sortent de la pile d'appel fantôme par les instructions PAC (Pointer Authentication Code, code d'authentification de pointeur) 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 et les 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 d'être utilisés. Conformément au guide d'implémentation FIPS 140-3 10.3.A, un seul vecteur de test par algorithme utilisant l'une des longueurs de clé prises en charge suffit pour les algorithmes de chiffrement, à condition que le chiffrement et le déchiffrement soient tous les deux testés.

L'API Linux CryptoAPI comporte une notion de priorité d'algorithme, où plusieurs implémentations (par exemple, une implémentation utilisant des instructions de chiffrement spéciales et une solution de remplacement pour les processeurs qui n'implémentent pas ces instructions) peuvent coexister. Par conséquent, vous devez tester toutes les implémentations du même algorithme. Cela est nécessaire, car l'API Linux CryptoAPI permet d'ignorer la sélection basée sur la priorité et de sélectionner un algorithme de priorité inférieure à 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. Toutefois, 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 compatibles. 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 compatibles.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 prises en charge. Dans les versions 6.6 et ultérieures, seuls 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 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
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 des 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 module fips140.ko, qui incluent le contenu du condensé HMAC-SHA256.

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 limité à 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 du processeur.

Le module de noyau ne peut pas être installé séparément. Il est inclus dans le micrologiciel de l'appareil et chargé automatiquement au démarrage. Elle fonctionne uniquement 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

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

L'utilisation des algorithmes à des fins de conformité FIPS est limitée aux algorithmes approuvés. Pour satisfaire à la norme FIPS 140-3 en termes d'indicateurs de service, le 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 provoque une panique du noyau et l'appareil ne poursuit pas le démarrage. Si un redémarrage de l'appareil ne résout pas le problème, il doit démarrer en mode récupération pour corriger le problème en reflashant l'appareil.

  1. Il est normal que les implémentations AES-GCM du module puissent être "approuvées par un algorithme", mais pas "module approuvé". Ils peuvent être validés, mais l'algorithme AES-GCM ne peut pas être considéré comme un algorithme approuvé du point de vue du module FIPS. En effet, les exigences du module FIPS pour GCM sont incompatibles avec les implémentations GCM qui ne génèrent pas leurs propres vecteurs d'initialisation. ↩