Keystore (Android): Was es ist, Architektur und Funktionsprinzipien

Was ist Android Keystore?

Android Keystore ist ein kryptografischer Anbieter, der in Android ab API 1 (Android 1.0) implementiert ist, aber die vollständige Hardwareunterstützung erschien mit Android 4.3 (API 18). Keystore löst das Problem der sicheren Speicherung privater Schlüssel, sodass selbst bei Kompromittierung des Betriebssystems ein Angreifer Schlüssel nicht im Klartext extrahieren kann.

KeyStore-Architektur unter Android

Die Android Keystore-Architektur besteht aus drei Ebenen: der Anwendungs-API (java.security.KeyStore), dem Systemdienst (keystore daemon) und der Hardware-Ebene (Keymaster HAL). Die Anwendung greift über die Standard-Java Cryptography Architecture (JCA)-API zu, und der Systemdienst leitet Anfragen an den in TEE laufenden Keymaster weiter.

Alle kryptografischen Operationen mit Schlüsseln (Signieren, Entschlüsseln) werden innerhalb von TEE oder Secure Element ausgeführt. Schlüssel verlassen niemals die sichere Umgebung — die Anwendung erhält nur einen Handle (Alias) zum Referenzieren des Schlüssels. Dies ist ein grundlegender Unterschied zu Software-KeyStores, bei denen Schlüssel potenziell im Prozessspeicher zugänglich sind.

Unterschied zu Java KeyStore

Standard-JKS (Java KeyStore) oder BKS (Bouncy Castle) speichern Schlüssel in passwortgeschützten Dateien. Android Keystore speichert Schlüssel in Hardware-Isolation, wo sie sogar vor dem Root-Benutzer geschützt sind. JKS ist anfällig für direkten Dateisystemzugriff; Android Keystore nicht.

Ein weiterer Unterschied: In Android Keystore haben Schlüssel strenge Nutzungsparameter (purpose — nur sign/verify/encrypt/decrypt), die bei der Generierung festgelegt werden. Sie können später nicht geändert werden, was eine Zweckentfremdung des Schlüssels verhindert.

Wie funktioniert Android Keystore?

Beim Erstellen eines neuen Schlüssels ruft die Anwendung KeyPairGenerator oder KeyGenerator mit KeyGenParameterSpec auf, das alle Parameter des zukünftigen Schlüssels enthält. Das System leitet die Anfrage an Keymaster HAL weiter, der den Schlüssel innerhalb von TEE generiert und einen Handle zurückgibt.

Schlüsselgenerierungsprozess

Die Methode KeyGenParameterSpec.Builder akzeptiert obligatorische Parameter: Schlüsselname im Keystore, Zweck (PURPOSE_SIGN, PURPOSE_ENCRYPT), Algorithmus (RSA, EC, AES). Zusätzlich: digest (SHA-256), padding (PKCS7), userAuthenticationRequired (Biometrie), keyValidityStart/End (Zeitbeschränkungen).

Nach dem Festlegen der Parameter gibt KeyPairGenerator.generateKeyPair() ein KeyPair zurück, wobei PrivateKey ein Objekt ist, das Operationen an Keymaster delegiert. Der öffentliche Schlüssel kann extrahiert werden, der private nicht. Er existiert nur innerhalb von TEE.

import java.security.KeyPairGenerator
import android.security.keystore.KeyGenParameterSpec
import android.security.keystore.KeyProperties

fun generateKey(alias: String) {
    val spec = KeyGenParameterSpec.Builder(alias,
        KeyProperties.PURPOSE_SIGN or KeyProperties.PURPOSE_VERIFY
    ).setDigests(KeyProperties.DIGEST_SHA256)
     .setSignaturePaddings(KeyProperties.SIGN_PADDING_RSA_PKCS1)
     .setUserAuthenticationRequired(true)
     .build()

    val kpGen = KeyPairGenerator.getInstance(
        KeyProperties.KEY_ALGORITHM_RSA,
        "AndroidKeyStore"
    )
    kpGen.initialize(spec)
    kpGen.generateKeyPair()
}

Signieren und Verifizieren

Signature für ECDSA oder RSA-PSS wird über die Standard-API erstellt: Signature.getInstance(algorithm).initSign(privateKey). Der Signiervorgang wird in TEE ausgeführt: Die Anwendung übergibt Daten, Keymaster signiert sie hardwaregestützt und gibt die Signatur zurück. Schlüssel und Daten vermischen sich nicht im gemeinsamen Speicher.

Für biometrischen Schutz muss der Benutzer vor dem Signieren über BiometricPrompt authentifiziert werden. Ohne erfolgreiche Authentifizierung führt Keymaster die Operation nicht aus und gibt CryptoAuthenticationException zurück.

import java.security.KeyStore
import java.security.Signature
import androidx.biometric.BiometricPrompt

fun signWithBiometric(alias: String) {
    val ks = KeyStore.getInstance("AndroidKeyStore")
    ks.load(null)
    val entry = ks.getEntry(alias, null) as KeyStore.PrivateKeyEntry
    val signature = Signature.getInstance("SHA256withRSA")
    signature.initSign(entry.privateKey)
    // BiometricPrompt mit CryptoObject(signature) fordert FaceID/PIN an
}

KeyStore-Speichertypen

Android unterstützt zwei Schlüsselspeichermodi: Software (auf Geräten ohne TEE) und Hardware (auf Geräten mit TEE oder Secure Element). Der Modus hängt von den SoC-Fähigkeiten und der Android-Version ab.

Software-KeyStore (nur Software)

