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

Matériel soutenu par Keystore

La disponibilité d'un environnement d'exécution de confiance dans un système sur une puce (SoC) offre une occasion pour les appareils Android pour fournir des services, sécurité forte soutenu matériel à l'OS Android, aux services de la plate-forme, et même à des applications tierces. Les développeurs qui cherchent les extensions spécifiques Android doivent aller à android.security.keystore .

Avant Android 6.0, Android a déjà une simple API de services de chiffrement matériel soutenu, fourni par les versions 0.2 et 0.3 de la couche d'abstraction matérielle Keymaster (HAL). Keystore fourni signature numérique et de vérification des opérations, ainsi que la production et l'importation des paires de clés asymétriques de signature. Ceci est déjà mis en œuvre sur de nombreux appareils, mais il y a de nombreux objectifs de sécurité avec seulement une API de signature ne peut pas être facile à réaliser. Keystore dans Android 6.0 étend l'API keystore pour fournir une plus large gamme de capacités.

Dans Android 6.0, Keystore ajouté primitives cryptographiques symétriques , AES et HMAC, et un système de contrôle d'accès pour les clés matérielles soutenues. Les contrôles d'accès sont précisées lors de la génération de clés et mises en œuvre pour la durée de vie de la clé. Les clés peuvent être limitées pour être utilisable uniquement lorsque l'utilisateur est authentifié, et uniquement à des fins spécifiées ou avec des paramètres de chiffrement spécifiés. Pour plus d' informations, consultez les autorisations Balises et fonctions pages.

En plus d'élargir la gamme des primitives cryptographiques, Keystore dans Android 6.0 ajoute ce qui suit:

  • Un système de contrôle d'utilisation pour permettre l'utilisation des clés se limiter, pour atténuer le risque de compromission de la sécurité en raison d'une mauvaise utilisation des clés
  • Un système de contrôle d'accès pour permettre la restriction des clés à certains utilisateurs, les clients et un intervalle de temps défini

Dans Android 7.0, Keymaster 2 Ajout du support pour l'attestation clé et la version obligatoire. Attestation clé fournit des certificats de clé publique qui contiennent une description détaillée de la clé et ses contrôles d'accès, pour rendre l'existence de la clé dans le matériel sécurisé et sa configuration à distance vérifiable.

Version de liaison Lié clés pour le système d' exploitation et la version du niveau de patch. Cela garantit qu'un attaquant qui découvre une faiblesse dans une ancienne version du système ou un logiciel T ne peut pas rouler un dos de l'appareil aux touches de version vulnérables et d'utilisation créés avec la nouvelle version. En outre, lorsqu'une touche avec un niveau de version et le patch donné est utilisé sur un dispositif qui a été mis à niveau vers une version plus récente ou niveau de correctif, la clé est mis à jour avant de pouvoir être utilisé, et la version précédente de la clé invalidée. Comme l'appareil est mis à niveau, les touches « cliquet » avant le long du dispositif, mais une réversion de l'appareil à une version antérieure provoque les clés pour être inutilisable.

Dans Android 8.0, Keymaster 3 passe de l'ancien style C structure couche d'abstraction matérielle (HAL) à l'interface C ++ HAL générée à partir d'une définition dans la nouvelle définition d'interface matérielle Langue (HIDL). Dans le cadre du changement, la plupart des types d'arguments changé, bien que les types et les méthodes ont une à une correspondance avec les anciens types et les méthodes de struct HAL. Voir la Functions page pour plus de détails.

En plus de cette révision de l' interface, Android 8.0 étend la fonction d'attestation de Keymaster 2 à l' appui attestation d'identité . attestation d'identification fournit un mécanisme limité et en option d'attestation fortement aux identificateurs de matériel, tel que le dispositif numéro de série, le nom du produit et l'ID de l'appareil (IMEI / MEID). Pour mettre en œuvre cet ajout, modifier le schéma d'attestation ASN.1 ajouter attestation d'identité. implémentations Keymaster doivent trouver un moyen sûr de récupérer les éléments de données pertinentes, ainsi que de définir un mécanisme de désactivation en toute sécurité et de façon permanente la fonction.

