Diese Seite wurde von der Cloud Translation API übersetzt.

Hardwaregestützte Schlüsselpaare mit Schlüsselattestierung prüfen

Die Schlüsselattestierung gibt Ihnen mehr Sicherheit, dass die in Ihrer App verwendeten Schlüssel im hardwaregestützten Schlüsselspeicher eines Geräts gespeichert werden. In den folgenden Abschnitten wird beschrieben, wie Sie die Eigenschaften hardwaregestützter Schlüssel überprüfen und die Erweiterungsdaten der Attestierungszertifikate interpretieren.

Hinweis: Bevor Sie die Eigenschaften der hardwaregestützten Schlüssel eines Geräts in einer Produktionsumgebung prüfen, müssen Sie sich vergewissern, dass das Gerät die Schlüsselattestierung auf Hardwareebene unterstützt. Prüfen Sie dazu, ob die Attestierungszertifikatskette ein Root-Zertifikat enthält, das mit dem Google Attestation Root Key signiert ist, und ob das attestationSecurityLevel-Element in der Schlüsselbeschreibung-Datenstruktur auf die Sicherheitsebene TrustedEnvironment oder StrongBox festgelegt ist.

Außerdem ist es wichtig, die Signaturen in der Zertifikatskette zu verifizieren und sicherzustellen, dass keiner der Schlüssel in der Kette widerrufen wurde. Überprüfen Sie dazu die Statusliste der Zertifikatssperrung. Wenn alle gültig sind und das Stammverzeichnis der Google-Root-Schlüssel ist, vertrauen Sie der Attestierung nicht vollständig. Beachten Sie jedoch, dass Geräte mit widerrufenen Zertifikaten mindestens genauso vertrauenswürdig sind wie Geräte, die nur die Softwareattestierung unterstützen. Eine vollständig gültige Attestierung ist ein starker positiver Indikator. Wenn Sie keine haben, ist das ein neutraler, nicht negativer Indikator.

Hardwaregestütztes Schlüsselpaar abrufen und bestätigen

Bei der Schlüsselattestierung geben Sie den Alias eines Schlüsselpaars an und rufen dessen Zertifikatskette ab. Damit können Sie die Attribute dieses Schlüsselpaars prüfen.

Wenn das Gerät die Schlüsselattestierung auf Hardwareebene unterstützt, wird das Stammzertifikat in dieser Kette mit einem Attestierungsstammschlüssel signiert, der sicher im hardwaregestützten Schlüsselspeicher des Geräts bereitgestellt wird.

Hinweis:Auf Geräten, die mit Schlüsselattestierung auf Hardwareebene, Android 7.0 (API-Level 24) oder höher und Google Play-Diensten ausgeliefert werden, wird das Root-Zertifikat mit dem Root-Schlüssel der Google-Attestierung signiert. Prüfen Sie, ob dieses Stammzertifikat zu den im Abschnitt Stamzertifikate aufgeführten gehört.

So implementieren Sie die Schlüsselattestierung:

Verwenden Sie die Methode getCertificateChain() eines KeyStore-Objekts, um eine Referenz auf die Kette der X.509-Zertifikate zu erhalten, die mit dem hardwaregestützten Schlüsselspeicher verknüpft sind.
Senden Sie die Zertifikate zur Validierung an einen separaten vertrauenswürdigen Server.

Achtung: Führen Sie den folgenden Validierungsprozess nicht auf demselben Gerät wie der Schlüsselspeicher aus. Wenn das Android-System auf diesem Gerät manipuliert wurde, kann das dazu führen, dass im Rahmen des Validierungsprozesses etwas als vertrauenswürdig eingestuft wird, das es nicht ist.
Holen Sie sich eine Referenz auf die für Ihr Toolset am besten geeignete Bibliothek zum Parsen und Validieren von X.509-Zertifikatsketten. Prüfen Sie, ob das öffentliche Stammzertifikat vertrauenswürdig ist und jedes Zertifikat das nächste Zertifikat in der Kette signiert.
Prüfen Sie den Widerrufsstatus jedes Zertifikats, um sicherzustellen, dass keines der Zertifikate widerrufen wurde.
Optional können Sie die Zertifikatserweiterung für Bereitstellungsinformationen prüfen, die nur in neueren Zertifikatsketten vorhanden ist.

Rufen Sie eine Referenz auf die CBOR-Parserbibliothek ab, die für Ihr Toolset am besten geeignet ist. Suchen Sie das Zertifikat, das sich am nächsten am Stammzertifikat befindet und die Zertifikaterweiterung für Bereitstellungsinformationen enthält. Verwenden Sie den Parser, um die Daten der Zertifikaterweiterung mit den Bereitstellungsinformationen aus diesem Zertifikat zu extrahieren.