Auf Geräten ohne Trusted Execution Environment (vor Android 4.3 oder Budget-SoCs) werden Schlüssel verschlüsselt mit einem Masterschlüssel gespeichert, der aus dem Sperrbildschirm-Passwort abgeleitet wird. Dieser Modus ist weniger sicher — Schlüssel sind während kryptografischer Operationen im Prozessspeicher zugänglich.

Das Schutzniveau basiert auf der Verschlüsselung der KeyStore-Datei mit AES-256-GCM. Der Verschlüsselungsschlüssel wird aus dem Benutzerpasswort oder der PIN über Scrypt (PBKDF2 mit hoher Iterationszahl) generiert.

Hardware-KeyMaster (TEE/Secure Element)

Auf modernen Geräten wird Keymaster 4.x in TEE (ARM TrustZone) verwendet. Schlüssel werden ausschließlich innerhalb von TrustZone generiert, gespeichert und verwendet. Selbst der Linux-Kernel hat keinen Zugriff auf private Schlüssel — nur Keymaster HAL kann Operationen ausführen.

Secure Element (z.B. eSE in Samsung Knox oder StrongBox in Google Pixel 3+) ist ein separater Chip mit eigenem Prozessor und Speicher. Es ist nach Common Criteria EAL 4+ zertifiziert und bietet maximalen Schutz, einschließlich Schutz vor physischer Manipulation.

Arbeiten mit der KeyStore-API

Android Keystore ist in Java Cryptography Architecture (JCA) integriert. Für den Zugriff auf den Anbieter wird KeyStore.getInstance("AndroidKeyStore") verwendet. Die API ist ab API 18 verfügbar.

Erstellen und Laden des KeyStore

Die Methode KeyStore.load(null) lädt den KeyStore-Container der Anwendung. Es ist kein Passwort erforderlich — Android verwendet den Anwendungskontext und seine UID zur Zugriffskontrolle. Jede Anwendung sieht nur ihre eigenen Einträge, sofern keine gemeinsame UID verwendet wird.

Die Methoden setEntry und getEntry arbeiten mit KeyStore.PrivateKeyEntry, SecretKeyEntry oder TrustedCertificateEntry. Der Parameter ProtectionParameter ist für Android Keystore immer null (der Schutz ist auf Systemebene implementiert).

import java.security.KeyStore
import java.security.cert.Certificate
import android.security.keystore.KeyProtection

fun storeSecretKey(alias: String, key: SecretKey) {
    val ks = KeyStore.getInstance("AndroidKeyStore")
    ks.load(null)
    val prot = KeyProtection.Builder(
        KeyProperties.PURPOSE_ENCRYPT or KeyProperties.PURPOSE_DECRYPT
    ).setBlockModes(KeyProperties.BLOCK_MODE_GCM)
     .setEncryptionPaddings(KeyProperties.ENCRYPTION_PADDING_NONE)
     .setUserAuthenticationRequired(true)
     .build()
    ks.setEntry(alias, KeyStore.SecretKeyEntry(key), prot)
}

Überprüfung des Speichertyps

Mit KeyCharacteristics kann ermittelt werden, in welcher Umgebung der Schlüssel gespeichert ist: Software-KeyStore, TEE oder StrongBox. Die Methode getKeyCharacteristics() gibt eine Reihe von Flags zurück: FLAG_HARDWARE (keymaster), FLAG_SECURE_ELEMENT (StrongBox), FLAG_TRUSTED_USER_PRESENCE_REQUIRED (Biometrie).

Algorithmen und Sicherheit

Android Keystore unterstützt eine breite Palette kryptografischer Algorithmen, unterteilt in drei Kategorien: asymmetrische, symmetrische und MAC. Die Unterstützung spezifischer Algorithmen hängt von der Keymaster HAL-Version ab.

Unterstützte Algorithmen

RSA (1024–4096 Bit) — zum Signieren (PKCS1, PSS) und Verschlüsseln (OAEP, PKCS1). EC (P-224, P-256, P-384, P-521) — für ECDSA-Signatur und ECDH-Schlüsselvereinbarung. AES (128, 256 Bit) — für symmetrische Verschlüsselung in den Modi CBC, CTR, GCM. HMAC (SHA1, SHA256, SHA512) — zur Nachrichtenauthentifizierung.

Für jeden Schlüssel wird setPurposes angegeben, um mögliche Operationen einzuschränken. Ein RSA-Schlüssel mit PURPOSE_SIGN kann nicht zum Verschlüsseln verwendet werden, selbst wenn ein Angreifer API-Zugriff hat. Dies ist die Durchsetzung der Schlüsselverwendung auf Hardware-Ebene.

Schutz vor Kompromittierung

Keymaster enthält einen Zähler für fehlgeschlagene biometrische Authentifizierungsversuche. Nach einer bestimmten Anzahl von Fehlschlägen (konfigurierbar über setInvalidatedByBiometricEnrollment) wird der Schlüssel unbrauchbar und muss gelöscht/neu generiert werden. Wenn alle biometrischen Vorlagen entfernt werden, werden alle Schlüssel mit userAuthenticationRequired=true automatisch ungültig.

Key Attestation (Android 8.1+) wird ebenfalls unterstützt: Auf Anfrage der Anwendung signiert Keymaster ein Zertifikat mit Informationen über die Schlüsseleigenschaften (Hardware/Software, Algorithmus, Zwecke). Der Server kann dieses Zertifikat verifizieren, um zu bestätigen, dass der Schlüssel in einer vertrauenswürdigen Umgebung erstellt wurde.