Данная копия приложения не поддерживает криптографическое средство

Обновлено: 23.01.2025

В этом пошаговом руководстве показано, как зашифровать и расшифровать содержимое. Пример кода предназначен для приложения Windows Forms. Это приложение не демонстрирует реальные сценарии, такие как использование смарт-карт. Вместо этого оно демонстрирует основные принципы шифрования и расшифровки.

В этом пошаговом руководстве использует следующие правила шифрования:

Используйте класс Aes с симметричным алгоритмом для шифрования и расшифровки данных при помощи автоматически созданных Key и IV.

Используйте RSA асимметричный алгоритм для шифрования и расшифровки ключа с данными, зашифрованными Aes . Асимметричные алгоритмы лучше подходят для небольших объемов данных, таких как ключ.

Если вы хотите защитить данные на компьютере вместо обмена зашифрованным содержимым с другими людьми, рассмотрите возможность использования ProtectedData класса.

В следующей таблице указаны задачи шифрования из этого раздела.

Задача	Описание
Создание приложения Windows Forms	Выводит список элементов управления, необходимых для запуска приложения.
Объявление глобальных объектов	Объявляет, что строковые переменные пути CspParameters и RSACryptoServiceProvider имеют глобальный контекст класса Form.
Создание асимметричного ключа	Создает пару значений открытого и закрытого асимметричного ключа и присваивает ей имя контейнера ключей.
Шифрование файла	Отображает диалоговое окно, где можно выбрать шифруемый файл, и шифрует этот файл.
Расшифровка файла	Отображает диалоговое окно, где можно выбрать зашифрованный файл, и выполняет расшифровку этого файла.
Получение закрытого ключа	Возвращает полную пару ключей при помощи имени контейнера ключей.
Экспорт открытого ключа	Сохраняет ключ в XML-файл только с открытыми параметрами.
Импорт открытого ключа	Загружает ключ из XML-файла в контейнер ключей.
Тестирование приложения	Список процедур для тестирования этого приложения.

Предварительные требования

Для выполнения этого пошагового руководства требуются следующие компоненты:

Создание приложения Windows Forms

Большинство примеров кода в этом пошаговом руководстве предназначено для использования в качестве обработчиков событий для элементов управления кнопок. В следующей таблице перечислены элементы управления, необходимые для образца приложения, и их имена в соответствии с примерами кода.

Элемент	Имя	Текстовое свойство (при необходимости)
Button	buttonEncryptFile	Шифрование файла
Button	buttonDecryptFile	Расшифровка файла
Button	buttonCreateAsmKeys	Создание ключей
Button	buttonExportPublicKey	Экспорт открытого ключа
Button	buttonImportPublicKey	Импорт открытого ключа
Button	buttonGetPrivateKey	Получение закрытого ключа
Label	label1	Ключ не задан
OpenFileDialog	openFileDialog1
OpenFileDialog	openFileDialog2

дважды щелкните кнопки в конструкторе Visual Studio, чтобы создать свои обработчики событий.

Объявление глобальных объектов

Добавьте следующий код как часть объявления класса Form1. Измените строковые переменные для среды и параметров.

Создание асимметричного ключа

Эта задача создает асимметричный ключ, который шифрует и расшифровывает ключ Aes. Этот ключ был использован для шифрования содержимого, и отображает имя контейнера ключей в элементе управления метки.

Добавьте следующий код в качестве обработчика событий Click для кнопки Create Keys ( buttonCreateAsmKeys_Click ).

Шифрование файла

Эта задача включает два метода: метод обработчика событий для Encrypt File кнопки ( buttonEncryptFile_Click ) и EncryptFile метод. Первый метод отображает диалоговое окно для выбора файла и передает имя этого файла во второй метод, который выполняет шифрование.

Зашифрованное содержимое, ключ и вектор инициализации сохраняются в один FileStream, который называется пакетом шифрования.

Метод EncryptFile выполняет следующие действия:

Создает симметричный алгоритм Aes для шифрования содержимого.

Создает объект RSACryptoServiceProvider для шифрования ключа Aes.

Использует объект CryptoStream для чтения и шифрования исходного файла FileStream блоками байтов в конечный объект FileStream для зашифрованного файла.

Определяет длину зашифрованного ключа и вектора инициализации и создает массивы байтов со значениями их длин.

Записывает ключ, вектор инициализации и значения их длин в зашифрованный пакет.

