Keystore: Was es ist, welche Formate es gibt und wie es funktioniert

Was ist ein Keystore

Keystore (KeyStore) ist ein Standardmechanismus der Java Cryptography Architecture (JCA) zum Speichern von kryptografischen Schlüsseln, Zertifikaten und vertrauenswürdigen Einträgen. In der Android-Entwicklung wird der Keystore verwendet, um den privaten Schlüssel zu speichern, mit dem die App vor der Veröffentlichung signiert wird. Die Signatur garantiert, dass die App tatsächlich vom angegebenen Entwickler veröffentlicht wurde und ihr Code nach der Veröffentlichung nicht verändert wurde. Jedes App-Update muss mit demselben Schlüssel signiert werden, sonst lehnt Google Play die APK oder das App Bundle ab.

Ein Keystore kann mehrere Einträge (Aliase) enthalten, die jeweils ein Schlüsselpaar (privat und öffentlich) mit einem Zertifikat darstellen. Alias ist ein eindeutiger Eintragsname, über den die App beim Signieren auf den Schlüssel zugreift. In einem typischen Android-Projekt enthält der Keystore einen Eintrag zum Signieren der Release-Version und kann zusätzliche Einträge zum Signieren von Debug-Builds enthalten. Die Google Play Console zeigt die SHA-1- und SHA-256-Zertifikatsfingerabdrücke für jede hochgeladene App an.

Android Studio bietet integrierte Keystore-Unterstützung über das Menü Build → Generate Signed Bundle / APK. Der Signierungsassistent von Android Studio ermöglicht es, einen neuen Keystore zu erstellen oder einen vorhandenen auszuwählen, einen Alias, Keystore- und Schlüsselpasswörter sowie Zertifikatsdaten (Organisationsname, Stadt, Land) anzugeben. Diese Daten werden in das Zertifikat eingebettet und sind für Benutzer bei der Überprüfung der APK-Signatur sichtbar. Google Play verlangt, dass das Zertifikat mindestens 25 Jahre gültig ist — Android überprüft das Ablaufdatum bei der Installation der App.

Warum Keystore für Android wichtig ist

App-Updates im Google Play sind nur mit demselben Schlüssel möglich, der die erste Version signiert hat. Wenn der Keystore verloren geht, ist es unmöglich, ein Update zu veröffentlichen — die App müsste unter einem neuen Paketnamen neu veröffentlicht werden. Laut Google Play Console Help (2026) kann der App-Signaturschlüssel nur über Google Play App Signing wiederhergestellt werden — ein Dienst, der den Schlüssel auf Google-Seite speichert. Wenn der Entwickler diese Option genutzt hat, ist der Verlust des lokalen Keystores nicht kritisch.

Wie ein Keystore funktioniert

Der Prozess der Signierung einer Android-App umfasst die Erstellung eines Digests (Hash) des APK-Inhalts und dessen Verschlüsselung mit dem privaten Schlüssel aus dem Keystore. Android SDK Build Tools enthalten das Dienstprogramm apksigner, das die Signierung mit APK Signature Scheme v2 (oder v3 für Android 9+) durchführt. Bei der Installation der App überprüft Android die Signatur: Es entschlüsselt die Signatur mit dem öffentlichen Schlüssel des Zertifikats, vergleicht den APK-Hash mit dem Original — stimmen die Hashes nicht überein, wird die Installation abgelehnt.

Android unterstützt mehrere Signaturschemata: v1 (JAR-Signierung), v2 (APK Signature Scheme), v3 (APK Signature Scheme mit Schlüsselrotationsunterstützung) und v4 (inkrementelle Installationen für Android 11+). Google Play verlangt v2 oder v3 für neue Apps. apksigner fügt beim Signieren automatisch alle erforderlichen Schemata hinzu, wenn der Schlüssel die entsprechenden Algorithmen unterstützt. Android 11+ unterstützt ADB-Installation mit v4-Signatur, was das inkrementelle Laden großer APKs auf das Gerät beschleunigt.

Algorithmen: Android empfiehlt die Verwendung von RSA-2048 oder ECDSA P-256 für den Signaturschlüssel. Das Zertifikat muss X.509 v3 sein. Android überprüft, ob das Zertifikat zum Zeitpunkt der Installation gültig ist — ist es abgelaufen, wird die Installation blockiert. Deshalb empfiehlt Google, die Gültigkeitsdauer des Zertifikats auf mindestens 25 Jahre festzulegen. Google Play App Signing verwendet zwei Schlüssel: den App-Signaturschlüssel (app signing key) und den Upload-Schlüssel (upload key) — der Entwickler verwendet den Upload-Schlüssel, um die APK in die Console hochzuladen, und Google signiert die App für die Benutzer mit dem Hauptschlüssel.

