Secure Storage sa Mga Mobile App: Ano Ito, Mga Paraan at Pagpapatupad

Ano ang Secure Storage?

Secure Storage — ang kasanayan ng pag-iimbak ng kumpidensyal na datos ng mobile app sa paraang hindi ito ma-access ng ibang mga app, malware, at attacker na may pisikal na access sa device. Hindi tulad ng ordinaryong imbakan, ang Secure Storage ay gumagamit ng encryption, paghihiwalay, at proteksyon ng hardware.

Hindi lahat ng datos ay nangangailangan ng Secure Storage: ang mga larawan ng profile o cache ng balita ay maaaring itago sa ordinaryong file system. Ngunit ang mga encryption key, authentication token, datos ng pagbabayad, pribadong key, at biometric template ay dapat protektahan. Ayon sa Google Security Blog (2025), 67% ng mga kahinaan sa mga mobile app ay nauugnay sa pag-iimbak ng mga lihim sa bukas na anyo.

Ang bawat mobile platform ay nagbibigay ng sarili nitong Secure Storage mechanism: Android — Keystore at EncryptedSharedPreferences, iOS — Keychain at Data Protection API. Ang mga mekanismong ito ay isinama sa mga hardware security module (TEE, Secure Enclave) at ginagarantiyang hindi mababasa ang datos kahit pagkatapos ng jailbreak o rooting ng device.

Ang tamang pagpili ng Secure Storage method ay depende sa uri ng datos, senaryo ng paggamit, at mga kinakailangan sa pagganap. Ang pag-unawa sa arkitektura ng bawat mekanismo ay nagpapahintulot sa developer na gumawa ng tamang desisyon sa arkitektura.

Secure Storage sa Android

Ang platform ng Android ay nagbibigay ng ilang antas ng proteksyon ng datos, mula sa hardware key storage hanggang sa naka-encrypt na SharedPreferences. Ang pagpili ay depende sa sensitivity ng datos at mga kinakailangan sa pagganap.

Android Keystore — Imbakan ng Key sa Hardware

Android Keystore — cryptographic provider na lumilikha at nag-iimbak ng mga key sa isang isolated execution environment (TEE — Trusted Execution Environment) sa mga device na may suporta sa hardware protection. Ang mga key ay hindi umaalis sa TEE: ang mga cryptographic operation ay isinasagawa sa loob ng protektadong lugar na hindi ma-access kahit ng operating system.

Mula sa Android 9 (API 28), sinusuportahan ng Keystore ang StrongBox Keymaster — isang dedicated security chip na may sariling CPU, True Random Number Generator (TRNG), at protektadong memorya. Ang StrongBox ay sertipikado ayon sa Common Criteria EAL 4+ at ito ang pinakaligtas na antas ng imbakan ng key sa Android. Para gamitin ang StrongBox, kailangan mong explicitly na itakda ang flag na inStrongBox() kapag lumilikha ng key.

Sinusuportahan ng Keystore ang mga algorithm: AES/GCM/NoPadding (256 bit), EC (secp256r1, secp384r1), RSA (2048–4096 bit), at HMAC-SHA256. Lahat ng key ay maaaring iugnay sa biometric authentication sa pamamagitan ng setUserAuthenticationRequired(true).

EncryptedSharedPreferences

EncryptedSharedPreferences — library mula sa AndroidX Security package na awtomatikong nag-e-encrypt ng lahat ng datos na iniimbak sa pamamagitan ng SharedPreferences API. Ang mga value ay naka-encrypt gamit ang AES-256 GCM key, at ang mga key — gamit ang AES-256 SIV (synthetic IV), na pumipigil sa dictionary attack sa mga pangalan ng key.

Ang pangunahing encryption key ay iniimbak sa Android Keystore, na nagbibigay ng dalawang antas na proteksyon: pinoprotektahan ng Keystore ang master key, pinoprotektahan ng EncryptedSharedPreferences ang datos. Ang pagganap ng encryption ay mas mababa sa 5 ms bawat operasyon ng pagbasa/pagsulat para sa tipikal na datos (token, setting), na ginagawang angkop ang library para sa mga senaryo ng user.

Ang EncryptedSharedPreferences ay hindi dinisenyo para sa malalaking volume ng datos (higit sa 5 MB) — sa mga ganitong kaso, gumamit ng naka-encrypt na database sa pamamagitan ng SQLCipher o Room na may encryption.

SQLCipher — Naka-encrypt na Database

SQLCipher — extension ng SQLite na nag-e-encrypt ng buong database page-per-page gamit ang AES-256-CBC. Ang bawat page ng database ay naka-encrypt gamit ang hiwalay na key na nagmula sa master password sa pamamagitan ng PBKDF2. Ang SQLCipher ay nagdaragdag ng humigit-kumulang 5–15% na overhead sa pagganap depende sa laki ng datos.

