Schlüssel- und ID-Attestierung

Der Schlüsselspeicher bietet einen sichereren Ort zum Erstellen, Speichern und Verwenden kryptografischer Daten Schlüssel verwalten können. Wenn hardwaregestützter Schlüsselspeicher verfügbar ist und verwendet wird, ist das Schlüsselmaterial sicherer vor Extraktion vom Gerät Der Keymaster erzwingt Einschränkungen, die sich nur schwer umkehren lassen.

Dies trifft jedoch nur zu, wenn bekannt ist, dass sich die Schlüsselspeicherschlüssel in hardwaregestützter Speicher. In Keymaster 1 gab es keine Möglichkeit, um zuverlässig überprüfen zu können, ob dies der Fall war. Schlüsselspeicher-Daemon den verfügbaren Keymaster HAL geladen und glaubt, was auch immer der HAL sagte, in Bezug auf die Hardwaresicherung der Schlüssel.

Um dies zu beheben, hat Keymaster in Android 7.0 (Keymaster 2) die Schlüsselattestierung und die ID-Bestätigung eingeführt. Attestierung in Android 8.0 (Keymaster 3).

Die Schlüsselattestierung soll eine Möglichkeit bieten, feststellen, ob ein asymmetrisches Schlüsselpaar hardwaregestützt ist, welche Eigenschaften des Schlüssels sind und welche Einschränkungen für seine Nutzung gelten.

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

Schlüsselattestierung

Um die Schlüsselattestierung zu unterstützen, wurden mit Android 7.0 eine Reihe von Tags, Typen und zur HAL-Methode hinzu.

Tags

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

Typ

Keymaster 2 und niedriger

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

AttestKey-Methode

Keymaster 3

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

Keymaster 2 und niedriger

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 Gerätestruktur des Keymasters.
• keyToAttest ist das Schlüssel-Blob, das von generateKey, für die die Attestierung erstellt wird.
• attestParams ist eine Liste aller Parameter, die für Attestierung. Dazu gehören Tag::ATTESTATION_CHALLENGE und möglicherweise Tag::RESET_SINCE_ID_ROTATION sowie Tag::APPLICATION_ID und Tag::APPLICATION_DATA. Die Die letzten beiden sind erforderlich, um den Schlüssel-BLOB zu entschlüsseln, sofern sie angegeben wurden. während der Schlüsselgenerierung.
• certChain ist der Ausgabeparameter, der ein Array von Zertifikate. Eintrag 0 ist das Attestierungszertifikat. zertifiziert den Schlüssel von keyToAttest und enthält den Attestierungserweiterung.

Die Methode attestKey gilt als Public-Key-Vorgang auf der da er jederzeit aufgerufen werden kann und Autorisierungsbeschränkungen. Wenn für den attestierten Schlüssel beispielsweise Authentifizierung verwenden, kann eine Attestierung ohne Nutzer-Authentifizierung generiert werden. Authentifizierung.

Attestierungszertifikat

Das Attestierungszertifikat ist ein standardmäßiges X.509-Zertifikat mit einem optionalen Attestierungserweiterung, die eine Beschreibung des attestierten Schlüssels enthält. Die Das Zertifikat ist mit einem zertifizierten Attestierungsschlüssel signiert. Attestierungsschlüssel verwendet möglicherweise einen anderen Algorithmus als der attestierte Schlüssel.

Das Attestierungszertifikat enthält die Felder in der folgenden Tabelle und kann nicht keine zusätzlichen Felder enthalten. Einige Felder enthalten einen festen Feldwert. Logo: CTS Mit den Tests wird geprüft, ob der Zertifikatinhalt genau mit der Definition übereinstimmt.

Zertifikat SEQUENCE

TBSCertificate-SEQUENCE

Attestierungserweiterung

