Основные положения электронной подписи приложений. Android & iOS: концепции распространения приложений и вопросы безопасности

Сейчас смартфоны под управлением Android и iOS являются одними из самых популярных среди потребителей во всем мире, хотя по количеству проданных устройств и наблюдается существенный разрыв. Так, согласно отчету NPD Group, доля Android-смартфонов на рынке США составляет 61%, в то время как доля iOS - 29%. Несмотря на все возрастающую популярность двух конкурирующих платформ, проблемы их безопасности разительно отличаются. В то время как сообщения об очередной атаке злоумышленников на пользователей Android-устройств появляются с завидной регулярностью, владельцы «яблочных» i-продуктов фактически не испытывают никаких опасений, а большинство из них могло даже не слышать об имевших место атаках.

В чем же причина столь большой разницы? Попытаемся ответить на этот вопрос. Для начала рассмотрим технические особенности каждой операционной системы.

В основе ОС Android лежит Ядро Linux, которое выступает мостом между аппаратными возможностями смартфона и программными функциями Android. Большинство приложений для этой системы создаются при помощи языка Java и выполняются в виртуальной среде Dalvik, являющейся интерпретацией виртуальной Java-машины. Помимо языка Java, для написания программ могут использоваться и другие языки, но вне зависимости от способа создания приложения работают в специальной защищенной среде - песочнице (sandbox). Благодаря этой песочнице приложения не могут получить доступ к процессам других программ или их данным.

В Android всем приложениям присваивается уникальный идентификатор пользователя User ID или UID. Во время работы каждая программа выполняется под своим пользователем и в отдельном процессе, что является составной частью песочницы. У одного и того же приложения, установленного на разных устройствах, этот идентификатор может быть разным, однако он всегда сохраняется за приложением на протяжении всего времени пребывания его в системе. По умолчанию доступ к root (учетной записи суперпользователя с неограниченными правами в системе) имеют только ядро и некоторые ключевые системные приложения.

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

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

Базовое приложение Android не содержит в себе функций, требующих доступа к контролируемым и защищаемым песочницей данным или возможностям смартфона. В случае необходимости задействования определенного функционала или доступа к данным разработчик должен указать для приложения соответствующие разрешения (Permissions) в конфигурационном файле AndroidManifest.xml. Во время установки подобного приложения пользователь увидит сообщение, содержащее информацию о функциях, необходимых для его работы. Операционная система оставляет за пользователем право решать, стоит ли доверять выбранной программе. После установки выполнение той или иной функции уже не потребует участия пользователя.

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

Операционная система iOS, как и OS X, на которой она базируется, построена на основе ядра Mach и интерфейсов BSD и представляет собой UNIX-подобную систему. Системное ядро отвечает за управление памятью, работу с файловой системой, доступ к аппаратным функциям, сети и т. п. Драйвера выполняют связующую роль между аппаратной частью и системными функциями. Доступ к ядру и драйверам ограничен, и его имеют лишь некоторые системные приложения и библиотеки.

Для обеспечения безопасности каждое устанавливаемое приложение помещается в песочницу - sandbox. Приложениям отводится отдельное место в файловой системе (каталог, содержащий саму программу и ее данные), доступ к которому для других приложений ограничивается. Помимо этого, песочница контролирует доступ к различным функциям системы, сети, аппаратным возможностям смартфона и т. д. Например, ограничения затрагивают доступ к СМС- и почтовой переписке, выполнению скрытого набора номера, отправке сообщений. Если в работе приложения предусмотрен обмен определенными данными с другими программами, у разработчиков существует возможность предоставить такой доступ. Все приложения, устанавливаемые пользователями, работают с ограниченными правами.

Приложения для iOS должны быть подписаны цифровым сертификатом. Этот сертификат служит идентификатором разработчика и гарантирует, что приложение было создано именно им, а также что разработчик является зарегистрированным членом Developer Program. Для получения сертификата разработчик должен направить запрос в Apple. В случае положительного решения этого вопроса он получает цифровой сертификат безопасности, который в дальнейшем используется при создании приложений.

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

