Keystore sa Android — ano ito, arkitektura at cryptography

Ano ang Keystore sa Android?

Android Keystore — isang system component ng Android platform na nagbibigay ng API para sa pagbuo, pag-iimbak at paggamit ng mga cryptographic key sa isang protektadong kapaligiran. Hindi tulad ng software cryptographic library (Bouncy Castle, Conscrypt), ginagarantiya ng Keystore na ang mga pribadong susi ay hindi lumalabas sa nakahiwalay na lugar ng pagpapatupad.

Lumitaw ang Keystore sa Android 4.3 (API 18) bilang isang software provider na may suporta sa RSA. Simula sa Android 6.0 (API 23), nakatanggap ang Keystore ng hardware support sa pamamagitan ng Keymaster Hardware Abstraction Layer (HAL), na nagde-delegate ng mga cryptographic na operasyon sa Trusted Execution Environment (TEE) sa mga katugmang device. Ayon sa Android Compatibility Definition Document (2025), lahat ng device na may Android 9+ ay kinakailangang sumuporta sa hardware Keystore sa pamamagitan ng TEE o StrongBox.

Ang mga susi sa Keystore ay tinutukoy ng alias — isang string na ipinapasa sa paggawa o pag-load ng susi. Hindi pinapayagan ng Keystore ang pagkuha ng raw key material: ang mga pamamaraan ng getEncoded() ay nagbabalik ng null para sa mga susi na ginawa sa Keystore. Ito ay isang pangunahing pagkakaiba sa software key — hindi maaaring makuha ng attacker ang pribadong susi kahit na may ganap na kontrol sa device.

Ang Keystore ay isinama sa iba pang mekanismo ng seguridad ng Android: biometric authentication (BiometricPrompt), file-level encryption (File-Based Encryption) at mga function ng pag-verify ng SafetyNet / Play Integrity. Ang mga susi ay maaaring i-configure para sa awtomatikong pagtanggal sa ilalim ng ilang mga kundisyon: sa pag-alis ng code-password, sa pagdaragdag ng bagong fingerprint o sa pag-expire ng validity period.

Arkitektura ng Android Keystore

Ang arkitektura ng Android Keystore ay may kasamang tatlong antas ng pagpapatupad na naiiba sa antas ng hardware protection. Ang antas ay depende sa hardware capabilities ng device.

Hardware-backed Keystore (TEE)

TEE (Trusted Execution Environment) — isang nakahiwalay na lugar na gumagana parallel sa pangunahing OS sa parehong processor. Gumagamit ang TEE ng ARM TrustZone technology, na naghahati sa physical processor core sa dalawang virtual na bahagi: Normal World (Android) at Secure World (TEE). Ang code sa Secure World ay may access sa memory at peripherals na hindi ma-access mula sa Normal World.

Kapag ang isang application ay tumawag ng isang cryptographic na operasyon sa pamamagitan ng Keystore, ang kahilingan ay ipinapadala sa pamamagitan ng Keymaster HAL sa TEE, kung saan ang operasyon ay isinasagawa sa hardware. Ang resulta ay ibinalik sa application, ngunit ang pribadong susi ay nananatili sa protected memory ng TEE. TEE ay sertipikado ayon sa GlobalPlatform TEE Protection Profile at isang mandatory requirement para sa Android 9+ sa mga device na may processors na sumusuporta sa TrustZone.

Sinusuportahan ng TEE ang mga algorithm na AES/GCM (128, 256 bits), RSA (2048, 4096 bits), EC (P-256, P-384, P-521) at HMAC-SHA256. Ang performance ng TEE ay mas mababa kaysa sa software cryptography (20–40% mas mababa), ngunit para sa mga tipikal na operasyon (JWT signature, session key decryption) ang latency ay hindi lalampas sa 10–50 ms.

StrongBox Keymaster

StrongBox — isang dedikadong security chip, pisikal na hiwalay mula sa pangunahing processor. Hindi tulad ng TEE na nagbabahagi ng processor time sa Android, ang StrongBox ay may sariling CPU, RAM, True Random Number Generator (TRNG) at protected storage (One-Time Programmable memory). StrongBox ay sertipikado ayon sa Common Criteria EAL 4+ at Secure IC Protection Profile.

