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 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 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 überprüfen und zu bestätigen, dass keiner der Schlüssel in der Kette widerrufen wurde. Sehen Sie dazu in der Liste mit dem Widerrufsstatus des Zertifikats nach. Wenn nicht alle gültig sind und der Stamm der Google-Stammschlüssel ist, sollten Sie der Attestierung nicht voll vertrauen.

Hardwaregestütztes Schlüsselpaar abrufen und bestätigen

Bei der Schlüsselattestierung geben Sie den Alias eines Schlüsselpaars an und rufen die 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 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, ist das Stammzertifikat mit dem Google Attestation Root Key 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 Server, dem Sie vertrauen.

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 bei der Überprüfung 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.

Holen Sie sich eine Referenz auf die CBOR-Parserbibliothek, 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 Zertifikatserweiterung für die Bereitstellungsinformationen aus diesem Zertifikat zu extrahieren.

Weitere Informationen finden Sie im Abschnitt zur Erweiterung für Bereitstellungsinformationen.
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 Zertifizierungserweiterung für die Schlüsselattestierung enthält. Wenn die Zertifikatserweiterung für die Bereitstellungsinformationen vorhanden war, muss die Zertifikatserweiterung für die Schlüsselattestierung im unmittelbar darauffolgenden Zertifikat enthalten sein. Verwenden Sie den Parser, um die Daten der Schlüsselattestierungszertifikaterweiterung aus diesem Zertifikat zu extrahieren.

Achtung:Angenommen wird nicht, dass die Schlüsselattestierungszertifikaterweiterung im Blattzertifikat der Kette enthalten ist. Nur das erste Vorkommen der Erweiterung in der Kette kann als vertrauenswürdig eingestuft werden. 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 Schlüsselattestierungserweiterung.
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 sollte.

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:

Zuvor ausgestellte Root-Zertifikate

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

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

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 nicht geheim ist, könnte die Attestierung von einem Angreifer erstellt worden sein, der vorgibt, sichere Hardware bereitzustellen.
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 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 für jedes zu prüfende Zertifikat keine 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-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"
    }
  }
}

Richtlinie zum Widerruf von Zertifikaten

Die Attestierung ist das Rückgrat von Missbrauchsprävention und Vertrauen im Android-Ökosystem. Sie stellt externen Parteien eine kryptografisch verifizierbare Erklärung über den Bootstatus des Geräts zur Verfügung.

Die Zertifikate für Android-Attestierungsschlüssel werden widerrufen, wenn die Schlüssel manipuliert werden, da die Gültigkeit der Attestierung von entscheidender Bedeutung ist. In diesem Abschnitt wird beschrieben, wann Zertifikate widerrufen werden. Diese Richtlinie wird sich wahrscheinlich weiterentwickeln und im Laufe der Zeit weitere Fälle umfassen.

In welchen Fällen kann ein Widerruf erfolgen?

Lecks von Attestierungsschlüsseln wirken sich nur auf den älteren Bereitstellungsmechanismus aus, der in Android unterstützt wird. Sie haben keine Auswirkungen auf Attestierungsschlüssel, die mit dem neueren Mechanismus zur Remote-Schlüsselbereitstellung zertifiziert sind.

Bei geleakten Attestationsschlüsseln können die Zertifikate jederzeit widerrufen werden. Es gibt verschiedene Möglichkeiten, wie Sie Lecks finden können:

Analyse von Attestierungsdaten in der Praxis
Entdeckung von Attestationsschlüsseln in sozialen Medien oder auf anderen öffentlichen Websites.
Meldungen direkt von Sicherheitsforschern

Bei der Erkennung 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 auch länger dauern. So wird der Widerruf von Zertifikaten für geleakte Attestationsschlüssel in der Regel verzögert, wenn die vom Widerruf betroffenen Geräte sicher neu bereitgestellt werden können. Die Auswirkungen des Widerrufs sind ebenfalls ein wichtiger Faktor für die Zeitspanne, in der der Widerruf wirksam wird.