Weitere Informationen finden Sie im Abschnitt zum Datenschema der Informationserweiterung für die Bereitstellung.
Rufen Sie eine Referenz auf die ASN.1-Parserbibliothek ab, die für Ihr Toolset am besten geeignet ist. Suchen Sie das Zertifikat, das sich am nächsten am Stammzertifikat befindet und die Erweiterung für das Zertifikat zur Schlüsselattestierung enthält. Wenn die Zertifikatserweiterung für Bereitstellungsinformationen vorhanden war, muss die Zertifikatserweiterung für die Schlüsselattestierung im unmittelbar darauffolgenden Zertifikat enthalten sein. Verwenden Sie den Parser, um die Daten zur Attestierungszertifikaterweiterung aus diesem Zertifikat zu extrahieren.

Achtung: Angenommen wird nicht, dass die Erweiterung des Zertifikats für die Schlüsselattestierung im Blattzertifikat der Kette enthalten ist. Nur das erste Vorkommen der Erweiterung in der Kette kann vertrauenswürdig sein. Alle weiteren Instanzen der Erweiterung wurden nicht von der sicheren Hardware ausgestellt und könnten von einem Angreifer stammen, der die Kette verlängert, während er versucht, gefälschte Attestierungen für nicht vertrauenswürdige Schlüssel zu erstellen.

Im Beispiel für die Schlüsselattestierung wird der ASN.1-Parser von Bouncy Castle verwendet, um die Erweiterungsdaten eines Attestierungszertifikats zu extrahieren. Sie können dieses Beispiel als Referenz verwenden, wenn Sie Ihren eigenen Parser erstellen.

Weitere Informationen finden Sie im Abschnitt zum Datenschema der Attestierungserweiterungsschlüssel.
Prüfen Sie die Erweiterungsdaten, die Sie in den vorherigen Schritten abgerufen haben, auf Konsistenz und vergleichen Sie sie mit den Werten, die der hardwaregestützte Schlüssel enthalten soll.

Root-Zertifikate

Die Vertrauenswürdigkeit der Attestierung hängt vom Stammzertifikat der Kette ab. Android-Geräte, die die erforderlichen Tests für die Google-App-Suite, einschließlich Google Play, bestanden haben und mit Android 7.0 (API-Level 24) oder höher ausgeliefert wurden, sollten Attestierungsschlüssel verwenden, die mit dem Stammzertifikat für die Hardwareattestierung von Google signiert sind. Die Attestierung war erst ab Android 8.0 (API-Ebene 26) erforderlich. Der öffentliche Stammschlüssel lautet wie folgt:

Zuvor ausgestellte Root-Zertifikate

Wenn das Root-Zertifikat in der Attestierungskette diesen öffentlichen Schlüssel enthält und keines der Zertifikate in der Kette zurückgezogen wurde, wissen Sie Folgendes:

Ihr Schlüssel befindet sich in Hardware, die Google als sicher einstuft.
Sie hat die im Attestierungszertifikat beschriebenen Attribute.

Wenn die Attestationskette einen anderen öffentlichen Stammschlüssel hat, übernimmt Google keine Gewähr für die Sicherheit der Hardware. Das bedeutet nicht, dass Ihr Schlüssel manipuliert wurde, sondern nur, dass die Attestierung nicht beweist, dass sich der Schlüssel auf sicherer Hardware befindet. Passen Sie Ihre Sicherheitsannahmen entsprechend an.

Wenn das Stammzertifikat den öffentlichen Schlüssel auf dieser Seite nicht enthält, gibt es zwei wahrscheinliche Gründe:

Höchstwahrscheinlich wurde das Gerät mit einer Android-Version unter 7.0 ausgeliefert und unterstützt keine Hardwareattestierung. In diesem Fall hat Android eine Softwareimplementierung der Attestierung, die dieselbe Art von Attestierungszertifikat generiert, aber mit einem Schlüssel signiert ist, der im Android-Quellcode hartcodiert ist. Da dieser Signaturschlüssel kein Secret ist, wurde die Attestierung möglicherweise von einem Angreifer erstellt, der sich als sichere Hardware ausgibt.
Ein weiterer wahrscheinlicher Grund ist, dass es sich nicht um ein Google Play-Gerät handelt. In diesem Fall kann der Gerätehersteller seinen eigenen Stamm erstellen und beliebige Behauptungen darüber aufstellen, was die Attestierung bedeutet. Weitere Informationen finden Sie in der Dokumentation des Geräteherstellers. Google ist derzeit nicht bekannt, dass Gerätehersteller dies tun.