Dans Android 9, mises à jour comprennent:

  • Mise à jour à Keymaster 4
  • Prise en charge des éléments sécurisés embarqués
  • Soutien à l'importation clé sécurisée
  • Soutien pour le chiffrement 3DES
  • Les modifications apportées à la version de reliure qui boot.img et system.img ont mis séparément les versions pour permettre des mises à jour indépendantes

Glossaire

Voici un aperçu rapide des composants clés et leurs relations.

AndroidKeystore est l'API Android et Framework composant utilisé par les applications pour accéder aux fonctionnalités Keystore. Il est mis en œuvre comme une extension aux Cryptography API d'architecture Java standard, et se compose de code Java qui fonctionne dans son propre espace de processus de l'application. AndroidKeystore répond aux demandes d'application pour le comportement Keystore en les transférant au démon keystore.

Le démon est un démon keystore système Android qui permet d' accéder à toutes les fonctionnalités Keystore via une API Binder . Il est responsable de la conservation « blobs clés », qui contiennent le matériel clé secrète réelle, chiffrée afin Keystore peut stocker mais pas l'utiliser ou révéler.

keymasterd est un serveur de HIDL qui donne accès à la Keymaster TA. (Ce nom n'est pas normalisée et à des fins conceptuelles.)

Keymaster TA (application de confiance) est le logiciel en cours d' exécution dans un contexte sécurisé, le plus souvent dans TrustZone sur un ARM SoC, qui fournit toutes les opérations magasins de clefs sécurisées, a accès à la matière clé brute, valide toutes les conditions de contrôle d'accès sur les clés , etc.

LockSettingsService est le composant système Android responsable de l' authentification des utilisateurs, à la fois le mot de passe et d' empreintes digitales. Il ne fait pas partie de Keystore, mais pertinent, car de nombreuses opérations clés nécessitent une authentification de magasins de clefs utilisateur. LockSettingsService interagit avec le Gatekeeper TA et TA d' empreintes digitales pour obtenir des jetons d'authentification, qu'il fournit au démon keystore, et qui sont finalement consommés par l'application Keymaster TA.

Gatekeeper TA (application de confiance) est un autre élément en cours d' exécution dans le contexte sécurisé, qui est responsable de l' authentification des mots de passe de l' utilisateur et de générer des jetons d' authentification utilisé pour prouver au TA Keymaster qu'une authentification a été effectuée pour un utilisateur particulier à un moment donné dans le temps.

Fingerprint TA (application de confiance) est un autre composant en cours d' exécution dans le contexte sécurisé qui est responsable de l' authentification des empreintes digitales de l' utilisateur et pour générer des jetons d' authentification utilisé pour prouver à la TA Keymaster qu'une authentification a été effectuée pour un utilisateur particulier à un moment particulier dans le temps.

Architecture

L'API Android et Keystore la Keymaster HAL sous-jacente fournit un ensemble basique mais correct des primitives cryptographiques pour permettre la mise en oeuvre des protocoles, à l'aide de touches à accès contrôlé matériel soutenu.

Le Keymaster HAL est un OEM fourni, librairie dynamique utilisé par le service Keystore pour fournir des services de chiffrement matériel soutenu. Pour garder les choses sécuriser, les implémentations HAL ne réalisent pas d'opérations sensibles dans l'espace utilisateur, ou même dans l'espace du noyau. opérations sensibles sont déléguées à un processeur sécurisé atteint grâce à une interface du noyau. L'architecture résultante ressemble à ceci:

L'accès à Keymaster

Figure 1. L' accès à Keymaster

Au sein d'un appareil Android, le « client » de la Keymaster HAL se compose de plusieurs couches (par exemple, l'application, le cadre, le démon Keystore), mais qui peut être ignorée aux fins du présent document. Cela signifie que l'API décrit Keymaster HAL est faible niveau, utilisé par les composants de la plate-forme interne, et non exposés aux développeurs d'applications. L'API de niveau supérieur est décrit sur le site des développeurs Android .

Le but de la Keymaster HAL est de ne pas mettre en œuvre les algorithmes sensibles à la sécurité, mais seulement aux demandes maréchal et désorganiser au monde sécurisé. Le format de fil est défini par l'implémentation.

Compatibilité avec les versions précédentes

