Андроид keystore что такое

Ключи, учетные данные и хранилище на Android

Russian (Pусский) translation by Ellen Nelson (you can also view the original English article)

В предыдущем материале о безопасности пользовательских данных Android мы рассмотрели шифрование данных с помощью предоставленного пользователем кода. В этом уроке перейдём к хранению учётных данных и ключей. Я начну с ознакомления с учётными данными и закончу примером защиты данных с помощью хранилища ключей KeyStore.

Часто, при работе со сторонней службой, требуется какая-то форма авторизации. Она может быть настолько простой, как /login на стороне пользователя, которая принимает имя пользователя и пароль.

Сначала может показаться, что простое решение — это собрать UI, который будет предлагать пользователю войти в систему, а затем записать и сохранить их данные для входа. Однако, это не лучший метод, так как нашему приложению не нужно знать данные для входа в сторонний аккаунт. Вместо этого, мы можем использовать Диспетчер учётных записей (Account Manager), который уполномочен отрабатывать эту конфиденциальную информацию для нас.

Диспетчер учётных записей

Диспетчер учётных записей (Account Manager) — это централизованный помощник для работы с учётными данными пользователя, поэтому вашему приложению, иметь дело с паролями напрямую не нужно. Часто он предоставляет токен вместо реального имени пользователя и пароля, который можно использовать для выполнения аутентифицированных запросов к службе. Например, при запросе токена OAuth2.

Иногда, вся необходимая информация уже хранится на устройстве, а иногда Account Manager придётся обращаться к серверу за новым токеном. Вы, наверное, видели раздел Учётные записи в Настройках вашего устройства для разных приложений. И вот как, мы можем получить список доступных учётных записей:

Этому коду потребуется разрешение android.permission.GET_ACCOUNTS . Если вы ищете определённую учётную запись, вы можете найти её вот так:

Как только найдёте учётную запись, её токен можно получить вызвав метод getAuthToken(Account, String, Bundle, Activity, AccountManagerCallback, Handler) . Затем, таки можно использовать как для авторизированных запросов API к сервису. Это может быть RESTful API, в котором вы передаёте параметр токена во время HTTPS-запроса без необходимости знать детали личной учётной записи пользователя.

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

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

В следующем уроке, мы рассмотрим использование сертификатов для аутентификации и безопасной связи, ну а пока, я всё же хочу рассмотреть, как хранить эти элементы. Изначально Keychain API был создан для очень конкретного использования — установка закрытого ключа или пары сертификатов из файла PKCS#12.

Keychain — связка ключей

Представленный в Android 4.0 (API Level 14), Keychain API управлял ключами. В частности, это работает с объектами PrivateKey и X509Certificate и обеспечивает более безопасный контейнер, чем использование хранилища данных вашего приложения. Связано это с тем, что разрешения закрытых ключей открывают доступ к ключам только вашему приложению и только после авторизации пользователя. Это означает, что, прежде чем, вы сможете использовать хранилище учётных данных, на устройстве должен быть настроен экран блокировки. Кроме того, объекты в связке ключей можно объединить с защитой от оборудования, если доступно.

Код установки сертификата выглядит следующим образом:

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

Как только выбор сделан, возвращается строка с названием псевдонима alias(final String alias) , где вы можете напрямую получить доступ к закрытому ключу или цепочке сертификатов.

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

KeyStore

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

Вот где можно использовать KeyStore API. Начиная с API 1, KeyStore используется системой для хранения учётных данных WiFi и VPN. Начиная с 4.3 (API 18), вы можете работать с асимметричными ключами конкретного приложения, а в Android M (API 23) можно хранить симметричный ключ AES. Таким образом, хотя API не позволяет хранить конфиденциальные строки напрямую, эти ключи можно сохранить, а затем использовать для шифрования строк.

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

Генерирование нового случайного ключа

В этом примере вместо генерации ключа AES из предоставленного пользователем пароля мы можем автоматически сгенерировать случайный ключ, который будет защищён в хранилище ключей KeyStore. Мы можем сделать это, создав экземпляр KeyGenerator , настроенного на поставщика «AndroidKeyStore» .

Здесь важно обратить внимание на спецификации .setUserAuthenticationRequired(true) и .setUserAuthenticationValidityDurationSeconds(120) . Для этого, обязательно должна быть включена блокировка экрана и ключ должен быть заблокирован, до тех пор, пока пользователь не аутентифицируется.

Изучив документацию .setUserAuthenticationValidityDurationSeconds() , вы увидите, что это означает, что ключ доступен только через определённое количество секунд после аутентификации по паролю, и что для передачи -1 требуется идентификация по отпечатку пальца каждый раз, когда вы хотите получить доступ к ключу. Включение требования для аутентификации также приводит к отзыву ключа, когда пользователь удаляет или изменяет экран блокировки.

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