Liste mit dem Status der Zertifikatssperrung

Attestierungsschlüssel können aus verschiedenen Gründen widerrufen werden, z. B. bei unsachgemäßer Handhabung oder bei Verdacht auf Extraktion durch einen Angreifer. Daher ist es wichtig, dass der Status jedes Zertifikats in einer Attestierungskette mit der offiziellen CRL (Certificate Revocation Status List) abgeglichen wird. Diese Liste wird von Google verwaltet und unter folgendem Link veröffentlicht: https://android.googleapis.com/attestation/status. Der Cache-Control-Header in der HTTP-Antwort gibt an, wie oft nach Updates gesucht werden soll, sodass nicht für jedes zu prüfende Zertifikat eine Netzwerkanfrage erforderlich ist. Diese URL gibt eine JSON-Datei mit dem Widerrufsstatus aller Zertifikate zurück, die keinen normalen gültigen Status haben. Das Format der JSON-Datei entspricht der folgenden JSON-Schemadefinition (draft 07):

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "properties": {
    "entries": {
      "description" : "Each entry represents the status of an attestation key. The dictionary-key is the certificate serial number in lowercase hex.",
      "type": "object",
      "propertyNames": {
        "pattern": "^[a-f1-9][a-f0-9]*$"
      },
      "additionalProperties": {
        "type": "object",
        "properties": {
          "status": {
            "description": "[REQUIRED] Current status of the key.",
            "type": "string",
            "enum": ["REVOKED", "SUSPENDED"]
          },
          "expires": {
            "description": "[OPTIONAL] UTC date when certificate expires in ISO8601 format (YYYY-MM-DD). Can be used to clear expired certificates from the status list.",
            "type": "string",
            "format": "date"
          },
          "reason": {
            "description": "[OPTIONAL] Reason for the current status.",
            "type": "string",
            "enum": ["UNSPECIFIED", "KEY_COMPROMISE", "CA_COMPROMISE", "SUPERSEDED", "SOFTWARE_FLAW"]
          },
          "comment": {
            "description": "[OPTIONAL] Free form comment about the key status.",
            "type": "string",
            "maxLength": 140
          }
        },
        "required": ["status"],
        "additionalProperties": false
      }
    }
  },
  "required": ["entries"],
  "additionalProperties": false
}

Beispiel für eine CRL:

{
  "entries": {
    "2c8cdddfd5e03bfc": {
      "status": "REVOKED",
      "expires": "2020-11-13",
      "reason": "KEY_COMPROMISE",
      "comment": "Key stored on unsecure system"
    },
    "c8966fcb2fbb0d7a": {
      "status": "SUSPENDED",
      "reason": "SOFTWARE_FLAW",
      "comment": "Bug in keystore causes this key malfunction b/555555"
    }
  }
}

Datenschema für die Schlüsselattestierungserweiterung

Die Erweiterung für die Schlüsselattestierung hat die OID 1.3.6.1.4.1.11129.2.1.17. Die Erweiterung speichert die Informationen gemäß einem ASN.1-Schema.

Die folgende Liste enthält eine Beschreibung der einzelnen Elemente im Schema:

KeyDescription

Diese Sequenz von Werten enthält allgemeine Informationen zum Schlüsselpaar, das über die Schlüsselattestierung überprüft wird, und bietet einfachen Zugriff auf zusätzliche Details.

attestationVersion

Die Version des Schlüsselattestierungsfeatures.

Wert	Version
1	Keymaster-Version 2.0
2	Keymaster-Version 3.0
3	Keymaster-Version 4.0
4	Keymaster Version 4.1
100	KeyMint Version 1.0
200	KeyMint Version 2.0
300	KeyMint Version 3.0

attestationSecurityLevel

Das Sicherheitsniveau der Attestierung.

Warnung:Es ist zwar möglich, Schlüssel zu bestätigen, die im Android-System gespeichert sind, also wenn der Wert von attestationSecurityLevel auf „Software“ gesetzt ist. Sie können diesen Attestierungen jedoch nicht vertrauen, wenn das Android-System manipuliert wird.

keymasterVersion/keyMintVersion

Die Version der Hardware-Abstraktionsschicht (HAL) von Keymaster oder KeyMint.

Wert	Version
0	Keymaster-Version 0.2 oder 0.3
1	Keymaster-Version 1.0
2	Keymaster-Version 2.0
3	Keymaster-Version 3.0
4	Keymaster-Version 4.0
41	Keymaster-Version 4.1
100	KeyMint Version 1.0
200	KeyMint Version 2.0
300	KeyMint-Version 3.0

keymasterSecurityLevel/keyMintSecurityLevel