Как мы видим, обе операционные системы обеспечивают вполне приемлемый уровень безопасности. Почему же сообщения об очередных угрозах для владельцев Android-устройств звучат гораздо чаще, чем об угрозах для смартфонов от Apple?

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

– онлайн-мошенничество;

– социальная инженерия;

– создание вредоносных и нежелательных программ.

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

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

Что касается ОС Android, прежде всего, стоит отметить тот факт, что SDK - средства разработки - доступны для Windows, Linux и Mac OS X. Этим обеспечивается охват самого широкого круга разработчиков.

Созданные приложения могут распространяться несколькими способами. Первый - через основную официальную площадку - каталог Google Play. За небольшую единовременную плату в размере $25 любой желающий может зарегистрировать аккаунт разработчика и распространять в этом каталоге созданные им приложения. Помещаемые в Google Play программы практически сразу становятся доступными для загрузки пользователями. До недавнего времени публикуемые в этом каталоге приложения не подвергались какой-либо проверке, однако из-за того, что злоумышленники периодически размещали в нем вредоносные программы, компании Google пришлось ввести специальную систему Bouncer, которая должна искать подозрительные и нежелательные приложения на основе уже имеющихся данных. Тем не менее, ни о какой жесткой политике проверки и тестирования приложений перед размещением речи не идет.

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

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

Рис.1. Схема возможных каналов получения приложений в ОС Android

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

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

Не стоит забывать, что компания Google позиционирует Android как открытую операционную систему. Несмотря на то что некоторые компоненты все же являются недоступными (например, ключевые системные драйверы и проприетарные приложения), имеющийся в открытом доступе код позволяет эффективнее обнаруживать различные уязвимости, которые в том числе берут на вооружение и используют в своих вредоносных программах злоумышленники. Одним из наиболее ярких примеров таких приложений являются троянцы Android.DreamExploid., Android.Wukong и Android.Gongfu, которые эксплуатируют уязвимости операционной системы, позволяющие повышать привилегии программного окружения до уровня root. Это дает им более широкие возможности по выполнению своих вредоносных функций, например, установке других приложений без участия пользователя.

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

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

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

Создание и распространение приложений для операционной системы iOS имеет ряд отличий. Во-первых, средства разработки доступны только для компьютеров Mac OS X. Во-вторых, разработчик должен выбрать подходящую ему модель распространения созданных приложений:

IOS Developer Program Individual или iOS Developer Program Company - для индивидуальных разработчиков и компаний, которые создают приложения для массового рынка;

IOS Developer Enterprise Program - для корпоративных клиентов, которым необходимы приложения для внутренних нужд;

IOS Developer University Program - для образовательных учреждений с целью повышения квалификации студентов и ознакомления их с процессом создания приложений для мобильной системы от Apple.

Первая модель является стандартной, рассчитанной на общий потребительский рынок (именно эта модель в дальнейшем будет использоваться в качестве основы для рассмотрения). Созданные на ее основе приложения доступны только через официальный каталог приложений App Store, причем прежде чем увидеть свет, они проходят определенную проверку. Процесс создания приложения, проверки и добавления в App Store выглядит следующим образом: сначала разработчик должен пройти простую регистрацию на сайте developer.apple.com , после чего ему будет доступна среда разработки. Однако для того, чтобы иметь возможность распространять в App Store созданные приложения, ему необходимо выбрать одну из подходящих моделей распространения (в случае с iOS Developer Program Individual или iOS Developer Program Company членство стоит $99 в год).

Для того чтобы разместить созданное приложение в каталоге App Store, разработчику необходимо направить его на рассмотрение в Apple. Для этого требуется уже откомпилированная и готовая к использованию программа. При проверке внимание обращается на соответствие многим требованиям, среди которых - оформление приложения и логика построения интерфейса, отсеивание малосодержательных приложений, а также программ, которые дублируют уже имеющийся функционал и вводят пользователя в заблуждение своим сходством со стандартным ПО. Также не допускаются приложения, иконка которых похожа на иконку системных приложений. Обязательным является проверка на следование установленным правилам безопасности. Среди них стоит выделить следующие:

Функционал соответствует заявленным возможностям, то есть не имеется скрытых и необъявленных функций;
- приложение может выполнять загрузку файлов, если это необходимо для ее основной работы, причем пользователь должен быть уведомлен об этом;
- если требуемый объем загрузки через мобильную сеть превышает лимит в 50 МБ, загрузка должна происходить только по Wi-Fi либо отдельными сессиями;
- приложение не выполняет установку или запуск других программ;
- приложение выполняется в своей среде и не имеет доступа к областям других приложений, включая их файлы;
- в приложении не используются недокументированные функции системы;
- пользователь должен быть уведомлен о сборе персональной информации (включая координаты местоположения), выполняемом приложением, и должен дать согласие на такие действия перед их выполнением;
- приложение должно уведомить пользователя о целях сбора персональной информации и возможных областях их применений.

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

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

Вторая модель - iOS Developer Enterprise Program - ориентирована на корпоративных клиентов, которым требуется создание приложений для внутренних нужд. Как и в предыдущем случае, для доступа к ней необходима платная регистрация, которая стоит уже $299 в год. Созданные впоследствии приложения могут быть распространены среди сотрудников компании и установлены следующими способами: через компьютер с имеющейся на нем программой iTunes, при помощи администрирующего приложения iPhone Configuration Utility, либо через специально созданный веб-сайт. Помимо корпоративных, также возможна установка общедоступных приложений, размещенных в каталоге App Store.

Третью модель - iOS Developer University Program - рассматривать не стоит, так как она служит образовательным целям.

Кроме описанных способов установки приложений на смартфоны с iOS, существует и третий. Он становится возможным после выполнения операции jailbreak - снятия стандартных ограничений системы и получения прав доступа к файловой системе устройства. Сделав jailbreak, пользователь может устанавливать приложения, минуя App Store. Доступ к таким приложениям осуществляется при помощи специализированных программ-каталогов, наиболее известный и широко применяемый из которых - Cydia. Маловероятно, что корпоративный сектор будет использовать такой метод, поэтому он в большей степени присущ определенной части обычных пользователей.

Рис. 2. Схема возможных каналов получения приложений в iOS

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

Среди того немногочисленного числа вредоносных программ, существующих для iOS, самой известной, пожалуй, является червь Ike. Этот червь функционировал только на взломанных смартфонах, где был выполнен jailbreak. Для своего распространения он использовал терминал SSH и стандартный root-пароль устройства: alpine. Червь устанавливал в качестве фонового изображения фотографию певца Рика Эстли (Rick Astley). Другая версия червя уже имела в своем функционале возможность принимать и выполнять команды от своих создателей. Более того, он менял стандартный пароль, чтобы снизить вероятность того, что пользователь сможет от него избавиться.

Помимо вредоносной программы Ike, для iOS существуют и коммерческие программы-шпионы. Однако для их установки необходимо, чтобы на устройстве также был выполнен jailbreak, так как они распространяются через сторонние площадки, отличные от App Store. Для успешного внедрения и настройки такого шпиона требуется непосредственное участие злоумышленника.

Также следует помнить, что iOS, являясь закрытой операционной системой, принадлежащей исключительно компании Apple, менее охотно поддается анализу. Это вовсе не значит, что уязвимости в ней найти невозможно. Тем не менее, обнаруженные уязвимости операционной системы, которые применяются на практике, больше всего направлены на выполнение операции jailbreak. Может сложиться впечатление, что смартфоны с jailbreak’ом являются хорошей мишенью для злоумышленников, и это отчасти справедливо. Однако нельзя забывать, что пользователей таких смартфонов все-таки существенно меньше, чем тех, кто предпочел ничего не модифицировать, поэтому экономическая эффективность (а именно финансовая сторона является одной из главных причин деятельности злоумышленников) здесь также под вопросом.

