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

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

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

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

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

Любая идея?


android encryption security oauth secret-key
person pomber    schedule 19.02.2015    source источник
comment
возможный дубликат Рекомендации по хранению закрытых ключей API в Android   -  person Duncan Jones    schedule 23.02.2015
comment
Возможный дубликат секретов OAuth в мобильных приложениях   -  person Damian Yerrick    schedule 01.08.2016

Ответы (5)


arrow_upward
4
arrow_downward

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

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

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

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

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

Вероятно, использование комбинации №4 и какого-либо способа однозначной идентификации устройства было бы достаточно безопасным.

person jmm    schedule 11.07.2015

arrow_upward
2
arrow_downward

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

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

Ваше здоровье

person agusgambina    schedule 23.07.2015
comment
То, что он не может быть декомпилирован, не означает, что его нельзя проверить: собственный код можно дизассемблировать в инструкции сборки, близкие к тем, которые сгенерированы компилятором. Его труднее читать, чем код высокого уровня, но, тем не менее, это код. - person mijiturka; 13.06.2017

arrow_upward
1
arrow_downward

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

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

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

Эти шаги не гарантируют сохранность секретного ключа, но значительно усложняют работу реверс-инженера.

person Semih    schedule 19.02.2015
comment
Наверное, это худший совет. - person Johny19; 08.01.2017
comment
На самом деле это очень хороший совет. Хотя секрет должен быть только между приложением и основным шлюзом, а не для других служб. Однако я не хочу слишком сильно менять ответ, поэтому отправлю отдельный. - person Archimedes Trajano; 15.10.2017
comment
@ Johny19, почему ты думаешь, что это плохо? - person Robert Brisita; 18.10.2018

arrow_upward
0
arrow_downward

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

person Aegis    schedule 19.02.2015

arrow_upward
0
arrow_downward

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

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

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

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

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

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

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

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

person Archimedes Trajano    schedule 15.10.2017