Die Sicherheitsstufe der Keymaster/KeyMint-Implementierung.

attestationChallenge

Enthält die Herausforderung, die beim Erstellen des Schlüssels angegeben wurde. Prüfen Sie, ob dieser Wert mit dem von Ihrem Server bereitgestellten Wert übereinstimmt, der im Autorisierungs-Tag Tag::ATTESTATION_CHALLENGE gespeichert ist. Andernfalls ist Ihr Dienst möglicherweise anfällig für das Replaying alter Attestierungszertifikate.

uniqueId

Dieser Wert identifiziert das Gerät, aber nur für einen begrenzten Zeitraum. Es wird berechnet und nur von Systemanwendungen verwendet. In allen anderen Apps ist uniqueId leer.

softwareEnforced

Optional. Die Autorisierungsliste von Keymaster / KeyMint, die vom Android-System und nicht von der Trusted Execution Environment (TEE) des Geräts erzwungen wird. Die Informationen in dieser Autorisierungsliste werden durch Code erfasst oder generiert, der zur Plattform gehört und in der Systempartition des Geräts gespeichert wird. Der Inhalt dieser Autorisierungsliste kann als vertrauenswürdig eingestuft werden, solange auf dem Gerät ein Betriebssystem ausgeführt wird, das dem Sicherheitsmodell der Android-Plattform entspricht. Alle zertifizierten Android-Geräte entsprechen diesem Sicherheitsmodell. Wenn das Gerät also gesperrt ist und der Status des Verified Boot Verified ist, sollten die hier angegebenen Werte zuverlässig sein. Auf einem modifizierten Gerät, bei dem der Bootloader entsperrt ist, kann der Nutzer ein Betriebssystem installieren, das nicht dem Android-Plattformsicherheitsmodell entspricht. Daher können die Werte in diesem Feld vom Nutzer willkürlich ausgewählt werden.

hardwareEnforced

Optional. Die Autorisierungsliste von Keymaster / KeyMint, die von der vertrauenswürdigen Ausführungsumgebung (Trusted Execution Environment, TEE) des Geräts erzwungen wird. Die Informationen in dieser Autorisierungsliste werden durch Code erfasst oder generiert, der Teil der sicheren Hardware ist und nicht von der Plattform gesteuert wird. Informationen in dieser Autorisierungsliste stammen beispielsweise aus dem Bootloader des Geräts oder aus dem TEE, das auf dem Gerät ausgeführt wird. Felder in dieser Autorisierungsliste, die nicht direkt von KeyMint festgelegt werden, werden von anderen Teilen der sicheren Hardware (z. B. dem Bootloader) über sichere Kommunikationskanäle bereitgestellt, die kein Vertrauen in die Plattform erfordern. Der Unterschied zwischen der sicheren Hardware und dem Android-System besteht darin, dass der Nutzer den Code, der auf der sicheren Hardware ausgeführt wird (die Firmware), nicht ändern kann. Er kann also die Werte in dieser Autorisierungsliste nicht manipulieren.

Sicherheitsniveau

Diese Datenstruktur gibt an, inwieweit eine Softwarefunktion, z. B. ein Schlüsselpaar, basierend auf ihrer Position im Gerät geschützt ist.

Da es sich bei der Datenstruktur um eine Aufzählung handelt, nimmt sie genau einen der folgenden Werte an:

Schlüsselspeicher: Die Logik zum Erstellen und Verwalten der Funktion ist im Android-System implementiert. Für das Erstellen und Speichern von Schlüsselpaaren ist dieser Speicherort weniger sicher als der TEE, aber sicherer als der Prozessbereich Ihrer App.
Vertrauenswürdige Umgebung: Die Logik zum Erstellen und Verwalten der Funktion wird in sicherer Hardware wie einer TEE implementiert. Für das Erstellen und Speichern von Schlüsselpaaren ist dieser Speicherort sicherer, da sichere Hardware sehr widerstandsfähig gegen Remote-Manipulation ist.
StrongBox: Die Logik zum Erstellen und Verwalten der Funktion ist in einem speziellen Hardware-Sicherheitsmodul implementiert. Für das Erstellen und Speichern von Schlüsselpaaren ist dieser Speicherort sicherer, da er sehr widerstandsfähig gegen Remote-Manipulationen und Hardwareangriffe auf das Modul ist.
Software: Die Logik zum Erstellen und Verwalten der Funktion wird in einer KeyMint- oder Keymaster-Implementierung implementiert, die nicht in einer sicheren Umgebung ausgeführt wird. Für das Erstellen und Speichern von Schlüsselpaaren ist dieser Speicherort weniger sicher als der TEE, aber sicherer als der Prozessbereich Ihrer App.

