Keystore-Grundlagen: Kryptografische Schlüssel sicher speichern

Wer in einer Android-App sensible Daten verschlüsselt, steht schnell vor einer delikaten Frage: Wo soll der kryptografische Schlüssel eigentlich liegen? Im SharedPreferences? In einer Datei im App-Verzeichnis? Beide Optionen haben dasselbe Problem – ein Angreifer mit Root-Zugriff kann das Schlüsselmaterial auslesen. Der Android Keystore löst dieses Problem grundlegend, indem er Schlüssel in einer isolierten Umgebung verwahrt, aus der sie niemals im Klartext herausgehen.

Was ist das?

Der Android Keystore ist ein systemweites Schlüsselverwaltungssystem, das seit Android 4.3 verfügbar ist und mit jeder Android-Version weiterentwickelt wurde. Er stellt eine sichere, vom App-Prozess isolierte Umgebung für kryptografisches Schlüsselmaterial bereit. Wichtig zu verstehen: Der Keystore speichert keine Passwörter oder Nutzerdaten – er verwaltet ausschließlich kryptografische Schlüssel wie RSA-, EC- oder AES-Schlüsseln.

Das zentrale Versprechen des Keystores lautet: Schlüssel verlassen den Keystore niemals im Klartext. Das bedeutet, dass du einen gespeicherten Schlüssel nicht exportieren oder direkt auslesen kannst – du kannst ihn nur benutzen. Wenn du Daten signieren oder verschlüsseln möchtest, übergibst du die Daten an den Keystore, und dieser führt die Operation intern durch. Das Ergebnis – etwa eine Signatur oder ein Chiffrat – erhältst du zurück, aber nie das Schlüsselmaterial selbst.

Im Kontext der Android-Architektur gehört der Keystore zur Data Layer: Er ist der sicherste Ablageort für Geheimnisse, auf die andere Teile deiner App für Authentifizierung oder Datenschutz angewiesen sind. Statt Schlüssel als Dateien im App-Verzeichnis oder in Preferences zu serialisieren, delegierst du die Verwaltung vollständig ans Betriebssystem.

Wie funktioniert es?

Android unterscheidet zwei Sicherheitsstufen für Keystore-Schlüssel:

Software-backed vs. Hardware-backed

Auf jedem Android-Gerät gibt es mindestens eine Software-Implementierung des Keystores, die Schlüssel im verschlüsselten Bereich des Betriebssystems ablegt. Auf Geräten mit einem Trusted Execution Environment (TEE) werden Schlüssel in einem vom Haupt-Prozessor logisch getrennten Sicherheitsbereich verwaltet. Seit Android 9 können Geräte zusätzlich über StrongBox verfügen – einen dedizierten Sicherheitschip nach dem Android-StrongBox-Standard, der physisch vom restlichen System getrennt ist. Hardware-backed Keys sind deutlich schwerer zu kompromittieren, weil selbst ein vollständig kompromittierter Kernel-Prozess keinen Zugriff auf das isolierte Schlüsselmaterial erhält.

Schlüssel anlegen mit KeyPairGenerator

Den Einstieg in den Keystore bilden zwei Klassen: KeyPairGenerator für asymmetrische Schlüssel und KeyGenerator für symmetrische. Die Konfiguration übernimmt KeyGenParameterSpec, mit der du festlegst, zu welchen Operationen ein Schlüssel berechtigt ist, ob eine Nutzerauthentifizierung vorausgesetzt wird, und welche Digest- oder Block-Algorithmen erlaubt sind.

Nutzerkontexte und Zugriffsschutz

Ein besonders nützliches Feature ist die Möglichkeit, einen Schlüssel so zu konfigurieren, dass er nur nach einer erfolgreichen Nutzerauthentifizierung – PIN, Fingerabdruck oder Face-Unlock – verfügbar ist. Dazu setzt du .setUserAuthenticationRequired(true) in der KeyGenParameterSpec. Damit schützt du Schlüssel auch dann, wenn ein Angreifer physischen Gerätezugriff hat und das Gerät entsperrt vorfindet: Nach einem Neustart muss der Nutzer sich zunächst authentifizieren, bevor der Schlüssel wieder nutzbar wird.

