Keystore in Android — was es ist, Architektur und Kryptografie

Was ist Keystore in Android?

Android Keystore — ein Systemkomponente der Android-Plattform, die eine API zum Generieren, Speichern und Verwenden kryptografischer Schlüssel in einer geschützten Umgebung bereitstellt. Im Gegensatz zu Software-Kryptobibliotheken (Bouncy Castle, Conscrypt) garantiert Keystore, dass private Schlüssel den isolierten Ausführungsbereich niemals verlassen.

Keystore erschien erstmals in Android 4.3 (API 18) als Softwareanbieter mit RSA-Unterstützung. Ab Android 6.0 (API 23) erhielt Keystore Hardwareunterstützung durch die Keymaster Hardware Abstraction Layer (HAL), die kryptografische Operationen an die Trusted Execution Environment (TEE) auf kompatiblen Geräten delegiert. Laut Android Compatibility Definition Document (2025) müssen alle Geräte mit Android 9+ hardwaregestützten Keystore über TEE oder StrongBox unterstützen.

Schlüssel in Keystore werden durch einen Alias identifiziert — eine Zeichenfolge, die beim Erstellen oder Laden eines Schlüssels übergeben wird. Keystore erlaubt keinen Zugriff auf das rohe Schlüsselmaterial: getEncoded()-Methoden geben null für in Keystore erstellte Schlüssel zurück. Dies ist ein grundlegender Unterschied zu Softwareschlüsseln — ein Angreifer kann den privaten Schlüssel selbst bei vollständiger Kontrolle über das Gerät nicht extrahieren.

Keystore ist in andere Android-Sicherheitsmechanismen integriert: biometrische Authentifizierung (BiometricPrompt), dateibasierte Verschlüsselung (File-Based Encryption) und SafetyNet/Play Integrity-Verifizierungsfunktionen. Schlüssel können für die automatische Löschung unter bestimmten Bedingungen konfiguriert werden: bei Entfernung des Passcodes, bei Hinzufügen eines neuen Fingerabdrucks oder bei Ablauf.

Android Keystore Architektur

Die Android Keystore-Architektur umfasst drei Implementierungsebenen, die sich im Grad des Hardwareschutzes unterscheiden. Die Ebene hängt von den Hardware-Fähigkeiten des Geräts ab.

Hardwaregestützter Keystore (TEE)

TEE (Trusted Execution Environment) — ein isolierter Bereich, der parallel zum Hauptbetriebssystem auf demselben Prozessor läuft. TEE verwendet die ARM TrustZone-Technologie, die den physischen Prozessorkern in zwei virtuelle Kerne aufteilt: Normal World (Android) und Secure World (TEE). Code in Secure World hat Zugriff auf Speicher und Peripherie, die von Normal World aus nicht zugänglich sind.

Wenn eine App einen kryptografischen Vorgang über Keystore aufruft, wird die Anfrage über Keymaster HAL an TEE weitergeleitet, wo der Vorgang hardwaregestützt ausgeführt wird. Das Ergebnis wird an die App zurückgegeben, aber der private Schlüssel bleibt im geschützten Speicher von TEE. TEE ist für die Einhaltung des GlobalPlatform TEE Protection Profile zertifiziert und eine verbindliche Anforderung für Android 9+ auf Geräten mit TrustZone-fähigen Prozessoren.

TEE unterstützt die Algorithmen AES/GCM (128, 256 Bit), RSA (2048, 4096 Bit), EC (P-256, P-384, P-521) und HMAC-SHA256. Die Leistung von TEE ist geringer als die von Software-Kryptografie (um 20–40 %), aber bei typischen Operationen (JWT-Signierung, Sitzungsschlüsselentschlüsselung) übersteigt die Latenz 10–50 ms nicht.

StrongBox Keymaster

StrongBox — ein dedizierter Sicherheitschip, physisch getrennt vom Hauptprozessor. Im Gegensatz zu TEE, das die Prozessorzeit mit Android teilt, verfügt StrongBox über eine eigene CPU, RAM, einen echten Zufallszahlengenerator (TRNG) und einen sicheren Speicher (One-Time Programmable Memory). StrongBox ist nach Common Criteria EAL 4+ und Secure IC Protection Profile zertifiziert.