Autorisierungsliste

Diese Datenstruktur enthält die Eigenschaften des Schlüsselpaars selbst, wie sie in der Hardware-Abstraktionsschicht (HAL) von Keymaster oder KeyMint definiert sind. Sie vergleichen diese Werte mit dem aktuellen Status des Geräts oder mit einer Reihe von erwarteten Werten, um zu prüfen, ob ein Schlüsselpaar noch für die Verwendung in Ihrer App gültig ist.

Jeder Feldname entspricht einem ähnlich benannten Keymaster-/KeyMint-Autorisierungs-Tag. Das Feld keySize in einer Autorisierungsliste entspricht beispielsweise dem Autorisierungs-Tag Tag::KEY_SIZE.

Die AIDL-Schnittstellenspezifikation enthält die endgültigen Informationen zu Autorisierungs-Tags. Damit werden der ID-Wert und -Typ jedes Tags definiert. Außerdem wird angegeben, ob jedes Tag in der hardwareEnforced-Autorisierungsliste enthalten sein muss (wodurch angegeben wird, dass das Tag in der sicheren Umgebung erzwungen wird) oder in der softwareEnforced-Autorisierungsliste (damit das Tag von Android, in der Regel von Keystore, erzwungen wird).

Alle Felder in der folgenden Liste sind optional:

purpose

Entspricht dem Autorisierungs-Tag Tag::PURPOSE, das den Tag-ID-Wert 1 verwendet.

algorithm

Entspricht dem Autorisierungs-Tag Tag::ALGORITHM, für das die Tag-ID 2 verwendet wird.

In einem Attestierungsobjekt vom Typ AuthorizationList ist der Algorithmuswert immer RSA oder EC.

keySize

Entspricht dem Autorisierungs-Tag Tag::KEY_SIZE, für das die Tag-ID 3 verwendet wird.

digest

Entspricht dem Autorisierungs-Tag Tag::DIGEST, das den Tag-ID-Wert 5 verwendet.

padding

Entspricht dem Autorisierungs-Tag Tag::PADDING, für das die Tag-ID 6 verwendet wird.

ecCurve

Entspricht dem Autorisierungs-Tag Tag::EC_CURVE, für das die Tag-ID 10 verwendet wird.

Die Parameter, die zum Generieren eines elliptischen-Kurven-Schlüsselpaars (EC) verwendet werden, das ECDSA für die Signatur und Überprüfung im Android-System-Schlüsselspeicher verwendet.

rsaPublicExponent

Entspricht dem Autorisierungs-Tag Tag::RSA_PUBLIC_EXPONENT, für das die Tag-ID 200 verwendet wird.

mgfDigest

Nur bei einer Schlüsselattestierungsversion von mindestens 100 vorhanden.

Entspricht dem Tag::RSA_OAEP_MGF_DIGEST-KeyMint-Autorisierungs-Tag mit der Tag-ID 203.

rollbackResistance

Nur in der Schlüsselattestierungsversion 3 oder höher vorhanden.

Entspricht dem Autorisierungs-Tag Tag::ROLLBACK_RESISTANT, für das die Tag-ID 303 verwendet wird.

earlyBootOnly

Nur vorhanden in Version der Schlüsselattestierung >= 4.

Entspricht dem Autorisierungs-Tag Tag::EARLY_BOOT_ONLY, das den Tag-ID-Wert 305 verwendet.

activeDateTime

Entspricht dem Autorisierungs-Tag Tag::ACTIVE_DATETIME, für das die Tag-ID 400 verwendet wird.

originationExpireDateTime

Entspricht dem Tag::ORIGINATION_EXPIRE_DATETIME-Keymaster-Autorisierungs-Tag, für das die Tag-ID 401 verwendet wird.

usageExpireDateTime

Entspricht dem Autorisierungs-Tag Tag::USAGE_EXPIRE_DATETIME, für das die Tag-ID 402 verwendet wird.

usageCountLimit

Entspricht dem Autorisierungs-Tag Tag::USAGE_COUNT_LIMIT, für das die Tag-ID 405 verwendet wird.

noAuthRequired

Entspricht dem Autorisierungs-Tag Tag::NO_AUTH_REQUIRED, für das die Tag-ID 503 verwendet wird.

userAuthType

Entspricht dem Autorisierungs-Tag Tag::USER_AUTH_TYPE, für das die Tag-ID 504 verwendet wird.

authTimeout

Entspricht dem Autorisierungs-Tag Tag::AUTH_TIMEOUT, für das die Tag-ID 505 verwendet wird.

allowWhileOnBody

