KeyStore (Android): concepte cheie, API și funcționarea depozitului criptografic

Ce este KeyStore în Android?

KeyStore în Android — nu este o aplicație sau un fișier separat, ci un furnizor criptografic care implementează interfața java.security.KeyStore. Acesta oferă o API unică pentru stocarea și utilizarea cheilor private, a cheilor simetrice și a certificatelor autorităților de certificare (CA). Furnizorul este înregistrat sub numele „AndroidKeyStore” și este accesibil prin KeyStore.getInstance() standard.

Evoluția Android KeyStore

Înainte de Android 4.3, operațiile criptografice erau executate software prin Bouncy Castle. Odată cu Android 4.3 a apărut Keymaster HAL 1.0, permițând utilizarea TEE pe ARM TrustZone. Android 6.0 (API 23) a adăugat Keymaster 2.0 cu suport pentru autentificare hardware prin amprentă. Android 9 (API 28) a introdus Keymaster 4.0 și StrongBox Keymaster pentru Secure Element dedicat.

Fiecare versiune Keymaster adaugă noi capabilități și îmbunătățește izolarea cheilor. Dispozitivele moderne (2022+) trebuie să suporte Keymaster 4.0 pentru certificarea Google Mobile Services, ceea ce garantează prezența TEE pentru toate aplicațiile Android.

Arhitectură și componente

Android KeyStore constă din trei niveluri: Java API (KeyStore, KeyPairGenerator), procesul de sistem keystore (C++, funcționează ca system service) și Keymaster HAL (bibliotecă în TEE sau Secure Element). Aplicația apelează API-ul, serviciul keystore direcționează cererea către Keymaster, iar operația se execută în mediul protejat.

Toate cheile private sunt stocate în TEE și nu pot fi citite din spațiul utilizatorului. Chiar și serviciul de sistem keystore nu are acces la cheile brute — doar la handlere care indică cheile din Keymaster.

Cum funcționează KeyStore ca furnizor criptografic?

Android KeyStore implementează interfața standard a furnizorului de servicii JCA. Când aplicația apelează Cipher.getInstance(„RSA/ECB/PKCS1Padding”, „AndroidKeyStore”), Android Security Provider delegă operația către Keymaster prin lanțul: Java → JNI → keystore service → Keymaster HAL.

Înregistrarea furnizorului

Furnizorul AndroidKeyStore se înregistrează automat la pornirea procesului. Prioritatea sa este mai mare decât Bouncy Castle sau Conscrypt. Prin urmare, la apelul KeyStore.getInstance() fără specificarea furnizorului, în majoritatea cazurilor se returnează AndroidKeyStore. Pentru apel explicit, utilizați KeyStore.getInstance(„AndroidKeyStore”).

Fiecare aplicație Android are un container izolat în KeyStore. Aplicațiile cu același UID (shared userId) pot avea acces comun la anumite chei, dar configurația standard garantează că aplicația A nu poate citi cheile aplicației B.

Metodele KeyStore și caracteristicile lor

load(null) — inițializarea KeyStore. Parametrul este întotdeauna null pentru AndroidKeyStore. setEntry — salvarea cheii cu specificarea KeyProtection (purposes, digest, padding). getEntry — obținerea KeyStore.PrivateKeyEntry, SecretKeyEntry sau TrustedCertificateEntry. containsAlias — verificarea existenței cheii. deleteEntry — ștergerea cheii (ireversibil).

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

