ハッキングされたサーバーがマスターサーバーになりすますのを防ぐ方法は？

プレイヤーが対戦をホストし、ホスト（つまり、権威のあるサーバー）として機能するルームベースのマルチレイヤーゲームモデルをセットアップしたいと思います。プレイヤーのアイテム、ランク、現金、経験値などを追跡するマスターサーバーをホストしたいと思います。

このようなモデルで、ゲームをホストしている（変更されたサーバーで）誰かが無効な一致結果でマスターサーバーをスプーフィングして、exp、お金、またはランキングを取得することを防ぐにはどうすればよいですか。

ありがとう。-コーディ

私の以前の答えは、あなたが「なりすまし」によって何を意味していたかについての誤解に基づいているかもしれないことが指摘されました。（その場合は、お知らせください。削除します。）

防止したいのがゲームサーバーが偽のデータをマスターサーバーに送信することである場合、Jari Komppaが指摘しているように、完全に防止することは通常不可能です。実際、これは、クライアントが不正行為の疑いがあるサーバーではなく中間サーバーを使用する場合を除いて、単に従来のマルチプレイヤーの不正行為防止問題の変形です。従来の不正行為防止に使用されているものと同じテクニックの多くはここでも機能しますが、いつものように、それらのどれも完全に完全なものではありません。

とはいえ、サーバーの不正行為を防止するために特にできることはいくつかあります。その1つは、試合に参加している各プレーヤーに個別にマスターサーバーに連絡して、その試合に参加していることを確認させることです。（おそらく、試合が始まる前にそうすることをお勧めします。これにより、参加者が誰であるかに誰もが同意し、誰も彼らが負けた試合に参加しなかったと主張したくありません。できます。へのデジタル署名を使用しますただし、基本的には、試合中のすべてのプレーヤーに「私はプレーヤーXであり、サーバーSの試合Mに時間TにプレーヤーY、Z、Wで参加しています。"そして、それを後でマスターサーバーに中継できるゲームサーバーに送信します。）これにより、少なくともそのサーバーで実際にプレイしていないプレーヤーのランキングに不正サーバーが影響を与えないようにすることができます。 。

これは、プレイヤーのランキングが主に相対的なパフォーマンスに依存するEloレーティングのようなものを使用している場合に特に役立ちます。確かに、偽のサーバーを実行している誰かがまだたくさんの偽のアカウントを作成し、自分のアカウントが偽のアカウントを打ち負かしたという結果を提出する可能性がありますが、相対ランキングシステムでは、詐欺師のアカウントを偽物よりわずかに上に配置するだけです（これはロックボトムの評価になります）。

不正行為を防止するためにすべきもう1つの明白なことは、マスターサーバーから直接プレーヤーに対戦結果を確認させることです。プレーヤーが新しいサーバーでの試合に勝ったが、マスターサーバーに送信された結果が、プレーヤーが負けたと言う場合（または結果がまったく送信されない場合）は、何か怪しいことが起こっていることを知らせます。うまくいけば、その時点で彼らはサーバーの不正行為を報告するか、少なくとも自分の足で投票してそのサーバーで再びプレイすることはないでしょう。

実際、これを自動化することもできます。各ゲームの後で、結果がマスターサーバーに送信されたら、クライアントにマスターサーバーから結果をフェッチして戻して、クライアントがゲームが終了したと考える方法と比較します。不一致がある場合は、プレーヤー（何かが間違っていることがわかるようにする）とマスターサーバー（不正なサーバーを検出できるようにする）の両方に報告します。もちろん、マスターサーバーのオペレーターとして、誰が嘘をついているか（サーバーまたはプレーヤー）を判断する必要がありますが、ほとんどの場合、レポートのパターンからそれが明らかであることを願っています。

注：この回答は、質問の誤解に基づいている可能性があります。以下のコメントを参照してください。

短い一般的な答え：デジタル署名を使用します。

