Keystore: podstata, jaké jsou formáty a jak funguje

Co je Keystore

Keystore (KeyStore) — je standardní mechanismus Java Cryptography Architecture (JCA) pro ukládání kryptografických klíčů, certifikátů a důvěryhodných záznamů. Při vývoji Androidu se Keystore používá k ukládání soukromého klíče, kterým se aplikace podepisuje před publikováním. Podpis zaručuje, že aplikace byla skutečně vydána uvedeným vývojářem a že její kód nebyl po publikování změněn. Každá aktualizace aplikace musí být podepsána stejným klíčem, jinak Google Play APK nebo App Bundle odmítne.

Keystore může obsahovat několik záznamů (aliasů), z nichž každý představuje pár klíčů (soukromý a veřejný) s certifikátem. Alias — jedinečný název záznamu, pod kterým aplikace přistupuje ke klíči při podepisování. V typickém Android projektu obsahuje Keystore jeden záznam pro podepisování release verze a může obsahovat další pro podepisování debug sestavení. Google Play Console zobrazuje otisky SHA-1 a SHA-256 certifikátu pro každou nahranou aplikaci.

Android Studio zahrnuje vestavěnou podporu pro Keystore prostřednictvím nabídky Build → Generate Signed Bundle / APK. Průvodce podepisováním Android Studio umožňuje vytvořit nový Keystore nebo vybrat existující, zadat alias, hesla Keystore a klíče, stejně jako certifikační údaje (název organizace, město, zemi). Tato data jsou vložena do certifikátu a viditelná uživatelům při ověřování podpisu APK. Google Play vyžaduje, aby platnost certifikátu byla nejméně 25 let — Android kontroluje datum vypršení při instalaci aplikace.

Proč je Keystore důležitý pro Android

Aktualizace aplikace v Google Play je možná pouze stejným klíčem, kterým byla podepsána první verze. Pokud je Keystore ztracen, publikování aktualizace je nemožné — aplikaci bude nutné znovu vydat pod novým názvem balíčku (package name). Podle Google Play Console Help (2026) lze klíč pro podepisování aplikace obnovit pouze prostřednictvím Google Play App Signing — služby, která ukládá klíč na straně Google. Pokud vývojář tuto možnost použil, ztráta místního Keystore není kritická.

Jak Keystore funguje

Proces podepisování Android aplikace zahrnuje vytvoření výtahu (hashe) obsahu APK a jeho zašifrování soukromým klíčem z Keystore. Android SDK Build Tools zahrnují nástroj apksigner, který provádí podepisování ve formátu APK Signature Scheme v2 (nebo v3 pro Android 9+). Při instalaci aplikace Android ověřuje podpis: dešifruje podpis veřejným klíčem certifikátu, porovná hash APK s originálem — pokud se hashe neshodují, instalace je odmítnuta.

Android podporuje několik schémat podepisování: v1 (JAR signing), v2 (APK Signature Scheme), v3 (APK Signature Scheme s podporou rotace klíčů) a v4 (inkrementální instalace Android 11+). Google Play vyžaduje v2 nebo v3 pro nové aplikace. apksigner automaticky přidává všechna potřebná schémata při podepisování, pokud klíč podporuje odpovídající algoritmy. Android 11+ podporuje instalaci ADB s podpisem v4, což urychluje inkrementální načítání velkých APK souborů do zařízení.

Algoritmy: Android doporučuje používat RSA-2048 nebo ECDSA P-256 pro podpisový klíč. Certifikát by měl být X.509 v3. Android kontroluje, zda je certifikát platný v okamžiku instalace — pokud vypršel, instalace je blokována. Právě proto Google doporučuje nastavit dobu platnosti certifikátu na nejméně 25 let. Google Play App Signing používá dva klíče: klíč aplikace (app signing key) a nahrávací klíč (upload key) — nahrávací klíč používá vývojář k nahrání APK do Console a Google podepisuje aplikaci pro uživatele hlavním klíčem.

Formáty Keystore: JKS a PKCS12

Java podporuje dva hlavní formáty Keystore: JKS (Java KeyStore) — proprietární formát Oracle, existující od JDK 1.2, a PKCS12 — standardizovaný formát Public-Key Cryptography Standards #12 od RSA Laboratories. JKS používá vlastní formát ukládání dat a je podporován pouze v ekosystému Java. PKCS12 je otevřený standard podporovaný Javou, .NET, OpenSSL, Python (cryptography) a většinou ostatních kryptografických knihoven.

Google Play doporučuje PKCS12 jako preferovaný formát pro nové Keystore vytvořené po roce 2021. JDK 9 a novější vytvářejí Keystore ve výchozím nastavení ve formátu PKCS12 (dříve byl výchozí JKS). Hlavní výhodou PKCS12 je kompatibilita: soubor .p12 lze otevřít v jakémkoli prostředí nezávislém na Javě. OpenSSL může extrahovat certifikáty z PKCS12 a převést je do formátu PEM. Soubory JKS vyžadují nástroje JDK pro čtení a nelze je zpracovat OpenSSL.

Převod mezi formáty se provádí nástrojem keytool z JDK. Při migraci z JKS na PKCS12 je třeba se ujistit, že všechny aliasy a hesla byly správně přeneseny. Příkaz keytool -importkeystore umožňuje importovat obsah jednoho Keystore do druhého bez ohledu na formát. Po převodu je lepší starý soubor JKS smazat, aby nedošlo k záměně s verzemi klíče. Android Studio podporuje oba formáty při generování podepsaného sestavení.

