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 parinit
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.
-
Il est normal que les implémentations AES-GCM du module soient des "algorithmes approuvé" 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 Implémentations GCM qui ne génèrent pas leurs propres vecteurs d'initialisation. ↩