Schlüssel- und ID-Beglaubigung

Keystore bietet einen sichereren Ort zum kontrollierten Erstellen, Speichern und Verwenden von kryptografischen Schlüsseln. Wenn ein hardwaregestützter Schlüsselspeicher verfügbar ist und verwendet wird, ist das Schlüsselmaterial sicherer gegen die Extraktion aus dem Gerät, und Keymaster erzwingt Beschränkungen, die schwer zu umgehen sind.

Dies gilt jedoch nur, wenn bekannt ist, dass sich die Keystore-Schlüssel in einem hardwaregestützten Speicher befinden. In Keymaster 1 gab es keine Möglichkeit für Apps oder Remote-Server, zuverlässig zu überprüfen, ob dies der Fall war. Der Keystore-Daemon lud die verfügbare Keymaster-HAL und glaubte, was auch immer die HAL in Bezug auf die Hardware-Unterstützung von Schlüsseln sagte.

Um dies zu beheben, hat Keymaster dieSchlüsselbeglaubigung in Android 7.0 (Keymaster 2) und die ID-Beglaubigung in Android 8.0 (Keymaster 3) eingeführt.

Der Schlüsselnachweis zielt darauf ab, eine Möglichkeit zu bieten, um sicher zu bestimmen, ob ein asymmetrisches Schlüsselpaar hardwaregestützt ist, welche Eigenschaften der Schlüssel hat und welche Einschränkungen auf seine Verwendung angewendet werden.

Die ID-Bestätigung ermöglicht es dem Gerät, seine Hardwarekennungen wie Seriennummer oder IMEI nachzuweisen.

Schlüsselbescheinigung

Um den Schlüsselnachweis zu unterstützen, hat Android 7.1 eine Reihe von Tags, Typen und Methoden in die HAL eingeführt.

Stichworte

• Tag::ATTESTATION_CHALLENGE
• Tag::INCLUDE_UNIQUE_ID
• Tag::RESET_SINCE_ID_ROTATION

Typ

Keymaster 2 und darunter

typedef struct {
    keymaster_blob_t* entries;
    size_t entry_count;
} keymaster_cert_chain_t;

AttestKey Methode

Schlüsselmeister 3

    attestKey(vec<uint8_t> keyToAttest, vec<KeyParameter> attestParams)
        generates(ErrorCode error, vec<vec<uint8_t>> certChain);

Keymaster 2 und darunter

keymaster_error_t (*attest_key)(const struct keymaster2_device* dev,
        const keymaster_key_blob_t* key_to_attest,
        const keymaster_key_param_set_t* attest_params,
        keymaster_cert_chain_t* cert_chain);

• dev ist die Keymaster-Gerätestruktur.
• keyToAttest ist das Schlüsselblob, das von generateKey zurückgegeben wird, für das die Beglaubigung erstellt wird.
• attestParams ist eine Liste aller für die Beglaubigung erforderlichen Parameter. Dazu gehören Tag::ATTESTATION_CHALLENGE und möglicherweise Tag::RESET_SINCE_ID_ROTATION sowie Tag::APPLICATION_ID und Tag::APPLICATION_DATA . Die beiden letzteren sind zum Entschlüsseln des Schlüsselblobs erforderlich, wenn sie während der Schlüsselgenerierung angegeben wurden.
• certChain ist der Ausgabeparameter, der ein Array von Zertifikaten zurückgibt. Eintrag 0 ist das Beglaubigungszertifikat, d. h. es beglaubigt den Schlüssel von keyToAttest und enthält die Beglaubigungserweiterung.

Die attestKey Methode wird als Public-Key-Operation für den attestierten Schlüssel betrachtet, da sie jederzeit aufgerufen werden kann und keine Autorisierungsbeschränkungen erfüllen muss. Wenn zum Beispiel der attestierte Schlüssel zur Verwendung eine Benutzerauthentifizierung benötigt, kann eine Attestierung ohne Benutzerauthentifizierung generiert werden.

Beglaubigungszertifikat