Keystore-Formate: JKS und PKCS12

Java unterstützt zwei Haupt-Keystore-Formate: JKS (Java KeyStore) — ein proprietäres Format von Oracle, das seit JDK 1.2 existiert, und PKCS12 — das standardisierte Public-Key Cryptography Standards #12-Format von RSA Laboratories. JKS verwendet ein eigenes Datenspeicherformat und wird nur innerhalb des Java-Ökosystems unterstützt. PKCS12 ist ein offener Standard, der von Java, .NET, OpenSSL, Python (cryptography) und den meisten anderen kryptografischen Bibliotheken unterstützt wird.

Google Play empfiehlt PKCS12 als bevorzugtes Format für neue Keystores, die nach 2021 erstellt wurden. JDK 9 und höher erstellen Keystores standardmäßig im PKCS12-Format (zuvor war JKS die Voreinstellung). Der Hauptvorteil von PKCS12 ist die Kompatibilität: Eine .p12-Datei kann in jeder Umgebung geöffnet werden, die nicht an Java gebunden ist. OpenSSL kann Zertifikate aus PKCS12 extrahieren und in das PEM-Format konvertieren. JKS-Dateien erfordern JDK-Dienstprogramme zum Lesen und können von OpenSSL nicht verarbeitet werden.

Die Konvertierung zwischen Formaten erfolgt mit dem keytool-Dienstprogramm aus dem JDK. Bei der Migration von JKS zu PKCS12 muss sichergestellt werden, dass alle Aliase und Passwörter korrekt übertragen werden. Der Befehl keytool -importkeystore ermöglicht das Importieren des Inhalts eines Keystores in einen anderen, unabhängig vom Format. Nach der Konvertierung sollte die alte JKS-Datei gelöscht werden, um Verwechslungen mit Schlüsselversionen zu vermeiden. Android Studio unterstützt beide Formate beim Generieren eines signierten Builds.

Keystore mit keytool erstellen

Das Dienstprogramm keytool ist Teil des JDK (Java Development Kit) und bietet einen vollständigen Satz von Befehlen zum Erstellen, Anzeigen und Verwalten von Keystores. Zum Erstellen eines neuen Keystores mit einem Schlüsselpaar wird der Befehl keytool -genkeypair verwendet, wobei das PKCS12-Format, der RSA-Algorithmus, die Schlüsselgröße und die Gültigkeitsdauer des Zertifikats angegeben werden. Google Play verlangt eine Zertifikatsgültigkeit von mindestens 25 Jahren (9125 Tage) — es wird empfohlen, diesen Wert im Parameter -validity anzugeben.

Einen neuen Keystore erstellen

Beispiel für die Generierung eines Keystores im PKCS12-Format für ein Android-Projekt. Der Parameter -dname enthält den X.500 Distinguished Name des Zertifikats. Der Parameter -ext fügt bei Bedarf den Subject Alternative Name hinzu — für Android sind Basic Constraints ausreichend:

# Erstellen eines PKCS12-Keystores für 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 fordert zur Eingabe des Keystore-Passworts und des Schlüsselpassworts auf (sie können übereinstimmen). Der Parameter -storetype PKCS12 erstellt eine Datei im modernen Format. -keysize 2048 erfüllt die Anforderungen von Google an die minimale RSA-Schlüsselgröße. -validity 9125 (25 Jahre) gewährleistet Kompatibilität über den gesamten erwarteten Lebenszyklus der Anwendung. Nach der Erstellung des Keystores wird empfohlen, dessen Inhalt mit dem Befehl keytool -list -v -keystore release-keystore.p12 zu überprüfen.

Keystore-Inhalt anzeigen

Zur Überprüfung der Keystore-Einträge wird der Befehl mit der Option -list verwendet. Die Ausgabe enthält den Alias, Erstellungs- und Ablaufdaten, den Eintragstyp und SHA-256-Fingerabdrücke. Android Studio zeigt dieselben Informationen im Dialogfeld Generate Signed Bundle / APK an, wenn ein vorhandener Keystore ausgewählt wird:

# Anzeigen von Keystore-Einträgen
keytool -list -v -keystore "release-keystore.p12" \
  -storetype PKCS12

