Le noyau GKI comprend un module de noyau Linux appelé fips140.ko qui est conforme aux exigences FIPS 140-3 pour les modules logiciels de chiffrement. Ce module peut être soumis à la certification FIPS si le produit exécutant le noyau GKI l'exige.
Les exigences FIPS 140-3 suivantes en particulier doivent ê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 est basée sur l'idée qu'une fois qu'un module logiciel ou matériel a été certifié, il n'est jamais modifié. S'il est modifié, il doit être recertifié. Cela ne correspond pas facilement aux processus de développement logiciel utilisés aujourd'hui, et 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 garantir que les modifications qui ne sont pas liées à la cryptographie ne 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 doit être recertifié à chaque mise à jour du noyau. En outre, GKI est compilé avec LTO (Link Time Optimization) activé, car LTO est une condition préalable pour CFI , qui est une fonctionnalité de sécurité importante. Cela rend impossible de tracer la limite du module FIPS autour du code cryptographique du noyau, car ce code ne se trouve pas à un emplacement clairement défini dans le binaire résultant. Les mises à jour du noyau peuvent également modifier le code crypto.
Par conséquent, tout le code couvert par les exigences FIPS 140-3 est regroupé dans un module de noyau séparé 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 transporté 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 qui sont également intégrées au 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 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'est logique de le déployer que si la certification FIPS 140-3 est une exigence. Au-delà de cela, le module ne fournit aucune fonctionnalité supplémentaire, et le charger inutilement ne risque que d'impacter le temps de démarrage, sans apporter aucun avantage.
Comment déployer le module
Le module peut être intégré à la version 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 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.loadsur la cible.modules.loadcontient la liste des modules qui sont chargés parinitlorsque le périphérique démarre.
L'autocontrôle d'intégrité
Le module de 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à effectué les modifications habituelles telles que le traitement de la relocalisation ELF et les correctifs alternatifs pour les errata CPU de ces sections. Les étapes supplémentaires suivantes sont prises pour s'assurer 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 en sens inverse à 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 de fournisseur.
Les autotests à réponse connue
Tous les algorithmes mis en œuvre qui sont couverts par les exigences FIPS 140-3 doivent effectuer un auto-test de réponse connue avant d'être utilisés. Selon le FIPS 140-3 Implementation Guidance 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, tant que le chiffrement et le déchiffrement sont testés.
La Linux CryptoAPI a une notion de priorités d'algorithme, où plusieurs implémentations (telles qu'une utilisant des instructions cryptographiques 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 Linux CryptoAPI permet d'éviter 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 lorsqu'ils sont construits à partir des sources android13-5.10 sont répertoriés comme suit.
| Algorithme | Implémentations | Approbable | 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 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 prises en charge. Le modèle cmac peut être composé avec n'importe quelle implémentation d' aes 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 utilisant ecb(<aes-impl>) . Les autres implémentations sont autonomes. |
cbc(aes) | cbc (modèle), cbc-aes-neon , cbc-aes-neonbs , cbc 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 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é 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 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) utilisant xts(<ecb(aes)-impl>) . Les autres implémentations sont autonomes. Toutes les implémentations implémentent la vérification de clé faible requise par FIPS ; c'est-à-dire que les clés XTS dont les première et seconde moitiés 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 à 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 à la prédiction 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 | 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. Le DRBG le plus prioritaire est drbg_nopr_hmac_sha256 . |
jitterentropy_rng | jitterentropy_rng | Non | Version 2.2.0 du Jitter RNG : Les utilisateurs de cette interface obtiennent leurs propres instances de Jitter RNG. Ils ne réutilisent pas les instances utilisées par les DRBG. |
xcbc(aes) | xcbc-aes-neon , xcbc-aes-ce | Non | |
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
Le module fips140.ko peut être créé à partir des sources du noyau GKI à l'aide de la commande suivante :
BUILD_CONFIG=common/build.config.gki.aarch64.fips140 build/build.sh
Ceci effectue la construction complète avec le noyau et le module fips140.ko , avec le résumé HMAC-SHA256 correct de son contenu intégré.
Sous Android 14 (AOSP expérimental) et versions ultérieures, créez avec Bazel au lieu de build/build.sh à l'aide de la commande suivante :
tools/bazel run //common:fips140_dist
Guide de l'utilisateur final
Conseils de l'agent de chiffrement
Pour faire fonctionner le module noyau, le système d'exploitation doit être limité à un mode de fonctionnement à opérateur unique. Ceci est géré automatiquement par Android à l'aide du matériel de gestion de la mémoire dans le processeur.
Le module noyau ne peut pas être installé séparément ; il est inclus dans le firmware de l'appareil et chargé automatiquement au démarrage. Il ne fonctionne que dans un mode de fonctionnement approuvé.
Le Crypto Officer peut faire exécuter les autotests à tout moment en redémarrant l'appareil.
Guide de l'utilisateur
L'utilisateur 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 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 répondre à l'exigence "indicateur de service" FIPS 140-3, 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 l'appareil ne poursuit 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 de récupération pour corriger le problème en reflashant l'appareil.
Il est prévu que les implémentations AES-GCM du module puissent être "approuvées par l'algorithme" mais pas "approuvées par le module". Ils peuvent être validés, mais 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 IV. ↩