2

私はクライアントサーバーゲームを持っています。クライアントはサーバーに接続し、ゲーム中(約5〜60分)接続を維持します。

新しいクライアントが安全に登録できるようにし、既存のクライアントがログイン資格情報が公開されることを心配せずに認証できるようにしたい。

重要なのは、パフォーマンス上の理由から、ゲームセッションではRC4のような単純で安価な暗号化を使用するのが最善ですが、対称鍵では登録手順を簡単に保護することはできません。

とにかく別のログインサーバーを保持したいので、私の考えは次のようになります。

  1. クライアントは、資格情報(または登録情報)を使用してHTTPS要求をログインサーバーに送信します
  2. ログインサーバーはユーザー情報を収集し、一時的なRC4セッション暗号化キーを生成します
  3. ゲームサーバーとログインサーバー間で共有される秘密対称鍵を使用したユーザー情報+RC4セッション+タイムスタンプ+ダイジェスト(両方のサーバーが時間的に同期されることを信頼できます)。
  4. パッケージ化されたデータ+RC4セッション暗号化キー+ゲームサーバーへのIPアドレスは、クライアントへのHTTPS要求への応答として送信されます。
  5. クライアントはゲームサーバーへの接続を開き、暗号化されたユーザー情報をペイロードとして含む最初の暗号化されていないhelloメッセージを送信します。
  6. ゲームサーバーは、(3)でパッケージ化されたデータを解凍します。これで、ユーザーと、使用することになっているRC4暗号化キーがわかります。
  7. タイムスタンプがログイン資格情報の有効期限が切れていることを示している場合、エラーがクライアントに返されます(クライアントは新しい情報を取得します)。復号化されたユーザーデータをダイジェストで検証できない場合は、別のエラーが返されます。
  8. すべてが正常にチェックされると、サーバーは暗号化されていないLOGIN_OKを送信し、RC4暗号化通信が開始されます。

考えられるセキュリティ上の懸念:

  • ゲームサーバーは、復号化したユーザー情報を100%信頼します。これにより、サーバーが完全に分離されます。これはすばらしいことですが、キーが危険にさらされた場合、ユーザーはユーザー情報を完全に偽造する可能性があります。これらのキーをローテーションすることで、これをいくらか軽減できるため、毎日または毎月新しいキーを使用できます。ゲームサーバーとログインサーバーの両方が、キーを管理する3番目のサーバーからこれを取得できます。次の理由から、やり過ぎかもしれません:a)サーバーにソースコードが公開されている侵入の場合、新しいキーで再起動できますb)十分なキー+暗号化により、ブルートフォース攻撃が困難になります(アルゴリズムに関する提案?)

  • RC4は最も安全なアルゴリズムではありませんが、最初の512バイト程度を破棄するようにしており、各キーは限られた時間、たとえば24時間のみ有効です。

  • 私が見る限り、中間者の影響を受けにくいようです。SSLはRC4セッションキーを保護します。(5)ゲームサーバーに送信されるRC4セッションキーも暗号化されます。可能なのはDoSであり、ユーザーにキーを再度要求させることです。(2)のデータが期限切れになるまでキャッシュされている場合、これによって新しいパケットが作成されることはありません。

  • (3)の暗号化は、キーにランダムビットを追加することで改善できます。これらのランダムビットは暗号化されたパケットと一緒に送信され、(5)でゲームサーバーに提示されます。(6)では、ゲームサーバーはそれらのランダムなビットをキーに追加し、その結果を使用してデータを復号化します。このようにすると、攻撃者はパックされたデータがいつ変更されたかを確認できません。

ここで見落としている脆弱性はありますか?

