Liaison de version

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 seule ro.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 : partition vendor
    • BOOT_PATCH_LEVEL : partition boot
    • OS_PATCH_LEVEL et OS_VERSION : partition system . ( OS_VERSION est supprimé de l'en-tête boot.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 incluront Tag::APPLICATION_ID et Tag::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.