Google s'est engagé à promouvoir l'équité raciale pour les communautés noires. Regarde comment.
Cette page a été traduite par l'API Cloud Translation.
Switch to English

Liaison de version

Dans Keymaster 1, toutes les clés keymaster étaient liées de manière cryptographique à 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 à la version vulnérable et utiliser les clés créées avec la version la plus récente. En outre, lorsqu'une clé avec une version et un niveau de correctif donnés est utilisée sur un périphérique 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é invalidée. De cette manière, à mesure que l'appareil est mis à niveau, les clés «cliquet» vers l'avant 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 patch séparés pour chaque partition. Cela permet à chaque partition d'être mise à jour indépendamment, tout en offrant une protection contre la restauration.

Dans Android 9, vendor partitions de boot , system et vendor ont chacune leur propre niveau de correctif.

  • Les appareils avec Android Verified Boot (AVB) peuvent placer tous les niveaux de correctif 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 le vbmeta chaîné. En général, les informations de version doivent être dans la vbmeta struct qui contient les données de vérification (hachage 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 le chargeur de démarrage puisse fournir le hachage à Keymaster.
    • boot.img peut continuer à stocker le niveau de patch 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 du 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é au 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 de boot
    • OS_PATCH_LEVEL et OS_VERSION : partition system . ( OS_VERSION est supprimé de l'en-tête boot.img .
  • Les implémentations de Keymaster doivent traiter tous les niveaux de patch indépendamment. Les clés sont utilisables si toutes les informations de version correspondent aux valeurs associées à une clé, et IKeymaster::upgradeDevice() à un niveau de patch supérieur si nécessaire.

Changements 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 et les méthodes configure et upgradeKey . Les balises de version sont automatiquement ajoutées par les implémentations de Keymaster 2+ à toutes les clés nouvellement générées (ou mises à jour). En outre, toute tentative d'utilisation d'une clé qui n'a pas de version du système d'exploitation ou de niveau de correctif correspondant à la version actuelle du système d'exploitation ou au niveau de correctif, respectivement, est rejetée avec ErrorCode::KEY_REQUIRES_UPGRADE .

Tag::OS_VERSION est une valeur UINT qui représente les parties majeures, mineures et sous-mineures d'une version 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 est le mois à deux chiffres. Par exemple, mars 2016 serait représenté par 201603.

UpgradeKey

Pour permettre aux clés d'être mises à niveau 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 à la 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 de l'appareil
  • 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écrypter l'objet 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 nouvel objet blob de clé.

Si upgradeKey est appelé avec un objet blob 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 d'une valeur non nulle à 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 retourne un nouvel objet blob clé dans upgradedKeyBlob .

keyBlobToUpgrade reste valide après l'appel upgradeKey et pourrait théoriquement être réutilisé si le périphérique était rétrogradé. En pratique, le magasin de deleteKey appelle généralement deleteKey sur l' keyBlobToUpgrade blob keyBlobToUpgrade peu de temps après l'appel à upgradeKey . Si keyBlobToUpgrade avait la balise Tag::ROLLBACK_RESISTANT , alors upgradedKeyBlob devrait l'avoir aussi (et devrait être résistante au retour arrière).

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 s'assurer que les informations qu'il reçoit correspondent parfaitement 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 d'image de démarrage remplit automatiquement ce champ. Les OEM et les implémenteurs de TA keymaster 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 a les mêmes informations de version que l'image de démarrage. À cette fin, la méthode configure a été ajoutée à la HAL du keymaster:

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 de la 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 que 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 de keymaster continuent à renvoyer ErrorCode::KEYMASTER_NOT_CONFIGURED . Si les informations correspondent, configure renvoie ErrorCode::OK , et les autres méthodes de 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 du maître de clé. Notez que ce processus exigera que tous les OTA mettent à jour les images système et de démarrage; ils ne peuvent pas être mis à jour séparément afin de garder les informations de version synchronisées.

Étant donné que configure sera appelé par le système dont il est destiné à valider le contenu, il existe une fenêtre d'opportunité étroite pour un attaquant de compromettre l'image système et de la forcer à fournir des informations de version qui correspondent à l'image de démarrage, mais qui ne sont pas les 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 soit appelé très tôt dans le démarrage du système devrait rendre cette fenêtre d'opportunité difficile à exploiter.