Keystore v Androidu — co to je, architektura a kryptografie

Co je Keystore v Androidu?

Android Keystore — systémová komponenta platformy Android, která poskytuje API pro generování, ukládání a používání kryptografických klíčů v chráněném prostředí. Na rozdíl od softwarových kryptografických knihoven (Bouncy Castle, Conscrypt) Keystore zaručuje, že soukromé klíče nikdy neopouštějí izolovanou oblast běhu.

Keystore se objevil v Androidu 4.3 (API 18) jako softwarový poskytovatel s podporou RSA. Od Androidu 6.0 (API 23) získal Keystore hardwarovou podporu prostřednictvím Keymaster Hardware Abstraction Layer (HAL), která deleguje kryptografické operace do Trusted Execution Environment (TEE) na kompatibilních zařízeních. Podle Android Compatibility Definition Document (2025) musí všechna zařízení s Androidem 9+ povinně podporovat hardwarový Keystore přes TEE nebo StrongBox.

Klíče v Keystore jsou identifikovány podle aliasu — řetězce, který se předává při vytvoření nebo načtení klíče. Keystore neumožňuje získat surový materiál klíče: metody getEncoded() vracejí null pro klíče vytvořené v Keystore. To je zásadní rozdíl od softwarových klíčů — útočník nemůže extrahovat soukromý klíč ani při plné kontrole nad zařízením.

Keystore je integrován s dalšími bezpečnostními mechanismy Androidu: biometrickou autentizací (BiometricPrompt), šifrováním na úrovni souborů (File-Based Encryption) a ověřovacími funkcemi SafetyNet / Play Integrity. Klíče lze nastavit na automatické odstranění za určitých podmínek: při odebrání kódového hesla, při přidání nového otisku prstu nebo po vypršení platnosti.

Architektura Android Keystore

Architektura Android Keystore zahrnuje tři úrovně implementace lišící se stupněm hardwarové ochrany. Úroveň závisí na možnostech hardwaru zařízení.

Hardware-backed Keystore (TEE)

TEE (Trusted Execution Environment) — izolovaná oblast pracující paralelně s hlavním OS na stejném procesoru. TEE využívá technologii ARM TrustZone, která rozděluje fyzické jádro procesoru na dva virtuální: Normal World (Android) a Secure World (TEE). Kód v Secure World má přístup k paměti a periferiím nepřístupným z Normal World.

Když aplikace zavolá kryptografickou operaci přes Keystore, požadavek je předán přes Keymaster HAL do TEE, kde je operace provedena hardwarově. Výsledek se vrátí aplikaci, ale soukromý klíč zůstává v chráněné paměti TEE. TEE je certifikován podle GlobalPlatform TEE Protection Profile a je povinným požadavkem pro Android 9+ na zařízeních s procesory podporujícími TrustZone.

TEE podporuje algoritmy AES/GCM (128, 256 bitů), RSA (2048, 4096 bitů), EC (P-256, P-384, P-521) a HMAC-SHA256. Výkon TEE je nižší než u softwarové kryptografie (o 20–40 %), ale pro typické operace (podpis JWT, dešifrování klíče relace) zpoždění nepřesahuje 10–50 ms.

StrongBox Keymaster

StrongBox — vyhrazený bezpečnostní čip, fyzicky oddělený od hlavního procesoru. Na rozdíl od TEE, který sdílí procesorový čas s Androidem, má StrongBox vlastní CPU, operační paměť, True Random Number Generator (TRNG) a chráněné úložiště (One-Time Programmable memory). StrongBox je certifikován na Common Criteria EAL 4+ a Secure IC Protection Profile.

StrongBox je k dispozici na zařízeních s Androidem 9+ při přítomnosti odpovídajícího čipu (např. Titan M u Google Pixel, Knox u Samsung Galaxy). Vývojář zapíná StrongBox pomocí příznaku setIsStrongBoxBacked(true) v KeyGenParameterSpec. Pokud hardwarová podpora chybí, příznak se ignoruje a Keystore přepne na TEE.

Omezení StrongBox: podporuje omezenou sadu algoritmů (AES-256, EC P-256, HMAC-SHA256), fronta operací — maximálně jedna současně, počet operací — omezen zdroji čipu. StrongBox není určen pro vysoce zatížené scénáře — používejte TEE pro časté operace a StrongBox pouze pro kritické klíče (master šifrovací klíče, podpisové klíče).

Software-based Keystore

Software-based Keystore — softwarová implementace používaná na zařízeních bez hardwarové podpory TEE nebo StrongBox. Klíče jsou uloženy zašifrované v souborovém systému, ale soukromý klíč může být dočasně dešifrován v operační paměti. Softwarový Keystore je méně bezpečný — útočník s root přístupem může klíč v paměti zachytit.

Od Androidu 12 (API 31) Google vyžaduje hardwarovou podporu Keystore pro všechna nová zařízení. Zařízení s Androidem 9–11 mohou mít softwarový Keystore u levných modelů. Vývojář může zkontrolovat úroveň ochrany pomocí KeyStore.getKeyCharacteristics() — atribut SECURITY_LEVEL_TRUSTED_ENVIRONMENT nebo SECURITY_LEVEL_STRONGBOX potvrzuje hardwarovou ochranu.

Podporované algoritmy a funkce

Android Keystore podporuje širokou škálu kryptografických algoritmů rozdělených do kategorií podle typu klíče. Volba algoritmu ovlivňuje výkon, kompatibilitu a úroveň zabezpečení.