Entspricht dem Autorisierungs-Tag Tag::ALLOW_WHILE_ON_BODY, für das die Tag-ID 506 verwendet wird.

Ermöglicht die Verwendung des Schlüssels nach Ablauf des Zeitlimits für die Authentifizierung, wenn der Nutzer das Gerät noch am Körper trägt. Ein sicherer Körpersensor bestimmt, ob das Gerät am Körper des Nutzers getragen wird.

trustedUserPresenceRequired

Nur vorhanden in Version der Schlüsselattestierung >= 3.

Entspricht dem Autorisierungs-Tag::TRUSTED_USER_PRESENCE_REQUIRED-Tag mit der Tag-ID 507.

Gibt an, dass dieser Schlüssel nur verwendet werden kann, wenn der Nutzer einen Nachweis seiner physischen Präsenz vorgelegt hat. Beispiele:

Bei einem StrongBox-Schlüssel: eine Hardwaretaste, die direkt mit einer Kontaktfläche auf dem StrongBox-Gerät verbunden ist.
Bei einem TEE-Schlüssel dient die Fingerabdruckauthentifizierung als Nachweis der Anwesenheit, solange der TEE die ausschließliche Kontrolle über den Scanner hat und den Abgleich des Fingerabdrucks durchführt.

trustedConfirmationRequired

Nur in Schlüsselattestierungsversionen ≥ 3 vorhanden.

Entspricht dem Autorisierungs-Tag::TRUSTED_CONFIRMATION_REQUIRED-Tag mit der Tag-ID 508.

Gibt an, dass der Schlüssel nur verwendet werden kann, wenn der Nutzer die zu signierenden Daten mit einem Genehmigungstoken bestätigt. Weitere Informationen zum Abrufen der Nutzerbestätigung finden Sie unter Android-geschützte Bestätigung.

Hinweis: Dieses Tag gilt nur für Schlüssel mit dem Zweck SIGN.

unlockedDeviceRequired

Nur in Schlüsselattestierungsversionen ≥ 3 vorhanden.

Entspricht dem Autorisierungs-Tag::UNLOCKED_DEVICE_REQUIRED-Tag mit der Tag-ID 509.

allApplications

Entspricht dem Autorisierungs-Tag Tag::ALL_APPLICATIONS, das den Tag-ID-Wert 600 verwendet.

Gibt an, ob alle Apps auf einem Gerät auf das Schlüsselpaar zugreifen können.

applicationId

Entspricht dem Autorisierungs-Tag Tag::APPLICATION_ID, für das die Tag-ID 601 verwendet wird.

creationDateTime

Entspricht dem Autorisierungs-Tag Tag::CREATION_DATETIME mit der Tag-ID 701.

origin

Entspricht dem Autorisierungs-Tag Tag::ORIGIN, für das die Tag-ID 702 verwendet wird.

rollbackResistant

Nur in den Schlüsselattestierungsversionen 1 und 2 vorhanden.

Entspricht dem Autorisierungs-Tag Tag::ROLLBACK_RESISTANT, für das die Tag-ID 703 verwendet wird.

rootOfTrust

Entspricht dem Autorisierungs-Tag Tag::ROOT_OF_TRUST, für das die Tag-ID 704 verwendet wird.

Weitere Informationen finden Sie im Abschnitt zur Datenstruktur RootOfTrust.

osVersion

Entspricht dem Autorisierungs-Tag Tag::OS_VERSION, für das die Tag-ID 705 verwendet wird.

Die Version des Android-Betriebssystems, die dem Keymaster zugeordnet ist, angegeben als sechsstellige Ganzzahl. Beispiel: Version 8.1.0 wird als 080100 dargestellt.

Nur Keymaster-Version 1.0 oder höher enthält diesen Wert in der Autorisierungsliste.

osPatchLevel

Entspricht dem Autorisierungs-Tag Tag::PATCHLEVEL, das den Tag-ID-Wert 706 verwendet.

Der Monat und das Jahr, die mit dem Sicherheitspatch verknüpft sind, der in Keymaster verwendet wird, angegeben als sechsstellige Ganzzahl. Der Patch für August 2018 wird beispielsweise als 201808 dargestellt.

Nur Keymaster Version 1.0 oder höher nimmt diesen Wert in die Autorisierungsliste auf.

attestationApplicationId

Nur in Schlüsselattestierungsversionen ≥ 2 vorhanden.

Entspricht dem Keymaster-Autorisierungs-Tag Tag::ATTESTATION_APPLICATION_ID, das den Tag-ID-Wert 709 verwendet.

Weitere Informationen finden Sie im Abschnitt zur Datenstruktur AttestationApplicationId.