StrongBox ist auf Geräten mit Android 9+ verfügbar, sofern der entsprechende Chip vorhanden ist (z. B. Titan M auf Google Pixel, Knox auf Samsung Galaxy). Der Entwickler aktiviert StrongBox über das Flag setIsStrongBoxBacked(true) in KeyGenParameterSpec. Wenn keine Hardwareunterstützung verfügbar ist, wird das Flag ignoriert und Keystore fällt auf TEE zurück.

StrongBox-Einschränkungen: unterstützt einen begrenzten Satz von Algorithmen (AES-256, EC P-256, HMAC-SHA256), die Operationswarteschlange — nicht mehr als eine gleichzeitig, die Anzahl der Operationen — durch Chipressourcen begrenzt. StrongBox ist nicht für hochbelastete Szenarien ausgelegt — verwenden Sie TEE für häufige Operationen und StrongBox nur für kritische Schlüssel (Master-Verschlüsselungsschlüssel, Signierschlüssel).

Softwarebasierter Keystore

Softwarebasierter Keystore ist eine Softwareimplementierung, die auf Geräten ohne Hardwareunterstützung für TEE oder StrongBox verwendet wird. Schlüssel werden verschlüsselt im Dateisystem gespeichert, aber der private Schlüssel kann vorübergehend im RAM entschlüsselt werden. Software-Keystore ist weniger sicher — ein Angreifer mit Root-Zugriff kann den Schlüssel im Speicher abfangen.

Ab Android 12 (API 31) verlangt Google hardwaregestützten Keystore für alle neuen Geräte. Geräte mit Android 9–11 können auf Budgetmodellen über einen softwarebasierten Keystore verfügen. Der Entwickler kann das Schutzniveau über KeyStore.getKeyCharacteristics() überprüfen — das Attribut SECURITY_LEVEL_TRUSTED_ENVIRONMENT oder SECURITY_LEVEL_STRONGBOX bestätigt den Hardwareschutz.

Unterstützte Algorithmen und Funktionen

Android Keystore unterstützt eine breite Palette kryptografischer Algorithmen, die je nach Schlüsseltyp in Kategorien unterteilt sind. Die Wahl des Algorithmus beeinflusst Leistung, Kompatibilität und Sicherheitsniveau.

AES (Advanced Encryption Standard) — symmetrische Verschlüsselung zum Schutz von Daten auf dem Gerät. Empfohlener Modus: AES/GCM/NoPadding (256 Bit). GCM bietet authentifizierte Verschlüsselung (AEAD) — Integritätsprüfung verschlüsselter Daten. IV-Größe (Initialisierungsvektor): 12 Byte für GCM. Verwenden Sie kein AES/ECB — es bietet keinen angemessenen Schutz.

RSA (Rivest–Shamir–Adleman) — asymmetrische Verschlüsselung zum Schutz von Sitzungsschlüsseln und digitalen Signaturen. Empfohlene Größe: 2048 oder 4096 Bit. Modi: RSA/ECB/PKCS1Padding (Verschlüsselung) und RSA/ECB/PKCS1Sign (Signatur). RSA 1024 gilt als veraltet und wird für neue Anwendungen nicht empfohlen (NIST SP 800-131A Rev. 2).

EC (Elliptic Curve) — asymmetrische Kryptografie auf elliptischen Kurven für Signatur und Schlüsselaustausch. Unterstützte Kurven: secp256r1 (P-256, obligatorisch), secp384r1 (P-384) und secp521r1 (P-521). EC bietet vergleichbare Sicherheit wie RSA bei deutlich geringerer Schlüsselgröße. P-256 wird für die meisten Szenarien empfohlen: es wird von allen Geräten unterstützt und bietet ein 128-Bit-Sicherheitsniveau.

