Code Signing — ano ito, pagpirma ng code at paano ito gumagana
Code Signing (pagpirma ng code) — mekanismo ng digital na pagpirma ng mga executable na file, na ginagarantiyahan ang pagiging tunay ng developer at integridad ng aplikasyon. Sa Android, bawat APK file ay dapat pirmahan ng sertipiko bago i-install sa device o i-publish sa Google Play. Ayon sa Google, 2024, sinusuportahan ng Android ang apat na henerasyon ng mga scheme ng pagpirma: mula v1 batay sa JAR hanggang v4 para sa streaming installation.
Pinakamahalaga
- Code Signing — digital na pirma ng code, na nagpapatunay sa pagiging may-akda at integridad ng aplikasyon.
- Sa Android, ang pagpirma ay ginagawa sa pamamagitan ng keystore — imbakan ng mga susi at sertipiko.
- Scheme v2 (APK Signature Scheme) — pangunahing pamantayan mula Android 7.0, na nagpoprotekta sa lahat ng byte ng APK.
- Pag-ikot ng susi (v3, Android 9.0+) ay nagbibigay-daan sa pagpalit ng susi ng pagpirma nang hindi tinatanggal ang aplikasyon.
- Gumagamit ang Google Play ng Play App Signing para sa sentralisadong pamamahala ng susi.
Ano ang Code Signing?
Code Signing — prosesong cryptographic kung saan pinipirmahan ng developer ang executable code gamit ang kanyang digital na sertipiko. Ang pirma ay nilikha gamit ang asymmetric encryption: gamit ang pribadong susi ng developer, nabubuo ang digital na pirma, at ang pampublikong susi ay naka-embed sa sertipiko. Kahit sino ay maaaring mag-verify ng pirma gamit ang pampublikong susi, ngunit ang pagbabago ng code nang hindi nasisira ang pirma ay imposible.
Sa mobile development, pagpirma ng code ay may tatlong function. Una — authentication: ang user at platform ay maaaring makilala ang developer ng aplikasyon. Pangalawa — integridad: anumang pagbabago sa APK pagkatapos ng pagpirma ay nagpapawalang-bisa sa pirma. Pangatlo — mapagkakatiwalaang update: pinapayagan ng platform ang pag-update ng aplikasyon lamang sa mga APK na pinirmahan ng parehong sertipiko tulad ng naka-install na bersyon.
Legal na katayuan
Ang digital na pirma ng mga Android application ay may legal na kahalagahan. Alinsunod sa batas ng Russian Federation (63-FZ) at European eIDAS, ang kwalipikadong electronic signature ay katumbas ng sariling lagda. Gayunpaman, ang pagpirma ng APK gamit ang self-signed na sertipiko (karaniwang kasanayan sa Android) ay hindi kwalipikado — kinukumpirma nito ang integridad, ngunit hindi ang pagkakakilanlan ng developer mula sa legal na pananaw.
Mga scheme ng pagpirma ng Android: v1, v2, v3, v4
Android ay sumusuporta sa apat na scheme ng pagpirma ng APK, bawat isa ay lumulutas sa mga problema ng nakaraang bersyon at nagdaragdag ng mga bagong kakayahan. Lahat ng scheme ay maaaring magkasama sa isang APK — ito ay kinakailangan para sa backward compatibility sa mas lumang bersyon ng Android.
Scheme v1 (JAR signing) ay lumitaw sa Android 1.0. Pinipirmahan nito ang mga indibidwal na file sa loob ng APK archive sa pamamagitan ng mga entry sa META-INF/MANIFEST.MF. Kahinaan: maaaring baguhin ang APK (magdagdag o magtanggal ng mga file) at muling pirmahan lamang ang mga binagong file, nang hindi ginagalaw ang pirma ng iba. Ito ay nagiging sanhi ng v1 na bulnerable sa ilang mga pag-atake. Scheme v2 (APK Signature Scheme), na ipinakilala sa Android 7.0, ay pinipirmahan ang buong APK file nang kumpleto, kasama ang lahat ng byte maliban sa pirma mismo, na nag-aalis ng posibilidad ng pumipiling pagbabago.
| Scheme | Android | Katangian | Pag-ikot ng susi |
|---|---|---|---|
| v1 (JAR) | 1.0+ | Pirma ng bawat file | Hindi |
| v2 | 7.0+ | Pirma ng buong APK | Hindi |
| v3 | 9.0+ | Pirma + pag-ikot | Oo |
| v4 | 11.0+ | Streaming + ADB | Oo |
v3: pag-ikot ng mga susi ng pagpirma
Scheme v3, na ipinakilala sa Android 9.0, ay lumulutas sa matagal nang problema: ano ang gagawin kung ang susi ng pagpirma ay nakompromiso o nag-expire? Dati, ang pagpapalit ng susi ng pagpirma ay nangangahulugan na ang aplikasyon ay itinuturing na bago — hindi ito mai-install sa ibabaw ng umiiral na. Nagdaragdag ang v3 ng mekanismo ng pag-ikot: sa APK ay maaaring isama ang patunay ng pagbabago ng susi (proof-of-rotation), na pinirmahan ng lumang susi. Sinusuri ng system ang chain at pinapayagan ang pag-update ng aplikasyon na pinirmahan ng bagong susi.
Keystore at mga sertipiko
Keystore — protektadong lalagyan na naglalaman ng mga pribadong susi at sertipiko para sa pagpirma ng mga aplikasyon. Sa Android development, ginagamit ang format na JKS (Java KeyStore) o PKCS12. Ang keystore ay nilikha gamit ang utility na keytool, na bahagi ng JDK. Ang bawat susi sa imbakan ay kinikilala ng alias at pinoprotektahan ng password.
Ang sertipiko sa keystore ay naglalaman ng pampublikong susi at impormasyon tungkol sa may-ari: pangalan ng organisasyon, bansa, panahon ng bisa. Para sa mga Android application, ang sertipiko ay maaaring self-signed — hindi nangangailangan ang Google ng certificate authority (CA), na nagpapakilala sa Android mula sa iOS. Gayunpaman, ang panahon ng bisa ng sertipiko ay dapat na hindi bababa sa 25 taon, dahil ang aplikasyon ay ia-update gamit ang parehong susi.
bash
# Paglikha ng bagong keystore para sa pagpirma
keytool -genkey -v -keystore my-release.keystore \
-alias my-app-alias \
-keyalg RSA \
-keysize 2048 \
-validity 10000
# Pagtingin ng nilalaman ng keystore
keytool -list -v -keystore my-release.keystoreMga format ng susi
Sinusuportahan ng Android ang dalawang algorithm para sa mga susi ng pagpirma: RSA at ECDSA. RSA na may sukat ng susi na 2048 bit — de facto standard, sinusuportahan ng lahat ng bersyon ng Android. Ang ECDSA (Elliptic Curve Digital Signature Algorithm) na may curve P-256 ay nagbibigay ng parehong cryptographic strength na may mas maliit na sukat ng susi. Mula Android 9.0, inirerekomenda ang paggamit ng ECDSA dahil mas mabilis ito sa pag-verify sa mga mobile device.
Pag-configure ng pagpirma sa build
Sa Android Gradle Plugin, ang pagpirma ay naka-configure sa pamamagitan ng block na signingConfigs sa build.gradle sa antas ng module. Para sa mga debug build, awtomatikong gumagawa ang Android Studio ng debug keystore na may alam na mga password. Para sa mga release build, tinutukoy ng developer ang path sa kanyang keystore, alias ng susi at mga password. Inirerekomenda na itago ang mga password sa magkahiwalay na configuration file, na hindi kasama sa version control system.
Ang modernong kasanayan ay sentralisadong pamamahala ng pagpirma sa pamamagitan ng CI/CD. Ang Jenkins, GitLab CI o GitHub Actions ay maaaring mag-imbak ng keystore bilang protektadong artifact, at mga password — sa mga lihim ng kapaligiran. Ito ay pumipigil sa pagtagas ng mga susi sa pamamagitan ng repository at pinapasimple ang pagpapalit ng susi kung kinakailangan.
groovy
// build.gradle (antas ng module) — configuration ng pagpirma
android {
signingConfigs {
release {
storeFile file("my-release.keystore")
storePassword System.getenv("KEYSTORE_PASSWORD")
keyAlias System.getenv("KEY_ALIAS")
keyPassword System.getenv("KEY_PASSWORD")
}
}
buildTypes {
release {
signingConfig signingConfigs.release
}
}
}Pagpirma ng maraming scheme
Para sa maximum na compatibility, ang APK ay dapat pirmahan ng lahat ng tatlong scheme (v1 + v2 + v3). Ang Android Gradle Plugin ay may kasamang lahat ng scheme bilang default. Ang APK na pinirmahan lamang ng v2 ay hindi mai-install sa Android 6.0 at mas mababa. APK na lamang v1 ay hindi magkakaroon ng mga bentahe ng integridad ng v2 sa Android 7.0+. Ang pagsasama ng lahat ng scheme ay hindi nagpapataas ng laki ng APK ng higit sa 1–2% at tinitiyak ang compatibility sa anumang device.
Play App Signing at pamamahala ng susi
Play App Signing — serbisyo ng Google Play na sentralisadong namamahala ng mga susi ng pagpirma ng mga aplikasyon. Ina-upload ng developer sa Google Play Console ang APK na pinirmahan ng upload key, at muling pinipirmahan ito ng Google Play gamit ang distribution key bago ihatid sa mga user. Pinoprotektahan nito ang distribution key mula sa pagkawala o kompromiso.
Mga bentahe ng Play App Signing: seguridad — ang distribution key ay naka-imbak sa protektadong imbakan ng Google; pag-ikot — maaaring humiling ng pagbabago ng susi sa pamamagitan ng console; pagbawi — kung mawala ang upload key, maaaring bumuo ng bago. Kahinaan: para sa mga application na umiral bago ang pagpapatupad ng Play App Signing, ang paglipat ay nangangailangan ng paglikha ng bagong application, dahil ang lumang distribution key ay ginagamit na.
bash
# Pagkuha ng fingerprint ng sertipiko (SHA-256)
keytool -list -v -keystore my-release.keystore \
-alias my-app-alias | grep "SHA256"
# Pagsusuri ng APK signature sa pamamagitan ng apksigner
apksigner verify --verbose app-release.apkPagbawi ng susi
Kung ang susi ng pagpirma ay nawala at hindi ginagamit ang Play App Signing, ang pagbawi ng kakayahang i-update ang aplikasyon ay imposible — kailangan mong lumikha ng bagong application sa Google Play na may bagong package name. Ito ay isa sa mga pangunahing dahilan upang gamitin ang Play App Signing. Inirerekomenda ng Google na mag-imbak ng backup ng keystore sa protektadong offline na imbakan (naka-encrypt na USB drive, bank vault).
Pag-verify ng pirma sa device
Sa pag-install ng APK, ginagawa ng Android ang pag-verify ng pirma sa ilang yugto. Una — pagsusuri ng sertipiko: hindi pa expired, tama ang format. Pangalawa — pagsusuri ng pirma: tugma ba ang cryptographic signature sa nilalaman ng APK. Pangatlo — paghahambing ng sertipiko sa naka-install na bersyon: kung ang application ay nasa device na, ang sertipiko ay dapat tumugma, kung hindi ay mai-block ang pag-install.
Ang sistema ng pag-verify ay naka-embed sa PackageManagerService. Sa pagproseso ng kahilingan sa pag-install, kinukuha ng PMS ang pirma mula sa APK, sinusuri ito gamit ang klase na android.util.PackageParser at inihahambing ito sa naka-imbak na pirma ng naka-install na application (kung mayroon). Sa kaso ng hindi pagkakatugma, natatanggap ng user ang error na „INSTALL_FAILED_UPDATE_INCOMPATIBLE”. Ang mekanismong ito ay pumipigil sa mga pag-atake ng pagpapalit (hindi maa-update ng malware ang lehitimong application gamit ang sarili nitong bersyon).
Pagsusuri ng developer
Maaaring suriin ng developer ang pirma ng APK gamit ang utility na apksigner mula sa Android SDK Build Tools. Ang command na apksigner verify --verbose app.apk ay nagpapakita kung anong mga scheme ang pinirmahan ng APK, kung valid ang mga sertipiko at kung tugma ang mga pirma sa nilalaman. Para sa programmatic na pag-verify ng pirma ng naka-install na application, ginagamit ang PackageManager.getPackageInfo() na may flag na GET_SIGNATURES.
kotlin
// Programmatic na pag-verify ng pirma ng naka-install na application
fun getAppSignature(context: Context, packageName: String): String? {
val pm = context.packageManager
val info = pm.getPackageInfo(
packageName,
PackageManager.GET_SIGNATURES
)
return info.signatures?.firstOrNull()?.toCharsString()
}Pinakamahusay na kasanayan sa seguridad ng pagpirma
Seguridad ng susi ng pagpirma — kritikal na aspeto ng Android development. Ang kompromiso ng susi ay nagpapahintulot sa attacker na pirmahan ang mga update ng iyong application gamit ang kanilang sariling code. Mga pangunahing patakaran: huwag kailanman itago ang susi sa repository, huwag gamitin ang isang susi para sa iba't ibang application, huwag ipadala ang susi sa pamamagitan ng hindi secure na mga channel (email, messenger).
Ang inirerekomendang kasanayan ay paghihiwalay ng mga susi. Gumamit ng hiwalay na susi para sa bawat application at hiwalay na susi para sa pag-upload sa Google Play (upload key). Para sa mga debug build, gumagawa ang Android Studio ng shared debug.keystore — hindi ito maaaring gamitin para sa mga release build. Ang panahon ng bisa ng sertipiko ay dapat na 25–30 taon (kasalukuyang pamantayan, kinumpirma ng Google).
| Kasanayan | Rekomendasyon |
|---|---|
| Pag-iimbak ng susi | Naka-encrypt na daluyan, CI/CD secrets |
| Panahon ng sertipiko | Hindi bababa sa 25 taon |
| Algorithm | RSA 2048+ o ECDSA P-256 |
| Paghihiwalay | Hiwalay na susi bawat application |
| Backup | Offline na kopya ng keystore |
Pag-audit ng mga pirma
Regular na suriin ang integridad ng chain ng pagpirma. Sa pagbabago ng mga empleyadong may access sa mga susi, i-update ang upload key sa pamamagitan ng Google Play Console. Gumamit ng mga tool tulad ng Google Play Integrity API upang suriin kung ang iyong application ay hindi peke sa mga device ng user. Ibinabalik ng API ang data tungkol sa pirma, integridad at ipinapadala ang mga ito sa server para sa pag-verify.
Mga madalas itanong
Ano ang Code Signing sa Android?
Code Signing — ay ang digital na pirma ng APK file na nagpapatunay na ang application ay ginawa ng isang partikular na developer at hindi nabago pagkatapos ng pagpirma. Kung walang pirma, hindi mai-install ang APK sa device.
Paano lumikha ng susi para sa pagpirma ng Android application?
Gamitin ang utility na keytool mula sa JDK: keytool -genkey -v -keystore my-release.keystore -alias my-alias -keyalg RSA -keysize 2048 -validity 10000. Ituro ang resultang keystore sa build.gradle sa block na signingConfigs.
Ano ang mangyayari kung mawala ang susi ng pagpirma?
Kung nawala ang susi at hindi ka gumagamit ng Play App Signing, ang pag-update ng application ay magiging imposible. Kailangan mong lumikha ng bagong application sa Google Play na may bagong package name. Gamitin ang Play App Signing upang protektahan ang iyong sarili mula sa pagkawala ng susi.
Ano ang pagkakaiba ng mga scheme ng pagpirma v1 at v2?
v1 ay pinipirmahan ang bawat file sa loob ng APK nang hiwalay — maaaring baguhin ng attacker ang isang file at muling pirmahan lamang ito. v2 ay pinipirmahan ang buong APK nang kumpleto — anumang pagbabago ay nagpapawalang-bisa sa pirma, na nagbibigay ng mas mataas na antas ng seguridad.
Ano ang Play App Signing?
Play App Signing — serbisyo ng Google Play na sentralisadong nag-iimbak ng distribution key ng mga application. Ina-upload ng developer ang APK na pinirmahan ng upload key, at muling pinipirmahan ito ng Google bago ihatid sa mga user, pinoprotektahan ang susi mula sa pagkawala o pagnanakaw.
Buod
- Code Signing — mandatoryong digital na pirma ng APK, na ginagarantiyahan ang pagiging tunay at integridad ng application.
- Sinusuportahan ng Android ang apat na scheme ng pagpirma: v1 (JAR), v2 (APK Signature), v3 (pag-ikot ng susi) at v4 (streaming).
- Keystore — protektadong lalagyan na may mga susi, nilikha sa pamamagitan ng keytool na may RSA 2048+ algorithm.
- Pag-ikot ng susi (v3, Android 9.0+) ay nagpapahintulot sa pagpapalit ng susi ng pagpirma nang hindi tinatanggal ang application.
- Play App Signing ay sentralisadong namamahala ng mga distribution key sa pamamagitan ng Google Play Console.
- Pag-verify ng pirma sa pag-install ay humaharang sa mga pag-atake ng pagpapalit: hindi pagkakatugma ng sertipiko = error na INSTALL_FAILED.
- Seguridad ng susi: hiwalay na susi bawat application, panahon 25+ taon, offline na kopya, walang susi sa repository.
Gagawa kami ng mobile application na turnkey
Gumagawa ang IT Sectr ng mga iOS at Android application para sa mga startup at negosyo mula noong 2017. Magpapayo kami sa iyo at magmumungkahi ng pinakamahusay na solusyon.
Basahin din