Hardwaregestützte Attestierung für digitale Anmeldedaten implementieren

In einem typischen Ablauf zur Ausstellung digitaler Berechtigungsnachweise gemäß der OpenID for Verifiable Credential Issuance-Spezifikation (OpenID4VCI) muss ein Aussteller wissen, dass der Schlüssel im zu signierenden Berechtigungsnachweis an einem sicheren Ort gespeichert ist. Der android_keystore_attestation Beweistyp – ein Format für die Verwendung mit OpenID4VCI – enthält einen von der Hardware signierten Bericht aus dem Android-Schlüsselspeicher. So wird sichergestellt, dass der Schlüssel in einer Trusted Execution Environment (TEE) oder StrongBox gesperrt ist und nicht exportiert oder geklont werden kann.

Übersicht zur Hardware-Attestierung

Wenn ein Schlüssel im Android-Schlüsselspeicher generiert wird, kann das System ein Attestierungszertifikat generieren. Dieses Zertifikat wird mit einem Schlüssel signiert, der durch die Hardware des Geräts geschützt ist und auf eine von Google verwaltete Root of Trust zurückgeht.

Der Beweis android_keystore_attestation ist ein Array von X.509-Zertifikatsketten. Jede Kette stellt einen einzelnen Authentifizierungsschlüssel dar und ist durch ein untergeordnetes Zertifikat gefolgt von Zwischenzertifikaten strukturiert.

  • Untergeordnetes Zertifikat: Enthält den Schlüssel und eine Android-spezifische Attestierung erweiterung.
  • Zwischenzertifikate: Verbinden das untergeordnete Zertifikat mit dem Android-Root.

Bestätigungsschritte

Aussteller sollten mehrere Validierungen für die Attestierung durchführen.

  • Suchen Sie in der Kette nach dem Zertifikat, das die Android-Attestierungserweiterung enthält (in der Regel das untergeordnete Zertifikat). Dieses Zertifikat enthält die Attestierungsdaten für den Schlüssel, der vom Android-Schlüsselspeicher erstellt wurde.
  • Prüfen Sie, ob das Feld attestationChallenge in der Erweiterung mit dem von dem Protokoll bereitgestellten c_nonce übereinstimmt, um Replay-Angriffe zu verhindern.
  • Prüfen Sie den Wert aller Zusicherungen in den Erweiterungen, die Sie interessieren.
  • Führen Sie eine Sperrprüfung für die Android-Schlüsselspeicherzertifikate durch.

Die Werte im Attestierungsbeweis stammen aus verschiedenen Quellen:

  • Aussteller: Verschiedene Werte werden vom Aussteller bereitgestellt. Die häufigsten werden im Metadatenformat des Ausstellers angegeben, um eine Filterung bei der Präsentation zu ermöglichen.
  • Inhaber:Werte wie der Paketname und die Signatur stammen vom Inhaber. Diese werden nicht über Standardverfahren zur Ausstellung geteilt und müssen unabhängig vom Inhaber bezogen werden.
  • Protokoll:Werte wie die Nonce mit attestationChallenge stammen vom Protokoll.

Weitere Informationen zum Validieren der Attestierungsdaten finden Sie in den folgenden Ressourcen:

Format des Attestierungsbeweises

In einer Berechtigungsnachweisanfrage ist der Beweis android_keystore_attestation im folgenden Beispiel enthalten:

{
  "type": "array",
  "description": "An array of certificate chains. Each chain attests a single key.",
  "items": {
    "type": "array",
    "description": "An X.509 certificate chain. Each certificate is a Base64-encoded string. The first element in the chain is the leaf certificate with the extension, the last is the Android Keystore root certificate.",
    "items": {
      "type": "string",
      "description": "A single X.509 certificate (Base64-NoWrap padded DER encoded)."
    },
    "minItems": 1
  },
  "minItems": 1
}

Er wird dann im Objekt proofs einer Berechtigungsnachweisanfrage gespeichert.

{
  "credential_configuration_id": "org.iso.18013.5.1.mDL",
  "proofs": {
    "android_keystore_attestation": [
      [
        "MII...", // Leaf certificate (contains Keystore extension)
        "MII...", // Intermediate certificate
        "MII..."  // Android Root certificate
      ],
      [ "MII...", "MII...", "MII..." ] // second proof
    ]
  }
}

Format der Ausstellermetadaten

