Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

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 sind. In den folgenden Abschnitten wird beschrieben, wie Sie die Eigenschaften von hardwaregestützten Schlüsseln überprüfen und wie Sie die Erweiterungsdaten der Attestierungszertifikate interpretieren.

Vorbereitung: Prüfen Sie, ob Ihr Gerät die Schlüsselattestierung auf Hardwareebene unterstützt.

Bevor Sie die Eigenschaften der hardwaregestützten Schlüssel eines Geräts in einer Produktionsumgebung überprüfen, müssen Sie prüfen, ob 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-Attestierungs-Root-Schlüssel signiert ist, und ob das attestationSecurityLevel Element in der Schlüsselbeschreibung Datenstruktur auf das TrustedEnvironment Sicherheitsniveau oder auf das StrongBox Sicherheitsniveau festgelegt ist.

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

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 dieser können Sie die Eigenschaften des Schlüsselpaars überprüfen.

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

So implementieren Sie die Schlüsselattestierung:

Verwenden Sie die Methode eines KeyStore Objekts getCertificateChain() , um einen Verweis auf die Kette der X.509-Zertifikate zu erhalten, die mit dem hardwaregestützten Schlüsselspeicher verknüpft sind.
Senden Sie die Zertifikate zur Überprüfung an einen separaten Server, dem Sie vertrauen.

Achtung:Führen Sie den folgenden Überprüfungsprozess auf demselben Gerät aus. Wenn das Android-System auf diesem Gerät kompromittiert ist, kann es passieren, dass der Überprüfungsprozess etwas als vertrauenswürdig einstuft, das nicht vertrauenswürdig ist.
Rufen Sie einen Verweis auf die Bibliothek zum Parsen und Überprüfen von X.509-Zertifikatsketten ab, die am besten zu Ihrem Toolset passt. Prüfen Sie, ob das öffentliche Root-Zertifikat 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.
Optional können Sie die Zertifikatserweiterung mit den Bereitstellungsinformationen prüfen, die nur in neueren Zertifikatsketten vorhanden ist.

Rufen Sie einen Verweis auf die CBOR-Parserbibliothek ab, die am besten zu Ihrem Toolset passt. Suchen Sie das Zertifikat, das dem Root-Zertifikat am nächsten ist und die Zertifikatserweiterung mit den Bereitstellungsinformationen enthält. Verwenden Sie den Parser, um die Daten der Zertifikatserweiterung mit den Bereitstellungsinformationen aus diesem Zertifikat zu extrahieren.

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

Achtung:Gehen Sie nicht davon aus, dass sich die Zertifikatserweiterung für die Schlüsselattestierung im Blattzertifikat der Kette befindet. Nur das erste Vorkommen der Erweiterung in der Kette ist vertrauenswürdig. Alle weiteren Instanzen der Erweiterung wurden nicht von der sicheren Hardware ausgestellt und möglicherweise von einem Angreifer, der die Kette erweitert hat, um gefälschte Attestierungen für nicht vertrauenswürdige Schlüssel zu erstellen.

Im Beispiel für die Schlüssel attestierung 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 der Zertifikatserweiterung für die Schlüsselattestierung.
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 bestanden haben, um die Google-App-Suite einschließlich Google Play zu erhalten, und die mit Android 7.0 (API-Level 24) oder höher auf den Markt gekommen sind, sollten Attestierung schlüssel verwendet werden, die mit dem Google-Root-Zertifikat für die Hardwareattestierung signiert sind. Die Attestierung war erst ab Android 8.0 (API-Level 26) erforderlich. Die gültigen Root-Zertifikate können als ein JSON-formatiertes Array heruntergeladen werden.

Root-Zertifikate

Die folgenden beiden Root-Zertifikate sollten als Vertrauensanker verwendet werden, wenn Sie eine Zertifikatskette für die Schlüssel attestierung überprüfen.

Zuvor ausgestellte Root-Zertifikate

Wenn das Root-Zertifikat 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 in Hardware, die Google als sicher einstuft.
Er hat die im Attestierungszertifikat beschriebenen Eigenschaften.

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

Wenn das Root-Zertifikat 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 auf den Markt gebracht und unterstützt keine Hardwareattestierung. 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 fest codiert ist. Da dieser Signaturschlüssel kein Geheimnis ist, wurde die Attestierung möglicherweise von einem Angreifer erstellt, der sich als Anbieter sicherer Hardware ausgegeben hat.
Der andere wahrscheinliche Grund ist, dass das Gerät kein Google Play-Gerät ist. In diesem Fall kann der Gerätehersteller ein eigenes Root-Zertifikat erstellen und die Bedeutung seiner Attestierungsdaten definieren. Weitere Informationen finden Sie in der Dokumentation des Geräteherstellers. Google sind keine Gerätehersteller bekannt, die dies getan haben.

Rotation von Root-Zertifikaten für die Hardwareattestierung

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 sensible Anwendungen. Für die Android-Schlüsselattestierung (KeyMint) wurde ein neuer Root-Schlüssel generiert. Der neue Root-Schlüssel ist ein ECDSA P-384-Schlüssel.