Пакет шифрования использует следующий формат:

Длина ключа, байты 0–3

Длина вектора инициализации, байты 4–7

Вы можете использовать значения длины ключа и вектора инициализации для определения начальных точек и длин всех частей пакета шифрования, которые затем можно использовать для расшифровки файла.

Добавьте следующий код в качестве обработчика событий Click для кнопки Encrypt File ( buttonEncryptFile_Click ).

Добавьте следующий метод EncryptFile к форме:

Расшифровка файла

Эта задача включает в себя два метода: метод обработчика событий для кнопки Decrypt File ( buttonDecryptFile_Click ) и метод DecryptFile . Первый метод отображает диалоговое окно для выбора файла и передает имя этого файла во второй метод, который выполняет расшифровку.

Метод Decrypt выполняет следующие действия:

Создает Aes симметричный алгоритм для расшифровки содержимого.

Считывает первые восемь байтов FileStream зашифрованного пакета в массивы байтов, чтобы получить значения длин зашифрованного ключа и вектора инициализации.

Извлекает ключ и вектор инициализации из пакета шифрования в массивы байтов.

Создает объект RSACryptoServiceProvider для расшифровки ключа Aes.

Использует объект CryptoStream для чтения и расшифровки зашифрованного текста пакета шифрования FileStream блоками байтов в объект FileStream для расшифрованного файла. После завершения этой операции расшифровка завершается.

Добавьте следующий код в качестве обработчика событий Click для кнопки Decrypt File .

Добавьте следующий метод DecryptFile к форме:

Экспорт открытого ключа

Эта задача сохраняет ключ, созданный при помощи кнопки Create Keys , в файл. Она экспортирует только открытые параметры.

Данная задача имитирует ситуацию, в которой Ольга предоставляет Дмитрию свой открытый ключ, чтобы он мог зашифровывать для нее файлы. Дмитрий и другие лица, имеющие этот открытый ключ, не смогут расшифровать данные, поскольку они не имеют полной пары ключей с закрытыми параметрами.

Добавьте следующий код в качестве обработчика событий Click для кнопки Export Public Key ( buttonExportPublicKey_Click ).

Импорт открытого ключа

Эта задача загружает ключ исключительно с открытыми параметрами, в том виде, в котором он был создан при помощи кнопки Export Public Key , и задает его в качестве имени контейнера ключей.

Данная задача имитирует ситуацию, в которой Дмитрий загружает ключ Ольги исключительно с открытыми параметрами, чтобы зашифровывать для нее файлы.

Добавьте следующий код в качестве обработчика событий Click для кнопки Import Public Key ( buttonImportPublicKey_Click ).

Получение закрытого ключа

Эта задача устанавливает в качестве имени контейнера ключей имя ключа, созданного при помощи кнопки Create Keys . Контейнер ключей будет содержать полную пару ключей с закрытыми параметрами.

Данная задача имитирует ситуацию, в которой Ольга использует свой закрытый ключ для расшифровки файлов, зашифрованных Дмитрием.

Добавьте следующий код в качестве обработчика событий Click для кнопки Get Private Key ( buttonGetPrivateKey_Click ).

Тестирование приложения

После сборки приложения необходимо выполнить следующие сценарии тестирования.

Создание ключей, шифрование и расшифровка

Изучите только что расшифрованный файл.

Закройте приложение и перезапустите его, чтобы протестировать извлечение сохраненных контейнеров ключей в следующем сценарии.

Шифрование при помощи открытого ключа

Этот сценарий показывает, как шифровать файлы для другого лица при наличии только открытого ключа. Обычно это лицо предоставляет вам только открытый ключ и утаивает закрытый ключ для расшифровки.

Расшифровка при помощи закрытого ключа

Производители средств криптографической защиты информации (СКЗИ) предлагают различные механизмы для интеграции криптосредств в информационные системы. Существуют решения, ориентированные на поддержку систем с Web-интерфейсом, мобильных и десктопных приложений, серверных компонентов. СКЗИ интегрируются в приложения Microsoft и в продукты Open Source, обеспечивают поддержку различных прикладных протоколов и форматов электронной подписи.

