Запутывание, чтобы скрыть какой-то алгоритм

Question

Я работаю над клиентским / серверным приложением java. Каждый пользователь должен иметь возможность создавать и изменять файлы (содержащие некоторые конфиденциальные данные) через клиентское приложение (помечая их цифровой подписью) или вручную (помечая их как ошибочную подпись с вероятностью 99,9999%). Подпись не использует идентификационные данные клиента, только содержимое файла, что означает, что два удаленных клиента, создающие один и тот же файл, в итоге получат два файла с одинаковой подписью).

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

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

• Трудно читать?
• Трудно найти?

На данный момент моя идея такова:

• Использование очень случайных имен и некоторых бесполезных обработок
• Поместить его в случайный класс в случайном месте и использовать вещи из случайных мест
• Удалить комментарии
• Рандомизировать

Также я не уверен, что понимаю, как работает компиляция и обратный инжиниринг.

Когда код компилируется, я когда-либо думал, что переменные были названы в « области метода », и что обратный инжиниринг вернет нам код с переменными с именами a, b, c ... и т. д. Но, похоже, дело обстоит не так, и теперь имеет смысл подумать об этом, поскольку в java возможно размышление, Прав ли я в этой последней части?

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

Answer 1

В итоге я подумал об использовании обфускации для защиты от злонамеренных пользователей, а не об использовании обратного инжиниринга для поиска алгоритма доставки цифровой подписи для данного файла.

Я думаю, что это невернопо следующим причинам:

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

   • https://en.wikipedia.org/wiki/Cryptographic_hash_function

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

   • https://en.wikipedia.org/wiki/Digital_Signature_Algorithm

   Существуют надежные реализации этих технологий для Java.Нет необходимости реализовывать свой собственный.

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

3. Запутывание не является адекватной защитой от обратного инжиниринга для извлечения секретов (таких как алгоритм) из кода.Действительно, в случае с Java это не более, чем «скачок скорости» для опытного хакера.

---

ОК, я просто пытаюсь понять, какМое приложение сможет определить, что подпись «а» равна некоторому слову, в то время как пользователь не может найти тот же алгоритм в Интернете, чтобы сделать точно такой же и найти ту же самую подпись.

У вас есть точка.Если известно, что «текст», для которого вы создаете хэш, очень короткий и / или его легко «угадать», то будет возможно осуществить грубую форсировку хэша, предполагая, что алгоритм известен.(Например, подход Gravatar, заключающийся в использовании хэшей адресов электронной почты для обеспечения конфиденциальности, является ошибочным, поскольку несложно собрать список известных адресов электронной почты, сгенерировать их хеши и сохранить их в базе данных, к которой можно обращаться.)

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

(Есть еще кое-что, что вам нужно сделать, чтобы создать полную цифровую подпись ... но прочитайте ссылку выше.)

Answer 2

Давайте проясним ваши неправильные представления о запутывании :

• Вы не делаете это на вашем исходном коде.В мире Java, если вы вообще запутываете двоичную доставку, другими словами: ваши файлы классов.Или, если быть точным: речь идет в основном об обфускации файлов классов, есть коммерческие инструменты для исходного кода обфускации.
• Обфускация по-прежнему используется в сфере Android, но "чистые" магазины Java,он редко используется в наши дни

И самое главное: «безопасность по неизвестности» редко работает.

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