Dans Keymaster 1, toutes les clés principales étaient liées cryptographiquement à la racine de confiance de l'appareil ou à la clé de démarrage vérifiée. Dans Keymaster 2 et 3, toutes les clés sont également liées au système d'exploitation et au niveau de correctif de l'image système. Cela garantit qu'un attaquant qui découvre une faiblesse dans une ancienne version du système ou du logiciel TEE ne peut pas restaurer un appareil vers la version vulnérable et utiliser les clés créées avec la version la plus récente. De plus, lorsqu'une clé avec une version et un niveau de correctif donnés est utilisée sur un appareil qui a été mis à niveau vers une version ou un niveau de correctif plus récent, la clé est mise à niveau avant de pouvoir être utilisée et la version précédente de la clé est invalidée. De cette façon, à mesure que l'appareil est mis à niveau, les clés avanceront avec l'appareil, mais tout retour de l'appareil à une version précédente rendra les clés inutilisables.
Pour prendre en charge la structure modulaire de Treble et rompre la liaison de system.img à boot.img, Keymaster 4 a modifié le modèle de liaison de version de clé pour avoir des niveaux de correctifs distincts pour chaque partition. Cela permet à chaque partition d'être mise à jour indépendamment, tout en offrant une protection contre la restauration.
Dans Android 9, les partitions boot
, system
et vendor
ont chacune leur propre niveau de correctif.
- Les appareils dotés d'Android Verified Boot (AVB) peuvent placer tous les niveaux de correctifs et la version du système dans vbmeta, afin que le chargeur de démarrage puisse les fournir à Keymaster. Pour les partitions chaînées, les informations de version de la partition seront dans la vbmeta chaînée. En général, les informations de version doivent figurer dans la
vbmeta struct
qui contient les données de vérification (hash ou hashtree) pour une partition donnée. - Sur les appareils sans AVB :
- Les implémentations de démarrage vérifié doivent fournir un hachage des métadonnées de version au chargeur de démarrage, afin que celui-ci puisse fournir le hachage à Keymaster.
-
boot.img
peut continuer à stocker le niveau de correctif dans l'en-tête -
system.img
peut continuer à stocker le niveau de correctif et la version du système d'exploitation dans des propriétés en lecture seule -
vendor.img
stocke le niveau de correctif dans la propriété en lecture seulero.vendor.build.version.security_patch
. - Le chargeur de démarrage peut fournir un hachage de toutes les données validées par un démarrage vérifié sur le keymaster.
- Sous Android 9, utilisez les balises suivantes pour fournir des informations de version pour les partitions suivantes :
-
VENDOR_PATCH_LEVEL
: partitionvendor
-
BOOT_PATCH_LEVEL
: partitionboot
-
OS_PATCH_LEVEL
etOS_VERSION
: partitionsystem
. (OS_VERSION
est supprimé de l'en-têteboot.img
.
-
- Les implémentations Keymaster doivent traiter tous les niveaux de correctifs indépendamment. Les clés sont utilisables si toutes les informations de version correspondent aux valeurs associées à une clé, et
IKeymaster::upgradeDevice()
passe à un niveau de correctif supérieur si nécessaire.
Changements dans HAL
Pour prendre en charge la liaison de version et l'attestation de version, Android 7.1 a ajouté les balises Tag::OS_VERSION
et Tag::OS_PATCHLEVEL
ainsi que les méthodes configure
et upgradeKey
. Les balises de version sont automatiquement ajoutées par les implémentations Keymaster 2+ à toutes les clés nouvellement générées (ou mises à jour). De plus, toute tentative d'utilisation d'une clé dont la version du système d'exploitation ou le niveau de correctif ne correspond pas respectivement à la version actuelle du système d'exploitation ou au niveau de correctif est rejetée avec ErrorCode::KEY_REQUIRES_UPGRADE
.
Tag::OS_VERSION
est une valeur UINT
qui représente les parties majeure, mineure et sous-mineure d'une version du système Android sous la forme MMmmss, où MM est la version majeure, mm est la version mineure et ss est la version sous-mineure. Par exemple, 6.1.2 serait représenté par 060102.
Tag::OS_PATCHLEVEL
est une valeur UINT
qui représente l'année et le mois de la dernière mise à jour du système sous la forme AAAAMM, où AAAA est l'année à quatre chiffres et MM le mois à deux chiffres. Par exemple, mars 2016 serait représenté par 201603.
Clé de mise à niveau
Pour permettre la mise à niveau des clés vers la nouvelle version du système d'exploitation et le niveau de correctif de l'image système, Android 7.1 a ajouté la méthode upgradeKey
au HAL :
Maître des clés 3
upgradeKey(vec keyBlobToUpgrade, vec upgradeParams) generates(ErrorCode error, vec upgradedKeyBlob);
Maître des clés 2
keymaster_error_t (*upgrade_key)(const struct keymaster2_device* dev, const keymaster_key_blob_t* key_to_upgrade, const keymaster_key_param_set_t* upgrade_params, keymaster_key_blob_t* upgraded_key);
-
dev
est la structure du périphérique -
keyBlobToUpgrade
est la clé qui doit être mise à niveau -
upgradeParams
sont des paramètres nécessaires pour mettre à niveau la clé. Ceux-ci inclurontTag::APPLICATION_ID
etTag::APPLICATION_DATA
, qui sont nécessaires pour déchiffrer le blob de clé, s'ils ont été fournis lors de la génération. -
upgradedKeyBlob
est le paramètre de sortie, utilisé pour renvoyer le nouveau blob de clé.
Si upgradeKey
est appelé avec un blob de clé qui ne peut pas être analysé ou qui est autrement invalide, il renvoie ErrorCode::INVALID_KEY_BLOB
. S'il est appelé avec une clé dont le niveau de correctif est supérieur à la valeur système actuelle, il renvoie ErrorCode::INVALID_ARGUMENT
. S'il est appelé avec une clé dont la version du système d'exploitation est supérieure à la valeur système actuelle et que la valeur système est différente de zéro, il renvoie ErrorCode::INVALID_ARGUMENT
. Les mises à niveau de version du système d'exploitation de non zéro à zéro sont autorisées. En cas d'erreurs de communication avec le monde sécurisé, il renvoie une valeur d'erreur appropriée (par exemple ErrorCode::SECURE_HW_ACCESS_DENIED
, ErrorCode::SECURE_HW_BUSY
). Sinon, il renvoie ErrorCode::OK
et renvoie un nouveau blob de clé dans upgradedKeyBlob
.
keyBlobToUpgrade
reste valide après l'appel upgradeKey
et pourrait théoriquement être réutilisé si l'appareil était rétrogradé. En pratique, keystore appelle généralement deleteKey
sur le blob keyBlobToUpgrade
peu de temps après l'appel à upgradeKey
. Si keyBlobToUpgrade
avait la balise Tag::ROLLBACK_RESISTANT
, alors upgradedKeyBlob
devrait l'avoir également (et devrait être résistant à la restauration).
Configuration sécurisée
Pour implémenter la liaison de version, le keymaster TA a besoin d'un moyen de recevoir en toute sécurité la version actuelle du système d'exploitation et le niveau de correctif (informations de version), et de garantir que les informations qu'il reçoit correspondent fortement aux informations sur le système en cours d'exécution.
Pour prendre en charge la livraison sécurisée des informations de version au TA, un champ OS_VERSION
a été ajouté à l'en-tête de l'image de démarrage. Le script de création de l'image de démarrage remplit automatiquement ce champ. Les OEM et les implémenteurs de keymaster TA doivent travailler ensemble pour modifier les chargeurs de démarrage des périphériques afin d'extraire les informations de version de l'image de démarrage et de les transmettre au TA avant le démarrage du système non sécurisé. Cela garantit que les attaquants ne peuvent pas interférer avec la fourniture des informations de version au TA.
Il est également nécessaire de s'assurer que l'image système possède les mêmes informations de version que l'image de démarrage. À cette fin, la méthode configure a été ajoutée au keymaster HAL :
keymaster_error_t (*configure)(const struct keymaster2_device* dev, const keymaster_key_param_set_t* params);
L'argument params
contient Tag::OS_VERSION
et Tag::OS_PATCHLEVEL
. Cette méthode est appelée par les clients keymaster2 après l'ouverture du HAL, mais avant d'appeler toute autre méthode. Si une autre méthode est appelée avant configure, le TA renvoie ErrorCode::KEYMASTER_NOT_CONFIGURED
.
La première fois configure
est appelé après le démarrage du périphérique, il doit vérifier que les informations de version fournies correspondent à celles fournies par le chargeur de démarrage. Si les informations de version ne correspondent pas, configure
renvoie ErrorCode::INVALID_ARGUMENT
et toutes les autres méthodes keymaster continuent de renvoyer ErrorCode::KEYMASTER_NOT_CONFIGURED
. Si les informations correspondent, configure
renvoie ErrorCode::OK
et les autres méthodes keymaster commencent à fonctionner normalement.
Les appels suivants à configure
renvoient la même valeur renvoyée par le premier appel et ne modifient pas l'état de keymaster. Notez que ce processus nécessite que tous les OTA mettent à jour les images système et de démarrage ; ils ne peuvent pas être mis à jour séparément pour maintenir les informations de version synchronisées.
Étant donné que configure
sera appelé par le système dont il est censé valider le contenu, un attaquant dispose d'une fenêtre d'opportunité étroite pour compromettre l'image système et l'obliger à fournir des informations de version qui correspondent à l'image de démarrage, mais qui ne sont pas la version réelle. version du système. La combinaison de la vérification de l'image de démarrage, de la validation dm-verity du contenu de l'image système et du fait que configure
est appelé très tôt lors du démarrage du système devrait rendre cette fenêtre d'opportunité difficile à exploiter.