HMAC (Hash-based Message Authentication Code) — symmetrische Nachrichtenauthentifizierung. Unterstützte Hash-Funktionen: SHA-256, SHA-384, SHA-512. HMAC wird zur Überprüfung der Datenintegrität und -authentizität verwendet, z. B. zur Verifizierung von Webhook-Anfragen oder zur Prüfung der Konfigurationsintegrität.

Alle Algorithmen können über KeyGenParameterSpec.Builder.setUserAuthenticationRequired(true) an die biometrische Authentifizierung gebunden werden. Unter Android 11+ ist das Flag setUserAuthenticationParameters() mit einem Timeout (in Sekunden) verfügbar, während dessen der Schlüssel nach der biometrischen Authentifizierung ohne erneute Anfrage verfügbar ist.

Codebeispiele: Schlüsselgenerierung und -verwendung

Sehen wir uns praktische Beispiele für die Arbeit mit Android Keystore in Kotlin an: Generieren eines AES-Schlüssels, Verschlüsseln von Daten und Erstellen eines asymmetrischen Paares für Signaturen.

AES-Schlüssel in Keystore generieren

Das Beispiel erstellt einen 256-Bit-AES/GCM-Schlüssel mit biometrischer Authentifizierungsbindung. Der Schlüssel kann nicht über getEncoded() exportiert werden.

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

private val keyStore = KeyStore.getInstance("AndroidKeyStore").apply { load(null) }

fun generateAesKey(alias: String) {
    val spec = KeyGenParameterSpec.Builder(
        alias,
        KeyProperties.PURPOSE_ENCRYPT or
        KeyProperties.PURPOSE_DECRYPT
    )
    .setKeySize(256)
    .setBlockModes(KeyProperties.KEY_BLOCK_MODE_GCM)
    .setEncryptionPaddings(KeyProperties.ENCRYPTION_PADDING_NONE)
    .setUserAuthenticationRequired(true)
    .setInvalidatedByBiometricEnrollment(true)
    .build()

    val generator = KeyGenerator.getInstance(
        KeyProperties.KEY_ALGORITHM_AES,
        "AndroidKeyStore"
    )
    generator.init(spec)
    generator.generateKey()
}

AES/GCM-Datenverschlüsselung

Das Beispiel verschlüsselt Daten mit einem Schlüssel aus Android Keystore. Cipher erhält den Schlüssel per Alias, initialisiert die AES/GCM-Verschlüsselung und gibt die verschlüsselten Daten zusammen mit dem IV zurück.

fun encryptData(alias: String, plaintext: ByteArray): ByteArray {
    val cipher = Cipher.getInstance("AES/GCM/NoPadding")
    val secretKey = keyStore.getKey(alias, null) as SecretKey
    cipher.init(Cipher.ENCRYPT_MODE, secretKey)

    val iv = cipher.getIV()
    val encrypted = cipher.doFinal(plaintext)

    // IV + verschlüsselte Daten
    return iv + encrypted
}

fun decryptData(alias: String, ciphertextWithIv: ByteArray): ByteArray {
    val iv = ciphertextWithIv.copyOfRange(0, 12)
    val encrypted = ciphertextWithIv.copyOfRange(12, ciphertextWithIv.size)

    val cipher = Cipher.getInstance("AES/GCM/NoPadding")
    val secretKey = keyStore.getKey(alias, null) as SecretKey
    val spec = GCMParameterSpec(128, iv)
    cipher.init(Cipher.DECRYPT_MODE, secretKey, spec)

    return cipher.doFinal(encrypted)
}

RSA-Schlüsselpaar für Signaturen generieren

Das Beispiel erstellt ein RSA-2048-Schlüsselpaar in Keystore mit StrongBox-Bindung. Der private Schlüssel wird zum Signieren verwendet, der öffentliche Schlüssel kann über getEncoded() exportiert werden.