AES (Advanced Encryption Standard) — symetrické šifrování pro ochranu dat na zařízení. Doporučený režim: AES/GCM/NoPadding (256 bitů). GCM poskytuje autentizované šifrování (AEAD) — kontrolu integrity zašifrovaných dat. Velikost IV (Initialization Vector): 12 bajtů pro GCM. Nepoužívejte AES/ECB — neposkytuje dostatečnou ochranu.

RSA (Rivest–Shamir–Adleman) — asymetrické šifrování pro ochranu klíčů relace a digitální podpis. Doporučená velikost: 2048 nebo 4096 bitů. Režimy: RSA/ECB/PKCS1Padding (šifrování) a RSA/ECB/PKCS1Sign (podpis). RSA 1024 je považován za zastaralý a nedoporučuje se pro nové aplikace (NIST SP 800-131A Rev. 2).

EC (Elliptic Curve) — asymetrická kryptografie na eliptických křivkách pro podpis a výměnu klíčů. Podporované křivky: secp256r1 (P-256, povinná), secp384r1 (P-384) a secp521r1 (P-521). EC poskytuje srovnatelné zabezpečení s RSA při výrazně menší velikosti klíče. P-256 se doporučuje pro většinu scénářů: je podporována všemi zařízeními a poskytuje 128bitovou úroveň zabezpečení.

HMAC (Hash-based Message Authentication Code) — symetrická autentizace zpráv. Podporované hashovací funkce: SHA-256, SHA-384, SHA-512. HMAC se používá pro kontrolu integrity a autentičnosti dat, např. pro ověření webhook požadavků nebo kontrolu integrity konfigurace.

Všechny algoritmy mohou být vázány na biometrickou autentizaci pomocí KeyGenParameterSpec.Builder.setUserAuthenticationRequired(true). Na Androidu 11+ je k dispozici příznak setUserAuthenticationParameters() s uvedením časového limitu (v sekundách), během kterého je klíč dostupný po biometrické autentizaci bez opakovaného požadavku.

Příklady kódu: generování a použití klíčů

Podívejme se na praktické příklady práce s Android Keystore v Kotlinu: generování AES klíče, šifrování dat a vytvoření asymetrického páru pro podpis.

Generování AES klíče v Keystore

Příklad vytváří 256bitový AES/GCM klíč s vazbou na biometrickou autentizaci. Klíč není k dispozici pro export pomocí getEncoded().

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()
}

Šifrování dat AES/GCM

Příklad šifruje data pomocí klíče z Android Keystore. Cipher získá klíč podle aliasu, inicializuje AES/GCM šifrování a vrátí zašifrovaná data spolu s IV.

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 + šifrovaná data
    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)
}

Generování RSA páru pro podpis

Příklad vytváří pár RSA-2048 klíčů v Keystore s vazbou na StrongBox. Soukromý klíč se používá pro podpis, veřejný — lze exportovat pomocí getEncoded().

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()

    // Veřejný klíč lze exportovat
    val publicKey = pair.public // X509EncodedKeySpec
}

Nejlepší postupy práce s Android Keystore

Efektivní používání Android Keystore vyžaduje dodržování pravidel, která zajišťují maximální ochranu při zachování výkonu.

Používejte KeyGenParameterSpec s minimálně nezbytnými parametry: uvádějte pouze ty purpose, block modes a paddings, které se skutečně používají. Nadbytečné parametry (např. PURPOSE_ENCRYPT u klíče používaného pouze pro podpis) vytvářejí zbytečné vektory útoku. Android doporučuje explicitně uvádět digest pro podpis — SHA256 je minimální přijatelná úroveň (SHA1 je zastaralý).

Vážte klíče na biometrii pro kritické operace: setUserAuthenticationRequired(true) zaručuje, že klíč lze použít pouze po biometrické autentizaci. Na Androidu 11+ používejte setUserAuthenticationParameters() s časovým limitem (doporučuje se 30–60 sekund), aby nebylo vyžadováno biometrické ověření pro každou operaci v rámci jedné relace. setInvalidatedByBiometricEnrollment(true) automaticky odstraní klíč při přidání nového otisku nebo obličeje — to zabraňuje přístupu pomocí starých biometrických údajů.

Kontrolujte úroveň zabezpečení při inicializaci: použijte KeyStore.getKeyCharacteristics() pro určení SECURITY_LEVEL. Pokud zařízení podporuje pouze softwarový Keystore (SECURITY_LEVEL_SOFTWARE), rozhodněte se buď funkci zakázat, nebo použít dodatečné šifrování (např. obalení klíče pomocí uživatelského hesla). Nespoléhejte na StrongBox, pokud není zaručen — vždy nastavte příznak setIsStrongBoxBacked(true) a zkontrolujte výsledek pomocí getKeyCharacteristics.

Obnovujte klíče podle plánu: kryptografické klíče mají doporučenou životnost. NIST SP 800-57 doporučuje měnit AES klíče každé 1–2 roky, RSA/EC páry každé 2–3 roky. Implementujte mechanismus rotace klíčů: při spuštění aplikace kontrolujte datum vytvoření klíče (KeyGenParameterSpec.Builder.setKeyValidityStart/End) a generujte nový klíč při vypršení platnosti. Stará data zašifrovaná starým klíčem musí být dešifrována a znovu zašifrována novým klíčem.

Nepoužívejte Keystore pro velká data: Keystore je určen pro ukládání klíčů (několik set bajtů), nikoli pro šifrování velkých souborů. Pro šifrování dat použijte schéma: vygenerujte náhodný AES klíč (DEK — Data Encryption Key), zašifrujte data tímto klíčem a DEK zašifrujte Keystore klíčem (KEK — Key Encryption Key). Android EncryptedSharedPreferences používá přesně toto schéma: master klíč v Keystore, data — AES-256 GCM.