С учетом растущего количества проектов с применением ЭЦП и появления массовых проектов для физических лиц, разработчикам подобных проектов требуется хорошо ориентироваться в предлагаемых производителями решениях по ЭЦП для того, чтобы сделать систему удобной в эксплуатации и недорогой в плане техподдержки. Таким образом, если еще лет 5 назад главным фактором выбора криптосредства являлось его полное соответствие требованиям регуляторов, то при сегодняшнем разнообразии важными критериями могут выступать охват поддерживаемых платформ, возможность интеграции с браузером, поддержка мобильных пользователей, возможность установки без прав системного администратора и т.п.

Рассмотрены в основном СКЗИ, использующиеся на клиентских местах для защиты клиент-серверных соединений по протоколу TLS, для организации ЭЦП, шифрования передаваемых данных;
Не рассматриваются СКЗИ, применяемые для создания VPN и шифрования файловой системы, хранимых данных, а так же УЦ;
Отдельно выделены аппаратные криптографические устройства.

технологий интеграции (CryptoAPI, Active-X, NPAPI и др.), которые поддерживают СКЗИ для встраивания в приложения и прикладные системы;
интерфейсов, которые предоставляют СКЗИ для встраивания в приложения и прикладные системы.

Криптопровайдеры

Следует отметить, что несовершенство предлагаемых MS Windows механизмов расширения вынуждает разработчиков криптопровайдеров дополнительно модифицировать высокоуровневые криптобиблиотеки и приложения MS Windows в процессе их выполнения для того, чтобы «научить» их использовать российские криптоалгоритмы.

Следует понимать, что не все СКЗИ одного вида реализуют полный объем функциональности, приведенный в таблицах. Для уточнения возможностей криптосредств следуют обратиться к производителю.

Отсутствие нормальной кроссплатформенности;
Установка с правами администратора, настройка;
Установка обновления Windows может потребовать обновления провайдера;
Необходимость встраивания в приложения посредством модификации кода «на лету»;
CSP — неродной интерфейс для не-Windows-приложений.

Широкий охват Windows-приложений;
Богатый инструментарий для разработчиков защищенных систем;
Апробированная на большом количестве проектов технология.

Нативные библиотеки

OpenSSL-style

Open Source библиотека OpenSSL обладает широкими криптографическими возможностями и удобным механизмом ее расширения другими криптоалгоритмами. OpenSSL является основным криптоядром для широкого спектра приложений Open Source.

После того, как в эту библиотеку компанией Криптоком были добавлены ГОСТы, появились патчи для «гостификации» многих популярных приложения, использующих OpenSSL. На базе OpenSSL некоторые вендоры разработали и сертифицировали СКЗИ, кроме того в ряд продуктов OpenSSL входит «неявным» образом.

OpenSSL и его аналоги не поддерживается приложениями Microsoft;
Необходимость патчить СПО, которое поддерживает OpenSSL, для включения ГОСТов.

Кроссплатформенность;
Использование в огромном количестве проектов, открытые исходники большей части проекта — выявление и устранение уязвимостей (как пример, недавнее выявление heartbleed);
Распространяется копированием — можно делать приложения, не требующие инсталляции;
Широкий охват приложений СПО, на базе которых можно делать защищенные сертифицированные продукты;
Широкая интеграция в фреймворки, но при этом проблемы с ГОСТами.

Функции доступа к устройству;
Функции записи/чтения произвольных данных;
Функции работы с ключами (поиск, создание, удаление, импорт, экспорт);
Функции работы с сертификатами (поиск, импорт, экспорт);
Функции ЭЦП;
Функции хэширования;
Функции шифрования;
Функции вычисления имитовставки;
Функции выработки ключа согласования (Диффи-Хeллман);
Функции экспорта/импорта сессионного ключа;

Для обеспечения быстродействия часть криптопримитивов может быть реализована программно.

Пример совместимости приложений приведен на схеме. Таким образом, возможно использование подходящего приложения в соответствующем месте инфосистемы.

NSS представляет собой криптографическую библиотеку от сообщества Mozilla. NSS используется такими приложениями, как браузер Mozilla Firefox, почтовым клиентом Mozilla Thunderbird.

В данный момент существуют два проекта по «гостификации» NSS:

Библиотеки c собственным интерфейсом

Локальные прокси

Основным принципом действия локального прокси является прием незащищенного соединения от приложения, установка TLS-туннеля с удаленным сервером и передача «прикладного уровня» между приложением и удаленным сервером по этому туннелю.