Ang StrongBox ay available sa mga device na may Android 9+ sa kondisyon na mayroong angkop na chip (hal., Titan M sa Google Pixel, Knox sa Samsung Galaxy). Ina-activate ng developer ang StrongBox sa pamamagitan ng flag na setIsStrongBoxBacked(true) sa KeyGenParameterSpec. Kung walang hardware support, ang flag ay binabalewala at ang Keystore ay lumipat sa TEE.

Mga limitasyon ng StrongBox: sumusuporta sa limitadong set ng mga algorithm (AES-256, EC P-256, HMAC-SHA256), operation queue — hindi hihigit sa isa sa isang pagkakataon, bilang ng mga operasyon — limitado ng chip resources. Ang StrongBox ay hindi dinisenyo para sa high-load scenario — gamitin ang TEE para sa mga madalas na operasyon at StrongBox lamang para sa mga kritikal na susi (master encryption key, signature key).

Software-based Keystore

Software-based Keystore — isang software implementation na ginagamit sa mga device na walang hardware support ng TEE o StrongBox. Ang mga susi ay naka-imbak na naka-encrypt sa file system, ngunit ang pribadong susi ay maaaring pansamantalang ma-decrypt sa RAM. Software Keystore ay hindi gaanong secure — ang isang attacker na may root access ay maaaring maharang ang susi sa memory.

Simula sa Android 12 (API 31), hinihingi ng Google ang hardware Keystore support para sa lahat ng bagong device. Ang mga device na may Android 9–11 ay maaaring magkaroon ng software Keystore sa budget models. Maaaring suriin ng developer ang antas ng proteksyon sa pamamagitan ng KeyStore.getKeyCharacteristics() — ang attribute na SECURITY_LEVEL_TRUSTED_ENVIRONMENT o SECURITY_LEVEL_STRONGBOX ay nagpapatunay ng hardware protection.

Mga sinusuportahang algorithm at function

Android Keystore ay sumusuporta sa isang malawak na hanay ng mga cryptographic algorithm na nahahati sa mga kategorya batay sa uri ng susi. Ang pagpili ng algorithm ay nakakaapekto sa performance, compatibility at antas ng seguridad.

AES (Advanced Encryption Standard) — simetrikong encryption para sa proteksyon ng data sa device. Inirerekomendang mode: AES/GCM/NoPadding (256 bits). Ang GCM ay nagbibigay ng authenticated encryption (AEAD) — pag-verify ng integridad ng naka-encrypt na data. Laki ng IV (Initialization Vector): 12 bytes para sa GCM. Huwag gamitin ang AES/ECB — hindi ito nagbibigay ng sapat na proteksyon.

RSA (Rivest–Shamir–Adleman) — asimetrikong encryption para sa proteksyon ng session key at digital signature. Inirerekomendang laki: 2048 o 4096 bits. Mga mode: RSA/ECB/PKCS1Padding (encryption) at RSA/ECB/PKCS1Sign (signature). RSA 1024 ay itinuturing na luma na at hindi inirerekomenda para sa mga bagong application (NIST SP 800-131A Rev. 2).

EC (Elliptic Curve) — asimetrikong cryptography sa elliptic curves para sa signature at key exchange. Mga sinusuportahang curve: secp256r1 (P-256, mandatory), secp384r1 (P-384) at secp521r1 (P-521). Ang EC ay nagbibigay ng maihahambing na seguridad sa RSA na may mas maliit na key size. P-256 ay inirerekomenda para sa karamihan ng mga scenario: sinusuportahan ng lahat ng device at nagbibigay ng 128-bit security level.

HMAC (Hash-based Message Authentication Code) — simetrikong pagpapatunay ng mensahe. Mga sinusuportahang hash function: SHA-256, SHA-384, SHA-512. Ang HMAC ay ginagamit para sa pag-verify ng integridad at pagiging tunay ng data, halimbawa, para sa pag-verify ng mga webhook request o pagsusuri ng configuration integrity.

Lahat ng algorithm ay maaaring i-binding sa biometric authentication sa pamamagitan ng KeyGenParameterSpec.Builder.setUserAuthenticationRequired(true). Sa Android 11+ available ang flag na setUserAuthenticationParameters() na may timeout (sa mga segundo) kung saan ang susi ay available pagkatapos ng biometric authentication, nang walang paulit-ulit na kahilingan.

Mga halimbawa ng code: pagbuo at paggamit ng mga susi

Tingnan natin ang mga praktikal na halimbawa ng paggamit ng Android Keystore sa Kotlin: pagbuo ng AES key, pag-encrypt ng data at paggawa ng asymmetric pair para sa signature.

