Хранение секретов и учетных данных внутри приложения Android - PullRequest
0 голосов
/ 13 сентября 2018

Я использую AWS Cognito, и мне нужно хранить некоторые учетные данные и секреты где-нибудь внутри моего приложения для Android, чтобы позже использовать их для входа / регистрации / выхода из системы.

В некоторых источниках предлагается хранить учетные данные в файле проекта gradle.properties . Оттуда учетные данные будут получены как BuildConfig.FIELD_NAME. Могу ли я быть на 100% уверен, что они не могут быть извлечены из apk при обратном проектировании?

Другой способ, которым я думал, - это зашифровать учетные данные с использованием асимметричного алгоритма шифрования (с открытым-закрытым ключом) и расшифровать их во время выполнения при необходимости, но опять же, мне нужно хранить где-то внутри моего приложения открытый ключ, чтобы расшифровать учетные данные. Это не работает снова, так как открытый ключ может быть извлечен декомпиляцией apk.

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

Итак, как я могу сделать это максимально безопасно? Я жду ваших решений! Спасибо

редактирование: Хранилище ключей на самом деле не работает, так как я должен получить секреты откуда-то, прежде чем добавить их в хранилище ключей

1 Ответ

0 голосов
/ 13 сентября 2018

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

Оттуда учетные данные будут извлечены как BuildConfig.FIELD_NAME. Могу ли я быть на 100% уверен, что они не могут быть извлечены из apk при обратном проектировании?

Я на 100% уверен, что его можно получить :). Java не будет зашифровывать какие-либо строки, и все они будут храниться в виде необработанного текста в файлах dex, готовые для использования в grep'd.

Оттуда ваши следующие шаги будут шифровать ключи в коде, используя статический ключ. Некоторые инструменты сделают это за вас, например DexGuard, Dasho, Dexprotector - вы также можете придумать свое собственное решение. Эта статья объясняет это хорошо.

Имейте в виду, что как ваше собственное решение, так и решение, предоставленное сторонним инструментом, может оказаться легко изменить: см. этот пример для DexGuard. Также обратите внимание, что при расшифровке во время выполнения эти учетные данные будут храниться в оперативной памяти устройства, что позволяет отладчику легко их читать.

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

Затем вы можете использовать криптографию whitebox, опять же со сторонними инструментами, такими как предложенные Inside Secure. Это будет по существу смешивать как алгоритм шифрования, так и ключ с обфусцированным нативным кодом, что может затруднить обратное преобразование и отладку методов шифрования / дешифрования. Здесь вы будете включать только зашифрованные учетные данные в ваше приложение, и они будут надежно дешифрованы внутри whitebox. Белый ящик, как правило, очень безопасен (но не невозможно взломать), но после расшифровки учетные данные будут храниться в памяти устройства. Это защитит вас от простой декомпиляции.

Тогда ... Я не думаю, что вы можете пойти гораздо дальше, не задействуя аппаратное решение (KeyStore, встроенный безопасный элемент) и сервер для резервного копирования всего.

...