Das Beglaubigungszertifikat ist ein standardmäßiges X.509-Zertifikat mit einer optionalen Beglaubigungserweiterung, die eine Beschreibung des beglaubigten Schlüssels enthält. Das Zertifikat wird mit einem werkseitig bereitgestellten Beglaubigungsschlüssel signiert, der denselben Algorithmus verwendet wie der zu beglaubigende Schlüssel (RSA für RSA, EC für EC).

Das Beglaubigungszertifikat enthält die Felder in der folgenden Tabelle und darf keine zusätzlichen Felder enthalten. Einige Felder geben einen festen Feldwert an. CTS-Tests validieren, dass der Zertifikatsinhalt genau wie definiert ist.

Zertifikat SEQUENZ

TBSCertificate SEQUENZ

Bescheinigungserweiterung

Die attestation enthält eine vollständige Beschreibung der dem Schlüssel zugeordneten Keymaster-Berechtigungen in einer Struktur, die direkt den Berechtigungslisten entspricht, wie sie in Android und der Keymaster-HAL verwendet werden. Jedes Tag in einer Autorisierungsliste wird durch einen ASN.1 SEQUENCE -Eintrag dargestellt, der explizit mit der Keymaster-Tag-Nummer gekennzeichnet ist, aber mit dem Typdeskriptor (vier höherwertige Bits) maskiert ist.

Beispielsweise ist in Keymaster 3 Tag::PURPOSE in types.hal als ENUM_REP | 1 definiert ENUM_REP | 1 . Für die Beglaubigungserweiterung wird der Wert ENUM_REP entfernt, sodass Tag 1 übrig bleibt. (Für Keymaster 2 und darunter ist KM_TAG_PURPOSE in keymaster_defs.h definiert.)

Werte werden gemäß dieser Tabelle auf einfache Weise in ASN.1-Typen übersetzt:

Schema

Der Inhalt der Beglaubigungserweiterung wird durch das folgende ASN.1-Schema beschrieben.

KeyDescription ::= SEQUENCE {
  attestationVersion         INTEGER, # KM2 value is 1. KM3 value is 2. KM4 value is 3.
  attestationSecurityLevel   SecurityLevel,
  keymasterVersion           INTEGER,
  keymasterSecurityLevel     SecurityLevel,
  attestationChallenge       OCTET_STRING,
  uniqueId                   OCTET_STRING,
  softwareEnforced           AuthorizationList,
  teeEnforced                AuthorizationList,
}

SecurityLevel ::= ENUMERATED {
  Software                   (0),
  TrustedEnvironment         (1),
  StrongBox                  (2),
}

AuthorizationList ::= SEQUENCE {
  purpose                     [1] EXPLICIT SET OF INTEGER OPTIONAL,
  algorithm                   [2] EXPLICIT INTEGER OPTIONAL,
  keySize                     [3] EXPLICIT INTEGER OPTIONAL.
  digest                      [5] EXPLICIT SET OF INTEGER OPTIONAL,
  padding                     [6] EXPLICIT SET OF INTEGER OPTIONAL,
  ecCurve                     [10] EXPLICIT INTEGER OPTIONAL,
  rsaPublicExponent           [200] EXPLICIT INTEGER OPTIONAL,
  rollbackResistance          [303] EXPLICIT NULL OPTIONAL, # KM4
  activeDateTime              [400] EXPLICIT INTEGER OPTIONAL
  originationExpireDateTime   [401] EXPLICIT INTEGER OPTIONAL
  usageExpireDateTime         [402] EXPLICIT INTEGER OPTIONAL
  noAuthRequired              [503] EXPLICIT NULL OPTIONAL,
  userAuthType                [504] EXPLICIT INTEGER OPTIONAL,
  authTimeout                 [505] EXPLICIT INTEGER OPTIONAL,
  allowWhileOnBody            [506] EXPLICIT NULL OPTIONAL,
  trustedUserPresenceRequired [507] EXPLICIT NULL OPTIONAL, # KM4
  trustedConfirmationRequired [508] EXPLICIT NULL OPTIONAL, # KM4
  unlockedDeviceRequired      [509] EXPLICIT NULL OPTIONAL, # KM4
  allApplications             [600] EXPLICIT NULL OPTIONAL,
  applicationId               [601] EXPLICIT OCTET_STRING OPTIONAL,
  creationDateTime            [701] EXPLICIT INTEGER OPTIONAL,
  origin                      [702] EXPLICIT INTEGER OPTIONAL,
  rollbackResistant           [703] EXPLICIT NULL OPTIONAL, # KM2 and KM3 only.
  rootOfTrust                 [704] EXPLICIT RootOfTrust OPTIONAL,
  osVersion                   [705] EXPLICIT INTEGER OPTIONAL,
  osPatchLevel                [706] EXPLICIT INTEGER OPTIONAL,
  attestationApplicationId    [709] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  attestationIdBrand          [710] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  attestationIdDevice         [711] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  attestationIdProduct        [712] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  attestationIdSerial         [713] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  attestationIdImei           [714] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  attestationIdMeid           [715] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  attestationIdManufacturer   [716] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  attestationIdModel          [717] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  vendorPatchLevel            [718] EXPLICIT INTEGER OPTIONAL, # KM4
  bootPatchLevel              [719] EXPLICIT INTEGER OPTIONAL, # KM4
}