Опция .setRandomizedEncryptionRequired(true) включает требование о наличии достаточного количества случайных чисел (каждый раз новый случайный ВИ [вектор инициализации]), чтобы при повторном шифровании одних и тех же данных, зашифрованный результат всё равно не повторялся. Это не позволяет злоумышленнику получить информацию о зашифрованном тексте на основе передачи тех же данных.

Ещё стоит отметить — setUserAuthenticationValidWhileOnBody(boolean remainsValid) , что блокирует ключ, как только устройство обнаружит, что он больше не принадлежит человеку.

Шифрование данных

Теперь, когда ключ хранится в хранилище KeyStore, мы можем создать метод, который зашифрует данные с использованием объекта Cipher , учитывая SecretKey . Это вернёт HashMap , содержащий зашифрованные данные и случайный ВИ, который понадобится для расшифровки данных. Зашифрованные данные вместе с ВИ могут быть сохранены в файл или в открытых настройках.

Расшифровка в массив байтов

Для расшифровки применяется обратный ход. Объект Cipher инициализируется с использованием константы DECRYPT_MODE , и возвращается расшифрованный массив byte[] .

Смотрим на примере

Теперь мы можем посмотреть на пример!

Использование асимметричных ключей RSA для старых устройств

Это хорошее решение для хранения данных в версии M и выше, но что, если ваше приложение поддерживает более ранние версии? Хотя симметричные ключи AES не поддерживаются в M, поддерживаются асимметричные ключи RSA. Это означает, что для достижения того же результата, мы можем использовать RSA ключи и шифрование.

Основное отличие заключается в том, что асимметричная пара ключей содержит два ключа: закрытый и открытый ключ, где открытый ключ шифрует данные, а закрытый ключ расшифровывает их. KeyPairGeneratorSpec передаётся в KeyPairGenerator , который инициализируется с помощью KEY_ALGORITHM_RSA и поставщика AndroidKeyStore .

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

Расшифровка выполняется с использованием объекта RSAPrivateKey .

Кое-что об RSA — шифрование медленнее, чем в AES. Для небольших объёмов информации, например, когда вы защищаете строки общих настроек, это не страшно. Если вы обнаружите проблему с производительностью при шифровании больших объёмов данных, то вместо этого вы можете использовать данный пример для шифрования и хранения только ключа AES. И тогда, для остальной части ваших данных, используйте более быстрое шифрование AES, которое обсуждалось в предыдущем уроке. Вы можете сгенерировать новый AES ключ и преобразовать его в массив byte[] , который совместим с этим примером.

Чтобы получить ключ, сделайте вот так:

Довольно много кода! Для простоты примеров, я пропустил обработку исключений. Но помните, что для итогового кода не рекомендуется просто перехватывать все случаи Throwable в одном операторе catch.

Заключение

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

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

Источник

Полный список

— создаем ключи и подписываем приложение

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

Подпись приложения

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

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

Итак, приложение обязательно должно быть подписанным, и Eclipse любезно берет это на себя. Он подписывает их debug-ключом. Раньше срок его действия был всего один год. Android проверяет срок действия ключа только при установке. Т.е. если вы установили приложение и срок действия ключа истек, вы все равно сможете использовать установленное приложение. А вот установить или обновить приложение, подписанное истекшим ключом, не получится. Система выдаст ошибку.

Сейчас срок debug-ключа равен 30 лет. Но приложение, подписанное debug-ключом, не получится опубликовать на маркете. А значит, нам надо будет создавать свой ключ и подписывать им приложение.

keytool

Для создания ключа нам понадобится утилита keytool. Ее можно найти по адресу \bin. Она умеет создавать новые ключи и показывать информацию о уже существующих. Давайте сначала попробуем посмотреть информацию о существующем ключе. Для этого возьмем тот самый debug-ключ, который используется для подписи приложений по умолчанию. Узнать где он находится можно в настройках Eclipse: Window > Preferences >Android > Build.

Файл debug.keystore имеет расширение keystore. Это можно перевести как хранилище ключей. Это действительно так, один такой файл может содержать в себе несколько ключей. Для того чтобы обратится к конкретному ключу внутри хранилища используется alias (алиас, можно рассматривать его как имя ключа).

Посмотрим, какие ключи есть в хранилище debug.keystore. Используем команду list. С помощью параметров keystore и storepass укажем имя файла хранилища и пароль к хранилищу:

keytool -list -keystore debug.keystore -storepass android

Мы видим, что здесь хранится один ключ с алиасом androiddebugkey, и создан он был 26.08.2012. Этот ключ и используется Eclipse-ом для подписи вашего приложения по умолчанию. Хранилище и ключ имеют одинаковый пароль — android.