作成されたペイロードの要約:

  • クライアントのログインクレデンシャル(SSLで保護)、ログインサーバーに送信
  • ユーザー情報+タイムスタンプ+一時的なゲームサーバーセッションキー+ゲームサーバーと共有される秘密キーを使用してログインサーバーによって暗号化されたダイジェスト。クライアントに渡され、変更せずにゲームサーバーに渡されます。a)クライアントが秘密鍵を知らないb)同じデータの再送信を回避するためのタイムスタンプがあるc)コンテンツが正しく暗号化されていることを確認するためのダイジェスト
  • ログインサーバーからクライアントに暗号化されたペイロードとともに送信される一時的なゲームサーバーセッションキー。SSLで保護されています。
  • クライアントゲームサーバーのログインパケット。ログインサーバーが受信した暗号化されたパケットで構成されます。

暗号化キーの概要:

  • 一時的なゲームサーバーセッションキー:暗号化されたゲームサーバー<->クライアント通信のためにログインサーバーによってランダムに生成されます。ログインサーバーによって生成され、クライアントとゲームサーバーに渡されます。
  • 秘密のユーザー情報暗号化キー。ゲームサーバーとログインサーバー間で共有され、クライアントをメッセンジャーとしてゲームサーバーにユーザー情報を渡すために使用されます。クライアントはこのキーを所有していません。
4

5 に答える 5

2

SSLを再発明しようとしているようです。各クライアントに証明書(独自のルート機関によって署名されたもの)を発行し、相互認証を使用してSSL経由でゲームサーバーに接続してみませんか?

于 2011-02-17T03:26:25.523 に答える
2

まず第一に、私はRC4を使用しません。より高速でより安全なストリーム暗号が存在するため、クライアントとサーバーの両方を制御する場合は、おそらくRC4よりも優れた方法を実行できます。Fluhrer、Mantin、Shamirの攻撃では、512バイトだけを破棄するだけでは不十分な場合がありますが、さらにバイトを破棄しても、Kleinの攻撃などがあります。問題が発生する価値があるかどうかはわかりません。

次に、生成するキーがランダムであることを確認します。当たり前のように思えますが、例についてはhttp://www.debian.org/security/2008/dsa-1571を参照してください。

しかし、本当の問題はこの部分です。「ゲームサーバーは復号化したユーザー情報を100%信頼します。これにより、サーバーは完全に分離されます。これは素晴らしいことですが、キーが危険にさらされた場合、ユーザーはユーザー情報を完全に偽造する可能性があります。」

ユーザーがキーを知っていると想定する必要があります。彼のゲームクライアントは、サーバーと通信できるようにキーを知っている必要があります。ユーザーが実際のデータを使用してssl経由でログインし、ストリーム暗号のキーを取得してから、必要な情報をゲームサーバーに送信できる場合、攻撃者はアカウントを取得して必要な操作を行うだけです。

キーを変更するたびにクライアントに渡す必要があるため、キーを変更する頻度は重要ではありません。したがって、バイトごとにキーを変更することもできますが、ここでは重要ではありません。

これは、使用する暗号やキーの生成よりも重要です。キーを取得しただけでは、誰もキーをブルートフォースすることはないからです。

クライアントを決して信用してはいけません。クライアントデータをサーバー側に保存してキーと照合するか、データに署名して検証するか、HMACなどを使用する必要があります。ゲームサーバーがユーザー情報を100%信頼している場合は、すぐに問題が発生するためです。それを回避する方法はほとんどありません。

于 2011-02-16T12:45:22.467 に答える
1

ハンドシェイクを再度実行したくないため、ゲームサーバーとクライアント間でSSLを使用できないことを理解しています。

プロトコルは一見問題ないようです。意味のあることを行うには対称セッションキーが本当に必要なので、リプレイ攻撃もありません。あなたができる最善のことは、AESへの切り替えも非常に高速で非常に安全です。AESに切り替えることでパフォーマンスが低下することはないと思います。

また、あなたが言及した最初のセキュリティ問題の箇条書きは、実際には問題ではありません。デスクトップ上のすべてのクライアントにとって問題です。たとえば、ブラウザでHTTPSを介して通信する場合に同じ問題が発生します。したがって、実際に解決する必要はありません。操作の試みを積極的に監視したい場合、ゲームロジックはどういうわけか悪い動作を探す必要があります。キーを再入力しても解決できません。