RootOfTrust ::= SEQUENCE {
  verifiedBootKey            OCTET_STRING,
  deviceLocked               BOOLEAN,
  verifiedBootState          VerifiedBootState,
  verifiedBootHash           OCTET_STRING, # KM4
}

VerifiedBootState ::= ENUMERATED {
  Verified                   (0),
  SelfSigned                 (1),
  Unverified                 (2),
  Failed                     (3),
}

KeyDescription-Felder

Die Felder keymasterVersion und attestationChallenge werden nach Position und nicht nach Tags identifiziert, sodass die Tags in der codierten Form nur den Feldtyp angeben. Die restlichen Felder werden implizit wie im Schema angegeben getaggt.

AuthorizationList-Felder

AuthorizationList -Felder sind alle optional und werden durch den Keymaster-Tag-Wert identifiziert, wobei die Typbits maskiert sind. Es wird explizites Tagging verwendet, sodass die Felder zur einfacheren Analyse auch ein Tag enthalten, das ihren ASN.1-Typ angibt.

Einzelheiten zu den Werten der einzelnen Felder finden Sie unter types.hal für Keymaster 3 und keymaster_defs.h für Keymaster 2 und darunter. Keymaster-Tag-Namen wurden in Feldnamen umgewandelt, indem das Präfix KM_TAG und der Rest in Kamelschreibweise geändert wurde, sodass Tag::KEY_SIZE zu keySize wurde.

RootOfTrust-Felder

Die RootOfTrust Felder werden positionsbezogen identifiziert.

VerifiedBootState-Werte

Die Werte verifiedBootState haben folgende Bedeutung:

SecurityLevel-Werte

Die Werte von securityLevel haben folgende Bedeutung:

Eindeutige ID

Die eindeutige ID ist ein 128-Bit-Wert, der das Gerät identifiziert, jedoch nur für einen begrenzten Zeitraum. Der Wert errechnet sich mit:

HMAC_SHA256(T || C || R, HBK)

Wo:

• T ist der "zeitliche Zählerwert", der berechnet wird, indem der Wert von Tag::CREATION_DATETIME CREATION_DATETIME durch 2592000000 geteilt wird, wobei alle Reste weggelassen werden. T ändert sich alle 30 Tage (2592000000 = 30 * 24 * 60 * 60 * 1000).
• C ist der Wert von Tag::APPLICATION_ID
• R ist 1, wenn Tag::RESET_SINCE_ID_ROTATION im attest_params-Parameter des attest_key-Aufrufs vorhanden ist, oder 0, wenn das Tag nicht vorhanden ist.
• HBK ist ein einzigartiges hardwaregebundenes Geheimnis, das der Trusted Execution Environment bekannt ist und von ihr nie preisgegeben wird. Das Geheimnis enthält mindestens 128 Entropiebits und ist für das einzelne Gerät eindeutig (probabilistische Eindeutigkeit ist angesichts der 128 Entropiebits akzeptabel). HBK sollte aus verschmolzenem Schlüsselmaterial über HMAC oder AES_CMAC abgeleitet werden.

