Keystore : ce que c'est, quels formats existent et comment ça fonctionne

Qu'est-ce qu'un Keystore

Keystore (KeyStore) est un mécanisme standard de Java Cryptography Architecture (JCA) pour stocker les clés cryptographiques, les certificats et les entrées de confiance. Dans le développement Android, le Keystore est utilisé pour stocker la clé privée qui signe l'application avant sa publication. La signature garantit que l'application a bien été publiée par le développeur spécifié et que son code n'a pas été modifié après la publication. Chaque mise à jour de l'application doit être signée avec la même clé, sinon Google Play rejettera l'APK ou l'App Bundle.

Un Keystore peut contenir plusieurs entrées (alias), chacune représentant une paire de clés (privée et publique) avec un certificat. Alias est un nom d'entrée unique par lequel l'application accède à la clé lors de la signature. Dans un projet Android typique, le Keystore contient une entrée pour signer la version de publication et peut contenir des entrées supplémentaires pour signer les versions de débogage. Google Play Console affiche les empreintes SHA-1 et SHA-256 du certificat pour chaque application téléchargée.

Android Studio inclut la prise en charge intégrée de Keystore via le menu Build → Generate Signed Bundle / APK. L'assistant de signature d'Android Studio permet de créer un nouveau Keystore ou d'en sélectionner un existant, de spécifier un alias, les mots de passe du Keystore et de la clé, ainsi que les données du certificat (nom de l'organisation, ville, pays). Ces données sont intégrées dans le certificat et sont visibles par les utilisateurs lors de la vérification de la signature APK. Google Play exige que le certificat soit valide pendant au moins 25 ans ; Android vérifie la date d'expiration lors de l'installation de l'application.

Pourquoi Keystore est important pour Android

Les mises à jour d'applications sur Google Play ne sont possibles qu'avec la même clé qui a signé la première version. Si le Keystore est perdu, il est impossible de publier une mise à jour — l'application devrait être republiée sous un nouveau nom de package. Selon Google Play Console Help (2026), la clé de signature de l'application ne peut être récupérée que via Google Play App Signing — un service qui stocke la clé du côté de Google. Si le développeur a utilisé cette option, la perte du Keystore local n'est pas critique.

Comment fonctionne un Keystore

Le processus de signature d'une application Android implique la création d'un digest (hash) du contenu de l'APK et son chiffrement avec la clé privée du Keystore. Android SDK Build Tools incluent l'utilitaire apksigner, qui effectue la signature avec APK Signature Scheme v2 (ou v3 pour Android 9+). Lors de l'installation de l'application, Android vérifie la signature : il déchiffre la signature avec la clé publique du certificat, compare le hash de l'APK avec l'original — si les hashs ne correspondent pas, l'installation est rejetée.

Android prend en charge plusieurs schémas de signature : v1 (signature JAR), v2 (APK Signature Scheme), v3 (APK Signature Scheme avec prise en charge de la rotation des clés) et v4 (installations incrémentielles pour Android 11+). Google Play exige v2 ou v3 pour les nouvelles applications. apksigner ajoute automatiquement tous les schémas nécessaires lors de la signature si la clé prend en charge les algorithmes correspondants. Android 11+ prend en charge l'installation ADB avec la signature v4, ce qui accélère le chargement incrémentiel des gros APK sur l'appareil.

Algorithmes : Android recommande d'utiliser RSA-2048 ou ECDSA P-256 pour la clé de signature. Le certificat doit être X.509 v3. Android vérifie que le certificat est valide au moment de l'installation — s'il a expiré, l'installation est bloquée. C'est pourquoi Google recommande de définir la période de validité du certificat sur au moins 25 ans. Google Play App Signing utilise deux clés : la clé de signature de l'application (app signing key) et la clé de téléchargement (upload key) — le développeur utilise la clé de téléchargement pour envoyer l'APK dans la Console, et Google signe l'application pour les utilisateurs avec la clé principale.

Formats de Keystore : JKS et PKCS12

Java prend en charge deux formats principaux de Keystore : JKS (Java KeyStore), un format propriétaire d'Oracle qui existe depuis JDK 1.2, et PKCS12, le format standardisé Public-Key Cryptography Standards #12 de RSA Laboratories. JKS utilise son propre format de stockage de données et n'est pris en charge que dans l'écosystème Java. PKCS12 est un standard ouvert pris en charge par Java, .NET, OpenSSL, Python (cryptography) et la plupart des autres bibliothèques cryptographiques.

Google Play recommande PKCS12 comme format préféré pour les nouveaux Keystores créés après 2021. JDK 9 et versions ultérieures créent les Keystores au format PKCS12 par défaut (auparavant, le format par défaut était JKS). Le principal avantage de PKCS12 est la compatibilité : un fichier .p12 peut être ouvert dans n'importe quel environnement non lié à Java. OpenSSL peut extraire les certificats de PKCS12 et les convertir au format PEM. Les fichiers JKS nécessitent des utilitaires JDK pour être lus et ne peuvent pas être traités par OpenSSL.

La conversion entre les formats est effectuée avec l'utilitaire keytool du JDK. Lors de la migration de JKS vers PKCS12, assurez-vous que tous les alias et mots de passe sont correctement transférés. La commande keytool -importkeystore permet d'importer le contenu d'un Keystore dans un autre, quel que soit le format. Après la conversion, il est préférable de supprimer l'ancien fichier JKS pour éviter toute confusion avec les versions de clé. Android Studio prend en charge les deux formats lors de la génération d'une compilation signée.

Créer un Keystore avec keytool

L'utilitaire keytool fait partie du JDK (Java Development Kit) et fournit un ensemble complet de commandes pour créer, visualiser et gérer les Keystores. Pour créer un nouveau Keystore avec une paire de clés, on utilise la commande keytool -genkeypair en spécifiant le format PKCS12, l'algorithme RSA, la taille de la clé et la période de validité du certificat. Google Play exige une validité de certificat d'au moins 25 ans (9125 jours) — il est recommandé de spécifier cette valeur dans le paramètre -validity.

Créer un nouveau Keystore

Exemple de génération d'un Keystore au format PKCS12 pour un projet Android. Le paramètre -dname contient le Distinguished Name X.500 du certificat. Le paramètre -ext inclut le Subject Alternative Name si nécessaire — pour Android, Basic Constraints est suffisant :

# Création d'un Keystore PKCS12 pour 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 demandera le mot de passe du Keystore et le mot de passe de la clé (ils peuvent être identiques). Le paramètre -storetype PKCS12 crée un fichier au format moderne. -keysize 2048 répond aux exigences de Google concernant la taille minimale de la clé RSA. -validity 9125 (25 ans) garantit la compatibilité pour toute la durée de vie attendue de l'application. Après avoir créé le Keystore, il est recommandé de vérifier son contenu avec la commande keytool -list -v -keystore release-keystore.p12.

Visualiser le contenu du Keystore

Pour vérifier les entrées du Keystore, on utilise la commande avec l'option -list. La sortie inclut l'alias, les dates de création et d'expiration, le type d'entrée et les empreintes SHA-256. Android Studio affiche les mêmes informations dans la boîte de dialogue Generate Signed Bundle / APK lors de la sélection d'un Keystore existant :

# Affichage des entrées du Keystore
keytool -list -v -keystore "release-keystore.p12" \
  -storetype PKCS12

Utiliser Keystore dans CI/CD

Dans un pipeline CI/CD, le Keystore doit être stocké de manière sécurisée et transmis à l'agent de compilation sans risque de compromission. GitHub Actions fournit des Secrets pour stocker les fichiers binaires au format base64. Le Keystore est encodé avec la commande base64, la chaîne résultante est enregistrée dans les secrets du dépôt, et pendant la phase de compilation, elle est décodée en fichier. GitLab CI utilise un mécanisme similaire via des Variables de type File.

Un exemple de configuration d'une compilation CI avec Keystore dans GitHub Actions inclut le décodage du Keystore depuis un secret, la configuration des propriétés Gradle et l'exécution d'une compilation signée. Gradle, le plugin Android, lit le chemin du Keystore et les mots de passe depuis le fichier keystore.properties (exclu du .gitignore pour le développement local) ou depuis les variables d'environnement du système CI :

// build.gradle (app) — configuration de signature
@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 lit les variables d'environnement définies par le système CI. Le fichier Keystore doit être situé à la racine du module de l'application, comme spécifié dans storeFile. Pour des raisons de sécurité, ne stockez jamais les mots de passe dans le dépôt — utilisez les Secrets du système CI. Fastlane pour Android fournit le plugin supply, qui fonctionne avec Google Play Console, mais la signature APK nécessite toujours un Keystore local sur l'agent.

Une alternative est Google Play App Signing. En utilisant cette option, le développeur télécharge uniquement la clé de téléchargement (upload key) sur Google Play, et Google signe l'APK final avec sa propre clé. Dans ce cas, le Keystore n'est utilisé que pour créer la clé de téléchargement, et sa perte ne bloque pas les mises à jour — une nouvelle clé de téléchargement peut être générée et enregistrée dans la Console. Google Play App Signing est obligatoire pour les nouvelles applications depuis août 2021.

Sécurité et sauvegarde du Keystore

La perte d'un Keystore est l'un des problèmes les plus critiques dans le développement Android. Sans sauvegarde, il est impossible de publier une mise à jour d'une application existante — Google Play rejette les APK signés avec une clé différente. Il est recommandé de conserver au moins deux copies de sauvegarde du Keystore dans des stockages physiques ou cloud différents : par exemple, un fichier chiffré dans le stockage cloud de l'équipe et un support physique dans le coffre de l'organisation. Les mots de passe du Keystore et de la clé sont stockés séparément du fichier, par exemple dans un gestionnaire de mots de passe avec contrôle d'accès.

Android Studio, lors de la création d'un nouveau Keystore dans la boîte de dialogue Generate Signed Bundle / APK, propose de mémoriser les chemins pour les futures compilations. Cependant, l'environnement de développement lui-même ne crée pas de sauvegarde — c'est la responsabilité du développeur. Pour le développement en équipe, il est recommandé d'utiliser Google Play App Signing avec la clé de téléchargement transmise par un canal sécurisé à tous les membres de l'équipe. Gradle peut signer automatiquement les compilations de débogage avec un debug.keystore généré, qui ne nécessite pas de sauvegarde — il est identique pour toutes les installations d'Android Studio.

Sécurité du Keystore lors du transfert : les fichiers .p12 ou .jks doivent être transférés uniquement via des canaux chiffrés (SFTP, HTTPS, pièces jointes chiffrées par email). N'incluez jamais le Keystore dans le dépôt de code source, même privé. GitGuardian ou GitHub secret scanning détectent automatiquement la publication d'informations d'identification, mais stocker le Keystore dans un dépôt reste une violation de sécurité. Pour CI/CD, utilisez le mécanisme de secrets de la plateforme (GitHub Actions Secrets, GitLab CI Variables, Jenkins Credentials) avec un chiffrement au niveau de l'infrastructure.