Android - Хранение конфиденциальных данных в базе данных sqlite - PullRequest
10 голосов
/ 01 марта 2012

Мне нужно хранить конфиденциальные данные в базе данных sqlite в приложении для Android.

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

Я узнал о SQLCipher . В нем говорится, что это очень безопасный способ шифрования данных в базе данных, но почему это так? Разве мне также не нужно иметь ключ, чтобы разблокировать эту информацию? Или это действительно идеальный способ убедиться, что данные в безопасности?

А если нет, то является (почти) безошибочным способом хранения конфиденциальных данных в базе данных sqlite?

Ответы [ 3 ]

12 голосов
/ 01 марта 2012

Вы сказали ...

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

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

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

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

9 голосов
/ 01 марта 2012

Симметричная криптография требует ключ для шифрования и тот же ключ для дешифрования.Обойти это невозможно.

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

При первом использовании спросите пользователя парольи используйте PBKDF2 для получения криптографически безопасного ключа для использования в шифровании.

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

И если срок действия истек, пользователю потребуется снова ввести пароль.

Я не проверил SQLCipher полностью, но он говорит, что использует AES-256.AES - это симметричный криптографический алгоритм, для которого требуется ключ для шифрования и тот же ключ для расшифровки.

1 голос
/ 10 августа 2014

Можно ли разрешить приложениям автоматически генерировать случайный пароль? Это может быть общая информация о месте, времени или другой информации, для этого не нужно спрашивать пароль пользователя.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...