Keystore in CI/CD verwenden

In einer CI/CD-Pipeline muss der Keystore sicher aufbewahrt und ohne Kompromittierungsrisiko an den Build-Agenten übergeben werden. GitHub Actions bietet Secrets zum Speichern von Binärdateien im base64-Format. Der Keystore wird mit dem base64-Befehl codiert, die resultierende Zeichenfolge wird in den Repository-Secrets gespeichert und während der Build-Phase wieder in eine Datei decodiert. GitLab CI verwendet einen ähnlichen Mechanismus über Variables vom Typ File.

Ein Beispiel für die Einrichtung eines CI-Builds mit Keystore in GitHub Actions umfasst das Decodieren des Keystores aus einem Secret, das Konfigurieren von Gradle-Eigenschaften und das Ausführen eines signierten Builds. Gradle, das Android-Plugin, liest den Keystore-Pfad und die Passwörter aus der Datei keystore.properties (für die lokale Entwicklung aus .gitignore ausgeschlossen) oder aus Umgebungsvariablen des CI-Systems:

// build.gradle (app) — Signierkonfiguration
@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 liest die vom CI-System festgelegten Umgebungsvariablen. Die Keystore-Datei sollte sich im Stammverzeichnis des Anwendungsmoduls befinden, wie in storeFile angegeben. Aus Sicherheitsgründen sollten Sie Passwörter niemals im Repository speichern — verwenden Sie die Secrets des CI-Systems. Fastlane für Android bietet das Plugin supply, das mit der Google Play Console arbeitet, aber die APK-Signatur erfordert weiterhin einen lokalen Keystore auf dem Agenten.

Eine Alternative ist Google Play App Signing. Bei Verwendung dieser Option lädt der Entwickler nur den Upload-Schlüssel (upload key) zu Google Play hoch, und Google signiert die endgültige APK mit seinem eigenen Schlüssel. In diesem Fall wird der Keystore nur zum Erstellen des Upload-Schlüssels verwendet, und sein Verlust blockiert keine Updates — ein neuer Upload-Schlüssel kann generiert und in der Console registriert werden. Google Play App Signing ist seit August 2021 für neue Anwendungen verpflichtend.

Keystore-Sicherheit und Backup

Der Verlust eines Keystores ist eines der kritischsten Probleme in der Android-Entwicklung. Ohne ein Backup ist es unmöglich, ein Update für eine bestehende Anwendung zu veröffentlichen — Google Play lehnt APKs ab, die mit einem anderen Schlüssel signiert wurden. Es wird empfohlen, mindestens zwei Sicherungskopien des Keystores an verschiedenen physischen oder Cloud-Speicherorten aufzubewahren: zum Beispiel eine verschlüsselte Datei im Cloud-Speicher des Teams und ein physisches Medium im Tresor der Organisation. Keystore- und Schlüsselpasswörter werden getrennt von der Datei aufbewahrt, zum Beispiel in einem Passwortmanager mit Zugriffskontrolle.

Android Studio bietet beim Erstellen eines neuen Keystores im Dialogfeld Generate Signed Bundle / APK an, die Pfade für zukünftige Builds zu merken. Die Entwicklungsumgebung selbst erstellt jedoch kein Backup — dies liegt in der Verantwortung des Entwicklers. Für die Teamentwicklung wird empfohlen, Google Play App Signing zu verwenden, wobei der Upload-Schlüssel über einen sicheren Kanal an alle Teammitglieder weitergegeben wird. Gradle kann Debug-Builds automatisch mit einem generierten debug.keystore signieren, das kein Backup erfordert — es ist bei allen Android Studio-Installationen gleich.

Keystore-Sicherheit bei der Übertragung: .p12- oder .jks-Dateien dürfen nur über verschlüsselte Kanäle (SFTP, HTTPS, verschlüsselte E-Mail-Anhänge) übertragen werden. Binden Sie den Keystore niemals in das Quellcode-Repository ein — auch nicht in ein privates. GitGuardian oder GitHub secret scanning erkennen die Veröffentlichung von Anmeldeinformationen automatisch, aber die Speicherung des Keystores in einem Repository stellt dennoch eine Sicherheitsverletzung dar. Verwenden Sie für CI/CD den Secret-Mechanismus der Plattform (GitHub Actions Secrets, GitLab CI Variables, Jenkins Credentials) mit Verschlüsselung auf Infrastrukturebene.