Keystore: суштина, који формати постоје и како ради

Шта је Keystore

Keystore (KeyStore) — стандардни механизам Java Cryptography Architecture (JCA) за чување криптографских кључева, сертификата и поузданих записа. У Android развоју, Keystore се користи за чување приватног кључа којим се апликација потписује пре објављивања. Потпис гарантује да је апликацију заиста објавио наведени програмер и да њен код није измењен након објављивања. Свако ажурирање апликације мора бити потписано истим кључем, у супротном Google Play ће одбити APK или App Bundle.

Keystore може садржати више записа (алиаса), од којих сваки представља пар кључева (приватни и јавни) са сертификатом. Alias — јединствено име записа под којим апликација приступа кључу приликом потписивања. У типичном Android пројекту, Keystore садржи један запис за потписивање релизне верзије и може садржати додатне за потписивање дебаг верзија. Google Play Console приказује SHA-1 и SHA-256 отиске сертификата за сваку отпремљену апликацију.

Android Studio укључује уграђену подршку за Keystore кроз мени Build → Generate Signed Bundle / APK. Чаробњак за потписивање Android Studio-а омогућава креирање новог Keystore-а или избор постојећег, навођење алиаса, лозинки Keystore-а и кључа, као и сертификационих података (назив организације, град, држава). Ови подаци се уграђују у сертификат и видљиви су корисницима приликом провере потписа APK-а. Google Play захтева да важност сертификата буде најмање 25 година — Android проверава датум истека приликом инсталације апликације.

Зашто је Keystore важан за Android

Ажурирање апликације у Google Play-у је могуће само истим кључем којим је потписана прва верзија. Ако се Keystore изгуби, објављивање ажурирања је немогуће — апликација ће морати да се поново објави под новим именом пакета (package name). Према Google Play Console Help (2026), кључ за потписивање апликације може се опоравити само путем Google Play App Signing-а — услуге која чува кључ на Google-овој страни. Ако је програмер користио ову опцију, губитак локалног Keystore-а није критичан.

Како ради Keystore

Процес потписивања Android апликације укључује креирање сажетка (хаша) садржаја APK-а и његово шифровање приватним кључем из Keystore-а. Android SDK Build Tools укључују алат apksigner који врши потписивање у формату APK Signature Scheme v2 (или v3 за Android 9+). Приликом инсталације апликације, Android проверава потпис: дешифрује потпис јавним кључем сертификата, упоређује хаш APK-а са оригиналом — ако се хашеви не поклапају, инсталација се одбија.

Android подржава неколико шема потписивања: v1 (JAR signing), v2 (APK Signature Scheme), v3 (APK Signature Scheme са подршком за ротацију кључева) и v4 (инкременталне инсталације Android 11+). Google Play захтева v2 или v3 за нове апликације. apksigner аутоматски додаје све потребне шеме приликом потписивања, ако кључ подржава одговарајуће алгоритме. Android 11+ подржава ADB инсталацију са v4 потписом, што убрзава инкрементално учитавање великих APK датотека на уређај.

Алгоритми: Android препоручује коришћење RSA-2048 или ECDSA P-256 за кључ потписивања. Сертификат треба да буде X.509 v3. Android проверава да ли је сертификат важећи у тренутку инсталације — ако је истекао, инсталација се блокира. Управо зато Google препоручује постављање периода важења сертификата на најмање 25 година. Google Play App Signing користи два кључа: кључ апликације (app signing key) и кључ за отпремање (upload key) — кључ за отпремање користи програмер за отпремање APK-а у Console, а Google потписује апликацију за кориснике главним кључем.

Формати Keystore-а: JKS и PKCS12

Java подржава два главна формата Keystore-а: JKS (Java KeyStore) — власнички формат Oracle-а, постоји од JDK 1.2, и PKCS12 — стандардизовани формат Public-Key Cryptography Standards #12 од RSA Laboratories. JKS користи сопствени формат чувања података и подржан је само у Java екосистему. PKCS12 је отворени стандард који подржавају Java, .NET, OpenSSL, Python (cryptography) и већина других криптографских библиотека.

Google Play препоручује PKCS12 као пожељни формат за нове Keystore-ове креиране након 2021. године. JDK 9 и новије верзије подразумевано креирају Keystore у PKCS12 формату (раније је подразумевани био JKS). Главна предност PKCS12-а је компатибилност: .p12 датотека се може отворити у било ком окружењу које није везано за Java. OpenSSL може да извуче сертификате из PKCS12-а и конвертује их у PEM формат. JKS датотеке захтевају JDK алате за читање и не могу се обрадити OpenSSL-ом.

Конверзија између формата врши се алатом keytool из JDK-а. Приликом миграције са JKS на PKCS12, потребно је осигурати да су сви алиаси и лозинке правилно пренети. Команда keytool -importkeystore омогућава увоз садржаја једног Keystore-а у други без обзира на формат. Након конверзије, стару JKS датотеку је боље обрисати како би се избегла забуна са верзијама кључа. Android Studio подржава оба формата приликом генерисања потписаног билда.

