Как не дать взломанному серверу подделать главный сервер?

Я хочу установить модель многослойной игры на основе комнаты, в которой игроки могут принимать матчи и выступать в качестве хоста (т.е. сервер с авторитетным полномочием). Я хочу разместить главный сервер, который отслеживает предметы игрока, его ранг, деньги, опыт и т. Д.

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

Спасибо. -Cody

Было отмечено, что мой предыдущий ответ мог быть основан на неправильном понимании того, что вы имели в виду под «подделкой». (Если так, пожалуйста, дайте мне знать, и я удалю его.)

Если вы хотите предотвратить то, что игровые серверы отправляют фиктивные данные на главный сервер, то, как отмечает Яри Комппа, это вообще невозможно предотвратить полностью. Фактически это просто вариант классической проблемы предотвращения мошенничества в многопользовательской среде , за исключением промежуточных серверов, а не клиентов, подозреваемых в мошенничестве. Многие из тех же методов, которые используются для традиционного мошенничества, также могут работать здесь, но, как обычно, ни один из них не является абсолютно надежным.

Тем не менее, есть есть некоторые вещи , которые вы могли бы сделать , что бы конкретно помочь против обмана серверов. Одним из них будет то, что каждый игрок в матче по отдельности свяжется с главным сервером и подтвердит свое участие в этом матче. (Возможно, вы захотите сделать это до начала матча, чтобы убедиться, что все согласны с тем, кто является участниками, и чтобы никто не испытывал соблазн утверждать, что не участвовал в проигранном матче. Вы можете использовать цифровые подписи, чтобы отложите это, хотя, по сути, вы могли бы попросить каждого игрока в матче подписать сообщение: « Я игрок X, и я участвую в матче M на сервере S в момент времени T с игроками Y, Z и W."и отправьте его на игровой сервер, который позже сможет передать его на главный сервер.) Таким образом, вы можете по крайней мере убедиться, что обманный сервер не может повлиять на рейтинг любого игрока, который фактически не играет на этом сервере ,

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

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

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

Примечание. Этот ответ может быть основан на неправильном понимании вопроса - см. Комментарии ниже.

Краткий общий ответ: используйте цифровые подписи .

В частности, главный сервер должен иметь закрытый ключ для подходящей схемы цифровой подписи (RSA, DSA, ECDSA и т. Д.) И должен каким-то образом безопасно передавать свой открытый ключ всем клиентам. Затем сервер может подписать любые данные, которые он отправляет клиентам с помощью закрытого ключа (или, возможно, использовать его для согласования общего секрета, используемого для симметричного шифрования и / или аутентификации обмена данными между ним и этим конкретным клиентом), и клиент может использовать открытый ключ для убедитесь, что подпись была сгенерирована сервером.

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

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

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

В частности, вы действительно должны взглянуть на существующие библиотеки SSL / TLS (которые обычно поставляются с реализацией PKI X.509 ) или, возможно, на SPKI . Они все еще несколько сложны, но, вероятно, проще (и более безопасны), чем пытаться свернуть свои собственные.

Это зависит от характера игры и от причины, по которой вы разгружаете роль сервера.

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

• Начальное состояние S0 включает в себя уникальный идентификатор для игры (для предотвращения повторных атак) и в остальном предполагается постоянным. Если есть случайный элемент, он должен быть создан центральным сервером и сохранен в нем для последующего сравнения.
• P1 делает ход m1; подписывает результирующее состояние S1, производя подпись C1; и отправляет его своим ходом (S1, C1, m1) в P2.
• P2 делает ход м2; подписывает результирующее состояние S2, производя подпись C2; и отправляет его своим ходом (S2, C2, m2) в P1.
• и т.п.

В конце оба клиента отправляют результат на центральный сервер, и если они не согласны, они отправляют контрольные журналы: (S1, C1, m1), (S2, C2, m2) и т. Д. Поскольку каждый игрок подписал свои ходы, они преданы им.

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

NB. Это всего лишь быстрый набросок - я уверен, что если вы опубликуете его на crypto.stackexchange.com, кто-то сделает в нем огромные дыры, - но я думаю, что принцип здравый. Получите любую схему, которую вы разрабатываете, отобранную кем-то, кто знает их, прежде чем вы начнете полагаться на нее.