具体的には、マスターサーバーには適切なデジタル署名スキーム（RSA、DSA、ECDSAなど）の秘密キーが必要であり、その公開キーを何らかの方法ですべてのクライアントに安全に中継する必要があります。次に、サーバーは、クライアントに送信するすべてのデータに秘密鍵で署名し（または、そのデータを使用して、サーバーとその特定のクライアント間の通信を対称的に暗号化および/または認証するために使用できる共有秘密をネゴシエートします）、クライアントは、公開鍵を使用して署名がサーバーによって生成されたことを確認します。

もちろん、次の問題は公開キーを配布することです。これにより、悪意のあるサーバーがそれを偽装して独自の公開キーを置き換えることができなくなります。事前にできれば（ゲームの実行可能ファイルと一緒にキーを配布するなど）、それほど難しくはないかもしれませんが、後で行う必要がある場合は、たとえば、マスターサーバーのIDが前進。標準的な解決策の1つは、他の公開鍵（対応する秘密鍵はあなただけが知っている）をすべてのクライアントに事前に配布し、マスターサーバーの公開鍵を含むメッセージにその他の鍵で署名してからブロードキャストすることです。

実際、このような署名チェーンをさらに拡張することもできます。たとえば、安全な場所に保管され、すべてのクライアントに公開鍵が知られている1つの超秘密のマスター秘密鍵と、実際にサーバーの鍵に署名するために使用され、その公開鍵自体が金庫に閉じ込められる前に超秘密のマスター鍵で署名されます。これ自体はそれほど有用ではありませんが、危険にさらされたキーを取り消すための何らかのメカニズムも含めると、非常に有用になる可能性があります。たとえば、毎日の使用キーが漏洩した場合、それを取り消して別のキーを生成できます。

上記で説明したのは、初歩的な種類の公開鍵インフラストラクチャです。実際に安全に実装することはかなり複雑になる可能性がありますが、幸いにも以前に行われていました。実際、HTTPSを使用して（ウィキペディアのような）Webサイトに接続するときは常に、これはブラウザーが行うこととほぼ同じです。サーバーから公開鍵証明書を受信し、証明書がURLのサーバー名と一致することを確認します。取り消されたものとしてリストされ、既知の信頼できる認証局によって署名されており、それを使用して一時的な対称暗号鍵をネゴシエートします自分自身と、証明書に対応する秘密鍵の所有者だけが知っています。次に、この対称鍵を使用して、クライアントとサーバー間で送信されるすべてのデータを暗号化および認証します。

特に、実際には既存のSSL / TLSライブラリ（通常はX.509 PKI実装に付属しています）、または場合によってはSPKIを確認する必要があります。これらはまだやや複雑ですが、独自のものをロールするよりもおそらく簡単です（そしてより安全です）。

これは、ゲームの性質と、サーバーの役割をオフロードする理由によって異なります。

特定の状況では、暗号化監査ログでこれをほぼ達成できる場合があります。たとえば、それが2プレーヤーのターンベースのゲームであり、署名の目的で各クライアントが秘密の非対称キーを持つように手配できる場合、次のプロトコルを使用できます。

• 初期状態S0には、ゲームの一意の識別子（リプレイアタックを防止するため）が含まれ、それ以外は一定であると見なされます。ランダムな要素がある場合は、中央サーバーによって生成され、将来の比較のためにそこにキャッシュされる必要があります。
• P1はm1を移動します。結果の状態S1に署名し、署名C1を生成します。そして、それを彼の移動（S1、C1、m1）とともにP2に送ります。
• P2はm2を移動します。結果の状態S2に署名し、署名C2を生成します。そしてそれを彼の移動（S2、C2、m2）とともにP1に送ります。
• 等

最後に、両方のクライアントが結果を中央サーバーに送信し、同意しない場合は、（S1、C1、m1）、（S2、C2、m2）などの監査証跡を送信します。各プレーヤーが自分の移動に署名しているため、彼らは彼らにコミットしています。

それでも、一方のプレーヤーが他方のDDOSを実行して結果を送信できないようにする脆弱性はありますが、それについてできることは実際にはあまりありません。

注：これは簡単なスケッチです。crypto.stackexchange.comに投稿すると、誰かが巨大な穴をあけることになると思いますが、原則は正しいと思います。設計を検討する前に、設計を理解している人が設計を検討する前に、スキームを確認してください。