Давайте создадим свой ключ. Для этого используем команду genkey и к ней идет куча параметров.

keytool -genkey -keystore mykeys.keystore -storepass spassword -alias mykey1 -keypass kpassword1 -dname “CN=Dmitry Vinogradov O=StartAndroid C=RU” -validity 10000

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

Именно эти вышеперечисленные параметры мы и задали в скрипте.

keystore — имя файла хранилища
storepass — пароль к хранилищу
alias — алиас создаваемого ключа
keypass — пароль к ключу
dname — информация о владельце ключа
validity — срок действия ключа (в днях)

dname задается в определенном формате. Я указал только имя, организацию и страну.

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

Теперь давайте снова используем команду list и поглядим на только что созданный ключ

keytool -list -keystore mykeys.keystore -storepass spassword

Видим, что внутри все так, как мы и создавали — один ключ с алиасом mykey1.

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

keytool -genkey -keystore mykeys.keystore -alias mykey2 -validity 10000

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

Функционально разницы нет, но при таком способе вам не надо знать формат ввода параметра dname (утилита все спросит сама), и посторонним не видны пароли, которые вы вводили.

Теперь в хранилище два ключа. Выполним list и убедимся.

keytool -list -keystore mykeys.keystore

Обратите внимание, что я не ввел пароль от хранилища (например, чтобы не «светить» его). Утилита спросит меня:

Видно, что был запрошен пароль и в хранилище сейчас два ключа.

Команду list можно еще выполнить с параметром v. Этот параметр добавляет информативности.

Теперь для каждого ключа виден не только алиас и дата создания, но и инфа о владельце, срок действия и пр.

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

jarsigner

Итак, разобрались с keytool. Знаем, как создавать хранилище с ключами и как посмотреть инфу о существующих. Осталось узнать, как подписать приложение ключом. Для этого используется другая утилита — jarsigner.

Скрипт подписи выглядит так:

jarsigner -keystore mykeys.keystore -storepass spassword -keypass kpassword1 Package1.apk mykey1

Имена параметров нам знакомы по keytool: хранилище (keystore), пароль (storepass) к нему и пароль (keypass) к ключу. А последние два параметра – это имя APK-файла, который вы хотите подписать и алиас ключа из указанного хранилища, который вы хотите использовать для подписи.

После этого приложение будет подписано и система примет его к установке.

Ради интереса давайте попробуем установить неподписанный APK. Чтобы создать его надо щелкнуть правой кнопкой мыши на проекте в Eclipse и выбрать Android tools > Export Unsigned Application Package. Далее указываем путь, куда сохранить APK-файл. Eclipse создает приложение из проекта и сохраняет его в указанный каталог. После этого он выводит сообщение, что перед публикацией приложения необходимо его подписать и сжать (утилитой zipalign).

Попробуем установить приложение на эмулятор с помощью adb. Получаем ошибку Failure [INSTALL_PARSE_FAILED_NO_CERTIFICATES]:

Система обнаружила, что приложение не подписано.

Если же сначала закинуть APK на эмулятор и там запустить файловым менеджером, получим такое сообщение при установке:

Визард

Eclipse предоставляет визард, который позволяет реализовать все вышеописанные шаги по подготовке приложения к установке. Для этого надо на проекте в Eclipse щелкнуть правой кнопкой и выбрать Android tools > Export Signed Application Package.

Визард на всякий случай уточнит проект

Затем надо выбрать: использовать существующее хранилище или создавать новое. Если используем существующее, то выбираем его и вводим пароль к этому хранилищу.

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

Выбираем существующий ключ, вводим пароль к нему

Осталось указать путь и имя файла, куда Eclipse сохранит готовое, подписанное и сжатое приложение. Заодно он сразу показывает срок действия сертификата.

Жмем Finish и получаем готовое приложение, которое можно публиковать на маркете.

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

В этом случае вы указываете, что хотите создать хранилище

Далее надо создать ключ

Здесь вы указываете алиас, пароль, срок действия (в годах) и инфу о владельце.

Ну и остается указать путь к создаваемому файлу

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

По поводу срока действия ключа, в хелпе пишут, что рекомендуется ставить 25 лет. И что при публикации приложения на маркете, проверяется, что срок действия закончится позднее, чем 22 октября 2033. Думаю, эта дата будет периодически сдвигаться.

На следующем уроке:

— разбираемся, что такое Package для приложения

Присоединяйтесь к нам в Telegram:

— в канале StartAndroid публикуются ссылки на новые статьи с сайта startandroid.ru и интересные материалы с хабра, medium.com и т.п.

— в чатах решаем возникающие вопросы и проблемы по различным темам: Android, Kotlin, RxJava, Dagger, Тестирование

— ну и если просто хочется поговорить с коллегами по разработке, то есть чат Флудильня

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

Источник