Шифрование на Java - PullRequest
       1

Шифрование на Java

3 голосов
/ 28 февраля 2011

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

Я рассмотрел AES для этого и наткнулся на этот простой пример.1005 * Это хороший подход?Я мог бы получить файл конфигурации в виде строки, закодировать его, записать закодированные байты в файл.Затем я мог бы распространять закодированный файл.

С другой стороны, как бы я расшифровал его?Как распространить спецификацию ключа, чтобы ее можно было расшифровать?

Спасибо

Ответы [ 4 ]

5 голосов
/ 28 февраля 2011

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

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

Как уже упоминалось @limc, вы можете воспользоваться какой-то центральной схемой проверки, со всеми проблемами и враждебностью, которые они приносят.Я думаю, что предложение @Mr Jacques - ваш лучший вариант, если вам действительно не нужно, чтобы он был на 100% защищен от взлома (в этом случае я думаю, что у вас есть большие проблемы), так как он будет сдерживать подавляющее большинство пользователей (пока кто-то не опубликуеттрещина то есть ...)

2 голосов
/ 28 февраля 2011

Если ваша цель - сделать так, чтобы пользователь не мог ИЗМЕНИТЬ файл, тогда вы можете вычислить простой хеш файла.

Жесткий код «соли», добавляемый в ваш хэш, а затем сохраняющий хэш во втором файле конфигурации.

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

2 голосов
/ 28 февраля 2011

Нет действительно надежного способа решить эту проблему. Я заметил, что некоторые крупные компании-разработчики программного обеспечения (Adobe, Microsoft, Symantec) требуют, чтобы пользователь проходил аутентификацию на своих серверах для выполнения n-way-handshake, чтобы убедиться, что ключи действительны. Это работает, но оно создает другой набор проблем ... например, пользователю нужен доступ в Интернет, пользователю нужно перенести серийный номер на новый компьютер и т. Д. *

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

2 голосов
/ 28 февраля 2011

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

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