In der Praxis

Hier ein vollständiges Beispiel, das einen EC-Schlüssel (Elliptic Curve) erstellt und damit Daten signiert:

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

private const val KEY_ALIAS = "my_signing_key"

fun generateKey() {
    val kpg = KeyPairGenerator.getInstance(
        KeyProperties.KEY_ALGORITHM_EC,
        "AndroidKeyStore"
    )
    kpg.initialize(
        KeyGenParameterSpec.Builder(
            KEY_ALIAS,
            KeyProperties.PURPOSE_SIGN or KeyProperties.PURPOSE_VERIFY
        )
            .setDigests(KeyProperties.DIGEST_SHA256)
            .setUserAuthenticationRequired(false)
            .build()
    )
    kpg.generateKeyPair()
}

fun signData(data: ByteArray): ByteArray {
    val keyStore = KeyStore.getInstance("AndroidKeyStore").apply { load(null) }
    val privateKey = keyStore.getKey(KEY_ALIAS, null) as java.security.PrivateKey

    return Signature.getInstance("SHA256withECDSA").run {
        initSign(privateKey)
        update(data)
        sign()
    }
}

Beachte, dass der Schlüssel einmalig erstellt und danach immer unter demselben Alias abgerufen wird. Ein erneuter Aufruf von generateKeyPair() mit dem gleichen Alias überschreibt den bestehenden Schlüssel – prüfe daher vorher, ob der Alias bereits existiert: keyStore.containsAlias(KEY_ALIAS).

Häufige Stolperfalle: Hardware-backed-Sicherheit stillschweigend voraussetzen

Ein typischer Fehler ist anzunehmen, dass ein Keystore-Schlüssel automatisch hardware-backed ist. Das trifft nur zu, wenn das Gerät ein TEE oder StrongBox besitzt und der Schlüssel darin angelegt wurde. Du kannst das zur Laufzeit überprüfen:

fun isKeyHardwareBacked(): Boolean {
    val keyStore = KeyStore.getInstance("AndroidKeyStore").apply { load(null) }
    val key = keyStore.getKey(KEY_ALIAS, null) as? java.security.PrivateKey
        ?: return false
    val factory = java.security.KeyFactory.getInstance(key.algorithm, "AndroidKeyStore")
    val keyInfo = factory.getKeySpec(key, android.security.keystore.KeyInfo::class.java)
    return keyInfo.isInsideSecureHardware
}

Verlässt du dich ohne diese Prüfung auf Hardware-backed-Sicherheit, kann deine Sicherheitsannahme auf älteren oder kostengünstigen Geräten still und leise falsch sein – mit gravierenden Folgen, falls du darauf eine Sicherheitsgarantie gegenüber Nutzern oder Auditoren abgegeben hast.

Fazit

Der Android Keystore ist das erste Mittel der Wahl, sobald deine App kryptografische Schlüssel verwaltet – egal ob für Signaturen, Verschlüsselung oder Nutzerauthentifizierung. Er entkoppelt das Schlüsselmaterial vollständig vom App-Code und nutzt dort, wo die Hardware es erlaubt, ein physisch isoliertes Sicherheitssystem. Um dein Verständnis zu festigen, lege in einem Testprojekt einen Schlüssel an, signiere damit eine Testzeichenkette, und überprüfe anschließend mit KeyInfo, ob dein Gerät wirklich Hardware-backed-Sicherheit bietet. Schreib dazu einen Instrumentierungstest, der die Signatur mit dem öffentlichen Schlüssel verifiziert – so stellst du sicher, dass der gesamte Schlüssellebenszyklus korrekt funktioniert, bevor du den Keystore in produktivem Code einsetzt.