Android get signed key

How to obtain SHA1 Keys for debug and release — Android Studio [Mac]

Debug Key

Click on the Gradle tab on the right hand side of the Android Studio window.

Go to the Project root folder -> Tasks -> android -> signingReport

UPDATE: (Newer versions) In case you don’t find an android folder here, go to :app instead of root, navigate to Tasks>android and you’ll find signingReport.

Double click on signingReport, this will build and post the SHA1 in the bottom view.

Release

Method 1

In Android Studio, go to Build menu -> Generate Signed Bundle / APK

Select your keystore and key alias.

Copy the key store path and the key alias.

Here, the path is /Users/technofreek/Documents/testkeystore

and the alias is key0.

Open terminal and type the command

keytool -list -v -keystore -alias

For this example, here’s the command

keytool -list -v -keystore /Users/technofreek/Documents/testkeystore -alias key0

This will print your SHA1

Method 2

If you have enabled App Signing for your app in your Google Play Developer Console, by uploading your signing certificate, then just go to your developer console and select your app.

Select Release Management -> App Signing, and you’ll see you release SHA1.

Источник

Ключи, учетные данные и хранилище на 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, поддерживаемый вашим приложением.

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

Источник

apksigner

The apksigner tool, available in revision 24.0.3 and higher of the Android SDK Build Tools, allows you to sign APKs and to confirm that an APK’s signature will be verified successfully on all versions of the Android platform supported by those APKs. This page presents a short guide for using the tool and serves as a reference for the different command-line options that the tool supports. For a more complete description of how the apksigner tool is used for signing your APKs, see the Sign your app guide.

Caution: If you sign your APK using apksigner and make further changes to the APK, the APK’s signature is invalidated. Therefore, you must use tools such as zipalign before signing your APK.

Usage

Sign an APK

The syntax for signing an APK using the apksigner tool is as follows:

When you sign an APK using the apksigner tool, you must provide the signer’s private key and certificate. You can include this information in two different ways:

• Specify a KeyStore file using the —ks option.
• Specify the private key file and certificate file separately using the —key and —cert options, respectively. The private key file must use the PKCS #8 format, and the certificate file must use the X.509 format.

Usually, you sign an APK using only one signer. In the event that you need to sign an APK using multiple signers, use the —next-signer option to separate the set of general options to apply to each signer:

Verify the signature of an APK

The syntax for confirming that an APK’s signature will be verified successfully on supported platforms is as follows:

Rotate signing keys

The syntax for rotating a signing certificate lineage, or a new sequence of signatures, is as follows:

Options

The following lists include the set of options for each command that the apksigner tool supports.

Sign command

General options

The following options specify basic settings to apply to a signer:

—out The location where you’d like to save the signed APK. If this option isn’t provided explicitly, the APK package is signed in-place, overwriting the input APK file. —min-sdk-version The lowest Android framework API level that apksigner uses to confirm that the APK’s signature will be verified. Higher values allow the tool to use stronger security parameters when signing the app but limit the APK’s availability to devices running more recent versions of Android. By default, apksigner uses the value of the minSdkVersion attribute from the app’s manifest file. —max-sdk-version The highest Android framework API level that apksigner uses to confirm that the APK’s signature will be verified. By default, the tool uses the highest possible API level. —v1-signing-enabled Determines whether apksigner signs the given APK package using the traditional, JAR-based signing scheme. By default, the tool uses the values of —min-sdk-version and —max-sdk-version to decide when to apply this signature scheme. —v2-signing-enabled Determines whether apksigner signs the given APK package using the APK Signature Scheme v2. By default, the tool uses the values of —min-sdk-version and —max-sdk-version to decide when to apply this signature scheme. —v3-signing-enabled Determines whether apksigner signs the given APK package using the APK Signature Scheme v3. By default, the tool uses the values of —min-sdk-version and —max-sdk-version to decide when to apply this signature scheme. —v4-signing-enabled Determines whether apksigner signs the given APK package using the APK Signature Scheme v4. This scheme produces a signature in an separate file ( apk-name .apk.idsig ). If true and the APK is not signed, then a v2 or v3 signature is generated based on the values of —min-sdk-version and —max-sdk-version . The command then produces the .idsig file based on the content of the signed APK. Use only to generate only the v4 signature without modifying the APK and any signatures it had before the invocation; only fails if the APK doesn’t have a v2 or v3 signature already, or if the signature used a different key than the one provided for the current invocation. By default, the tool uses the values of —min-sdk-version and —max-sdk-version to decide when to apply this signature scheme. -v , —verbose Use the verbose output mode.

