私は iPhone 用のゲームに取り組んでおり、サーバーにスコアを送信できるようにしたいと考えています。簡単ですが、スコアが実際にゲームプレイから得られることを確認したいと思います。輸出条件付きの実際の暗号の (事実上の) 禁止により、安全な/検証済みのチャネルで情報を取り戻すための最良の方法は何でしょうか?
私の考えはすべてRSAスタイルのデジタル署名アルゴリズムに戻りますが、そのエクスポートの問題を解決するには、「暗号化」の少ないアルゴリズムを好むでしょう.
ありがとう!
長い話を非常に短くするために、デジタル署名コードはほとんど制限なくエクスポートできます。詳細については、BIS 輸出に関する FAQ をご覧ください。
おそらく、デジタル署名の免除をカバーするEAR 742.15(b)3を見たいと思うでしょう。
もちろん、私は弁護士ではありません。ルールは昨年変更された可能性があります。
クライアント証明書 (署名済み) を使用して、サーバーへの HTTPS 接続を確立できませんでしたか? サーバーは、署名済みのクライアント証明書で開始された接続のみを受け入れるように構成されています。
実際の暗号を使用しても、実際には何も購入できません。基本的に、典型的な DRM 問題の逆です。その場合、人々がコンテンツを解読できないようにしたいのですが、視聴するには解読する必要があるため、とにかくキーを与える必要があります。
あなたの場合、人々が偽のスコアに署名するのを防ぎたいのですが、実際のスコアに署名できる必要があるため、とにかくキーを渡す必要があります。
あなたがする必要があるのは、潜在的な報酬よりもクラックするためにあなたのスキームがより多くの努力を必要とすることを確認することです. ゲームのリーダー ボードについて話しているので、賭け金はそれほど高くありません。tcpdump を使用している人がすぐに理解できないようにします。サーバーが「実験」 (1 つのソースからの多数の失敗した送信) を検出できるほどスマートである場合、暗号化アルゴリズムに依存するよりも安全です。
十分かもしれない1つのアイデア:
それで:
アプリがサーバーと初めて通信するときに、DevicePasswordを要求します。iPhoneが送信するもの:DeviceID、Hash(DeviceID + Secret1)
サーバーはSecret1を使用して、リクエストがアプリから送信されたことを確認します。その場合、DevicePasswordが生成され、DeviceIDとDevicePasswordの間の関連付けがサーバーに保存されます。
サーバーの応答:DevicePassword、Hash(DevicePassword + Secret2)
アプリはSecret2を使用して、パスワードがサーバーからのものであることを確認します。もしそうなら、それはそれを保存します。
スコアを送信するために、iPhoneはDeviceID、Score、Hash(Score + DevicePassword + Secret3)を送信します
サーバーは、Secret3とDevicePasswordを使用して検証します。
DevicePasswordの利点は、各デバイスが事実上一意のシークレットを持っていることです。私が知らなかった場合、送信されたスコアをパケットスニッフィングしてシークレットを判別するのが難しくなります。
また、通常の場合、アプリはインストールごとに1回だけDevicePasswordを要求する必要があるため、DevicePasswordの疑わしい要求を簡単に特定したり、1日1回に制限したりできます。
免責事項:このソリューションは頭から離れているため、このスキームに大きな欠陥がないことを保証することはできません。
ランダムな、かなり長いものを生成し、スコアを最後に追加し、おそらく名前またはその他の静的なものを追加し、sha1 / md5で両方をサーバーに渡し、ランダムハッシュがハッシュと等しいことを確認します.
後付け: 逆エンジニアをより困難にしたい場合は、ランダムにその日の数値表現 (月曜日 = 1、火曜日 = 2、...) を掛けます。