fun generateRsaKeyPair(alias: String) {
    val spec = KeyGenParameterSpec.Builder(
        alias,
        KeyProperties.PURPOSE_SIGN or
        KeyProperties.PURPOSE_VERIFY
    )
    .setKeySize(2048)
    .setSignaturePaddings(
        KeyProperties.SIGNATURE_PADDING_RSA_PKCS1
    )
    .setDigests(KeyProperties.DIGEST_SHA256)
    .setIsStrongBoxBacked(true)
    .build()

    val pair = KeyPairGenerator.getInstance(
        KeyProperties.KEY_ALGORITHM_RSA,
        "AndroidKeyStore"
    ).apply { init(spec) }
     .generateKeyPair()

    // Öffentlicher Schlüssel kann exportiert werden
    val publicKey = pair.public // X509EncodedKeySpec
}

Bewährte Praktiken für Android Keystore

Die effektive Nutzung von Android Keystore erfordert die Einhaltung von Regeln, die maximalen Schutz bei gleichzeitiger Leistungserhaltung gewährleisten.

Verwenden Sie KeyGenParameterSpec mit den minimal notwendigen Parametern: geben Sie nur die Purpose, Block-Modi und Paddings an, die tatsächlich verwendet werden. Redundante Parameter (z. B. PURPOSE_ENCRYPT für einen Schlüssel, der nur zum Signieren verwendet wird) erzeugen unnötige Angriffsvektoren. Android empfiehlt, den Digest für Signaturen explizit anzugeben — SHA256 ist das minimal akzeptable Niveau (SHA1 ist veraltet).

Binden Sie Schlüssel für kritische Operationen an Biometrie: setUserAuthenticationRequired(true) garantiert, dass der Schlüssel nur nach biometrischer Authentifizierung verwendet werden kann. Unter Android 11+ verwenden Sie setUserAuthenticationParameters() mit einem Timeout (empfohlen 30–60 Sekunden), um die Biometrie nicht bei jeder Operation innerhalb einer Sitzung anzufordern. setInvalidatedByBiometricEnrollment(true) löscht den Schlüssel automatisch, wenn ein neuer Fingerabdruck oder ein neues Gesicht registriert wird — dies verhindert den Zugriff mit alten biometrischen Daten.

Überprüfen Sie das Sicherheitsniveau bei der Initialisierung: Verwenden Sie KeyStore.getKeyCharacteristics(), um SECURITY_LEVEL zu bestimmen. Wenn das Gerät nur Software-Keystore unterstützt (SECURITY_LEVEL_SOFTWARE), treffen Sie eine Entscheidung: entweder die Funktionalität ablehnen oder zusätzliche Verschlüsselung verwenden (z. B. Schlüsselverpackung über Benutzerpasswort). Verlassen Sie sich nicht auf StrongBox, wenn es nicht garantiert ist — geben Sie immer das Flag setIsStrongBoxBacked(true) an und überprüfen Sie das Ergebnis über getKeyCharacteristics.

Rotieren Sie Schlüssel planmäßig: Kryptografische Schlüssel haben eine empfohlene Lebensdauer. NIST SP 800-57 empfiehlt, AES-Schlüssel alle 1–2 Jahre zu wechseln, RSA/EC-Paare alle 2–3 Jahre. Implementieren Sie einen Schlüsselrotationsmechanismus: Überprüfen Sie das Erstellungsdatum des Schlüssels beim App-Start (KeyGenParameterSpec.Builder.setKeyValidityStart/End) und generieren Sie einen neuen Schlüssel bei Ablauf. Alte mit dem alten Schlüssel verschlüsselte Daten sollten entschlüsselt und mit dem neuen Schlüssel neu verschlüsselt werden.

Verwenden Sie Keystore nicht für große Daten: Keystore ist für die Speicherung von Schlüsseln (einige hundert Bytes) ausgelegt, nicht für die Verschlüsselung großer Dateien. Verwenden Sie für die Datenverschlüsselung das Schema: Generieren Sie einen zufälligen AES-Schlüssel (DEK — Data Encryption Key), verschlüsseln Sie die Daten mit diesem Schlüssel und verschlüsseln Sie den DEK mit einem Keystore-Schlüssel (KEK — Key Encryption Key). Android EncryptedSharedPreferences verwendet genau dieses Schema: Masterschlüssel in Keystore, Daten — AES-256 GCM.