于 2011-02-17T20:23:41.190 に答える
1

私はsci.cryptにも投稿することになりました。興味があるかもしれない場合に備えて、提案された変更を(私が理解している限り)以下に要約しようと思います。

ステップ1:クライアントは、資格情報を使用してHTTPS要求をログインサーバーに送信します

資格情報がログイントークンの形式をとると仮定して、自己割り当ての一意のIDも追加します。

ステップ3:ユーザー情報+RC4セッション+タイムスタンプ+ダイジェスト

ダイジェストを明示的に使用する代わりに、整合性を保証する暗号化アルゴリズムを使用してください。例:AES-GCMまたはAES-CCM。手順1で追加のidフィールドを追加します。ゲームサーバーにもIPを追加します。

ステップ4:パッケージ化されたデータ+RC4セッション暗号化キー+ゲームサーバーへのIPアドレスが応答として送信されます。

クライアントにタイムスタンプを与えると、クライアントはセッションの有効期限が切れたことを知ることができます。これにより、期限切れのクレデンシャルを使用したゲームサーバーへの不要な接続が回避されます。

ステップ5:クライアントはゲームサーバーへの接続を開き、暗号化されたユーザー情報をペイロードとして含む最初の暗号化されていないhelloメッセージを送信します。

手順1で自己割り当てIDを暗号化せずにペイロードに追加します。

ステップ6:ゲームサーバーは(3)でパッケージ化されたデータを解凍します。これで、ユーザーと、使用することになっているRC4暗号化キーがわかります。

ゲームサーバーは、自身のIPと暗号化されたIPの両方、および暗号化されたIDとクライアントから指定されたIDの両方を照合します。1つ目は、ユーザーが同じ資格情報を持つ別のサーバーにアクセスできないようにします。

ステップ8:すべてが正常にチェックされると、サーバーは暗号化されていないLOGIN_OKを送信し、RC4暗号化通信が開始されます。

この時点で、ゲームサーバーはクライアントのIDを確認できません。セッションキーを使用し、ナンス+厳密に増加するセッションID+ログイン成功状態をAES-GCM/ CCMを使用して暗号化し、クライアントに送信します。

クライアントは、ログインの成功状態を復号化してチェックします。これが当てはまる場合、クライアントはゲームサーバーがセッションキーを知っていることを知っています(GCM / CCMはパケットが改ざんされていないことを確認します)。クライアントはsid+nonceを返します。

サーバーは、sid+nonceが送信された値と同じであることを確認します。

最後に、クライアントとサーバーは、セッションキーをsid + nonce + saltでハッシュして、結果として生じる通信用のキーを作成し、リプレイ攻撃の可能性を防ぐことによって、新しいセッションキーを作成します。

RC4について

RC4には脆弱性がありますが、キーの再スケジュールがかなり積極的であるため、このスキームにはおそらく十分です。ただし、Snow 2.0やTriviumなど、より安全で高速な最新の暗号があります。

于 2011-02-25T11:54:19.783 に答える
0

ゲームサーバーにSSLを使用するだけです。最新の暗号解読は、いくつかのより優れた暗号化アルゴリズムのいくつかの非常に高速な実装をもたらしました。たとえば、適切に最適化されたAES実装は、リモートの最新のマシンで150MB/秒を超える速度で簡単に暗号化できます。また、AESは高く評価されていますが、私が知っている2つの弱点がありますが、正しく使用すると、これらの弱点は重要ではなくなります。

クライアントとゲームサーバーの間で高度な鍵スケジュールアルゴリズムを使用することに言及しなかったことに気づきました。そうしないと、暗号化アルゴリズムの弱点がさらに深刻になります。SSL/TLSが鍵スケジュールを実行する必要があります。

于 2011-02-17T06:11:15.637 に答える