Diese Seite wurde von der Cloud Translation API übersetzt.

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

Mit der Schlüsselbestätigung können Sie sich darauf verlassen, dass die in Ihrer App verwendeten Schlüssel im hardwaregestützten Keystore eines Geräts gespeichert sind. In den folgenden Abschnitten wird beschrieben, wie Sie die Eigenschaften von hardwaregestützten Schlüsseln überprüfen und die Erweiterungsdaten der Attestierungszertifikate interpretieren.

Hinweis : Bevor Sie die Eigenschaften der hardwarebasierten Schlüssel eines Geräts in einer Produktionsumgebung überprüfen, müssen Sie sicherstellen, dass das Gerät die Schlüsselbestätigung auf Hardwareebene unterstützt. Prüfen Sie dazu, ob die Attestierungszertifikatkette ein Root-Zertifikat enthält, das mit dem Google-Attestierungs-Root-Schlüssel signiert ist, und ob das attestationSecurityLevel-Element in der Datenstruktur Schlüsselbeschreibung auf die Sicherheitsstufe TrustedEnvironment oder StrongBox festgelegt ist.

Außerdem ist es wichtig, die Signaturen in der Zertifikatskette zu überprüfen und zu bestätigen, dass keiner der Schlüssel in der Kette widerrufen wurde. Dazu muss die Liste mit dem Status des Zertifikatswiderrufs geprüft werden. Wenn nicht alle gültig sind und der Root-Schlüssel der Google-Root-Schlüssel ist, vertrauen Sie der Attestierung nicht vollständig.

Hardwaregestütztes Schlüsselpaar abrufen und überprüfen

Bei der Schlüsselattestierung geben Sie den Alias eines Schlüsselpaars an und rufen die zugehörige Zertifikatskette ab, mit der Sie die Eigenschaften dieses Schlüsselpaars überprüfen können.

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 Keystore des Geräts bereitgestellt wird.

Hinweis:Auf Geräten, die mit einer Schlüsselbestätigung auf Hardwareebene, Android 7.0 (API-Level 24) oder höher und Google Play-Diensten ausgeliefert werden, wird das Stammzertifikat mit dem Google-Bestätigungsstammschlüssel signiert. Prüfen Sie, ob dieses Stammzertifikat in der Liste im Abschnitt Stammzertifikate enthalten ist.

So implementieren Sie die Schlüsselattestierung:

Verwenden Sie die Methode getCertificateChain() eines KeyStore-Objekts, um einen Verweis auf die Kette von X.509-Zertifikaten zu erhalten, die mit dem hardwaregestützten Keystore verknüpft sind.
Senden Sie die Zertifikate zur Validierung an einen separaten Server, dem Sie vertrauen.

Achtung:Führen Sie den folgenden Validierungsprozess nicht auf demselben Gerät durch. Wenn das Android-System auf diesem Gerät manipuliert wurde, kann es sein, dass beim Validierungsprozess etwas als vertrauenswürdig eingestuft wird, das nicht vertrauenswürdig ist.
Rufen Sie einen Verweis auf die Bibliothek zum Parsen und Validieren der X.509-Zertifikatskette ab, die für Ihr Toolset am besten geeignet ist. Prüfen Sie, ob das öffentliche Stammzertifikat vertrauenswürdig ist und ob 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.
Prüfen Sie optional die Zertifikaterweiterung für Bereitstellungsinformationen, die nur in neueren Zertifikatsketten vorhanden ist.

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

Weitere Informationen finden Sie im Abschnitt zur Erweiterung für Bereitstellungsinformationen.
Rufen Sie einen Verweis auf die ASN.1-Parserbibliothek ab, die für Ihr Toolset am besten geeignet ist. Suchen Sie das Zertifikat, das dem Stammzertifikat am nächsten ist und die Schlüsselbestätigungszertifikaterweiterung enthält. Wenn die Zertifikaterweiterung für die Bereitstellungsinformationen vorhanden war, muss sich die Zertifikaterweiterung für die Schlüsselbestätigung im unmittelbar nachfolgenden Zertifikat befinden. Verwenden Sie den Parser, um die Daten der Zertifikaterweiterung für die Schlüsselattestierung aus diesem Zertifikat zu extrahieren.

Achtung:Gehen Sie nicht davon aus, dass sich die Zertifikaterweiterung für die Schlüsselbestätigung im Blattzertifikat der Kette befindet. Nur dem ersten Vorkommen der Erweiterung in der Kette kann vertraut werden. Alle weiteren Instanzen der Erweiterung wurden nicht von der sicheren Hardware ausgestellt und könnten von einem Angreifer ausgestellt worden sein, der die Kette verlängert, um 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 für die Erstellung Ihres eigenen Parsers verwenden.

