Случается так, что после перепрошивки некоторых моделей телефонов при попытке обновления встроенных в новую прошивку программ через 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-битным ключом) .
В данной статье мы с Вами узнаем, как подписать приложение личным сертификатом, используя ПК.
В статье "Общие сведения о сертификатах безопасности." мы познакомились с видами сертификации, общими сведениями о них. Узнали о том, что существуют приложения, для которых требуется личный, персональный сертификат, для того чтобы выполнить им подписку приложения.
Итак, Вы получили персональный сертификат для своего смартфона. Теперь надо Вам подписать свое приложение. Как и с помощью каких приложений это можно сделать, мы и рассмотрим.
В данной статье я расскажу о двух способах подписи приложений на компьютере:
Первый способ. Для подписи используем программу SisSigner .
Данная программа позволяет после получения личного сертификата подписать любое приложение, которое Вы захотите установить на свой смартфон.
1. Скачиваем архив с программой SISSigner. Данный архив содержит все необходимые файлы для начала работы:
- Папка "cert" содержит внутри файл mykey (этот файл необходимо будет заменить).
- Установочный файл программы SISSigner.
Итак, Вы уже имеете персональный сертификат и ключ к нему (получили заранее), установленное приложение для подписи, теперь рассмотрим сам процесс подписи приложения при помощи программы SISSigner:
2. Заходим в папку программы SISSigner (куда Вы ее установили).
- Копируем в нее Ваш полученный сертификат (файл с расширением cer).
- Копируем в нее Ваш полученный ключ к сертификату (файл с расширением key).
- Копируем в нее приложение для смартфона, которое необходимо подписать.
3. Запускаем файл SISSigner и указываем в окне программы:
- Путь к ключу key (что получили при заказе сертификата)
- Путь к сертификату cer (что получили при заказе)
- Пароль key файла (по умолчанию 12345678)
- Путь к приложению, которое необходимо подписать
4. Нажимаем кнопку Подписать.
После появления запроса "Для продолжения нажмите любую клавишу..." - нажимаем любую клавишу.
5. Вот теперь наше приложение подписано и его можно устанавливать в телефон.
6. Подключаем телефон к ПК и с помощью программы PC Suite устанавливаем наше подписанное приложение в смартфон.
Второй способ. Для подписи используем приложение Signsis .
Данное приложение интересно тем, что не требует работы с командной строкой, не требует ввода путей в окне программы. Программу достаточно установить и настроить один раз. И затем у Вас будет возможность подписать приложение, расположенное в любом месте на жестком диске, в любой папке, из контекстного меню.
После установки и настройки этой программы добавляется следующая надпись в меню при нажатии правой кнопки мыши:
Рассмотрим процесс установки этой программы и ее настройки:
1. Скачиваем и распаковываем архив с программой Signsis. В архиве четыре файла:
- install1.bat
- install2.bat
- uninstall.bat
- signsis.exe
3. Переименовываем Ваш сертификат в cert.cer, а ключ в cert.key.
4. Открываем файл install1.bat в Блокноте для редактирования.
- Изменяем значение set password1 на свой пароль (по умолчанию 12345678).
- Изменяем путь к папке программы в значениях set disk_ins и set app_path .
В данном примере программа расположена в папке:
D:\Nokia\6290\sign_sis\
Следовательно, необходимо прописать значения таким образом:
set disk_ins=D:
set app_path=Nokia/6290/sign_sis
Обратите внимание на наклон cлеш (косых линий), если их поставить в обратную сторону, то программа уже не станет работать.
5. Сохраняем файл, нажав в Блокноте "Сохранить".
6. Запускаем файл install1.bat двойным нажатием мыши.
7. Если все выполнено верно, то в результате по нажатию правой кнопкой мыши по инсталляционному пакету sis, у Вас появится контекстное меню с пунктом "Подписать персональным сертификатом".
8. Выбираем приложение на жестком диске, что необходимо подписать. Нажимаем правой кнопкой мыши по нему один раз, в контекстном меню выбираем "Подписать персональным сертификатом". В результате рядом с неподписанным файлом появится еще один файл с тем же именем, но с добавлением к имени "_signed".
9. Подключаем телефон к ПК и с помощью программы PC Suite устанавливаем наше подписанное приложение в смартфон.
Примечание: Если нужно сделать два меню, для подписи двумя разными персональными сертификатами (в случае, если в семье два и более телефонов), то по аналогии редактируем и запускаем install2.bat.
Для полного удаления приложения, а также удаления записей реестра, запустить файл uninstall.bat.
Скачать программы, описанные в статье.
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 по
Случается так, что после перепрошивки некоторых моделей телефонов при попытке обновления встроенных в новую прошивку программ через Google Play Маркет аппарат выдает ошибку «Файл пакета подписан неверно», удалите предыдущую версию и попробуйте снова. После выполнения требуемых операций проблема не решается - приложения не обновляются, зато появляется сообщение о новой ошибке: «Подписи приложений, использующие этот идентификатор, не совпадают». Если у вас имеются права суперпользователя, то вы можете попробовать исправить ситуацию, воспользовавшись следующим способом:
1. Сначала нужно установить программу Titanium Backup .
2. Затем зайти в нее и вверху по центру нажать на кнопку «Резервные копии» (должен появиться полный список приложений, установленных на устройстве);
3. Для страховки сделать резервную копию программы, которую намерены обновить (выбрать нужное приложение, в открывшемся небольшом меню нажать кнопку «Сохранить»).
4. Вернуться к списку программ, снова найти то самое приложение, которое необходимо обновить, но не просто нажать на него, а нажать и удерживать до тех пор, пока на экране телефона не появится сплывающее окно. В нем выбрать функцию «Преобразовать в пользовательское приложение», после чего выйти из TitaniumBackup .
5. Зайти в Google Play, найти обновляемое приложение и произвести манипуляции, необходимые для его обновления. На экране появится уже знакомое сообщение об ошибке, но теперь с предложением удалить старую версию программы («Файл пакета подписан неверно, удалите предыдущую версию и попробуйте снова»). Придется удалить и старую версию. Всё. На этом приложение полностью удалено с устройства.
6. Вот теперь можно заново установить приложение. Разумеется, с маркета установится последняя версия программы, что и требовалось. Больше проблемы с этой программой уже не возникнут.
При желании можно повторить пункт 4 с той только разницей, что преобразовать пользовательское приложение обратно в системное. Просто выберите соответствующий пункт в меню.
Если принятые меры от ошибки избавиться не помогли, резервное копирование, выполненное в самом начале процесса с помощью