Kürzen Sie die HMAC_SHA256-Ausgabe auf 128 Bit.

Beglaubigungsschlüssel und Zertifikate

Zwei Schlüssel, ein RSA und ein ECDSA, und die entsprechenden Zertifikatsketten werden sicher im Gerät bereitgestellt.

ID-Bescheinigung

Android 8.0 beinhaltet optionale Unterstützung für die ID-Bestätigung für Geräte mit Keymaster 3. Die ID-Bestätigung ermöglicht es dem Gerät, seine Hardwarekennungen wie Seriennummer oder IMEI nachzuweisen. Obwohl es sich um ein optionales Feature handelt, wird dringend empfohlen, dass alle Keymaster 3-Implementierungen es unterstützen, da die Möglichkeit, die Identität des Geräts nachzuweisen, Anwendungsfälle wie eine echte Zero-Touch-Remote-Konfiguration sicherer macht (weil die Remote-Seite sich dessen sicher sein kann spricht mit dem richtigen Gerät, nicht mit einem Gerät, das seine Identität vortäuscht).

Die ID-Bestätigung funktioniert, indem Kopien der Hardwarekennungen des Geräts erstellt werden, auf die nur die Trusted Execution Environment (TEE) zugreifen kann, bevor das Gerät das Werk verlässt. Ein Benutzer kann den Bootloader des Geräts entsperren und die Systemsoftware und die von den Android-Frameworks gemeldeten Kennungen ändern. Die Kopien der vom TEE gespeicherten Identifikatoren können auf diese Weise nicht manipuliert werden, wodurch sichergestellt wird, dass die Geräte-ID-Bestätigung immer nur die ursprünglichen Hardware-Identifikatoren des Geräts bestätigt, wodurch Spoofing-Versuche vereitelt werden.

Die Haupt-API-Oberfläche für die ID-Beglaubigung baut auf dem bestehenden Schlüsselbeglaubigungsmechanismus auf, der mit Keymaster 2 eingeführt wurde. Beim Anfordern eines Beglaubigungszertifikats für einen Schlüssel im Besitz von Keymaster kann der Aufrufer anfordern, dass die Hardwarekennungen des Geräts in die Metadaten des Beglaubigungszertifikats aufgenommen werden. Wenn der Schlüssel im TEE aufbewahrt wird, wird das Zertifikat zu einem bekannten Vertrauensanker zurückverkettet. Der Empfänger eines solchen Zertifikats kann verifizieren, dass das Zertifikat und sein Inhalt, einschließlich der Hardwarekennungen, von der TEE geschrieben wurden. Bei der Aufforderung, Hardwarekennungen in das Beglaubigungszertifikat aufzunehmen, attestiert das TEE nur die in seinem Speicher befindlichen Kennungen, wie sie in der Fabrikhalle vorhanden sind.

Speichereigenschaften

Der Speicher, der die Kennungen des Geräts enthält, muss diese Eigenschaften aufweisen:

• Die aus den ursprünglichen Kennungen des Geräts abgeleiteten Werte werden in den Speicher kopiert, bevor das Gerät das Werk verlässt.
• Die Methode destroyAttestationIds() kann diese Kopie der von der Kennung abgeleiteten Daten dauerhaft zerstören. Dauerhafte Zerstörung bedeutet, dass die Daten vollständig entfernt werden, sodass sie weder durch Zurücksetzen auf die Werkseinstellungen noch durch andere auf dem Gerät durchgeführte Verfahren wiederhergestellt werden können. Dies ist besonders wichtig für Geräte, bei denen ein Benutzer den Bootloader entsperrt und die Systemsoftware geändert und die von Android-Frameworks zurückgegebenen Kennungen geändert hat.
• RMA-Einrichtungen sollten in der Lage sein, neue Kopien der von der Hardwarekennung abgeleiteten Daten zu erstellen. Auf diese Weise kann ein Gerät, das die RMA durchläuft, erneut eine ID-Beglaubigung durchführen. Der von RMA-Einrichtungen verwendete Mechanismus muss geschützt werden, damit Benutzer ihn nicht selbst aufrufen können, da dies es ihnen ermöglichen würde, Bescheinigungen über gefälschte IDs zu erhalten.
• Kein anderer Code als die vertrauenswürdige Keymaster-App im TEE ist in der Lage, die von der Kennung abgeleiteten Daten im Speicher zu lesen.
• Die Aufbewahrung ist manipulationssicher: Wenn der Inhalt der Aufbewahrung verändert wurde, behandelt das TEE dies so, als ob die Kopien der Inhalte vernichtet worden wären, und verweigert alle Identitätsbescheinigungsversuche. Dies wird durch Signieren oder MACing des Speichers wie unten beschrieben implementiert .
• Der Speicher enthält nicht die ursprünglichen Identifikatoren. Da es sich bei der ID-Beglaubigung um eine Abfrage handelt, liefert der Aufrufer immer die zu beglaubigenden Identifikatoren. Der TEE muss nur überprüfen, ob diese mit den ursprünglichen Werten übereinstimmen. Das Speichern sicherer Hashes der ursprünglichen Werte anstelle der Werte ermöglicht diese Überprüfung.