Le Keymaster 1 HAL est totalement incompatible avec les HALs précédemment publiées, par exemple Keymaster 0,2 et 0,3. Pour faciliter l'interopérabilité sur les appareils fonctionnant sous Android 5.0 et versions antérieures qui a lancé avec les HALs Keymaster âgées, Keystore fournit un adaptateur qui implémente le Keymaster 1 HAL avec des appels à la bibliothèque de matériel existant. Le résultat ne peut pas fournir la gamme complète de fonctionnalités dans le Keymaster 1 HAL. En particulier, il ne supporte que les algorithmes RSA et ECDSA, et toutes les forces de l'autorisation clé est effectuée par l'adaptateur, dans le monde non sécurisé.

2 Keymaster encore simplifié l'interface HAL en enlevant les get_supported_* méthodes et permettant à la finish() méthode pour accepter l' entrée. Cela réduit le nombre d'allers-retours à la TEE dans les cas où l'entrée est tout à la fois disponible et simplifie la mise en œuvre de décryptage AEAD.

Dans Android 8.0, Keymaster 3 passe de l'ancien style C structure HAL à l'interface C ++ HAL générée à partir d'une définition dans la nouvelle définition de l'interface matérielle Langue (HIDL). Un nouveau style de mise en œuvre HAL est créée par la sous - classement généré IKeymasterDevice classe et mise en œuvre des méthodes virtuelles pures. Dans le cadre du changement, la plupart des types d'arguments ont changé, bien que les types et les méthodes ont une à une correspondance avec les anciens types et les méthodes de struct HAL.

Vue d'ensemble HIDL

La définition d'interface matérielle Langue (HIDL) fournit un mécanisme indépendant de la langue mise en œuvre pour spécifier les interfaces matérielles. L'outillage de HIDL supporte actuellement génération d'interfaces C ++ et Java. Il est prévu que la plupart implémenteurs trouveront l'outil C ++ plus pratique, de sorte que ce document ne traite que la représentation C ++ Environnement (T) Trusted Execution.

interfaces HIDL se composent d'un ensemble de méthodes, exprimée en tant que:

  methodName( INPUT ARGUMENTS ) generates ( RESULT ARGUMENTS );

Il existe différents types définis pré-et HALs peuvent définir de nouveaux types énumérés et de structure. Pour plus de détails sur HIDL, consultez la section de référence .

Un exemple de procédé de la Keymaster 3 IKeymasterDevice.hal est:

generateKey(vec<KeyParameter> keyParams)
        generates(ErrorCode error, vec<uint8_t> keyBlob,
                  KeyCharacteristics keyCharacteristics);

Ceci est l'équivalent de ce qui suit de la keymaster2 HAL:

keymaster_error_t (*generate_key)(
        const struct keymaster2_device* dev,
        const keymaster_key_param_set_t* params,
        keymaster_key_blob_t* key_blob,
        keymaster_key_characteristics_t* characteristics);

Dans la version HIDL, le dev argument est supprimé, car il est implicite. Le params argument ne soit plus une structure contenant un pointeur référençant un tableau de key_parameter_t objets, mais un vec (vecteur) contenant KeyParameter objets. Les valeurs de retour sont répertoriés dans le « generates la clause », y compris un vecteur de uint8_t valeurs pour la clé blob.

La méthode virtuelle C du produit par le compilateur HIDL est:

Return<void> generateKey(const hidl_vec<KeyParameter>& keyParams,
                         generateKey_cb _hidl_cb) override;

generate_cb est un pointeur de fonction définie comme:

std::function<void(ErrorCode error, const hidl_vec<uint8_t>& keyBlob,
                   const KeyCharacteristics& keyCharacteristics)>

Autrement dit, generate_cb est une fonction qui prend les valeurs de retour figurant dans la clause générer. La classe d'implémentation HAL remplace cette generateKey méthode et appelle le generate_cb pointeur de fonction pour retourner le résultat de l'opération à l'appelant. Notez l'appel de pointeur de fonction est synchrone. L'appelant appelle generateKey et generateKey appelle le pointeur de fonction fournie, qui exécute à son terme, le contrôle de retour à la generateKey mise en œuvre, qui retourne ensuite à l'appelant.

Pour un exemple détaillé, voir l'implémentation par défaut dans le hardware/interfaces/keymaster/3.0/default/KeymasterDevice.cpp . L'implémentation par défaut offre une compatibilité descendante pour les appareils avec style ancien keymaster0, keymaster1 ou HALS keymaster2.