прокси должен быть запущен;
приложение должно работать через прокси, нужно «научить» его этому;
могут использоваться нестандартные порты, отсюда проблемы в файрволом
если приложение «ходит» через localhost, то, например, в адресной строке браузера прописано localhost… — нестандартно
дополнительные ограничения на разработку web-сайта — в ряде случаев использование только относительных ссылок, чтобы не «вылететь» из туннеля
прокси сконфигурирован на проксирование конечной группы сайтов, расширение группы — это обновление клиентского конфига
работа через внешний прокси требует дополнительного конфигурирования локального прокси, при этом могут быть проблемы с аутентификацией пользователя на внешнем прокси

решение использует универсальную технологию, поэтому можно не бояться его устаревания;
решение может применяться на большом числе платформ, в том числе на мобильных платформах;
кроссбраузерность, поддержка всех WEB-серверов без модификации;
не требует инсталляции;
поддержка различных прикладных протоколов.

Браузерные плагины

Кроссбраузерные плагины

ActiveX

При использовании КриптоПро ЭЦП Browser plug-in могут возникать ошибки, приводящие к тому, что плагин не работает или работает некорректно, из-за чего электронная подпись не создаётся. Рассмотрим наиболее распространённые варианты ошибок и разберёмся, как их устранить.

При проверке отображается статус «Плагин загружен», но нет информации о криптопровайдере

Не удаётся построить цепочку сертификатов для доверенного корневого центра. (0x800B010A)

При этой ошибке плагин не может сформировать запрос на создание ЭЦП. Она возникает, если по каким-то причинам нет возможности проверить статус сертификата. Например, если нет привязки к ключу или доступа к спискам отзыва. Также проблема может воспроизводиться, если не установлены корневые сертификаты.

Для устранения этой ошибки нужно привязать сертификат к закрытому ключу.

Сначала проверьте, строится ли цепочка доверия. Для этого нужно открыть файл сертификата, а затем вкладку Путь сертификации.

Если на значке сертификата отображается крест, это означает, что цепочка доверия не строится. В этом случае необходимо скачать и установить корневые и промежуточные сертификаты. Они должны быть доступны для загрузки на сайте удостоверяющего центра, который выпустил сертификат на ваше имя.

Для установки корневого сертификата необходимо:

Кликнуть правой кнопкой мыши по файлу.
В контекстном меню выбрать пункт Установить сертификат.
После запуска Мастера установки нажать Далее.
Выбрать вариант Поместить все сертификаты в выбранной хранилище и нажать Обзор.
Выбрать в списке хранилищ Доверенные корневые центры сертификации, нажать ОК, затем Далее.
Нажать Готово.

Установка промежуточных сертификатов выполняется точно так же, как и установка корневых, за исключением того, что в процессе установки вместо пункта Доверенные корневые центры сертификации нужно выбрать пункт Промежуточные центры сертификации.

Если вы создаёте ЭЦП таких форматов, как CAdES-T или CAdES-X Long Type 1, ошибка может возникать из-за отсутствия доверия к сертификату оператора службы предоставления штампов времени. В этой ситуации нужно установить корневой сертификат УЦ в доверенные корневые центры.

ЭЦП создаётся с ошибкой при проверке цепочки сертификатов

Данная проблема возникает из-за отсутствия доступа к спискам отозванных сертификатов. Списки должны быть доступны для загрузки на сайте удостоверяющего центра, который выпустил сертификат ЭЦП. Установка списков выполняется по той же схеме, что и установка промежуточного сертификата.

Ошибка несоответствия версии плагина

Данная проблема может возникнуть, если ваш браузер не поддерживает установленную версию плагина. Попробуйте воспользоваться другим обозревателем.

Ошибки 0x8007064A и 0x8007065B

Ошибка возникает в связи с окончанием срока действия лицензий на КриптоПро CSP (КриптоПро TSP Client 2.0, Криптопро OCSP Client 2.0).

Чтобы создать электронную подпись с форматом CAdES-BES, необходима действующая лицензия на КриптоПро CSP. Создание ЭЦП с форматом CAdES-X Long Type 1 потребует наличия действующих лицензий:

КриптоПро CSP;
КриптоПро OCSP Client 2.0;
КриптоПро TSP Client 2.0.

После приобретения лицензии потребуется её активация.

Набор ключей не существует (0x80090016)

Возникает из-за того, что у браузера нет прав для выполнения операции. Для решения проблемы в настройках плагина добавьте сайт в Список доверенных узлов.

Отказано в доступе (0x80090010)