Vytvoření Keystore pomocí keytool

Nástroj keytool je součástí JDK (Java Development Kit) a poskytuje úplnou sadu příkazů pro vytváření, prohlížení a správu Keystore. Pro vytvoření nového Keystore s jedním párem klíčů se používá příkaz keytool -genkeypair s uvedením formátu PKCS12, algoritmu RSA, velikosti klíče a doby platnosti certifikátu. Google Play vyžaduje platnost certifikátu nejméně 25 let (9125 dní) — tuto hodnotu se doporučuje uvést v parametru -validity.

Vytvoření nového Keystore

Příklad generování Keystore ve formátu PKCS12 pro Android projekt. Parametr -dname obsahuje X.500 Distinguished Name certifikátu. Parametr -ext v případě potřeby zapne Subject Alternative Name — pro Android stačí Basic Constraints:

# Vytvoření PKCS12 Keystore pro 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 vyzve k zadání hesla Keystore a hesla klíče (mohou být stejná). Parametr -storetype PKCS12 vytváří soubor v moderním formátu. -keysize 2048 odpovídá požadavkům Google na minimální velikost klíče RSA. -validity 9125 (25 let) zajišťuje kompatibilitu po celý očekávaný životní cyklus aplikace. Po vytvoření Keystore se doporučuje zkontrolovat jeho obsah příkazem keytool -list -v -keystore release-keystore.p12.

Prohlížení obsahu Keystore

Pro kontrolu záznamů Keystore se používá příkaz s přepínačem -list. Výstup zahrnuje alias, data vytvoření a vypršení, typ záznamu a otisky SHA-256. Android Studio zobrazuje stejné informace v dialogovém okně Generate Signed Bundle / APK při výběru existujícího Keystore:

# Zobrazení záznamů Keystore
keytool -list -v -keystore "release-keystore.p12" \
  -storetype PKCS12

Použití Keystore v CI/CD

V CI/CD pipeline musí být Keystore bezpečně uložen a předán sestavovacímu agentovi bez rizika kompromitace. GitHub Actions poskytuje Secrets pro ukládání binárních souborů ve formátu base64. Keystore se zakóduje příkazem base64, výsledný řetězec se uloží do tajemství repozitáře a ve fázi sestavení se dekóduje zpět do souboru. GitLab CI používá podobný mechanismus prostřednictvím Variables s typem File.

Příklad konfigurace CI sestavení s Keystore v GitHub Actions zahrnuje dekódování Keystore z tajemství, konfiguraci vlastností Gradle a provedení podepsaného sestavení. Gradle Android pluginu čte cestu k Keystore a hesla ze souboru keystore.properties (vyloučeného z .gitignore pro lokální vývoj) nebo z proměnných prostředí CI systému:

// build.gradle (app) — konfigurace podepisování
@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 čte proměnné prostředí nastavené CI systémem. Soubor Keystore by měl být umístěn v kořenovém adresáři modulu aplikace, jak je uvedeno v storeFile. Kvůli bezpečnosti nikdy neukládejte hesla v repozitáři — používejte Secrets CI systému. Fastlane pro Android poskytuje plugin supply, který pracuje s Google Play Console, ale podepisování APK stejně vyžaduje místní Keystore na agentovi.

Alternativou je Google Play App Signing. Při použití této možnosti vývojář nahrává do Google Play pouze nahrávací klíč (upload key) a Google podepisuje finální APK svým klíčem. V tomto případě se Keystore používá pouze pro vytvoření nahrávacího klíče a jeho ztráta neblokuje aktualizace — lze vygenerovat nový upload key a zaregistrovat jej v Console. Google Play App Signing je povinný pro nové aplikace od srpna 2021.

Bezpečnost a zálohování Keystore

Ztráta Keystore je jedním z nejkritičtějších problémů při vývoji Androidu. Bez zálohy Keystore nelze vydat aktualizaci existující aplikace — Google Play odmítá APK podepsaný jiným klíčem. Doporučuje se ukládat alespoň dvě zálohy Keystore v různých fyzických nebo cloudových úložištích: například zašifrovaný soubor v cloudovém úložišti týmu a fyzické médium v trezoru organizace. Hesla Keystore a klíče se ukládají odděleně od souboru, například ve správci hesel s kontrolou přístupu.

Android Studio při vytváření nového Keystore v dialogovém okně Generate Signed Bundle / APK nabízí zapamatování cest pro budoucí sestavení. Samotné vývojové prostředí však zálohu nevytváří — to je odpovědnost vývojáře. Pro týmový vývoj se doporučuje používat Google Play App Signing s předáním upload key prostřednictvím bezpečného kanálu všem členům týmu. Gradle umožňuje podepisování debug sestavení automaticky generovaným debug.keystore, který nevyžaduje zálohování — je stejný pro všechny instalace Android Studio.

Bezpečnost Keystore při přenosu: soubor .p12 nebo .jks by měl být přenášen pouze prostřednictvím šifrovaných kanálů (SFTP, HTTPS, šifrované e-mailové přílohy). Nikdy nezahrnujte Keystore do repozitáře zdrojového kódu — ani soukromého. GitGuardian nebo GitHub secret scanning automaticky detekují publikaci přihlašovacích údajů, ale ukládání Keystore v repozitáři je stále porušením bezpečnosti. Pro CI/CD používejte mechanismus tajemství platformy (GitHub Actions Secrets, GitLab CI Variables, Jenkins Credentials) se šifrováním na úrovni infrastruktury.