Креирање Keystore-а помоћу keytool-а

Алат keytool је део JDK-а (Java Development Kit) и пружа комплетан скуп команди за креирање, преглед и управљање Keystore-ом. За креирање новог Keystore-а са једним паром кључева користи се команда keytool -genkeypair са навођењем формата PKCS12, алгоритма RSA, величине кључа и периода важења сертификата. Google Play захтева важност сертификата од најмање 25 година (9125 дана) — ову вредност је препоручено навести у параметру -validity.

Креирање новог Keystore-а

Пример генерисања Keystore-а у PKCS12 формату за Android пројекат. Параметар -dname садржи X.500 Distinguished Name сертификата. Параметар -ext ће укључити Subject Alternative Name, ако је потребан — за Android су довољни Basic Constraints:

# Креирање PKCS12 Keystore-а за 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 ће затражити лозинку Keystore-а и лозинку кључа (могу бити исте). Параметар -storetype PKCS12 креира датотеку у модерном формату. -keysize 2048 одговара Google-овим захтевима за минималну величину RSA кључа. -validity 9125 (25 година) обезбеђује компатибилност током целог очекиваног животног циклуса апликације. Након креирања Keystore-а, препоручује се провера његовог садржаја командом keytool -list -v -keystore release-keystore.p12.

Преглед садржаја Keystore-а

За проверу записа Keystore-а користи се команда са заставицом -list. Резултат укључује алиас, датуме креирања и истека, тип записа и SHA-256 отиске. Android Studio приказује исте информације у дијалогу Generate Signed Bundle / APK приликом избора постојећег Keystore-а:

# Преглед записа Keystore-а
keytool -list -v -keystore "release-keystore.p12" \
  -storetype PKCS12

Коришћење Keystore-а у CI/CD

У CI/CD цевоводу, Keystore мора бити сачуван на безбедан начин и прослеђен агента за билд без ризика од компромитације. GitHub Actions пружа Secrets за чување бинарних датотека у base64 формату. Keystore се кодује командом base64, добијени стринг се чува у тајнама репозиторијума, а у фази билда се декодује назад у датотеку. GitLab CI користи сличан механизам кроз Variables са типом File.

Пример конфигурације CI билда са Keystore-ом у GitHub Actions-у укључује декодовање Keystore-а из тајне, конфигурисање Gradle својстава и извршавање потписаног билда. Gradle Android прикључак чита путању до Keystore-а и лозинке из датотеке keystore.properties (искључене из .gitignore-а за локални развој) или из променљивих окружења CI система:

// build.gradle (app) — конфигурација потписивања
@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
        }
    }
}

Gradle чита променљиве окружења постављене од стране CI система. Датотека Keystore треба да се налази у корену модула апликације, како је наведено у storeFile. Ради безбедности, никада не чувајте лозинке у репозиторијуму — користите Secrets CI система. Fastlane за Android пружа прикључак supply који ради са Google Play Console-ом, али потписивање APK-а и даље захтева локални Keystore на агенту.

Алтернатива је Google Play App Signing. При коришћењу ове опције, програмер отпрема у Google Play само кључ за отпремање (upload key), а Google потписује коначни APK својим кључем. У овом случају, Keystore се користи само за креирање кључа за отпремање, а његов губитак не блокира ажурирања — може се генерисати нови upload key и регистровати у Console-у. Google Play App Signing је обавезан за нове апликације од августа 2021. године.

Безбедност и резервна копија Keystore-а

Губитак Keystore-а је један од најкритичнијих проблема у Android развоју. Без резервне копије Keystore-а није могуће објавити ажурирање постојеће апликације — Google Play одбија APK потписан другим кључем. Препоручује се чување најмање две резервне копије Keystore-а у различитим физичким или облачним складиштима: на пример, шифрована датотека у облачном складишту тима и физички медиј у сефу организације. Лозинке Keystore-а и кључа чувају се одвојено од датотеке, на пример у менаџеру лозинки са контролом приступа.

Android Studio приликом креирања новог Keystore-а у дијалогу Generate Signed Bundle / APK нуди да запамти путање за будуће билдове. Међутим, само развојно окружење не креира резервну копију — то је одговорност програмера. За тимски развој, препоручује се коришћење Google Play App Signing-а са преносом upload key-а преко безбедног канала свим члановима тима. Gradle омогућава потписивање дебаг билдова аутоматски генерисаним debug.keystore-ом, који не захтева прављење резервне копије — исти је за све инсталације Android Studio-а.

Безбедност Keystore-а приликом преноса: .p12 или .jks датотека сме се преносити само преко шифрованих канала (SFTP, HTTPS, шифровани имејл прилози). Никада не укључујте Keystore у репозиторијум изворног кода — чак ни приватни. GitGuardian или GitHub secret scanning аутоматски откривају објављивање акредитива, али чување Keystore-а у репозиторијуму и даље представља безбедносни пропуст. За CI/CD користите механизам тајни платформе (GitHub Actions Secrets, GitLab CI Variables, Jenkins Credentials) са шифровањем на нивоу инфраструктуре.