attestationIdBrand

Nur in Schlüsselattestierungsversionen >= 2 vorhanden.

Entspricht dem Keymaster-Tag Tag::ATTESTATION_ID_BRAND mit der Tag-ID 710.

attestationIdDevice

Nur in Schlüsselattestierungsversionen >= 2 vorhanden.

Entspricht dem Keymaster-Tag Tag::ATTESTATION_ID_DEVICE mit der Tag-ID 711.

attestationIdProduct

Nur in Schlüsselattestierungsversionen >= 2 vorhanden.

Entspricht dem Keymaster-Tag Tag::ATTESTATION_ID_PRODUCT mit der Tag-ID 712.

attestationIdSerial

Nur in Schlüsselattestierungsversionen >= 2 vorhanden.

Entspricht dem Keymaster-Tag Tag::ATTESTATION_ID_SERIAL mit der Tag-ID 713.

attestationIdImei

Nur in Schlüsselattestierungsversionen >= 2 vorhanden.

Entspricht dem Autorisierungs-Tag Tag::ATTESTATION_ID_IMEI, für das die Tag-ID 714 verwendet wird.

attestationIdMeid

Nur in Schlüsselattestierungsversionen ≥ 2 vorhanden.

Entspricht dem Autorisierungs-Tag Tag::ATTESTATION_ID_MEID, für das die Tag-ID 715 verwendet wird.

attestationIdManufacturer

Nur in Schlüsselattestierungsversionen ≥ 2 vorhanden.

Entspricht dem Autorisierungs-Tag Tag::ATTESTATION_ID_MANUFACTURER mit der Tag-ID 716.

attestationIdModel

Nur in Schlüsselattestierungsversionen >= 2 vorhanden.

Entspricht dem Autorisierungs-Tag Tag::ATTESTATION_ID_MODEL, für das die Tag-ID 717 verwendet wird.

vendorPatchLevel

Nur in Schlüsselattestierungsversionen ≥ 3 vorhanden.

Entspricht dem Autorisierungs-Tag::VENDOR_PATCHLEVEL-Tag mit der Tag-ID 718.

Gibt die Sicherheitspatch-Ebene des Anbieter-Images an, die auf dem Gerät installiert sein muss, damit dieser Schlüssel verwendet werden kann. Der Wert wird im Format JJJJMMTT angezeigt und entspricht dem Datum des Sicherheitspatches des Anbieters. Wenn beispielsweise ein Schlüssel auf einem Android-Gerät generiert wurde, auf dem der Sicherheitspatch des Anbieters vom 1. August 2018 installiert ist, würde dieser Wert 20180801 lauten.

bootPatchLevel

Nur in Schlüsselattestierungsversionen ab 3 vorhanden.

Entspricht dem Autorisierungs-Tag Tag::BOOT_PATCHLEVEL, das den Tag-ID-Wert 719 verwendet.

Gibt die Sicherheitspatch-Ebene des Kernel-Images an, die auf dem Gerät installiert sein muss, damit dieser Schlüssel verwendet werden kann. Der Wert wird im Format JJJJMMTT angezeigt und entspricht dem Datum des Systemsicherheits-Patches. Wenn ein Schlüssel beispielsweise auf einem Android-Gerät generiert wurde, auf dem der Sicherheitspatch vom 5. August 2018 installiert ist, lautet dieser Wert 20180805.

deviceUniqueAttestation

Nur in Schlüsselattestierungsversionen >= 4 vorhanden.

Entspricht dem Autorisierungs-Tag::DEVICE_UNIQUE_ATTESTATION-Tag mit der Tag-ID 720.

attestationIdSecondImei

Nur in Schlüsselattestierungsversionen ≥ 300 vorhanden.

Entspricht dem Autorisierungs-Tag Tag::ATTESTATION_ID_SECOND_IMEI, das den Tag-ID-Wert 723 verwendet.

RootOfTrust

Diese Werte enthalten wichtige Informationen zum Status des Geräts.

Alle Felder in der folgenden Liste sind erforderlich:

verifiedBootKey

Ein sicherer Hash des Schlüssels, mit dem das System-Image verifiziert wird. Wir empfehlen, für diesen Hash den SHA-256-Algorithmus zu verwenden.

deviceLocked

„True“, wenn der Bootloader des Geräts gesperrt ist. Dadurch wird die Überprüfung des verifizierten Bootmodus aktiviert und verhindert, dass ein nicht signiertes Geräte-Image auf das Gerät geflasht wird. Weitere Informationen zu dieser Funktion finden Sie in der Dokumentation zum Überprüfen des Starts.

verifiedBootState