Pagbuo ng AES key sa Keystore

Ang halimbawa ay gumagawa ng 256-bit AES/GCM key na may binding sa biometric authentication. Ang susi ay hindi available para sa export sa pamamagitan ng 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()
}

Pag-encrypt ng data gamit ang AES/GCM

Ang halimbawa ay nag-e-encrypt ng data gamit ang isang susi mula sa Android Keystore. Cipher ay nakukuha ang susi sa pamamagitan ng alias, sinisimulan ang AES/GCM encryption at ibinabalik ang naka-encrypt na data kasama ng 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 + naka-encrypt na 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)
}

Pagbuo ng RSA pair para sa signature

Ang halimbawa ay gumagawa ng RSA-2048 key pair sa Keystore na may binding sa StrongBox. Ang pribadong susi ay ginagamit para sa signature, ang pampublikong susi ay maaaring i-export sa pamamagitan ng 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()

    // Ang pampublikong susi ay maaaring i-export
    val publicKey = pair.public // X509EncodedKeySpec
}

Mga pinakamahusay na kasanayan sa paggamit ng Android Keystore

Ang epektibong paggamit ng Android Keystore ay nangangailangan ng pagsunod sa mga patakaran na nagbibigay ng maximum na proteksyon habang pinapanatili ang performance.

Gamitin ang KeyGenParameterSpec na may pinakamababang kinakailangang parameter: tukuyin lamang ang mga purpose, block modes at paddings na talagang ginagamit. Ang labis na parameter (hal., PURPOSE_ENCRYPT para sa isang susi na ginagamit lamang para sa signature) ay lumilikha ng mga karagdagang attack vector. Android ay nagrerekomenda na tukuyin nang tahasan ang digest para sa signature — ang SHA256 ay ang pinakamababang katanggap-tanggap na antas (ang SHA1 ay luma na).

I-binding ang mga susi sa biometric para sa mga kritikal na operasyon: tinitiyak ng setUserAuthenticationRequired(true) na ang susi ay magagamit lamang pagkatapos ng biometric authentication. Sa Android 11+ gamitin ang setUserAuthenticationParameters() na may timeout (inirerekomenda 30–60 segundo) upang hindi humiling ng biometric para sa bawat operasyon sa loob ng isang session. setInvalidatedByBiometricEnrollment(true) ay awtomatikong nagtatanggal ng susi kapag nagdagdag ng bagong fingerprint o mukha — pinipigilan nito ang pag-access gamit ang lumang biometric data.

Suriin ang antas ng seguridad sa yugto ng pagsisimula: gamitin ang KeyStore.getKeyCharacteristics() upang matukoy ang SECURITY_LEVEL. Kung ang device ay sumusuporta lamang sa software Keystore (SECURITY_LEVEL_SOFTWARE), gumawa ng desisyon: alinman sa tanggihan ang functionality, o gumamit ng karagdagang encryption (hal., pag-wrap ng susi gamit ang password ng user). Huwag umasa sa StrongBox kung hindi ito garantisado — palaging tukuyin ang flag na setIsStrongBoxBacked(true) at suriin ang resulta sa pamamagitan ng getKeyCharacteristics.

I-update ang mga susi ayon sa iskedyul: ang mga cryptographic key ay may inirerekomendang habang-buhay. NIST SP 800-57 ay nagrerekomenda ng pagpapalit ng AES keys bawat 1–2 taon, RSA/EC pairs bawat 2–3 taon. Ipatupad ang key rotation mechanism: sa pagsisimula ng application, suriin ang petsa ng paggawa ng susi (KeyGenParameterSpec.Builder.setKeyValidityStart/End) at bumuo ng bagong susi kapag nag-expire na. Ang lumang data na naka-encrypt gamit ang lumang susi ay dapat na i-decrypt at muling i-encrypt gamit ang bago.

Huwag gamitin ang Keystore para sa malalaking data: ang Keystore ay idinisenyo para sa pag-iimbak ng mga susi (ilang daang bytes), hindi para sa pag-encrypt ng malalaking file. Para sa data encryption gamitin ang scheme: bumuo ng random AES key (DEK — Data Encryption Key), i-encrypt ang data gamit ang key na ito, at i-encrypt ang DEK gamit ang Keystore key (KEK — Key Encryption Key). Android EncryptedSharedPreferences ay gumagamit nang eksakto ng scheme na ito: master key sa Keystore, data — AES-256 GCM.