Каждый раз при создании обновленной версии существующего приложения AIR следует подписывать обновленное приложение. При оптимальном раскладе для подписи обновленной версии используется тот же сертификат, что и для предыдущей версии. В этом случае процесс подписи в точности схож с первоначальной подписью приложения.
Если срок сертификата, использованного для подписи предыдущей версии приложения, истек, и он был заменен или обновлен, для подписи обновленной версии можно использовать обновленный или новый (полученный на замену) сертификат. Для этого следует подписать приложение новым сертификатом и применить подпись переноса к оригинальному сертификату. Подпись переноса подтверждает, что владелец исходного сертификата опубликовал обновление.
Прежде чем применить подпись переноса, обратите внимание на следующие моменты.
Чтобы применить подпись переноса, исходный сертификат должен быть действителен или быть просроченным не более чем на 365 дней. Этот период считается льготным, и его продолжительность может быть изменена в будущем.
Примечание. До выхода AIR 2.6 льготный период составлял 180 дней.
После окончания 365-дневного льготного периода, который отсчитывается с момента истечения действия сертификата, подпись переноса не может быть применена. В этом случае пользователям потребуется перед установкой обновления удалить текущую версию приложения.
365-дневный льготный период применяется только к приложениям, для которых в пространстве имен дескриптора приложения указана версия AIR 1.5.3 или более поздняя версия.
Важная информация. Подписание обновлений с использованием подписи переноса просроченного сертификата является временным решением. Окончательное решение предполагает разработку стандартизированной процедуры подписания для управления развертыванием обновлений приложений. К примеру, каждое обновление подписывается последним имеющимся сертификатом, и применяется сертификат переноса - сертификат, использованный для подписи предыдущего обновления (если таковое было). Каждое обновление размещается на сервере с собственным URL, с помощью которого происходит загрузка приложения пользователями. Дополнительные сведения см. в разделе «Процедура подписания для обновлений приложений ».
Следующая таблица и рисунок иллюстрируют процесс обращения с подписями переноса:
Сценарий |
Состояние оригинального сертификата |
Действие разработчика |
Действие пользователя |
|---|---|---|---|
Приложение на основе среды выполнения Adobe AIR 1.5.3 или более новой версии |
Действительный |
Действия не требуются |
|
Срок истек, но не более 365 дней назад |
Подпишите приложение новым сертификатом. Примените подпись переноса с использованием устаревшего сертификата. |
Действия не требуются Приложение обновляется автоматически |
|
Идентификатор издателя в дескрипторе обновленного приложения совпадает с идентификатором предыдущей версии |
Действительный |
Опубликуйте последнюю версию приложения AIR |
Действия не требуются Приложение обновляется автоматически |
Просрочен, льготный период закончился |
Подпись переноса не может быть применена для обновления приложения AIR. Вместо этого опубликуйте другую версию приложения AIR, используя новый сертификат. Пользователи могут установить новую версию приложения AIR после удаления существующей версии. |
Удалите текущую версию приложения AIR и установите последнюю версию |
|
Приложение на основе среды выполнения Adobe AIR 1.5.2 или более ранней версии Идентификатор издателя в дескрипторе обновленного приложения не совпадает с идентификатором предыдущей версии |
Подпишите приложение AIR действующим сертификатом и опубликуйте его последнюю версию. |
Удалите текущую версию приложения AIR и установите последнюю версию |
Процедура подписания для обновлений
Процедура переноса приложения AIR на новый сертификат при обновлении приложения:
Упакуйте и подпишите файл обновления AIR новым сертификатом
Подпишите файл AIR снова, на этот раз оригинальным сертификатом с помощью команды ADT -migrate
Файл AIR, подписанный с помощью команды -migrate , может также использоваться для установки новой версии приложения - не только для обновления любой прошлой версии, подписанной устаревшим сертификатом.
Примечание. При обновлении приложения, опубликованного для версии AIR, предшествующей 1.5.3, в дескрипторе приложения необходимо указать исходный идентификатор издателя. В противном случае перед установкой обновления пользователям приложения потребуется удалить более раннюю версию.
Используйте команду ADT - migrate со следующим синтаксисом:
Adt -migrate SIGNING_OPTIONS air_file_in air_file_out
SIGNING_OPTIONS . Параметры подписи определяют закрытый ключ и сертификат подписи файла AIR. Эти параметры должны определять оригинальный Параметры подписания кода ADT »).
air_file_in - обновляемый файл AIR, подписанный новым сертификатом.
air_file_out - создаваемый файл AIR.
Примечание. Имена входных и выходных файлов AIR должны отличаться.
Следующий пример иллюстрирует вызов функции ADT с флагом -migrate для применения подписи переноса к обновленной версии приложения AIR:
Adt -migrate -storetype pkcs12 -keystore cert.p12 myAppIn.air myApp.air
Примечание. Команда -migrate была добавлена в ADT в AIR версии 1.1.
Перенос приложения AIR с собственным файлом установки на новый сертификат
Приложение AIR, опубликованное как собственный файл установки для конкретной платформы (например, приложение, использующее собственный API платформы), не может быть подписано командой ADT -migrate , поскольку не является файлом air. Для переноса приложения AIR, опубликованного в качестве собственного расширения платформы, на новый сертификат предусмотрена другая процедура:
Создайте обновление приложения.
Убедитесь, что в файле-дескрипторе приложения (app.xml) тег
Упакуйте и подпишите обновленное приложение как файл air при помощи команды ADT -package с новым сертификатом.
Примените сертификат переноса к файлу.air, используя команду ADT -migrate с оригинальным сертификатом (как описано ранее в разделе «Перенос приложения AIR для использования нового сертификата »).
Упакуйте файл.air в виде собственного установочного файла платформы при помощи команды ADT -package с флагом -target native . Поскольку приложение уже подписано, на этом шаге нет необходимости указывать сертификат подписи.
В следующем примере показаны этапы 3–5 этой процедуры. Код вызывает программу ADT с командой -package , затем - с командой -migrate , затем снова с командой -package для упаковки обновленной версии приложения AIR в виде собственного файла установки данной платформы:
Adt -package -storetype pkcs12 -keystore new_cert.p12 myAppUpdated.air myApp.xml myApp.swf adt -migrate -storetype pkcs12 -keystore original_cert.p12 myAppUpdated.air myAppMigrate.air adt -package -target native myApp.exe myAppMigrate.air
Перенос на новый сертификат приложения AIR, использующего собственное расширение платформы
Приложение AIR, использующее собственное расширение платформы, не может быть подписано при помощи команды ADT -migrate . Его перенос также не может быть выполнен по процедуре переноса приложения AIR с собственным файлом установки, поскольку оно не может быть опубликовано как промежуточный файл.air. Для переноса приложения AIR, использующего собственное расширение платформы, на новый сертификат предусмотрена другая процедура:
Создайте обновление приложения
Упакуйте и подпишите обновленный собственный файл установки при помощи команды ADT -package . Упакуйте приложение с указанием нового сертификата и включите в команду флаг -migrate с указанием оригинального сертификата.
Для вызова команды ADT -package с флагом -migrate используется следующий синтаксис:
Adt -package AIR_SIGNING_OPTIONS -migrate MIGRATION_SIGNING_OPTIONS -target package_type NATIVE_SIGNING_OPTIONS output app_descriptor FILE_OPTIONS
AIR_SIGNING_OPTIONS новый сертификат подписи (их описание приводится в разделе «Параметры подписания кода ADT »).
MIGRATION_SIGNING_OPTIONS . Параметры подписи определяют закрытый ключ и сертификат подписи файла AIR. Эти параметры определяют оригинальный сертификат подписи (их описание приводится в разделе «Параметры подписания кода ADT »).
Прочие параметры те же, что применяются при упаковке приложения AIR с собственным файлом установки; они описаны в разделе «Команда ADT package ».
В следующем примере иллюстрируется вызов программы ADT с командой -package и флагом -migrate для упаковки обновленной версии приложения AIR, использующего собственное расширение платформы, и для применения к нему подписи переноса:
Adt -package -storetype pkcs12 -keystore new_cert.p12 -migrate -storetype pkcs12 -keystore original_cert.p12 -target native myApp.exe myApp.xml myApp.swf
Примечание. Флаг -migrate команды -package доступен в программе ADT в версиях AIR 3.6 и более поздних.
Случается так, что после перепрошивки некоторых моделей телефонов при попытке обновления встроенных в новую прошивку программ через Google Play Маркет аппарат выдает ошибку «Файл пакета подписан неверно
», удалите предыдущую версию и попробуйте снова. После выполнения требуемых операций проблема не решается - приложения не обновляются, зато появляется сообщение о новой ошибке: «Подписи приложений, использующие этот идентификатор, не совпадают». Если у вас имеются права суперпользователя, то вы можете попробовать исправить ситуацию, воспользовавшись следующим способом:
1.
Сначала нужно установить программу Titanium Backup.
2. Затем зайти в нее и вверху по центру нажать на кнопку «Резервные копии » (должен появиться полный список приложений, установленных на устройстве);
3. Для страховки сделать резервную копию программы, которую намерены обновить (выбрать нужное приложение, в открывшемся небольшом меню нажать кнопку «Сохранить »).
4. Вернуться к списку программ, снова найти то самое приложение, которое необходимо обновить, но не просто нажать на него, а нажать и удерживать до тех пор, пока на экране телефона не появится сплывающее окно. В нем выбрать функцию «Преобразовать в пользовательское приложение », после чего выйти из TitaniumBackup.
5. Зайти в Google Play, найти обновляемое приложение и произвести манипуляции, необходимые для его обновления. На экране появится уже знакомое сообщение об ошибке, но теперь с предложением удалить старую версию программы («Файл пакета подписан неверно, удалите предыдущую версию и попробуйте снова »). Придется удалить и старую версию. Всё. На этом приложение полностью удалено с устройства.
6. Вот теперь можно заново установить приложение. Разумеется, с маркета установится последняя версия программы, что и требовалось. Больше проблемы с этой программой уже не возникнут.
При желании можно повторить пункт 4 с той только разницей, что преобразовать пользовательское приложение обратно в системное. Просто выберите соответствующий пункт в меню.
Если принятые меры от ошибки избавиться не помогли, резервное копирование, выполненное в самом начале процесса с помощью Titanium Backup, позволит вернуть старую версию приложения. На этот раз выбрать следует кнопку «Восстановить », а на вопрос, что именно, ответить нажатием варианта «Программу и все данные к ней ». Приложение вы, конечно, не обновили, но и ничего не потеряли, кроме нескольких минут времени, затраченного на попытку.
В некоторых случаях у разработчиков приложений или ОС возникает потребность или, во всяком случае, желание разрешить контролируемую смену идентичности для исполнения одной операции или группы тесно связанных операций над данными. Требование контролируемости означает, что нельзя разрешать пользователю свободное выполнение таких операций: например, в системе документооборота пользователю может быть разрешено поставить под документом подпись, что он с ним ознакомился, но при этом не дано права изменять содержание документа или удалять ранее поставленную подпись. Если предоставляемый системой список прав на документ либо позволяет редактирование документа целиком, либо опять-таки целиком запрещает его редактирование, то мы сталкиваемся с неразрешимой проблемой.
Авторизация доступа к полям документа в Notes
Программный комплекс Lotus Notes, широко признанный как лучшая основа для реализации систем документооборота, позволяет устанавливать права на отдельные поля или группы полей документа, а стандартная техника реализации вышеприведенных требований состоит в том, чтобы сначала предоставить пользователю право записи в поле, где должна быть подпись, а потом - после подписания - это право тут же снять. Впрочем, при реализации сложных циклов документооборота, включающих много взаимосвязанных документов, нередко возникают ситуации, неразрешимые с помощью только этих средств [Керн/Линд 2000].
Можно привести и другой пример, более тесно связанный с темой книги:
для изменения информации о пользователе необходим доступ для записи в
соответствующую базу данных, но не во всю, а только в определенную запись.
Вполне естественно и даже необходимо дать пользователю возможность менять
пароль, не обращаясь к администратору. С другой стороны, совершенно недопустимо,
чтобы один пользователь, не являясь администратором учетных записей, мог
сменить пароль другому.
Одним из решений было бы хранение пароля для каждого из пользователей
в отдельном файле, но это во многих отношениях неудобно. Другое решение
может состоять в использовании модели клиент-сервер с процессом-сервером,
исполняющимся с привилегиями администратора, который является единственным
средством доступа к паролям. Например, в Win32 весь доступ к пользовательской
базе данных осуществляется через системные вызовы, т. е. функции процесса-сервера
исполняет само ядро системы.
В системах семейства Unix для этой цели был предложен оригинальный механизм,
известный как setuid (setting of user id - установка
[эффективного] идентификатора пользователя). По легенде, идея этого механизма
возникла именно при решении задачи о том, как же пользователи смогут менять
свои пароли, если их хэши будут храниться в одном файле.
Установка идентификатора пользователя в Unix
В Unix каждая задача имеет два пользовательских идентификатора: реальный и эффективный. Реальный идентификатор обычно совпадает с идентификатором пользователя, запустившего задание. Для проверки прав доступа к файлам и другим объектам, однако, используется эффективный идентификатор. При запуске обычных задач реальный и эффективный идентификаторы совпадают. Несовпадение может возникнуть при запуске программы с установленным признаком setuid. При этом эффективный идентификатор для задачи устанавливается равным идентификатору хозяина файла, содержащего программу.
Признак setuid является атрибутом файла, хранящего загрузочный модуль
программы. Только хозяин может установить этот признак, таким образом,
передавая другим пользователям право исполнять эту программу от своего
имени. При модификации файла или при передаче его другому пользователю
признак setuid автоматически сбрасывается.
Например, программа /bin/passwd, вызываемая для смены пароля, принадлежит
пользователю root, и у нее установлен признак setuid. Любой пользователь,
запустивший эту программу, получает задачу, имеющую право модификации
пользовательской базы данных, - файлов /etc/passwd и /etc/shadow. Однако,
прежде чем произвести модификацию, программа passwd проверяет допустимость
модификации. Например, при смене пароля она требует ввести
старый пароль (рис. 12.20). Сменить пароль пользователю, который его забыл,
может только root.
Другим примером setuid-программы может служить программа /bin/ps (process
status - состояние процессов) в старых системах. До установления стандарта
на псевдофайловую систему /proc, Unix не предоставляла штатных средств
для получения статистики об исполняющихся процессах. Программа /bin/ps
в таких системах анализировала виртуальную память ядра системы, доступную
как файл устройства /dev/kmem, находила в ней список процессов и выводила
содержащиеся в списке данные. Естественно, только привилегированная программа
может осуществлять доступ к /dev/kmem.
Рис. 12.20. Смена идентификатора пользователя в Unix
Механизм setuid был изобретен одним из отцов-основателей Unix, Деннисом Ритчи, и запатентован компанией AT&T в 1975 г. Через несколько месяцев после получения патента, ему был дан статус public domain. Официально AT&T объяснила это тем, что плату за использование данного патента нецелесообразно делать высокой, а сбор небольшой платы с большого числа пользователей неудобен и тоже нецелесообразен.
Механизм setuid позволяет выдавать привилегии, доступные только суперпользователю, как отдельным пользователям (при этом setuid-программа должна явным образом проверять реальный идентификатор пользователя и сравнивать его с собственной базой данных), так и группам (при этом достаточно передать setuid-программу соответствующей группе и дать ей право исполнения на эту программу), таким образом, отчасти компенсируя недостаточную гибкость стандартной системы прав доступа и привилегий в системе Unix.
Серверные агенты в Notes
До совершенства механизм setuid доведен в Lotus Notes (этот пакет относится к прикладным программам, а не операционным системам, но реализует собственные схемы аутентификации и авторизации). В этой системе все объекты базы данных, в том числе и агенты (хранимые процедуры), снабжены электронной подписью. Серверные агенты исполняются не от имени пользователя, инициировавшего операцию, а от имени того, кем агент подписан. В данном случае подпись кода означает, что либо пользователь сам занимался разработкой агента, либо он явным образом согласился взять на себя ответственность за результаты его работы. Подпись подделать практически невозможно (используется алгоритм RSA с 631-битным ключом) .
Android требует, чтобы все APK — приложения были подписаны с сертификатами перед их установкой. Данный пост описывает то, как происходит процесс подписания APK — файла, используя Android Studio, включая создание и хранение сертификатов, подпись различных конфигураций построений, используя различные сертификаты и настройка процесса построения для автоматизированной подписи APK.
Сертификаты и хранилища ключей
Сертификат с публичным ключом, также называемый, как электронный сертификат или идентификационный сертификат, содержит публичный ключ в паре публичный/приватный ключи, а также некоторые другие матаданные, идентифицирующие владельца ключей (к примеру, имя и место). Собственник сертификата держит при себе соответствующий публичному сертификату приватный ключ.
Когда файл APK подписывается, то инструмент подписи прикрепляет сертификат публичного ключа к приложению с расширением APK. Сертификат публичного ключа обслуживается также, как и отпечаток пальца(«fingerprint»), который уникально ассоциируется с распространяемым приложением APK и с соответствующему приватному ключу владельца APK. Это помогает Android гарантировать, что будущие обновления приложения с форматом APK можно будет аутентифицировать(владелец может авторизироваться к учетной записи Google Play) и что все изменения приложения придут от оригинального автора, который это приложение разработал. Ключ, используемый для создания сертификата называется ключом подписи приложения .
Хранилище ключей или так называемый keystore — это бинарный файл. который содержит один или нескольких приватных ключей.
Таким образом, каждое приложение должно использовать некоторый сертификат в течении его жизненного цикла, давая иметь возможность сторонним пользователям устанавливать новые версии и обновления в приложении. Для получения дополнительной информации о преимуществах использования одного и того же сертификата для всех ваших приложений на протяжении всей их жизни см. Ниже раздел «Требования к подписи».
Подписка отладочной сборки APK (debug build APK)
Когда проект запускается в режиме отладки, то среда Android Studio или Cordova автоматически подписывает наш файл APK с debug — сертификатом, который генерируется инструментами Android SDK. В первый раз, когда запускается проектируемое приложение в режиме debug в Android Studio или через консоль Cordova, то Android SDK автоматически создает хранилище debug — ключей и в него сертификаты ключей, задав им свои пароли. Данное хранилище расположено по пути $HOME/.android/debug.keystore .
Из-за того, что debug — сертификаты созданы инструментами построения и они небезопасны для проектирования полноценного приложения, то большинство магазинов приложений, включая и Google Play не принимают APK — файлы, подписанные с debug — сертификатом для публикации.
Android Studio и Cordova автоматически сохраняет вашу информацию debug — подписки в конфигурации подписки приложения, поэтому вам не нужно вводить его каждый раз, когда вы отлаживаете приложение. Конфигурация подписки — это объект, содержащий всю необходимую информацию для подписания APK, включая путь к хранилищу ключей, пароль к хранилищу ключей, имя ключа и пароль к ключу. Вы не можете напрямую редактировать конфигурацию debug — подписки, но вы можете конфигурировать то, как вы смогли бы подписывать релиз(release) — построение .
Release — конфигурация, при котором приложение не подписывается по умолчанию после построения. APK, полученное в процессе данной конфигурации необходимо настроить на подпись сертификатом подписи, который мы создаем, как распространитель приложения. Debug — это конфигурация, которая подписывается по умолчанию debug-сертификатом автоматически в процессе построения и отладки, поэтому, вы могли бы заметить, что приложение построенное в конфигурации debug при прошествии некоторого времени перестает работать, хотя, вы его год или два назад построили — это все дело подписки. Время debug — подписки ограничено временем разработки и отладки приложения и это время может быть разным у каждого SDK.
Для большей информации о том, как построить и запустить приложение для дебаггинга можете посмотреть официальный .
Истечение срока действия отладочного сертификата
Ваш собственный сертификат используется для подписи вашего же APK и для него можно индивидуально установить время истечения срока жизненного цикла приложения, после чего приложения нельзя будет устанавливать на мобильные устройства, а вот что касается сертификата debug, то его дата истечения около 365 дней с даты его сборки. Когда дата данного сертификата истекает, то выбрасывается ошибка построения приложения.
Для того, чтобы решить проблему истечения времени debug — сертификата просто нужно удалить файл debug.keystore, который расположен по пути:
- ~/.android/ на OS X и Linux
- C:\Documents and Settings\
\.android\ на Windows XP - C:\Users\
\.android\ на Windows Vista и Windows 7, 8, и 10
В последующем вашем построении и запуске приложения в режиме debug, инструмент построения будет регенирировать новое хранилище ключей и debug — ключ, который будет добавлен в это хранилище. Суть в том, вы можете теперь запустить приложение, последующее построение текущего приложения не будет регенерировать новый ключ, а будет использовать уже созданный на этапе первого построения. Если создает новое приложение, то для него добавляется новый ключ в хранилище ключей и т.д.
Управление вашими ключами подписки
Поскольку ваш ключ подписи приложения используется для проверки вашей личности как разработчика и для обеспечения бесперебойных и безопасных обновлений для ваших пользователей, управление вашим ключом и обеспечение его безопасности очень важны как для вас, так и для ваших пользователей. Вы можете выбрать либо использовать приложение Google Play App Signing для безопасного управления и хранения ключа подписи приложения с помощью инфраструктуры Google, либо управлять и защищать собственное хранилище ключей и ключей подписи приложений.
Использование подписи Google Play App для добавления и обновления приложений APK
При использовании Google Play Signing вы будете иметь 2 ключа: ключ подписи приложения(app signing key ) и ключ выгрузки(upload key ). Google управляет и защищает ключи подписи приложения у себя на сервере и держит при себе ключ выгрузки и использует его для авторизации разработчика в сервисе Google Play Store для выгрузки приложения.
Управление своим собственным хранилищем ключей
Вместо использования Google App Signing вы можете использовать и управлять собственными подписываемыми ключами и хранилищем ключей. Если вы выбираете управление собственными подписываемыми ключами и хранилищем ключей, то вы сами отвечаете за безопасность ключей и хранилищем ключей. Вы должны выбрать строгий пароль для вашего хранилища ключей и разделить строгий пароль для каждого приватного ключа, хранящегося в хранилище ключей. Вы должны держать хранилище ваших ключей в закрытом и безопасном месте. Если вы потеряете доступ к вашим подписываемым ключам, то ваши ключи будут скомпрометированы и Google не сможет вернуть вам ключи подписки приложения и у вас потеряется возможность выпускать новые обновления для оригинального приложения и придется распространять приложение уже под другим идентификатором и названием. Больше об этом можете почитать в разделе «Безопасность ваших ключей» .
Если вы сами управляете собственными ключами подписки приложения и хранилищем ключей, когда вы подписываете ваш APK, то вы должны подписать его локально на вашем ПК, используя ваши ключи подписки приложений и загрузить подписанный APK прямо в Google Play Store для распространения сторонним пользователям, как показано на картинке
При составлении данной статьи использовался официальный ресурс Android Studio по
