Keystore: esensya, anong mga format ang mayroon at kung paano ito gumagana

Ano ang Keystore

Keystore (KeyStore) — ay isang standard na mekanismo ng Java Cryptography Architecture (JCA) para sa pag-imbak ng mga cryptographic na susi, sertipiko at mapagkakatiwalaang mga entry. Sa pag-develop ng Android, ang Keystore ay ginagamit para sa pag-imbak ng pribadong susi kung saan naka-sign ang app bago i-publish. Ginagarantiya ng lagda na ang app ay talagang inilabas ng tinukoy na developer at ang code nito ay hindi binago pagkatapos ng pag-publish. Bawat update ng app ay dapat na naka-sign gamit ang parehong susi, kung hindi ay tatanggihan ng Google Play ang APK o App Bundle.

Ang Keystore ay maaaring maglaman ng maraming entry (alias), bawat isa ay kumakatawan sa isang pares ng susi (pribado at pampubliko) na may sertipiko. Alias — ang natatanging pangalan ng entry kung saan ina-access ng app ang susi sa pag-sign. Sa isang tipikal na Android project, ang Keystore ay naglalaman ng isang entry para sa pag-sign ng release version at maaaring maglaman ng mga karagdagang entry para sa pag-sign ng debug builds. Ipinapakita ng Google Play Console ang SHA-1 at SHA-256 fingerprint ng sertipiko para sa bawat na-upload na app.

Ang Android Studio ay may built-in na suporta para sa Keystore sa pamamagitan ng menu na Build → Generate Signed Bundle / APK. Ang signing wizard ng Android Studio ay nagpapahintulot na gumawa ng bagong Keystore o pumili ng umiiral na, tukuyin ang alias, mga password ng Keystore at susi, pati na rin ang data ng sertipikasyon (pangalan ng organisasyon, lungsod, bansa). Ang data na ito ay naka-embed sa sertipiko at nakikita ng mga user kapag sine-verify ang lagda ng APK. Kinakailangan ng Google Play na ang bisa ng sertipiko ay hindi bababa sa 25 taon — sinusuri ng Android ang petsa ng pag-expire kapag ini-install ang app.

Bakit mahalaga ang Keystore para sa Android

Ang pag-update ng app sa Google Play ay posible lamang gamit ang parehong susi kung saan naka-sign ang unang bersyon. Kung nawala ang Keystore, imposibleng mag-publish ng update — ang app ay kailangang ilabas muli sa ilalim ng bagong package name. Ayon sa Google Play Console Help (2026), ang signing key ng app ay maaari lamang mabawi sa pamamagitan ng Google Play App Signing — isang serbisyo na nag-iimbak ng susi sa panig ng Google. Kung ginamit ng developer ang opsyong ito, ang pagkawala ng lokal na Keystore ay hindi kritikal.

Paano gumagana ang Keystore

Ang proseso ng pag-sign ng Android app ay kinabibilangan ng paggawa ng digest (hash) ng nilalaman ng APK at pag-encrypt nito gamit ang pribadong susi mula sa Keystore. Ang Android SDK Build Tools ay may kasamang utility na apksigner na nagsasagawa ng pag-sign sa format na APK Signature Scheme v2 (o v3 para sa Android 9+). Kapag ini-install ang app, sine-verify ng Android ang lagda: dini-decrypt ang lagda gamit ang pampublikong susi ng sertipiko, inihahambing ang hash ng APK sa orihinal — kung hindi tugma ang mga hash, tatanggihan ang pag-install.

Sinusuportahan ng Android ang ilang signing scheme: v1 (JAR signing), v2 (APK Signature Scheme), v3 (APK Signature Scheme na may suporta sa key rotation) at v4 (incremental na pag-install ng Android 11+). Kinakailangan ng Google Play ang v2 o v3 para sa mga bagong app. Awtomatikong idinaragdag ng apksigner ang lahat ng kinakailangang scheme sa pag-sign, kung sinusuportahan ng susi ang mga kaukulang algorithm. Ang Android 11+ ay sumusuporta sa ADB installation na may v4 signature, na nagpapabilis ng incremental na pag-load ng malalaking APK file sa device.

Mga algorithm: Inirerekomenda ng Android ang paggamit ng RSA-2048 o ECDSA P-256 para sa signing key. Ang sertipiko ay dapat na X.509 v3. Sinusuri ng Android kung ang sertipiko ay wasto sa oras ng pag-install — kung nag-expire na, ang pag-install ay haharangin. Ito ang dahilan kung bakit inirerekomenda ng Google na itakda ang panahon ng bisa ng sertipiko sa hindi bababa sa 25 taon. Ang Google Play App Signing ay gumagamit ng dalawang susi: ang app signing key at ang upload key — ang upload key ay ginagamit ng developer para mag-upload ng APK sa Console, at pinipirmahan ng Google ang app para sa mga user gamit ang pangunahing susi.