Der Bootstatus des Geräts gemäß der Funktion „Verifizierter Bootmodus“.

verifiedBootHash

Nur in Schlüsselattestierungsversionen ≥ 3 vorhanden.

Ein Digest aller Daten, die durch Verified Boot geschützt sind. Bei Geräten, die die Android-Implementierung des bestätigten Bootmodus verwenden, enthält dieser Wert den Hashwert der VBMeta-Struktur oder der Metadatenstruktur des bestätigten Bootmodus.

Weitere Informationen zur Berechnung dieses Werts finden Sie im VBMeta-Digest.

VerifiedBootState

Diese Datenstruktur gibt den aktuellen Bootstatus des Geräts an, der den Schutz für Nutzer und Apps nach dem Start des Geräts darstellt. Weitere Informationen zu dieser Funktion finden Sie im Abschnitt Bootstatus der Dokumentation zum Überprüfen des Starts.

Diese Datenstruktur ist eine Aufzählung und kann genau einen der folgenden Werte annehmen:

Bestätigt

Gibt eine vollständige Vertrauenskette an, die den Bootloader, die Bootpartition und alle geprüften Partitionen umfasst.

Wenn sich das Gerät in diesem Bootstatus befindet, ist verifiedBootKey der Hash des in das Gerät eingebetteten Zertifikats, das der Gerätehersteller dem ROM des Geräts bei der Werkseinstellung hinzufügt.

SelfSigned

Gibt an, dass die Bootpartition des Geräts mit dem im Gerät eingebetteten Zertifikat überprüft wurde und die Signatur gültig ist.

Wenn sich das Gerät in diesem Bootstatus befindet, ist verifiedBootKey der Hash eines vom Nutzer installierten Zertifikats, das eine Bootpartition signiert, die der Nutzer anstelle der ursprünglichen, vom Hersteller bereitgestellten Bootpartition auf dem Gerät hinzufügt.

Nicht verifiziert

Gibt an, dass der Nutzer das Gerät frei ändern kann. Daher ist der Nutzer für die Überprüfung der Geräteintegrität verantwortlich.

Fehlgeschlagen

Gibt an, dass die Überprüfung des Geräts fehlgeschlagen ist. Im Attestierungszertifikat darf dieser Wert für VerifiedBootState niemals verwendet werden.

AttestationApplicationId

Diese Datenstruktur spiegelt die Ansicht der Android-Plattform wider, welche Apps das geheime Schlüsselmaterial unter Attestierung verwenden dürfen. Die ID kann mehrere Pakete umfassen, wenn und nur wenn mehrere Pakete dieselbe UID haben. Der Oktettstring ist selbst nach dem folgenden ASN.1-Schema formatiert:

AttestationApplicationId ::= SEQUENCE {
    package_infos  SET OF AttestationPackageInfo,
    signature_digests  SET OF OCTET_STRING,
}

AttestationPackageInfo ::= SEQUENCE {
    package_name  OCTET_STRING,
    version  INTEGER,
}

package_infos

Eine Reihe von AttestationPackageInfo-Objekten, von denen jedes den Namen und die Versionsnummer eines Pakets angibt.

signature_digests

Eine Reihe von SHA-256-Digests der Signaturzertifikate der App. Eine App kann mehrere Zertifikatsketten für Signaturschlüssel haben. Für jedes wird das untergeordnete Zertifikat gehasht und in das Feld signature_digests eingefügt. Der Feldname ist irreführend, da es sich bei den verarbeiteten Daten aus den Signaturzertifikaten der Anwendung und nicht um die Anwendungssignaturen handelt, da er nach der Klasse Signature benannt ist, die durch einen Aufruf von getPackageInfo() zurückgegeben wird. Das folgende Code-Snippet zeigt einen Beispielsatz:

{SHA256(PackageInfo.signature[0]), SHA256(PackageInfo.signature[1]), ...}

Schema für Bereitstellungsinformationen für Erweiterungsdaten

Die Erweiterung für Bereitstellungsinformationen hat die OID 1.3.6.1.4.1.11129.2.1.30. Die Erweiterung enthält Informationen, die dem Bereitstellungsserver über das Gerät bekannt sind. Diese Erweiterung folgt einem CDDL-Schema.

  {
        1 : int,   ; certificates issued
  }

Die Karte ist nicht versioniert und neue optionale Felder können hinzugefügt werden.

certs_issued: Eine ungefähre Anzahl der Zertifikate, die für das Gerät in den letzten 30 Tagen ausgestellt wurden. Dieser Wert kann als Signal für potenziellen Missbrauch verwendet werden, wenn er um mehrere Größenordnungen über dem Durchschnitt liegt.