Ein Aussteller gibt die unterstützten Beweistypen an, indem er das Objekt android_keystore_attestation im Objekt proof_types_supported für eine bestimmte Berechtigungsnachweiskonfiguration einfügt.

Dies ist ein Beispiel für das Objekt android_keystore_attestation für Aussteller:

{
  "type": "object",
  "properties": {
    "proof_signing_alg_values_supported": {
      "type": "array",
      "description": "REQUIRED. As defined in OpenID4VCI 1.0 Section 12.2.4.",
      "items": {
        "type": "string",
        "description": "Cryptographic algorithm identifiers used in the proof_signing_alg_values_supported Credential Issuer metadata parameter for this proof type are case sensitive strings and SHOULD be one of those defined in [IANA.JOSE]."
      },
      "minItems": 1
    },
    "key_attestations_required": {
      "type": "object",
      "description": "OPTIONAL. Specifies the minimum attestation requirements.",
      "properties": {
        "key_mint_security_level": {
          "type": "string",
          "description": "OPTIONAL. Minimum accepted keyMintSecurityLevel. Values defined in https://source.android.com/docs/security/features/keystore/attestation#securitylevel-values.",
          "enum": ["Software", "TrustedEnvironment", "StrongBox"],
          "default": "TrustedEnvironment"
        },
        "user_auth_types": {
          "type": "array",
          "description": "OPTIONAL. A list of authentication types which can authorize the use of the key. If empty, no authentication is required. If multiple, any are allowed.",
          "items": {
            "type": "string",
            "description": "Allowed values are 'LSKF' and 'BIOMETRIC'. These values are meant to mimic the values used during the key generation process here.",
            "enum": ["LSKF", "BIOMETRIC"]
          },
          "default": []
        }
      }
    }
  },
  "required": ["proof_signing_alg_values_supported"]
}

Dies ist ein Beispiel für das äußere Objekt proof_types_supported:

{
  "credential_configurations_supported": {
    "org.iso.18013.5.1.mDL": {
      "format": "mso_mdoc",
      "doctype": "org.iso.18013.5.1.mDL",
      "cryptographic_binding_methods_supported": [
        "cose_key"
      ],
      "credential_signing_alg_values_supported": [
        -7, -9
      ],
      "proof_types_supported": {
        "android_keystore_attestation": {
          "proof_signing_alg_values_supported": [
            "ES256" // ecdsaWithSHA256
          ],
          "key_attestations_required" : {
            // OPTIONAL String - Representing the minimum accepted value for keyMintSecurityLevel values
            // defined here ("Software"|"TrustedEnvironment"|"StrongBox"). Default value: "TrustedEnvironment"
            "key_mint_security_level": "TrustedEnvironment",
            // OPTIONAL List of Strings - Representing all allowed values for userAuthType values defined here.
            // [] value will represent noAuthRequired. Default value: [].
            "user_auth_types": ["LSKF", "BIOMETRIC"]
          }
        }
      }
    }
  }
}

Zuordnung von VCI-Attestierungsansprüchen zum Android-Schlüsselspeicher

Diese Tabelle enthält eine informative Zuordnung, damit Entitäten, die mit dem Standardbeweistyp für die OpenID4VCI-Attestierung vertraut sind, nachvollziehen können, wo sich ähnliche Konzepte in der Android-Schlüsselspeicherattestierung befinden.

VCI-Attestierungsanspruch

android_keystore_attestation-Speicherort

Speicherort des erwarteten Werts

iss

Öffentlicher Schlüssel des Root-Zertifikats des Schlüsselspeichers

–

iat

creationDateTime-Wert in der Attestierungserweiterung

–

exp

Feld validUntil im untergeordneten Zertifikat

–

attested_keys

Öffentlicher Schlüssel im untergeordneten Zertifikat jeder Kette

–

key_storage

keyMintSecurityLevel-Wert in der Attestierungserweiterung

Vom Aussteller ausgewählt: Feld key_mint_security_level in den Ausstellermetadaten

user_authentication

userAuthType- und noAuthRequired-Werte in der Attestierungserweiterung

Vom Aussteller ausgewählt: Feld user_auth_types in den Ausstellermetadaten

nonce

attestationChallenge-Wert in der Attestierungserweiterung

Vom Protokoll: c_nonce Wert vom Nonce-Endpunkt, der in VCI beschrieben wird

certification

–

–

status

–

–