Mga format ng Keystore: JKS at PKCS12

Sinusuportahan ng Java ang dalawang pangunahing format ng Keystore: JKS (Java KeyStore) — ang proprietary na format ng Oracle, umiiral mula noong JDK 1.2, at PKCS12 — ang standardized na format na Public-Key Cryptography Standards #12 mula sa RSA Laboratories. Ang JKS ay gumagamit ng sarili nitong format ng pag-imbak ng data at sinusuportahan lamang sa Java ecosystem. Ang PKCS12 ay isang bukas na pamantayan na sinusuportahan ng Java, .NET, OpenSSL, Python (cryptography) at karamihan sa iba pang cryptographic na mga library.

Inirerekomenda ng Google Play ang PKCS12 bilang ginustong format para sa mga bagong Keystore na ginawa pagkatapos ng 2021. Ang JDK 9 at mas bago ay lumilikha ng Keystore bilang default sa PKCS12 format (dati ang default ay JKS). Ang pangunahing bentahe ng PKCS12 ay compatibility: ang .p12 file ay maaaring buksan sa anumang kapaligiran na hindi nakatali sa Java. Ang OpenSSL ay maaaring kumuha ng mga sertipiko mula sa PKCS12 at i-convert ang mga ito sa PEM format. Ang mga JKS file ay nangangailangan ng JDK utilities para mabasa at hindi ma-process ng OpenSSL.

Ang conversion sa pagitan ng mga format ay ginagawa gamit ang keytool utility mula sa JDK. Sa paglipat mula JKS patungong PKCS12, dapat tiyakin na ang lahat ng alias at password ay nailipat nang tama. Ang command na keytool -importkeystore ay nagpapahintulot sa pag-import ng nilalaman ng isang Keystore sa isa pa anuman ang format. Pagkatapos ng conversion, mas mainam na tanggalin ang lumang JKS file upang maiwasan ang pagkalito sa mga bersyon ng susi. Ang Android Studio ay sumusuporta sa parehong format kapag gumagawa ng naka-sign na build.

Paggawa ng Keystore gamit ang keytool

Ang utility na keytool ay bahagi ng JDK (Java Development Kit) at nagbibigay ng kumpletong hanay ng mga command para sa paggawa, pagtingin at pamamahala ng Keystore. Para gumawa ng bagong Keystore na may isang pares ng susi, gamitin ang command na keytool -genkeypair na may pagtukoy sa PKCS12 format, RSA algorithm, laki ng susi at panahon ng bisa ng sertipiko. Kinakailangan ng Google Play ang bisa ng sertipiko ng hindi bababa sa 25 taon (9125 araw) — ang halagang ito ay inirerekomenda na tukuyin sa parameter na -validity.

Paggawa ng bagong Keystore

Halimbawa ng paggawa ng Keystore sa PKCS12 format para sa isang Android project. Ang parameter na -dname ay naglalaman ng X.500 Distinguished Name ng sertipiko. Ang parameter na -ext ay magpapagana ng Subject Alternative Name kung kinakailangan — para sa Android, sapat na ang Basic Constraints:

# Paggawa ng PKCS12 Keystore para sa Android
keytool -genkeypair -alias "upload_key" \
  -keyalg RSA -keysize 2048 -validity 9125 \
  -keystore "release-keystore.p12" \
  -storetype PKCS12 \
  -dname "CN=Developer,O=Company,C=RU"

Keytool ay hihingi ng password ng Keystore at password ng susi (maaaring pareho). Ang parameter na -storetype PKCS12 ay lumilikha ng file sa modernong format. Ang -keysize 2048 ay tumutugma sa mga kinakailangan ng Google para sa minimum na laki ng RSA key. Ang -validity 9125 (25 taon) ay nagsisiguro ng compatibility sa buong inaasahang lifecycle ng app. Pagkatapos gawin ang Keystore, inirerekomenda na suriin ang nilalaman nito gamit ang command na keytool -list -v -keystore release-keystore.p12.

Pagtingin sa nilalaman ng Keystore

Para suriin ang mga entry ng Keystore, gamitin ang command na may flag na -list. Kasama sa output ang alias, mga petsa ng paggawa at pag-expire, uri ng entry at SHA-256 fingerprint. Ang Android Studio ay nagpapakita ng parehong impormasyon sa dialog na Generate Signed Bundle / APK kapag pumipili ng umiiral na Keystore:

# Pagtingin sa mga entry ng Keystore
keytool -list -v -keystore "release-keystore.p12" \
  -storetype PKCS12

Paggamit ng Keystore sa CI/CD