So geht es weiter

Wenn Ihre App auf die Android-Schlüsselattestierung angewiesen ist, fügen Sie die neuen Root-Zertifikate bis zum 31. März 2026 Ihren Vertrauens speichern hinzu. Laden Sie sowohl das neue als auch das alte Zertifikat von https://android.googleapis.com/attestation/root herunter.
Geräte, die die Remote-Schlüsselbereitstellung (Remote Key Provisioning, RKP) verwenden, erhalten ab Februar 2026 Zertifikate, die auf diesem neuen Zertifikat basieren. Geräte mit aktivierter RKP verwenden ab dem 10. April 2026 ausschließlich das neue Root-Zertifikat.
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 das alte Root-Zertifikat.
Das Schema der Zertifikatserweiterung bleibt unverändert. Nur das Root-Zertifikat ändert sich.
Sowohl die für Menschen als auch die für Maschinen lesbare Form des neuen Root-Zertifikats sind öffentlich verfügbar.

Best Practices

Fragen Sie zur Laufzeit keinen Endpunkt nach vertrauenswürdigen Root-Zertifikaten ab, da dies Sicherheitsrisiken birgt. Änderungen an Root-Zertifikaten sollten über einen formellen Prozess abgewickelt werden.

Auslaufen von werkseitigen Schlüsseln: Remote-Schlüsselbereitstellung (Remote Key Provisioning, RKP)

Auf Geräten, die mit Android 16 auf den Markt kommen, wird nur RKP unterstützt. Mit dieser Richtlinie werden werkseitige Schlüssel auslaufen. Sie verbessert die Bereitstellung und Verwaltung von Attestierungsschlüsseln und erweitert die Android 15-Richtlinie, bei der die RKP-Unterstützung optional war. RKP verhindert das Auslaufen 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 beschränken.

Bibliotheken zur 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 die neuen Root-Zertifikate bereits in diese Bibliothek integriert. Wenn Sie einen anderen Verifizierer verwenden, empfehlen wir, stattdessen zur Kotlin-Bibliothek zu wechseln. Sie ist gut getestet und deckt Grenzfälle ab, die bei benutzerdefinierten Verifizierern oft übersehen werden.

Liste mit dem Status des Zertifikatswiderrufs

Attestierungsschlüssel können aus verschiedenen Gründen widerrufen werden, z. B. bei unsachgemäßer Handhabung oder wenn ein Angreifer sie möglicherweise extrahiert hat. Daher ist es wichtig, den Status jedes Zertifikats in einer Attestierungskette mit der offiziellen Liste mit dem Status des Zertifikatswiderrufs (Certificate Revocation List, CRL) zu vergleichen. 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, sodass nicht für jedes zu überprüfende Zertifikat eine Netzwerkanfrage erforderlich ist. Diese URL gibt eine JSON-Datei mit dem Widerrufsstatus für alle Zertifikate zurück, die keinen normalen gültigen Status haben. Das Format der JSON-Datei entspricht der folgenden JSON-Schema (Entwurf 07) Definition:

{
  "$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 Zertifikatssperrliste:

{
  "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 für den Zertifikatswiderruf

Die Attestierung ist das Rückgrat der Missbrauchsprävention und des Vertrauens im Android-Ökosystem. Sie liefert externen Parteien eine kryptografisch verifizierbare Aussage zum Bootmodus des Geräts.

Die Zertifikate für Android-Attestierungsschlüssel werden widerrufen, wenn die Schlüssel kompromittiert sind, da die Gültigkeit der Attestierung von kritischer Natur ist. In diesem Abschnitt wird eine Richtlinie für den Widerruf von Zertifikaten beschrieben. Diese Richtlinie wird sich wahrscheinlich weiterentwickeln und im Laufe der Zeit weitere Fälle umfassen.

Was qualifiziert für den Widerruf?

Für Attestierungsschlüssel, die geleakt wurden, können die Zertifikate immer widerrufen werden. Lecks können auf verschiedene Weise entdeckt werden, z. B.:

Analyse von Attestierungsdaten in freier Wildbahn
Entdeckung von Attestierungsschlüsseln in sozialen Medien oder auf anderen öffentlichen Websites
Berichte direkt von Sicherheitsforschern

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

Hardwaregestützte Schlüsselpaare mit Schlüsselattestierung prüfen Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Vorbereitung: Prüfen Sie, ob Ihr Gerät die Schlüsselattestierung auf Hardwareebene unterstützt.

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

Root-Zertifikate

Rotation von Root-Zertifikaten für die Hardwareattestierung

So geht es weiter

Best Practices

Auslaufen von werkseitigen Schlüsseln: Remote-Schlüsselbereitstellung (Remote Key Provisioning, RKP)

Bibliotheken zur Attestierungsüberprüfung

Liste mit dem Status des Zertifikatswiderrufs

Richtlinie für den Zertifikatswiderruf

Was qualifiziert für den Widerruf?

Datenschema der Zertifikatserweiterung für die Schlüsselattestierung

Datenschema der Zertifikatserweiterung mit den Bereitstellungsinformationen

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