Надежно хранить секрет клиента

Я знаю, что a публичный клиент не должен использовать секрет клиента потому что, независимо от того, насколько вы его запутываете, он не будет защищен от инженерный.

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

Итак, я подумал о шифровании его с помощью во время сборки с помощью gradle и храните его в файле. Затем, когда мне это нужно во время выполнения, я расшифровываю его. Но теперь я должен решить проблему как сохранить ключ шифрования...

Я мало знаю о безопасности, поэтому я не знаю, можно ли это решить, или если Android (min sdk 15) предоставляет какой-либо механизм для такого рода сценариев.

есть идеи?

6
android encryption oauth secret-key security

5 ответов

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

  1. хранить в открытом виде

  2. хранить в зашифрованном виде с помощью симметричного ключа

  3. Использование хранилища ключей Android

  4. хранить зашифрованные с помощью асимметричных ключей

вероятно, используя комбинацию #4 и какой-то способ однозначной идентификации устройства будет безопасное достаточно

4

возможно, лучший вариант-использовать NDK, потому что его нельзя декомпилировать, как точки Годфри Нолана здесь

вот ресурс, который я нашел полезным, который помог мне реализовать его ссылка на ресурс

Ура

2

Как вы сказали, что бы вы ни делали, сколько бы вы ни пытались скрыть свой ключ, вы не можете скрыть его на 100%. Но, если вы хотите сделать работу обратного инженера более трудной;

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

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

эти шаги не гарантируют безопасность секретного ключа, но делают работу обратного инженера действительно трудной.

0

вы также можете попробовать Dexguard чтобы запутать и зашифровать данные. Dexguard сделан тем же парнем, который разработал proguard.

0

ответ@Semih был на правильном пути. Секретный ключ-это то, что нужно расширить.

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

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

  1. сервер создает пара ключей, специфичная для входа клиента.
  2. открытый ключ сервера отправляется для шифрования, специфичного для входа клиента в
  3. приложение будет генерировать пару ключей для своих собственных целей
  4. приложение отправит открытый ключ, зашифрованный открытым ключом сервера
  5. сервер проверяет открытый ключ, подписанный открытый ключ.

любые будущие запросы будут включать следующие

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

проблема заключается в обеспечении #1 любой может войти в систему и начать процесс, так как бы вы предотвратить это? Единственный способ, который я могу придумать, - это сделать проверку CAPTCHA на входе.

решение толкает хранение секретов клиента на сервер, а не на само приложение и защищает его с помощью приложения полномочия.

0