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

Question

Проблема вкратце: я разрабатываю приложение (например, игру), которое распространяется в двоичном виде. Игра звонит домой и отправляет рекорд пользователя в виде сообщения на сервер онлайн-игры.

То, что я хотел бы сделать, - это цифровое шифрование и подписать сообщение, чтобы я мог поверить, что оно не было подделано.

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

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

Answer 1

Короче говоря: нет ... нет надежного решения этой проблемы. Проблема в том, что приложение, которое отправляет вам рекорды, работает под контролем человека, которому вы не «доверяете» в этой транзакции. Если они могут выполнить обратный инжиниринг кода, то они могут изменить содержимое любого сообщения, прежде чем оно будет подписано.

Answer 2

Ты просто не можешь. Нет реального решения этой проблемы, просто все больше и больше запутываний и проверок на фальсификацию (ИМХО, это просто трата времени). Гипотетически, каждая программа может быть перепроектирована, эмулирована и подделана. С этим ничего не поделаешь.

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

Answer 3

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

Answer 4

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

Вопрос становится вопросом стоимости. Является ли стоимость взлома системы защиты выше, чем стоимость, которую она защищает? И какова стоимость восстановления после успешного взлома?

Так как таблица рекордов, как правило, не является целью высокого значения, вы можете попробовать любой из этих:

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

2. Отправьте рекорд с использованием шифрования с общим секретом. Не храните общий секрет в виде простого текста в вашем приложении. Желательно использовать алгоритм для его расчета в реальном времени.

3. Запутать ваш код клиента.

4. Хранить рекорды с IP-адресами клиентов и отметкой времени.

Answer 5

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

Прочтите Trusted Computing . Он построен на основе открытого / закрытого ключа, встроенного в ваш компьютер, к которому ваш компьютер никогда не позволит получить доступ. Занятие памяти / Запечатанное хранение мешало бы злоумышленнику попытаться обнаружить ключ, доставленный в ваше приложение.

Answer 6

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

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

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

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

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

Это слишком много, но слишком много для реверса.

Другим способом решения вашей проблемы является добавление двухбайтового (слова) значения безопасности (CRC) на основе содержимого пакета с помощью собственных вычислений. Сервер проверит это значение, а если оно недопустимое -> Disconnect.

Answer 7

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