Konstruktion

Um eine Implementierung mit den oben aufgeführten Eigenschaften zu erstellen, speichern Sie die von der ID abgeleiteten Werte in der folgenden Konstruktion S. Speichern Sie keine anderen Kopien der ID-Werte, mit Ausnahme der normalen Stellen im System, die ein Gerätebesitzer durch Rooten ändern kann:

S = D || HMAC(HBK, D)

wo:

• D = HMAC(HBK, ID 1 ) || HMAC(HBK, ID 2 ) || ... || HMAC(HBK, ID n )
• HMAC ist die HMAC-Konstruktion mit einem geeigneten sicheren Hash (SHA-256 empfohlen)
• HBK ist ein hardwaregebundener Schlüssel, der für keinen anderen Zweck verwendet wird
• ID 1 ...ID n sind die ursprünglichen ID-Werte; Die Zuordnung eines bestimmten Werts zu einem bestimmten Index ist implementierungsabhängig, da verschiedene Geräte eine unterschiedliche Anzahl von Kennungen haben
• || steht für Verkettung

Da die HMAC-Ausgaben eine feste Größe haben, sind keine Header oder andere Strukturen erforderlich, um einzelne ID-Hashes oder den HMAC von D zu finden , Berechnen von HMAC(HBK, D) und Vergleichen mit dem Wert in S, um zu verifizieren, dass keine einzelnen IDs modifiziert/beschädigt wurden. Außerdem müssen Implementierungen konstante Zeitvergleiche für alle einzelnen ID-Elemente und die Validierung von S verwenden. Die Vergleichszeit muss konstant sein, unabhängig von der Anzahl der bereitgestellten IDs und der korrekten Übereinstimmung aller Teile des Tests.

Hardware-Identifikatoren

Die ID-Bestätigung unterstützt die folgenden Hardwarekennungen:

1. Markenname, wie von Build.BRAND in Android zurückgegeben
2. Gerätename, wie von Build.DEVICE in Android zurückgegeben
3. Produktname, wie von Build.PRODUCT in Android zurückgegeben
4. Name des Herstellers, wie von Build.MANUFACTURER in Android zurückgegeben
5. Modellname, wie von Build.MODEL in Android zurückgegeben
6. Seriennummer
7. IMEIs aller Radios
8. MEIDs aller Funkgeräte

Um den Geräte-ID-Nachweis zu unterstützen, bestätigt ein Gerät diese Kennungen. Alle Geräte mit Android haben die ersten sechs und sie sind notwendig, damit diese Funktion funktioniert. Wenn das Gerät über integrierte Mobilfunkgeräte verfügt, muss das Gerät auch die Bestätigung für die IMEIs und/oder MEIDs der Funkgeräte unterstützen.

Die ID-Beglaubigung wird angefordert, indem eine Schlüsselbeglaubigung durchgeführt und die zu beglaubigenden Gerätekennungen in die Anfrage aufgenommen werden. Die Identifikatoren sind gekennzeichnet als:

• ATTESTATION_ID_BRAND
• ATTESTATION_ID_DEVICE
• ATTESTATION_ID_PRODUCT
• ATTESTATION_ID_MANUFACTURER
• ATTESTATION_ID_MODEL
• ATTESTATION_ID_SERIAL
• ATTESTATION_ID_IMEI
• ATTESTATION_ID_MEID