Weitere Informationen finden Sie im Abschnitt zum Datenschema für die Schlüsselbestätigungserweiterung.
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 Root-Zertifikat der Kette ab. Auf Android-Geräten, 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 eingeführt wurden, sollten Attestierungsschlüssel verwendet werden, die mit dem Google Hardware Attestation Root-Zertifikat signiert sind. Die Geräteattestierung war erst ab Android 8.0 (API-Ebene 26) erforderlich. Die Menge der gültigen Stammzertifikate kann als JSON-formatiertes Array heruntergeladen werden.

Root-Zertifikate

Die folgenden beiden Root-Zertifikate sollten als Vertrauensanker verwendet werden, wenn eine Zertifikatskette für die Schlüsselattestierung überprüft wird.

Das folgende Stammzertifikat wird ab dem 1. Februar 2025 zum Signieren von Attestzertifikatsketten verwendet.

Zuvor ausgestellte Root-Zertifikate

Wenn das Stammzertifikat in der Attestierungskette, die Sie erhalten, diesen öffentlichen Schlüssel enthält und keines der Zertifikate in der Kette widerrufen wurde, wissen Sie Folgendes:

Ihr Schlüssel befindet sich auf Hardware, die Google für sicher hält.
Es hat die im Attestierungszertifikat beschriebenen Eigenschaften.

Wenn die Attestierungskette einen anderen öffentlichen Stammschlüssel enthält, macht Google keine Aussagen zur Sicherheit der Hardware. Das bedeutet nicht, dass Ihr Schlüssel manipuliert wurde, sondern nur, dass die Attestierung nicht beweist, dass sich der Schlüssel in sicherer Hardware befindet. Passen Sie Ihre Sicherheitsannahmen entsprechend an.

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

Wahrscheinlich wurde das Gerät mit einer Android-Version unter 7.0 eingeführt und unterstützt keine Hardware-Attestierung. In diesem Fall hat Android eine Softwareimplementierung der Attestierung, die dieselbe Art von Attestierungszertifikat erzeugt, aber mit einem Schlüssel signiert wird, der im Android-Quellcode hartcodiert ist. Da dieser Signaturschlüssel nicht geheim ist, wurde die Attestierung möglicherweise von einem Angreifer erstellt, der vorgibt, sichere Hardware bereitzustellen.
Der andere wahrscheinliche Grund ist, dass es sich bei dem Gerät nicht um ein Google Play-Gerät handelt. In diesem Fall kann der Gerätehersteller einen eigenen Root erstellen und beliebige Behauptungen darüber aufstellen, was die Attestierung bedeutet. Weitere Informationen finden Sie in der Dokumentation des Geräteherstellers. Google ist nicht bekannt, dass Gerätehersteller dies getan haben.

Rotation des Root-Zertifikats für die Hardware-Attestierung

Google führt ein neues Root-Zertifikat für die Android-Schlüsselattestierung ein. Diese Änderung erhöht die Sicherheit und Zuverlässigkeit des Attestierungsprozesses für vertrauliche Anwendungen. Ein neuer Stammschlüssel wurde für die Android-Schlüsselbestätigung (KeyMint) generiert. Der neue Stamm ist ein ECDSA-P-384-Schlüssel. Ein ML-DSA-Schlüssel (Post-Quantum Digital Signature Algorithm) ist für die Zukunft geplant.

Maßnahmen für Entwickler

Wenn Ihre App auf Android Key Attestation basiert, fügen Sie das neue Root-Zertifikat bis Januar 2026 Ihren Trust-Stores hinzu. Laden Sie sowohl das neue als auch das alte Zertifikat von https://android.googleapis.com/attestation/root herunter.
Geräte, die Remote Key Provisioning (RKP) verwenden, erhalten ab Februar 2026 Zertifikate, die in diesem neuen Zertifikat verwurzelt sind. RKP-fähige Geräte verwenden ab dem 10. April 2026 ausschließlich den neuen Root.
Aktualisieren Sie Ihre Attestierungsprozesse so, dass sowohl die neuen als auch die vorhandenen Root-Zertifikate vertrauenswürdig sind. Ältere Geräte mit werkseitig bereitgestellten Schlüsseln unterstützen die Schlüsselrotation nicht und verwenden weiterhin den alten Root.
Das Schema der Zertifikaterweiterung selbst bleibt unverändert. Nur das Root-Zertifikat wird geändert.
Sowohl die für Menschen als auch die für Maschinen lesbare Form der neuen Root-Zertifizierungsstelle wird öffentlich verfügbar sein.

Best Practices

Fragen Sie zur Laufzeit keinen Endpunkt nach vertrauenswürdigen Stammzertifikaten ab, da dies Sicherheitsrisiken birgt. Änderungen an Roots of Trust müssen über einen formalen Prozess abgewickelt werden.

Ausphasung von Werksschlüsseln: Remote Key Provisioning (RKP)