Ко всему прочему, iOS не лицензируется сторонним производителям. Это помогает сохранять контроль над целостностью платформы, обеспечивая тем самым более высокую надежность и позволяя оперативно выпускать обновления системы для все еще поддерживаемых устройств. Это, в свою очередь, также снижает вероятность создания злоумышленниками вредоносных программ, использующих различные уязвимости системы, как, например, происходит в случае Android. Хорошим примером такого подхода может служить недавний выпуск обновления системы, iOS 5.1.1, устраняющего уязвимости, которые могли привести к подмене отображаемого адреса веб-страницы, межсайтовому скриптингу, а также выполнению произвольного кода. Это обновление доступно сразу для нескольких поколений мобильных устройств от Apple.

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

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

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

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 по

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

Авторизация доступа к полям документа в 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, а затем уже в ее папку добавляем папку "cert" с ключом из архива.

Итак, Вы уже имеете персональный сертификат и ключ к нему (получили заранее), установленное приложение для подписи, теперь рассмотрим сам процесс подписи приложения при помощи программы SISSigner:

2. Заходим в папку программы SISSigner (куда Вы ее установили).

• Копируем в нее Ваш полученный сертификат (файл с расширением cer).
• Копируем в нее Ваш полученный ключ к сертификату (файл с расширением key).
• Копируем в нее приложение для смартфона, которое необходимо подписать.

3. Запускаем файл SISSigner и указываем в окне программы:

• Путь к ключу key (что получили при заказе сертификата)
• Путь к сертификату cer (что получили при заказе)
• Пароль key файла (по умолчанию 12345678)
• Путь к приложению, которое необходимо подписать

Сертификат, ключ и приложение можно не переименовывать - главное правильно в окне программы SisSinger указать к ним путь!

4. Нажимаем кнопку Подписать.

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

5. Вот теперь наше приложение подписано и его можно устанавливать в телефон.

6. Подключаем телефон к ПК и с помощью программы PC Suite устанавливаем наше подписанное приложение в смартфон.

Второй способ. Для подписи используем приложение Signsis .

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

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

Рассмотрим процесс установки этой программы и ее настройки:

1. Скачиваем и распаковываем архив с программой Signsis. В архиве четыре файла:

• install1.bat
• install2.bat
• uninstall.bat
• signsis.exe

2. Копируем в тот же каталог, куда мы распаковали файлы, свои сертификат и ключ.
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.

Скачать программы, описанные в статье.

Случается так, что после перепрошивки некоторых моделей телефонов при попытке обновления встроенных в новую прошивку программ через Google Play Маркет аппарат выдает ошибку «Файл пакета подписан неверно », удалите предыдущую версию и попробуйте снова. После выполнения требуемых операций проблема не решается - приложения не обновляются, зато появляется сообщение о новой ошибке: «Подписи приложений, использующие этот идентификатор, не совпадают». Если у вас имеются права суперпользователя, то вы можете попробовать исправить ситуацию, воспользовавшись следующим способом:

1. Сначала нужно установить программу Titanium Backup.

2. Затем зайти в нее и вверху по центру нажать на кнопку «Резервные копии » (должен появиться полный список приложений, установленных на устройстве);

3. Для страховки сделать резервную копию программы, которую намерены обновить (выбрать нужное приложение, в открывшемся небольшом меню нажать кнопку «Сохранить »).

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

5. Зайти в Google Play, найти обновляемое приложение и произвести манипуляции, необходимые для его обновления. На экране появится уже знакомое сообщение об ошибке, но теперь с предложением удалить старую версию программы («Файл пакета подписан неверно, удалите предыдущую версию и попробуйте снова »). Придется удалить и старую версию. Всё. На этом приложение полностью удалено с устройства.

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

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

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