Der zu bestätigende Bezeichner ist eine UTF-8-codierte Bytezeichenfolge. Dieses Format gilt auch für numerische Bezeichner. Jede zu bestätigende Kennung wird als UTF-8-codierte Zeichenfolge ausgedrückt.

Wenn das Gerät keine ID-Bestätigung unterstützt (oder destroyAttestationIds() zuvor aufgerufen wurde und das Gerät seine IDs nicht mehr bestätigen kann), schlägt jede Schlüsselbestätigungsanforderung, die eines oder mehrere dieser Tags enthält, mit ErrorCode::CANNOT_ATTEST_IDS .

Wenn das Gerät die ID-Beglaubigung unterstützt und ein oder mehrere der oben genannten Tags in einer Schlüsselbeglaubigungsanforderung enthalten sind, überprüft das TEE, dass die mit jedem der Tags gelieferte Kennung mit seiner Kopie der Hardware-Kennungen übereinstimmt. Wenn eine oder mehrere Kennungen nicht übereinstimmen, schlägt die gesamte Attestierung mit ErrorCode::CANNOT_ATTEST_IDS . Es gilt, dass derselbe Tag mehrfach geliefert wird. Dies kann zum Beispiel beim Attestieren von IMEIs nützlich sein: Ein Gerät kann mehrere Funkgeräte mit mehreren IMEIs haben. Eine Beglaubigungsanforderung ist gültig, wenn der mit jeder ATTESTATION_ID_IMEI gelieferte Wert mit einem der Funkgeräte des Geräts übereinstimmt. Gleiches gilt für alle anderen Tags.

Wenn die Beglaubigung erfolgreich ist, werden die beglaubigten IDs der Beglaubigungserweiterung (OID 1.3.6.1.4.1.11129.2.1.17) des ausgestellten Beglaubigungszertifikats hinzugefügt, wobei das Schema von oben verwendet wird. Änderungen gegenüber dem Keymaster 2-Bestätigungsschema sind fett gedruckt und kommentiert.

Java-API

Dieser Abschnitt dient nur zu Informationszwecken. Keymaster-Implementierer implementieren oder verwenden die Java-API weder. Dies wird bereitgestellt, um Implementierern zu helfen, zu verstehen, wie die Funktion von Anwendungen verwendet wird. Systemkomponenten können es unterschiedlich verwenden, weshalb es wichtig ist, dass dieser Abschnitt nicht als normativ behandelt wird.

// Create KeyPairGenerator and set generation parameters for an ECDSA key pair
// using the NIST P-256 curve.  "Key1" is the key alias.
KeyPairGenerator keyPairGenerator = KeyPairGenerator.getInstance(
    KeyProperties.KEY_ALGORITHM_EC, "AndroidKeyStore");
keyPairGenerator.initialize(
    new KeyGenParameterSpec.Builder("Key1", KeyProperties.PURPOSE_SIGN)
         .setAlgorithmParameterSpec(new ECGenParameterSpec("secp256r1"))
         .setDigests(KeyProperties.DIGEST_SHA256,
                     KeyProperties.DIGEST_SHA384,
                     KeyProperties.DIGEST_SHA512)
         // Only permit the private key to be used if the user
         // authenticated within the last five minutes.
         .setUserAuthenticationRequired(true)
         .setUserAuthenticationValidityDurationSeconds(5 * 60)
         // Request an attestation with challenge "hello world".
         .setAttestationChallenge("hello world".getBytes("UTF-8"))
         .build());
// Generate the key pair. This will result in calls to both generate_key() and
// attest_key() at the keymaster2 HAL.
KeyPair keyPair = keyPairGenerator.generateKeyPair();
// Get the certificate chain
KeyStore keyStore = KeyStore.getInstance("AndroidKeyStore");
keyStore.load(null);
Certificate[] certs = keyStore.getCertificateChain("Key1");
// certs[0] is the attestation certificate. certs[1] signs certs[0], etc.,
// up to certs[certs.length - 1].