Возникает в связи с истечением срока действия закрытого ключа. Чтобы проверить срок действия, запустите Крипто-Про CSP, затем откройте вкладку Сервис. Далее необходимо выбрать пункт Протестировать и указать контейнер с закрытым ключом. Если в результатах тестирования вы увидите, что срок действия закрытого ключа истёк, необходимо получить новый ключ.

Ошибка: Invalid algorithm specified. (0x80090008)

Появление такой ошибки означает, что криптопровайдер не поддерживает алгоритм используемого сертификата. Рекомендуется проверить актуальность версии КриптоПро CSP.

Если предлагаемые выше способы устранения ошибок не помогут, рекомендуем обратиться в службу поддержки КриптоПро.

У вас ещё нет электронной подписи? Её можно заказать у нас на сайте. Выберите подходящий вариант ЭЦП: для участия в электронных торгах, работы с порталами или отчётности. Процедура оформления не займёт больше одного дня.

Исторически сложилось так, что разработчики отвечали за создание своих собственных закрытых ключей и сохраняли их в безопасности на протяжении всего срока службы приложения. И хотя такой подход предлагал большую гибкость, он также приводил к ошибкам: генерация слабых ключей, случайная проверка вашего закрытого ключа в публичном репозитории или даже полная его потеря — это всего лишь несколько распространенных ошибок, которые регулярно происходят даже с опытными разработчиками.

В настоящее время у разработчиков есть привлекательная альтернатива для управления ключами самостоятельно: подписание приложения на Google Play, где ключ загрузки (тот, который вы используете, чтобы загрузить свои артефакты в Google Play) и ключ для подписи приложения (который используется для подписи APK-файлов, распространяющихся на устройства) могут быть разными, и второй ключ хранится на Google инфраструктуре.

Несмотря на то, что многие другие популярные платформы используют такой способ распределения ключей, для многих разработчиков это отход от предыдущей модели подписи Android, и некоторые из них могут подумать, что они теряют контроль над своими приложениями.

Вот почему я хочу развеять некоторые распространенные заблуждения относительно подписи приложений в Google Play, а также дать рекомендации по конкретным сценариям, с которыми вы можете столкнуться.

Этот совет основан на вопросах, которые наша команда по связям с разработчиками слышала на конференциях, в онлайн-форумах и наших чатах 1:1.

Давайте начнем с самой убедительной причины для перехода на подписание приложений с помощью Google Play:

1. Я потерял ключ, используемый для подписи артефактов релиза, которые я загружаю в Google Play. Какие у меня есть варианты?

Без подписи приложения в Google Play: благодаря защите безопасности, встроенной в Android, без ключа вы или Google ничего не можете сделать для продолжения обновления вашего приложения. Ваш единственный вариант — это создать новый список с новым именем пакета и начать с нуля.

С подписью приложения в Google Play: вы можете запросить новый ключ загрузки. Play сможет продолжать подписывать обновления вашего приложения с помощью ключа подписи приложения, который надежно хранится в Google.

2. Почему Google хочет, чтобы разработчики переключились на подписание приложений с помощью Google Play?

Первым приоритетом Google Play является создание безопасной и надежной платформы для миллиардов пользователей и миллионов разработчиков.

От этого зависит устойчивость и успех экосистемы. Большинство разработчиков не могут обеспечить тот уровень безопасности, который может предложить Google.

Новая модель приложения, где Play поглощает артефакты публикации и генерирует подписанные, предназначена для минимизации шанса того, что ключи подписи будут раскрыты. Она не только безопасна, но и более эффективна, а также ориентирована на будущее с выгодой как для конечных пользователей, так и для разработчиков.

Например, ряд приложений, находящихся в настоящее время в Play Store, до сих пор не приняли более безопасную схему подписи v2. После регистрации в приложении подписи от Google Play приложения автоматически получают преимущества новых механизмов защиты и будущих улучшений, без необходимости работы разработчика.

И наконец, разделение формата публикации (с использованием пакетов приложений для Android) и формата обслуживания (разделенные APK) открывает преимущества как для разработчиков, так и для пользователей: от повышения безопасности до оптимизации, снижения сложности и фрагментации. Однако для этого Play должен иметь возможность подписывать обслуживающие артефакты.

Некоторые примеры функций, доступных прямо сейчас, — это автоматическая оптимизация размера для доставки приложений, а также новые настраиваемые параметры доставки модулей в вашем приложении.