Sa CI/CD pipeline, ang Keystore ay dapat na naka-imbak nang secure at ilipat sa build agent nang walang panganib ng kompromiso. Ang GitHub Actions ay nagbibigay ng Secrets para sa pag-imbak ng binary file sa base64 format. Ang Keystore ay naka-encode gamit ang base64 command, ang resultang string ay naka-imbak sa mga lihim ng repository, at sa yugto ng build ay dina-decode pabalik sa isang file. Ang GitLab CI ay gumagamit ng katulad na mekanismo sa pamamagitan ng Variables na may type na File.

Isang halimbawa ng configuration ng CI build na may Keystore sa GitHub Actions ay kinabibilangan ng pag-decode ng Keystore mula sa lihim, pag-configure ng Gradle properties at pag-execute ng naka-sign na build. Ang Gradle ng Android plugin ay nagbabasa ng path sa Keystore at mga password mula sa file na keystore.properties (hindi kasama sa .gitignore para sa lokal na pag-develop) o mula sa mga environment variable ng CI system:

// build.gradle (app) — configuration ng pag-sign
@Override
android {
    signingConfigs {
        release {
            storeFile file("release-keystore.p12")
            storePassword System.getenv("STORE_PASSWORD")
            keyAlias System.getenv("KEY_ALIAS")
            keyPassword System.getenv("KEY_PASSWORD")
        }
    }
    buildTypes {
        release {
            signingConfig signingConfigs.release
        }
    }
}

Ang Gradle ay nagbabasa ng environment variable na itinakda ng CI system. Ang Keystore file ay dapat na matatagpuan sa root directory ng app module, gaya ng tinukoy sa storeFile. Para sa seguridad, huwag kailanman mag-imbak ng mga password sa repository — gamitin ang Secrets ng CI system. Ang Fastlane para sa Android ay nagbibigay ng supply plugin na gumagana sa Google Play Console, ngunit ang pag-sign ng APK ay nangangailangan pa rin ng lokal na Keystore sa agent.

Ang alternatibo ay Google Play App Signing. Kapag ginagamit ang opsyong ito, ang developer ay nag-a-upload lamang ng upload key sa Google Play, at pinipirmahan ng Google ang huling APK gamit ang sarili nitong susi. Sa kasong ito, ang Keystore ay ginagamit lamang para sa paggawa ng upload key, at ang pagkawala nito ay hindi humaharang sa mga update — maaaring gumawa ng bagong upload key at i-rehistro ito sa Console. Ang Google Play App Signing ay sapilitan para sa mga bagong app mula noong Agosto 2021.

Seguridad at backup ng Keystore

Ang pagkawala ng Keystore ay isa sa mga pinaka-kritikal na problema sa pag-develop ng Android. Kung walang backup ng Keystore, hindi mailalabas ang update ng umiiral na app — tinatanggihan ng Google Play ang APK na naka-sign gamit ang ibang susi. Inirerekomenda na mag-imbak ng hindi bababa sa dalawang backup ng Keystore sa iba't ibang pisikal o cloud na imbakan: halimbawa, isang naka-encrypt na file sa cloud storage ng team at isang physical na media sa safe ng organisasyon. Ang mga password ng Keystore at susi ay naka-imbak nang hiwalay sa file, halimbawa sa isang password manager na may kontrol sa pag-access.

Ang Android Studio kapag gumagawa ng bagong Keystore sa dialog na Generate Signed Bundle / APK ay nag-aalok na tandaan ang mga path para sa mga susunod na build. Gayunpaman, ang development environment mismo ay hindi gumagawa ng backup — ito ay responsibilidad ng developer. Para sa team development, inirerekomenda na gamitin ang Google Play App Signing na may paglipat ng upload key sa pamamagitan ng secure na channel sa lahat ng miyembro ng team. Ang Gradle ay nagpapahintulot sa pag-sign ng debug builds gamit ang awtomatikong nabuong debug.keystore, na hindi nangangailangan ng backup — pareho ito para sa lahat ng pag-install ng Android Studio.

Seguridad ng Keystore sa paglipat: ang .p12 o .jks file ay dapat lamang ilipat sa pamamagitan ng naka-encrypt na mga channel (SFTP, HTTPS, naka-encrypt na email attachment). Huwag kailanman isama ang Keystore sa source code repository — kahit pribado. Ang GitGuardian o GitHub secret scanning ay awtomatikong nakakatuklas ng pag-publish ng mga kredensyal, ngunit ang pag-imbak ng Keystore sa repository ay isa pa ring paglabag sa seguridad. Para sa CI/CD, gamitin ang platform secret mechanism (GitHub Actions Secrets, GitLab CI Variables, Jenkins Credentials) na may encryption sa antas ng infrastructure.