Auf Geräten, die mit Android 16 auf den Markt kommen, wird nur RKP unterstützt. Mit dieser Richtlinie werden Werksschlüssel nach und nach abgeschafft. Sie verbessert die Bereitstellung und Verwaltung von Attestierungsschlüsseln und erweitert die Android 15-Richtlinie, in der die RKP-Unterstützung optional war. RKP verhindert das Auslesen von Schlüsseln, da das System keine Schlüssel direkt auf dem Gerät programmiert. Sie können diese Schlüssel nicht vom Gerät löschen. Wenn Sie einen Schlüssel widerrufen müssen, können Sie den Widerruf auf ein einzelnes Gerät ausrichten.

Bibliotheken für die Attestierungsüberprüfung

Verwenden Sie die Kotlin-Bibliothek zur Attestierungsüberprüfung, um Zertifikatsketten für die Schlüsselattestierung zu überprüfen. Außerdem sind in dieser Bibliothek bereits die neuen Stammzertifikate enthalten. Wenn Sie einen anderen Verifier verwenden, empfehlen wir, stattdessen zur Kotlin-Bibliothek zu wechseln. Sie ist gut getestet und deckt Grenzfälle ab, die bei benutzerdefinierten Prüfungen oft übersehen werden.

Liste des Zertifikatsperrstatus

Bestätigungsschlüssel können aus verschiedenen Gründen widerrufen werden, z. B. bei unsachgemäßer Handhabung oder wenn ein Angreifer versucht, sie zu extrahieren. Daher ist es wichtig, dass der Status jedes Zertifikats in einer Attestierungskette mit der offiziellen Liste des Zertifikatsperrstatus (Certificate Revocation List, CRL) abgeglichen wird. Diese Liste wird von Google verwaltet und unter https://android.googleapis.com/attestation/status veröffentlicht. Der Cache-Control-Header in der HTTP-Antwort bestimmt, wie oft nach Updates gesucht werden soll. Daher ist für jedes zu überprüfende Zertifikat keine Netzwerkanfrage erforderlich. Diese URL gibt eine JSON-Datei mit dem Sperrstatus für alle Zertifikate zurück, die keinen normalen gültigen Status haben. Das Format der JSON-Datei entspricht der folgenden JSON-Schema-Definition (Entwurf 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"
    }
  }
}

Richtlinie zum Sperren von Zertifikaten

Die Attestierung bildet das Fundament für die Bekämpfung von Missbrauch und für das Vertrauen in das Android-Ökosystem. Sie stellt eine kryptografisch verifizierbare Aussage für externe Parteien über den Boot-Status des Geräts bereit.

Die Zertifikate für Android-Attestierungsschlüssel werden gesperrt, wenn die Schlüssel manipuliert wurden. Das liegt an der kritischen Natur der Attestierungsgültigkeit. In diesem Abschnitt wird eine Richtlinie für den Fall beschrieben, dass Zertifikate widerrufen werden. Diese Richtlinie wird sich wahrscheinlich weiterentwickeln und im Laufe der Zeit zusätzliche Fälle umfassen.

Was qualifiziert sich für einen Widerruf?

Schlüsselverluste bei der Geräteattestierung betreffen nur den älteren Bereitstellungsmechanismus, der in Android unterstützt wird, und gelten nicht für Attestierungsschlüssel, die durch den neueren RKP-Mechanismus (Remote Key Provisioning) zertifiziert wurden.

Bei Attestierungsschlüsseln, die offengelegt wurden, können die zugehörigen Zertifikate immer gesperrt werden. Lecks können auf verschiedene Arten entdeckt werden, darunter:

Analyse von Attestierungsdaten in der Praxis.
Auffinden von Attestierungsschlüsseln in sozialen Medien oder auf anderen öffentlichen Websites.
Berichte direkt von Sicherheitsforschern.

Nach der Erkennung werden Attestierungszertifikate widerrufen, indem ihre Seriennummern der Sperrliste hinzugefügt werden. Normalerweise erfolgt dies innerhalb weniger Tage nach der Entdeckung, kann in seltenen Fällen aber auch länger dauern. Die Sperrung von Zertifikaten für geleakte Attestierungsschlüssel wird in der Regel verzögert, wenn die von der Sperrung betroffenen Geräte sicher neu bereitgestellt werden können. Auch das Ausmaß der Auswirkungen des Widerrufs ist ein wichtiger Faktor für die Widerrufsfristen.

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

Hardwaregestütztes Schlüsselpaar abrufen und überprüfen

Root-Zertifikate

Rotation des Root-Zertifikats für die Hardware-Attestierung

Maßnahmen für Entwickler

Best Practices

Ausphasung von Werksschlüsseln: Remote Key Provisioning (RKP)

Bibliotheken für die Attestierungsüberprüfung

Liste des Zertifikatsperrstatus

Richtlinie zum Sperren von Zertifikaten

Was qualifiziert sich für einen Widerruf?

Datenschema für die Schlüsselattestierungserweiterung

Bereitstellungsschema für Erweiterungsdaten