Die Erweiterung attestation enthält eine vollständige Beschreibung des Keymasters Autorisierungen, die mit dem Schlüssel verknüpft sind, in einer Struktur, die direkt zu den Autorisierungslisten, die in Android und im Keymaster HAL verwendet werden. Jedes Tag in Eine Autorisierungsliste wird durch eine ASN.1 dargestellt. SEQUENCE expliziten mit der Keymaster-Tag-Nummer, aber mit dem Typdeskriptor (vier hoch werden ausgeblendet.

Beispiel: In Keymaster 3 ist Tag::PURPOSE definiert in types.hal als ENUM_REP | 1. Für die Attestierungserweiterung wird der Wert ENUM_REP entfernt, sodass das Tag 1 beibehalten wird. (Für Keymaster 2 und niedriger wird KM_TAG_PURPOSE in keymaster_defs.h.)

Werte werden gemäß der folgenden Tabelle auf einfache Weise in ASN.1-Typen umgewandelt:

Schema

Der Inhalt der Attestierungserweiterung 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,
  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

keymasterVersion und attestationChallenge werden identifiziert, statt nach Tag, sodass die Tags in der codierten Form nur Feldtyp. Die verbleibenden Felder werden implizit wie in den Schema.

AuthorizationList-Felder

AuthorizationList-Felder sind alle optional und werden identifiziert nach Keymaster-Tag-Wert, wobei die Typ-Bits ausgeblendet sind. Da explizites Tagging verwendet wird, enthalten die Felder auch ein Tag, das angibt, ASN.1-Typ, um das Parsen zu erleichtern.

Weitere Informationen zu den Werten in den einzelnen Feldern finden Sie unter types.hal für Keymaster 3 und keymaster_defs.h für Keymaster 2 und niedriger. Namen der Keymaster-Tags wurden in Feldnamen umgewandelt, indem KM_TAG weggelassen wurde und das Ändern des Präfixes Rest des Camel-Case-Vorgangs, sodass Tag::KEY_SIZE zu keySize

RootOfTrust-Felder

Die RootOfTrust-Felder werden positionell identifiziert.

VerifiedBootState-Werte

Die Werte von 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 eine nur für einen begrenzten Zeitraum. Der Wert wird so berechnet:

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

Dabei gilt:

• T ist der "temporäre Zählerwert", der berechnet wird, indem der Wert von Tag::CREATION_DATETIME um 25.920.000.000, wobei alle Rest. T-Änderungen alle 30 Tage (259.200.000 = 30 × 24 × 60 * 60 * 1000).
• C ist der Wert von Tag::APPLICATION_ID.
• R ist 1, wenn Tag::RESET_SINCE_ID_ROTATION gleich im Parameter attest_params an den Aufruf von attest_key übergeben werden, oder 0, wenn der Wert Tag ist nicht vorhanden.
• HBK ist ein eindeutiges hardwaregebundenes Secret, das der vertrauenswürdigen Ausführungsumgebung und wird nie von ihr offengelegt. Das Secret enthält mindestens 128 Bit Entropie und ist für das jeweilige Gerät einzigartig (probabilistische Eindeutigkeit ist angesichts der 128 Bit Entropie akzeptabel). HBK sollte über HMAC oder AES_CMAC abgeleitet wird.

Kürzt die HMAC_SHA256-Ausgabe auf 128 Bit.

Attestierungsschlüssel und Zertifikate

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

Mit Android 12 wird die Remote-Schlüsselbereitstellung eingeführt und für Android 13 sind Geräte erforderlich um sie zu implementieren. Mit der Remote-Schlüsselbereitstellung erhalten Geräte im Außendienst ECDSA P256-Zertifizierungszertifikate pro Anwendung. Diese Zertifikate sind kürzer als die werkseitig bereitgestellten Zertifikate.

Mehrere IMEIs

Unter Android 14 werden nun mehrere IMEIs in den Eintrag zur Android-Schlüsselattestierung. OEMs können diese Funktion implementieren, indem sie ein KeyMint-Tag für eine zweite IMEI hinzufügen. Geräte nutzen immer häufiger mehrere Mobilfunkschnittstellen. und OEMs können jetzt Geräte mit zwei IMEIs unterstützen.

OEMs müssen eine sekundäre IMEI haben, sofern sie auf ihren Geräten vorhanden ist, um der KeyMint-Implementierung(en) bereitgestellt werden, damit diese genauso, wie sie die erste IMEI bestätigen

ID-Attestierung

Android 8.0 bietet optionale Unterstützung für die ID-Attestierung für Geräte mit Keymaster 3. Die ID-Attestierung ermöglicht es dem Gerät, seine Hardware nachzuweisen Seriennummern oder IMEI-Nummern. Dies ist zwar eine optionale Funktion, unbedingt von allen Keymaster 3-Implementierungen unterstützen. da der Nachweis der Identität des Geräts Anwendungsfälle wie wahre Zero-Touch-Remote-Konfiguration für mehr Sicherheit zu sorgen (da die Remote-Seite sicher sein, dass es mit dem richtigen Gerät kommuniziert und nicht durch Geräte-Spoofing Identität).

Bei der ID-Attestierung werden Kopien der Hardwarekennungen des Geräts erstellt auf die nur die vertrauenswürdige Ausführungsumgebung (Trusted Execution Environment, TEE) vor dem Gerät zugreifen kann die Fabrik verlässt. Ein Nutzer kann den Bootloader des Geräts entsperren und die Systemsoftware und die von den Android-Frameworks gemeldeten Kennungen. Die Kopien der Kennung im Besitz des TEE dürfen nicht auf diese Weise manipuliert werden. Sie stellen sicher, dass die Geräte-ID-Attestierung immer nur die eigene Hardwarekennungen und verhindern damit Spoofing-Versuche.

Die Haupt-API-Oberfläche für die ID-Attestierung baut auf dem vorhandenen Schlüssel auf. Attestierungsmechanismus, der mit Keymaster 2 eingeführt wurde. Wenn Sie eine Attestierungszertifikat für einen Schlüssel von Keymaster, der vom Aufrufer angefordert werden kann Die Hardwarekennung des Geräts muss in der Bescheinigung enthalten sein die Metadaten des Zertifikats an. Wenn der Schlüssel im TEE vorhanden ist, wird das Zertifikat zu einer bekannten Vertrauensbasis zurückführen. Der Empfänger eines solchen Zertifikats kann Prüfen Sie, ob das Zertifikat und sein Inhalt, einschließlich der Hardware, -Kennungen, wurden vom TEE geschrieben. Wenn Sie gebeten werden, Hardware anzugeben Kennzeichnungen im Bescheinigungszertifikat bestätigt, bestätigt das TEE nur die im Lager aufbewahrte Kennungen gemäß den Angaben für die Fabrikhalle.

Speichereigenschaften

Der Speicher mit den Gerätekennungen muss folgende Eigenschaften haben:

• Die aus den ursprünglichen Geräte-IDs abgeleiteten Werte werden an folgenden Ort kopiert: im Speicher, bevor das Gerät in fabrikneuem Zustand ist.
• Die Methode destroyAttestationIds() kann endgültig löschen der über die ID abgeleiteten Daten. Dauerhafte Vernichtung bedeutet, dass Daten vollständig entfernt, sodass weder das Zurücksetzen auf die Werkseinstellungen noch andere kann sie wiederhergestellt werden. Das ist besonders wichtig für Geräte, auf denen ein Nutzer den Bootloader entsperrt und die Systemsoftware verändert und die von Android zurückgegebenen IDs geändert wurden. Frameworks.
• RMA-Einrichtungen sollten Folgendes können: neue Kopien der von der Hardwarekennung abgeleiteten Daten generieren. Auf diese Weise Gerät, das die RMA erfolgreich abschließt, kann noch einmal eine ID-Attestierung durchführen. Die Der von RMA-Einrichtungen verwendete Mechanismus muss so geschützt sein, dass Nutzer aufrufen, da dies es ihnen ermöglichen würde, Attestierungen von gefälschte IDs.
• Nur der vertrauenswürdige Code der Keymaster App im TEE kann den aus einer ID abgeleitete Daten gespeichert werden.
• Die Speicherung ist manipulationssicher: Wenn der Inhalt des Speichers behandelt das TEE ihn genauso, als ob die Kopien der Inhalte gelöscht wurde und alle ID-Attestierungsversuche ablehnt. Dies wird implementiert, durch Signieren oder MACing des Speichers wie beschrieben unten.
• Die ursprünglichen IDs werden nicht gespeichert. Weil ID-Attestierung mit einer Herausforderung verbunden ist, stellt der Anrufer immer die IDs bereit, bestätigt haben. Das TEE muss nur überprüfen, ob diese mit den Werten übereinstimmen, die sie ursprünglich hatte. Speichern von sicheren Hashes der ursprünglichen Werte anstelle des Werte aktiviert diese Überprüfung.

Baugewerbe

Um eine Implementierung mit den oben aufgeführten Eigenschaften zu erstellen, speichern Sie den ID-abgeleitete Werte in der folgenden Konstruktion S. Speichern Sie keine weiteren Kopien von ID-Werte mit Ausnahme der normalen Stellen im System, die ein Geräteeigentümer kann durch Rooting geändert werden:

S = D || HMAC(HBK, D)

Dabei gilt:

• D = HMAC(HBK, ID1) || HMAC(HBK, ID2) || ... || HMAC(HBK, IDn)
• 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
• ID1...IDn sind die ursprünglichen ID-Werte. einer Wert eines bestimmten Index hängt von der Implementierung ab, da Geräte haben eine unterschiedliche Anzahl von IDs.
• || steht für Verkettung.

Da die HMAC-Ausgaben eine feste Größe haben, werden keine Header oder andere Strukturen erforderlich, um einzelne ID-Hashes oder den HMAC von D zu finden. Außerdem zur Prüfung der bereitgestellten Werte zur Durchführung der Attestierung müssen die Implementierungen S überprüfen, indem D aus S extrahiert, HMAC(HBK, D) berechnet und mit den Wert in S, um zu überprüfen, ob einzelne IDs verändert/beschädigt wurden. Außerdem Bei Implementierungen müssen Vergleiche mit konstanten Zeitangaben für alle einzelnen IDs verwendet werden und die Validierung von S. Der Vergleichszeitraum muss unabhängig von die Anzahl der bereitgestellten IDs und die korrekte Übereinstimmung aller Teile des Tests.

Hardware-IDs

Die ID-Attestierung unterstützt die folgenden Hardware-IDs:

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. Herstellername, wie von Build.MANUFACTURER in Android zurückgegeben
5. Modellname, wie von Build.MODEL in Android zurückgegeben
6. Seriennummer
7. IMEIs aller Funkschnittstellen
8. MEIDs aller Funkschnittstellen

Um die Geräte-ID-Attestierung zu unterstützen, werden diese IDs von einem Gerät bestätigt. Alle mit Android-Geräten haben die ersten sechs. um die Funktion zu nutzen. Wenn das Gerät über integrierte Mobilfunkverbindungen verfügt, muss auch die Attestierung für die IMEIs und/oder MEIDs der Funkschnittstellen unterstützen.

Die ID-Attestierung wird durch eine Schlüsselattestierung angefordert und die Geräte-IDs, die in der Anfrage bestätigt werden sollen. Die IDs sind mit folgenden Tags versehen:

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

Die zu bestätigende Kennung ist ein UTF-8-codierter Bytestring. Dieses Format gilt für numerische Kennzeichnungen. Jede zu bestätigende Kennung wird als UTF-8-codierter String.

Wenn das Gerät keine ID-Attestierung unterstützt (oder destroyAttestationIds() wurde bereits angerufen und das Gerät kann keine länger seine IDs bestätigen), werden alle Schlüsselattestierungsanfragen gesendet, die mindestens eine der schlagen diese Tags mit ErrorCode::CANNOT_ATTEST_IDS fehl.

Wenn das Gerät die ID-Attestierung unterstützt und mindestens eines der oben genannten Tags Schlüsselattestierungsanfrage enthalten, prüft das TEE die ID die jeweils mit der Kopie der Hardwarekennungen übereinstimmen. Wenn eine oder mehrere Kennzeichnungen nicht übereinstimmen, schlägt die gesamte Attestierung fehl mit ErrorCode::CANNOT_ATTEST_IDS Es ist gültig, dass dasselbe Tag mehrfach angegeben werden. Das kann beispielsweise beim Bestätigen von IMEIs nützlich sein: Ein Gerät kann mehrere Funkschnittstellen mit mehreren IMEIs haben. Eine Attestierungsanfrage ist gültig, wenn der mit jedem ATTESTATION_ID_IMEI angegebene Wert übereinstimmt eines der Funkschnittstellen des Geräts. Dasselbe gilt für alle anderen Tags.

Wenn die Attestierung erfolgreich ist, werden die attestierten IDs Attestierungserweiterung (OID 1.3.6.1.4.1.11129.2.1.17) des ausgestellten Bescheinigungszertifikats, mithilfe des Schemas oben. Änderungen gegenüber Keymaster 2 Attestierungsschemas sind fett formatiert und enthalten Kommentare.

Java API

Dieser Abschnitt dient nur zur Information. Keine der Keymaster-Implementierer die Java-API implementieren oder nutzen. Sie soll den Implementierern helfen, zu verstehen, wie die Funktion von Anwendungen genutzt wird. Möglicherweise wird es von Systemkomponenten verwendet Daher ist es wichtig, 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].