Что еще более важно, такой подход дает нам возможность развивать и совершенствовать механизмы доставки в будущем, обеспечивая при этом доверие и безопасность распределяемых артефактов.

Несмотря на то, что мы продолжаем совершенствовать наш стек обслуживания, мы не изменяем и не распространяем код вашего приложения без вашего ведома и одобрения, и новые оптимизации, которые выполняет Play, доступны для вашего контроля в bundletool с открытым исходным кодом. Далее в этом часто FAQ мы обсудим некоторые метаданные (те, которые не влияют на работу вашего приложения), которые вы можете увидеть между артефактами, загруженными из Play и созданными локально.

3. Мой ключ подписи приложения был сгенерирован много лет назад, и я боюсь, что его криптографическая сила больше не соответствует сегодняшним стандартам, или мне кажется, что произошла утечка моего ключа подписи приложения. Что я могу сделать для обновления?

Без подписи приложения в Google Play: как уже упоминалось ранее, вы не можете просто переключиться на новый ключ, так как это будет означать, что ваши существующие пользователи не смогут получать обновления приложений. Вы должны либо продолжать использовать существующий ключ и рисковать безопасностью данных ваших пользователей, либо начать новую запись приложения с нуля.

С подписью приложения в Google Play: если вы используете слабый ключ или ваш ключ был скомпрометирован, вы можете обновить его для новых установок.

Это осуществляется путем доставки APK, подписанных вашим устаревшим ключом, существующим пользователям, когда они обновляют приложение, в то время как новые установки приложений получают APK, подписанные обновленным безопасным ключом.

Рассмотрите включение подписи приложения сейчас и как можно скорее переключитесь на использование отдельного ключа загрузки, что снизит вероятность компрометирования ключа подписи приложения.

Текущий процесс обновления до нового ключа не является мгновенным, и если ключ подписи приложения утечет, ваши существующие пользователи будут подвергаться риску до тех пор, пока они не переустановят приложение или не перейдут на новое устройство.

Обратите внимание, что текущий процесс обновления ключа не использует преимущества функции ротации ключа, введенной в Android 9 (Pie) и выше. В настоящее время мы изучаем поддержку ротации ключей с помощью подписи приложения версии 3 для устройств на этих версиях ОС и сообщим об этом сообществу разработчиков, как только оно будет готово, в отдельном объявлении.

4. Ключ загрузки, который я использовал для подписи своих артефактов, был украден. Какие у меня есть варианты?

Без подписи приложения в Google Play: нет никакой концепции отдельного “ключа загрузки”, поэтому, если ваш ключ подписи выпуска утечет, вы можете оказаться в большой беде: кто-то может создать вредоносные или несанкционированные версии вашего приложения, которые будут неразличимы (и обновляемы!) от вашего оригинального APK.

Конечно, защита учетной записи Google применяется к доступу к консоли Google Play (и мы рекомендуем разработчикам включить 2-ступенчатую проверку), поэтому злоумышленнику все равно придется найти способ обмануть пользователя, чтобы он загрузил такой измененный APK. Тем не менее безопасность вашего приложения ослаблена.

Обратитесь к вопросу 3 о скомпрометированном ключе подписи приложения, чтобы узнать, какие исправления доступны, а также как обновить ключ для новых установок.

С подписью приложения в Google Play: если ваш ключ загрузки отделен от ключа подписи приложения (рекомендованный вариант), и просочился только первый, то данные ваших пользователей будут в безопасности — одного ключа загрузки недостаточно, чтобы подменить APK, подписанные ключом подписи приложения. Просто запросите новый ключ загрузки.

5. Я включил функцию подписи приложений в Google Play для своего приложения, но передумал и хотел бы загрузить ключ подписи приложений, хранящийся в инфраструктуре Google.

Вы или кто-либо другой в вашей учетной записи разработчика не может загрузить и сохранить закрытый ключ для вашего приложения, хранящегося в защищенной инфраструктуре Google. Это делается для обеспечения защиты ключа подписи вашего приложения.

Если вы предвидите ситуацию, в которой вам потребуется постоянный доступ к ключу подписи вашего приложения, вам следует сделать следующее при включении подписи приложения:

· Не выбирайте опцию, в которой Google Play создает ключ подписи приложения за вас. Вместо этого создайте свой ключ подписи локально на вашем компьютере.

· Надежно перенесите свой ключ в Google Play и не удаляйте его с вашего компьютера.