object KeyStoreManager {
    private val keyStore by lazy {
        KeyStore.getInstance("AndroidKeyStore").apply { load(null) }
    }

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

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

Algoritmi și tipuri de chei suportate

Android KeyStore suportă un set larg de algoritmi criptografici, care variază în funcție de versiunea Keymaster HAL de pe dispozitiv. Dezvoltatorul poate obține lista algoritmilor suportați prin KeyGenParameterSpec.Builder la încercarea de generare — parametrii incompatibili cauzează InvalidAlgorithmParameterException.

Algoritmi asimetrici

RSA (1024–4096 biți) — pentru semnătură (PKCS1, PSS cu SHA-1/SHA-256/SHA-384/SHA-512) și criptare (OAEP cu SHA-1/SHA-256). EC (P-224, P-256, P-384, P-521) — pentru semnătura ECDSA și acordul de chei ECDH. X25519 și Ed25519 — de la Android 12 (API 31) pentru protocoale criptografice moderne.

Pentru cheile asimetrice Generați întotdeauna în Keymaster, NU importați niciodată chei private. Cheile private importate nu sunt protejate hardware — sunt stocate în stratul software și sunt vulnerabile la compromiterea AP.

Algoritmi simetrici

AES (128, 256 biți) — pentru criptare simetrică în modurile CBC, CTR, GCM. HMAC (SHA-1, SHA-256, SHA-512) — pentru autentificarea mesajelor. ChaCha20 (Android 12+) — pentru criptare stream de înaltă performanță cu autentificare Poly1305.

Tipuri de chei și serializarea lor

KeyStore.PrivateKeyEntry — conține cheia privată (neexportabilă) și lanțul de certificate. KeyStore.SecretKeyEntry — pentru chei simetrice. KeyStore.TrustedCertificateEntry — pentru certificate CA de încredere. Cheile publice sunt disponibile pentru export prin keyStore.getCertificate(alias).publicKey.

Exemplu de generare și utilizare a cheilor

Să analizăm un scenariu complet: generarea unei chei AES pentru criptarea datelor și generarea unei chei EC pentru semnătură cu protecție biometrică. Ambele chei sunt create în Android KeyStore cu suport hardware.

Generarea cheii AES pentru criptare

Cheia AES se creează prin KeyGenerator cu KeyGenParameterSpec. Parametri: PURPOSE_ENCRYPT + PURPOSE_DECRYPT, BLOCK_MODE_GCM (mod recomandat cu autentificare), ENCRYPTION_PADDING_NONE (pentru GCM padding nu este necesar).

import javax.crypto.KeyGenerator
import javax.crypto.Cipher
import javax.crypto.spec.GCMParameterSpec

fun generateAndEncrypt(alias: String, plainText: ByteArray): ByteArray {
    val spec = KeyGenParameterSpec.Builder(alias,
        KeyProperties.PURPOSE_ENCRYPT or KeyProperties.PURPOSE_DECRYPT
    ).setBlockModes(KeyProperties.BLOCK_MODE_GCM)
     .setEncryptionPaddings(KeyProperties.ENCRYPTION_PADDING_NONE)
     .setKeySize(256)
     .build()

    val kg = KeyGenerator.getInstance(KeyProperties.KEY_ALGORITHM_AES, "AndroidKeyStore")
    kg.initialize(spec)
    kg.generateKey()

    val cipher = Cipher.getInstance("AES/GCM/NoPadding")
    cipher.init(Cipher.ENCRYPT_MODE, getKeyFromStore(alias))
    return cipher.doFinal(plainText)
}

Semnătura cu protecție biometrică

Cheia EC cu userAuthenticationRequired=true necesită autentificarea utilizatorului înainte de fiecare operație de semnătură. În acest scop se utilizează BiometricPrompt cu CryptoObject care conține obiectul Signature. După biometria reușită, Keymaster permite operația.

fun createBiometricSignKey(alias: String) {
    val spec = KeyGenParameterSpec.Builder(alias,
        KeyProperties.PURPOSE_SIGN
    ).setAlgorithmParameterSpec(
        ECGenParameterSpec("secp256r1")
    ).setDigests(KeyProperties.DIGEST_SHA256)
     .setUserAuthenticationRequired(true)
     .setInvalidatedByBiometricEnrollment(true)
     .build()

    val kpg = KeyPairGenerator.getInstance(
        KeyProperties.KEY_ALGORITHM_EC,
        "AndroidKeyStore"
    )
    kpg.initialize(spec)
    kpg.generateKeyPair()
}

KeyStore și securitatea pe dispozitiv

Android KeyStore oferă garanții de securitate hardware pe care KeyStore-urile software (JKS, BKS) nu le pot asigura. Cheile sunt protejate la nivelul SoC, iar chiar și controlul complet asupra spațiului utilizatorului Android nu permite extragerea cheii private.

Key Attestation (Android 8.1+)

Key Attestation — mecanism care permite aplicației (și serverului) să verifice în ce mediu a fost creată cheia. Android Keystore semnează un certificat care conține lista caracteristicilor cheii: algoritm, dimensiune, purges, hardware-backed (True/False), origin (GENERATED, IMPORTED). Serverul verifică lanțul de certificate până la certificatul rădăcină Google.

Acest lucru este esențial pentru aplicațiile financiare: serverul poate solicita ca cheia să fie creată în mediu hardware (Hardware-Backed = True) și să respingă cheile create în Keystore software. Key Attestation previne atacurile în care atacatorul înlocuiește Keystore cu un emulator.

Invalidarea cheilor la modificarea biometriei

setInvalidatedByBiometricEnrollment(true) înseamnă că cheia va fi ștearsă automat de Keymaster la modificarea sau ștergerea șabloanelor biometrice ale utilizatorului. Aceasta este o protecție împotriva atacurilor în care atacatorul își adaugă propria amprentă în contul existent. După adăugarea unei noi amprente, cheile vechi devin inaccesibile.

Contorul încercărilor eșuate de autentificare biometrică este, de asemenea, gestionat de Keymaster. După maxBiometricAttempt (configurat de producător, de obicei 5), Keymaster blochează toate operațiile cu chei biometrice timp de 30 de secunde. După 10 încercări eșuate — până la introducerea parolei dispozitivului (PIN secret).