Per-signer options

The following options specify the configuration of a particular signer. These options aren’t necessary if you sign your app using only one signer.

—next-signer Used for specifying different general options for each signer. —v1-signer-name The base name for the files that comprise the JAR-based signature for the current signer. By default, apksigner uses the key alias of the KeyStore or the basename of the key file for this signer.

Key and certificate options

The following options specify the signer’s private key and certificate:

—ks The signer’s private key and certificate chain reside in the given Java-based KeyStore file. If the filename is set to «NONE» , the KeyStore containing the key and certificate doesn’t need a file specified, which is the case for some PKCS #11 KeyStores. —ks-key-alias The name of the alias that represents the signer’s private key and certificate data within the KeyStore. If the KeyStore associated with the signer contains multiple keys, you must specify this option. —ks-pass

The password for the KeyStore that contains the signer’s private key and certificate. You must provide a password to open a KeyStore. The apksigner tool supports the following formats:

– Password provided inline with the rest of the apksigner sign command.

env: – Password is stored in the given environment variable.

file: – Password is stored as a single line in the given file.

stdin – Password is provided as a single line in the standard input stream. This is the default behavior for —ks-pass .

Note: If you include multiple passwords in the same file, specify them on separate lines. The apksigner tool associates passwords with an APK’s signers based on the order in which you specify the signers. If you’ve provided two passwords for a signer, apksigner interprets the first password as the KeyStore password and the second one as the key password.

—pass-encoding Includes the specified character encodings (such as, ibm437 or utf-8 ) when trying to handle passwords containing non-ASCII characters.

Keytool often encrypts keystores by converting the password using the console’s default charset. By default, apksigner tries to decrypt using several forms of the password: the Unicode form, the form encoded using the JVM default charset, and, on Java 8 and older, the form encoded using the console’s default charset. On Java 9, apksigner cannot detect the console’s charset. So, you may need to specify —pass-encoding when a non-ASCII password is used. You may also need to specify this option with keystores that keytool created on a different OS or in a different locale.

The password for the signer’s private key, which is needed if the private key is password-protected. The apksigner tool supports the following formats:

– Password provided inline with the rest of the apksigner sign command.

env: – Password is stored in the given environment variable.

file: – Password is stored as a single line in the given file.

stdin – Password is provided as a single line in the standard input stream. This is the default behavior for —key-pass .

Note: If you include multiple passwords in the same file, specify them on separate lines. The apksigner tool associates passwords with an APK’s signers based on the order in which you specify the signers. If you’ve provided two passwords for a signer, apksigner interprets the first password as the KeyStore password and the second one as the key password.

Verify command

Examples

Sign an APK

Sign an APK using release.jks , which is the only key in the KeyStore:

Sign an APK using a private key and certificate, stored as separate files:

Sign an APK using two keys:

Verify the signature of an APK

Check whether the APK’s signatures are expected to be confirmed as valid on all Android platforms that the APK supports:

Check whether the APK’s signatures are expected to be confirmed as valid on Android 4.0.3 (API level 15) and higher:

Rotate signing keys

Enable a signing certificate lineage that supports key rotation:

Rotate your signing keys again:

Content and code samples on this page are subject to the licenses described in the Content License. Java is a registered trademark of Oracle and/or its affiliates.

Источник