Ang pagsasama sa Android ay ginagawa sa pamamagitan ng library na net.zetetic:android-database-sqlcipher, na nagbibigay ng API na compatible sa standard na SQLiteOpenHelper. Ang password para sa SQLCipher ay inirerekomendang itago sa Keystore, hindi sa code o SharedPreferences.

Secure Storage sa iOS

Ang platform ng iOS ay nagbibigay ng Keychain Services — ang pangunahing ligtas na imbakan, pati na rin ang Data Protection API para sa encryption ng file sa antas ng OS.

Keychain Services

Keychain — isang naka-encrypt na SQLite database kung saan iniimbak ng iOS ang mga password, encryption key, certificate, at tala. Ang bawat elemento ng Keychain (SecItem) ay iniimbak sa naka-encrypt na anyo gamit ang hardware key na natatangi sa device. Ang access sa elemento ay kinokontrol sa pamamagitan ng ACL (Access Control List), na maaaring mangailangan ng biometric authentication (Face ID, Touch ID) o passcode.

Sinusuportahan ng Keychain ang mga klase ng proteksyon (Protection Class) na tumutukoy kung kailan available ang datos: kSecAttrAccessibleWhenUnlockedThisDeviceOnly — ang datos ay available lamang kapag naka-unlock ang device at hindi inililipat sa backup. Ang klaseng ito ay inirerekomenda para sa karamihan ng mga senaryo ng pag-iimbak ng authentication token.

Sa iOS 15+, available ang Security framework na may suporta para sa hardware key sa pamamagitan ng Secure Enclave — isang dedicated na Apple processor na nagpoproseso ng cryptographic operation at nag-iimbak ng mga pribadong key sa isolated na memorya. Sinusuportahan ng Secure Enclave ang mga algorithm na ECDSA (secp256r1) at ECDH para sa paglikha ng mga key na hindi ma-extract mula sa chip.

Data Protection API

Data Protection — mekanismo ng iOS na nag-e-encrypt ng bawat file sa antas ng file system (APFS) gamit ang key na nakaugnay sa passcode ng device. Tinutukoy ng developer ang antas ng proteksyon sa pamamagitan ng NSFileProtectionType attribute kapag lumilikha ng file: NSFileProtectionComplete — ang file ay available lamang kapag naka-unlock ang device.

Ang Data Protection ay awtomatikong gumagana sa lahat ng device na may iOS 5+ kung nakatakda ang passcode. Ang encryption ay ginagawa sa antas ng hardware sa pamamagitan ng Dedicated AES Engine ng Apple processor, na tinitiyak ang mataas na pagganap — ang latency ng encryption ay halos hindi napapansin ng user. Para i-activate ang proteksyon sa app, sapat na itakda ang protection attribute kapag lumilikha ng file sa pamamagitan ng FileManager.

Ang Data Protection ay hindi pumapalit sa Keychain para sa pag-iimbak ng key — ito ay ginagamit para sa pag-encrypt ng mga file, Core Data database, at iba pang malalaking volume ng datos. Ang kombinasyon ng Keychain (para sa key) at Data Protection (para sa file) ay nagbibigay ng kumpletong cycle ng ligtas na imbakan sa iOS.

Mga Halimbawa ng Code: Encryption ng Datos sa Android at iOS

Tingnan natin ang mga praktikal na halimbawa ng Secure Storage gamit ang built-in na API ng Android at iOS.

EncryptedSharedPreferences sa Kotlin

Ipinapakita ng halimbawa ang pagsisimula ng EncryptedSharedPreferences na may master key mula sa Android Keystore. Lahat ng kasunod na operasyon ng pagbasa at pagsulat ay awtomatikong naka-encrypt at nade-decrypt.

import androidx.security.crypto.EncryptedSharedPreferences
import androidx.security.crypto.MasterKey

val masterKey = MasterKey.Builder(context)
    .setKeyScheme(MasterKey.KeyScheme.AES256_GCM)
    .build()

val prefs = EncryptedSharedPreferences.create(
    context,
    "secure_prefs",
    masterKey,
    EncryptedSharedPreferences.PrefKeyEncryptionScheme.AES256_SIV,
    EncryptedSharedPreferences.PrefValueEncryptionScheme.AES256_GCM
)

prefs.edit()
    .putString("auth_token", "eyJhbGciOiJIUzI1NiJ9...")
    .apply()

Keychain sa Swift

Ipinapakita ng halimbawa ang pag-save at pagbasa ng datos mula sa iOS Keychain gamit ang Security framework. Ginagamit ng code ang kSecAttrAccessibleWhenUnlockedThisDeviceOnly para sa maximum na proteksyon.

import Security