· Храните ключ в надежном месте, чтобы он не просочился к третьим лицам.

· Убедитесь, что вы регулярно создаете и тестируете резервные копии своего ключа, так как в случае его потери вы не сможете загрузить его из Google.

Эти шаги описаны в документации. В инструкции о том, как ”выбрать существующее приложение”, показано, как зашифровать свой ключ подписи, чтобы загрузить его на консоль Google Play из Android Studio или командной строки.

Если вы абсолютно уверены, что вам не понадобится постоянный доступ к ключу подписи вашего личного приложения, мы рекомендуем вам либо разрешить Play генерировать ваш ключ (для новых приложений), либо удалить свою копию после передачи ее в Play и переключиться на использование ключа загрузки.

Ключ загрузки может быть сброшен, и это не ставит под угрозу безопасность ваших пользователей в случае утечки информации.

6. Как я могу быть уверен, что мой закрытый ключ не будет перехвачен при передаче его в Google Play?

Если вы включаете подпись приложения для нового приложения и выбираете опцию создания нового ключа в консоли Google Play, ключ никогда не передается и генерируется непосредственно на защищенном сервере Google.

Если вам нужно передать существующий ключ подписи (необязательно для новых приложений и обязательно для существующих приложений), вы всегда делаете это в зашифрованном виде. Независимо от того, экспортируете ли вы ключ из Android Studio или из командной строки, вы будете использовать инструмент шифрования закрытого ключа Play (PEPK) локально на вашем компьютере перед передачей ключа.

В случае, если вам нужно знать детали используемого шифрования, PEPK использует асимметричное шифрование эллиптической кривой P256 с симметричным шифрованием AES. Если вам нужно получить более подробную информацию, вы можете загрузить инструмент PEPK и его исходный код во время процесса регистрации подписи приложения.

Не стесняйтесь просматривать или компилировать его самостоятельно, чтобы он мог быть запущен в вашей собственной безопасной среде, гарантируя, что незашифрованный ключ никогда не будет раскрыт.

Используйте только версии PEPK, загруженные с консоли Google Play, никогда не загружайте его или его источник с непроверенных сторонних веб-сайтов.

7. Как ключ защищен на остальной инфраструктуре Google? Как я могу быть уверен, что никто не имеет к нему доступа?

Когда вы используете подпись приложения в Google Play, ваши ключи хранятся в той же инфраструктуре, где и Google хранит свои собственные.

Доступ к ключам регулируется строгими ACL и аудиторскими следами с защитой от несанкционированного доступа для всех операций.

Все артефакты, созданные и подписанные ключом разработчика, становятся доступными в консоли Google Play для проверки/аттестации.

Кроме того, чтобы предотвратить потерю ключей, мы очень часто делаем резервные копии нашего основного хранилища. Эти резервные копии строго зашифрованы, и мы регулярно тестируем восстановление из этих резервных копий.

Если вы хотите узнать о технической инфраструктуре Google, ознакомьтесь с информационными документами Google Cloud Security.

8. Мне нужен публичный сертификат для регистрации внешних сервисов, но у меня нет доступа к своему ключу. Что я могу сделать?

Если вы хотите использовать сервисы или API, которые требуют регистрации с хэшем публичного сертификата вашего приложения, вы можете просмотреть или загрузить “отпечатки пальцев” публичного сертификата из раздела “App signing“ консоли Google Play:

Не забывайте всегда использовать эти отпечатки пальцев при включении сервисов для выпускных версий вашего приложения, а не для тех, которые получены из вашего ключа загрузки.

Большинство сервисов позволяют включить несколько сертификатов для приложения, поэтому вы можете продолжить тестирование с локально построенными APK, а также APK, генерируемыми Google Play.

9. Отличаются ли артефакты, которые Google Play распространяет среди пользователей моего приложения, от тех, которые я создаю локально, кроме ключа, используемого для их подписи?

Как уже говорилось ранее, Play не будет изменять функциональность вашего приложения без вашего ведома и одобрения. Однако он вставляет небольшое количество метаданных, которые помогают проверить источник и целостность распространения. Эти метаданные бывают двух видов:

• Для всех приложений, загруженных в Google Play, Play добавлял метаданные безопасности после блока подписи, чтобы включить такие функции, как авторизованный обмен приложениями P2P. Мы объявили об этом первоначально в своем блоге в 2017 году.

