Keystore: суть, какие бывают форматы и как работает

Что такое Keystore

Keystore (KeyStore) — это стандартный механизм Java Cryptography Architecture (JCA) для хранения криптографических ключей, сертификатов и доверенных записей. В Android-разработке Keystore используется для хранения закрытого ключа, которым подписывается приложение перед публикацией. Подпись гарантирует, что приложение действительно выпущено указанным разработчиком, и его код не был изменён после публикации. Каждое обновление приложения должно быть подписано тем же ключом, иначе Google Play отклонит APK или App Bundle.

Keystore может содержать несколько записей (aliases), каждая из которых представляет собой пару ключей (закрытый и открытый) с сертификатом. 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 на устройство.

Algorithms: 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) автоматически сгенерированным debug.keystore, который не требует резервирования — он одинаков для всех установок Android Studio.

Безопасность Keystore при передаче: файл .p12 или .jks должен передаваться только через зашифрованные каналы (SFTP, HTTPS, зашифрованные email-вложения). Никогда не включайте Keystore в репозиторий исходного кода — даже в приватный. GitGuardian или GitHub secret scanning автоматически детектят публикацию учётных данных, но хранение Keystore в репозитории всё равно является нарушением безопасности. Для CI/CD используйте механизм секретов платформы (GitHub Actions Secrets, GitLab CI Variables, Jenkins Credentials) с шифрованием на уровне инфраструктуры.