func saveToKeychain(key: String, data: Data) {
    let query: [String: Any] = [
        kSecClass as String: kSecClassGenericPassword,
        kSecAttrAccount as String: key,
        kSecValueData as String: data,
        kSecAttrAccessible as String:
            kSecAttrAccessibleWhenUnlockedThisDeviceOnly
    ]
    SecItemDelete(query as CFDictionary)
    SecItemAdd(query as CFDictionary, nil)
}

func readFromKeychain(key: String) -> Data? {
    let query: [String: Any] = [
        kSecClass as String: kSecClassGenericPassword,
        kSecAttrAccount as String: key,
        kSecReturnData as String: true,
        kSecMatchLimit as String: kSecMatchLimitOne
    ]
    var result: AnyObject?
    let status = SecItemCopyMatching(
        query as CFDictionary, &result
    )
    return status == errSecSuccess ? result as? Data : nil
}

SQLCipher sa Kotlin

Halimbawa ng koneksyon sa naka-encrypt na SQLite database sa pamamagitan ng SQLCipher na may password na iniimbak sa Android Keystore.

import net.sqlcipher.database.SQLiteDatabase
import net.sqlcipher.database.SQLiteOpenHelper

class SecureDBHelper(context: Context) :
    SQLiteOpenHelper(context, "secure.db", null, 1) {

    private val password = getKeyFromKeystore()

    override fun onCreate(db: SQLiteDatabase) {
        db.execSQL("CREATE TABLE tokens (id INTEGER PRIMARY KEY, value TEXT)")
    }

    override fun onUpgrade(
        db: SQLiteDatabase, oldVersion: Int, newVersion: Int
    ) {
        onCreate(db)
    }
}

// Paggamit: ilagay ang password kapag binubuksan
val helper = SecureDBHelper(context)
val db = helper.getWritableDatabase(password)

Mga Rekomendasyon para sa Ligtas na Imbakan ng Datos

Ang tamang paggamit ng Secure Storage ay nangangailangan ng pagsunod sa ilang pangunahing prinsipyo na pumipigil sa mga karaniwang pagkakamali ng developer.

Tukuyin ang klasipikasyon ng datos: aling datos ang nangangailangan ng hardware protection (Keystore / Secure Enclave), alin ang — encryption sa antas ng OS (EncryptedSharedPreferences / Data Protection), at alin ang maaaring itago sa ordinaryong file system. Ang authentication token, pribadong key, at datos ng pagbabayad — tanging antas ng hardware. Ang mga setting ng user (tema, wika) — sapat na ang EncryptedSharedPreferences. Datos ng sesyon (pansamantalang cache) ay maaaring itago sa memorya o pansamantalang direktoryo.

Huwag kailanman mag-imbak ng mga lihim sa code: ang mga string na may API key, password, o seed phrase sa source code — ang pinakamalubhang pagkakamali sa seguridad. Ang anumang reverse engineering ay agad na magbubunyag ng mga datos na ito. Gamitin ang Keystore para sa key, at para sa configuration — server loading kapag nagsimula ang app (remote config).

Gamitin ang biometric binding para sa mga kritikal na operasyon: Ang Android Keystore at iOS Keychain ay sumusuporta sa pag-uugnay ng key sa biometric authentication. Sa bawat pag-access sa key, hihingi ang system ng Face ID, Touch ID, o Android biometrics (BiometricPrompt). Ginagarantiya nito na kahit na may ganap na kontrol sa device, hindi magagamit ng attacker ang nakaimbak na datos nang walang may-ari.

Subukan ang proteksyon: gumamit ng mga tool sa pagsusuri ng seguridad — MobSF (Mobile Security Framework) para sa static analysis, objection para sa runtime testing, at Frida para sa pag-bypass ng proteksyon. Suriin na ang datos ay hindi ma-access pagkatapos ng rooting o jailbreak. Ang Android ay nagpapahintulot sa pagsusuri ng pagkakaroon ng root sa pamamagitan ng SafetyNet Attestation o Play Integrity API, iOS — sa pamamagitan ng pag-verify ng integridad ng Secure Enclave.

Regular na i-update ang cryptographic library: ang mga kahinaan sa encryption library ay regular na natutuklasan. Subaybayan ang CVE para sa AndroidX Security, SQLCipher, at Keychain wrapper. Magpatupad ng sistema ng awtomatikong abiso tungkol sa mga bagong bersyon sa pamamagitan ng Dependabot o Renovate.

Ayon sa Apple Security Research (2025), ang tamang pagpapatupad ng Secure Storage ay pumipigil sa 96% ng mga pag-atake na nagta-target sa pagnanakaw ng datos mula sa device. Ang natitirang 4% — mga pag-atake na may pisikal na access at zero-day exploit, kung saan epektibo ang biometric binding.