• Для приложений, загруженных в виде пакетов приложений, мы улучшим безопасность, введя так называемый штамп источника. Эти исходные метаданные вставляются в манифест приложения с помощью bundletool. Когда APK генерируется на сервере Play, он также подписывается с помощью ключа Google в дополнение к вашему ключу подписи приложения.

Это означает, что метаданные безопасности не могут быть удалены или изменены без аннулирования подписи Google. Такой подход дает сигнал высокой уверенности в том, что немодифицированные АПК, содержащие исходный штамп, пришли из Google Play.

Вы можете локально использовать bundletool с открытым исходным кодом для генерации APK из пакетов точно так же, как это делает Play на сервере. Метаданные исходного штампа, добавленные bundletool, не будут подписаны ключом Google. Другие исходные подписи будут возможны, когда ApkSigner будет обновлен со следующим выпуском Android.

10. Как я могу получить доступ к последним артефактам, которые Google Play распространяет среди пользователей моего приложения?

Есть несколько вариантов, доступных для вас:

• В целях тестирования вы можете использовать внутреннюю ссылку на общий доступ к приложению для любой исторической версии вашего приложения из проводника пакетов приложений консоли Google Play. Нажатие на ссылку на устройстве приведет к установке APK, которые Play Store установит в prod для этого устройства.

• Вы также можете загрузить подписанные APK-файлы для конкретных устройств из проводника пакетов приложений консоли Google Play.

11. Как я могу продолжать распространять свое приложение в других магазинах, если я хочу использовать подпись приложения в Google Play?

Приложения можно распространять несколькими способами и по разным каналам. Есть несколько соображений, которые вы должны иметь в виду, в зависимости от того, является ли это приложение новым или существующим.

Для новых приложений вы можете использовать отдельные ключи подписи для каждого канала распространения, а Google будет генерировать ключ, используемый Google Play для вас. Это самый безопасный способ для приложений, распространяемых в Play, так как ключ никогда не покидает серверы Google, что сводит вероятность того, что кто-то перехватит ключ, почти к нулю.

Кроме того, для тех, кто не хочет управлять несколькими ключами, но все еще использует преимущества безопасности подписи приложений в Google Play, мы скоро предоставим возможность загружать подписанные универсальные APK из проводника пакетов приложений и распространять их в других магазинах.

Для существующих приложений: если вы уже используете один ключ для разных магазинов, при желании вы можете продолжать это делать. При включении входа в приложение в Google Play вам будет предложено загрузить существующий ключ.

При необходимости вы можете рассмотреть функцию обновления ключа, упомянутую ранее, чтобы со временем отказаться от совместного использования ключа, используемого Google Play, с другими каналами распространения.

Есть одно предостережение, которое приходит вместе с вышеприведенным советом: пожалуйста, обратите внимание, что если вы решите использовать отдельные ключи подписи для разных магазинов, ваши пользователи не смогут перекрестно обновлять приложение между различными каналами распространения. Например, когда кто-то изначально установил приложение через другой магазин, а затем пытается обновить его через Play. Они должны будут удалить и установить приложение снова.

12. Я занят работой над функционалом, и все это звучит сложно. Нужно ли мне переключаться на пакеты приложений для Android или использовать расширенные функции, такие как динамическая доставка?

Нет, вы не должны делать все сразу.

Вы можете выбрать подписание приложений от Google Play и продолжить публикацию APK. Когда вы будете готовы, вы можете начать публиковать пакеты приложений для Android.

Публикация с помощью пакета приложений проста для систем сборки, которые поддерживают его, и автоматически предоставляет такие преимущества, как уменьшение размера, для большинства приложений.

Со временем вы можете воспользоваться преимуществами расширенных функций, таких как динамическая доставка. Вы также можете модулировать свое приложение с помощью динамических функциональных модулей, чтобы улучшить время сборки и воспользоваться преимуществами настраиваемой доставки. Play может использовать динамическую доставку для предоставления высококачественных активов во время или после установки с настраиваемыми режимами и интеллектуальными опциями таргетинга.

Если вы хотите начать использовать подпись приложений, но ваши менеджеры или команды по безопасности нуждаются в объяснении преимуществ и предостережений касательно подписи приложений, то покажите им эту статью.

Перевод: Лебедев Даниил.

Еще больше полезной и нужной информации вы найдете в нашем Телеграм-канале по ссылке:

Читайте также: