2

このトピックについて調査しましたが、私の質問に似たものは見つかりませんでした。ですから、皆さんの何人かが私を助けてくれることを願っています。

2つの個別のクライアント間のアプリケーションのネットワークにAES128暗号化（CFBモード）を使用したいと思います。交換されるデータは、特定の構造のテキスト文字列のみで構成されます。たとえば、最初のバイトは常に受信者に受信するメッセージの種類を通知するため、受信者はそれらを処理できます。AESを使用してメッセージの機密性を確保したいのですが、今度は「整合性」の問題が発生します。

通常、MACの使用を検討します。しかし、受信者がメッセージを正しく復号化できる場合、つまり、文字列の形式が原因でメッセージをアプリケーションで正しく使用できる場合、誰もメッセージを変更していないことが保証されませんか？暗号化されたメッセージをサードパーティによって（1ビットでも）変更すると、復号化中にガベージが発生しませんか？

さらに、アプリケーションがマルチパーティのピアツーピアゲームであり、2人のプレーヤーがプライベートであるがAESで暗号化されたチャネルで相互に通信していると仮定します。現在、メッセージの発信者は公平にプレイしておらず、メッセージがランダムなサードパーティによって変更されたという印象を伝えるために（プレーヤーを強制的に終了させるために）不正な暗号化メッセージを意図的に送信しています。これで、受信者はメッセージが変更されたかどうか、または送信者が不正行為をしたかどうかを判断する機会がなくなります。それで、誠実さはそのような状況ではあまり役に立たず、無視される可能性がありますか？

これは奇妙で世界外の例のように聞こえるかもしれません。しかし、これは私が最近同様のアプリケーションで遭遇したものであり、問​​題の解決策があるかどうか、またはAES暗号化の基本的なアイデアを得たかどうかを自問しています。

4

2 に答える 2

1

あなたが言ったように、あなたは暗号化の後にプレーンテキストメッセージのフォーマットの変化を検出するかもしれません。しかし、どのレベルでうまくいかないでしょうか？テストするのに十分な大きさで冗長なものがありますか？変更されたプレーンテキストの結果、どこかであいまいな例外が発生した場合はどうしますか？CFB（ほとんどのモードと同様）を使用すると、攻撃者は、たとえば、メッセージの最後の部分だけが変更されていることを確認し、最初のブロックをそのままにしておくことができます。

そして、あなたはチートについても心配しています。

私の意見では、MACまたはHMACアルゴリズム、または機密性に加えて整合性/認証を提供する暗号モード（たとえば、EAXまたはGCM）を使用する方がはるかに優れています。他の誰も対称鍵を持っていないことが確実な場合は、認証チェック（MACなど）により、データが正しい鍵で署名されていることが証明されます。したがって、信頼性チェックが成功した場合、ユーザーはトランスポートでデータが変更されたと主張することはできません。

次の質問は次のようになります。対称鍵は他のプレーヤーだけが所有していると信頼できますか？このために、DHなどのキー交換メカニズムと一緒に（非対称キーを使用して）ある種のPKIスキームを使用することをお勧めします。しかし、あなたがそのように行くことにした場合、それは後でです。

于 2011-12-19T01:56:28.970 に答える
0

これは私の深さから少し外れていますが...

はい、AES暗号化メッセージの暗号化されたバイトを変更すると、復号化が失敗するはずです（これはc＃実装での私の経験です）。復号化するクライアントは、メッセージが無効であることを認識します。編集：どうやらこれはそうではありません。メッセージが正常に復号化されたことを確認するには、CRCまたはハッシュが必要なようです。より深刻な問題は、秘密のAESキーが漏洩した場合です（ピアツーピア環境では、受信者がメッセージを完全に復号化できるように、キーを送信する必要があります）。そうすれば、サードパーティは正当なクライアントであるかのようにメッセージを送信でき、OKとして受け入れられます。

誠実さははるかに困難です。どれだけ堅牢にするかは完全にはわかりませんが、公開鍵暗号化を使用したいと思います。これにより、秘密鍵に基づいてメッセージのハッシュ（署名やMACなど）を含めて、メッセージの有効性を主張できます。受信者は公開鍵を使用してハッシュを検証するため、元のメッセージはOKです。AESのような対称暗号化に対する公開鍵暗号化の主な利点は、秘密鍵を送信する必要がなく、公開鍵のみを送信できることです。これにより、クライアントになりすますことがはるかに困難になります。SSL / TLSは公開鍵暗号化を使用します。

いずれにせよ、無効なメッセージを送信しているクライアントを特定すると、そのクライアントを信頼するかどうかを決定することになります。つまり、悪意のある動作（心配していること）による破損ですか？または、クライアントの実装に欠陥がありますか（無能）？または、通信リンクに障害がありますか？そして、これは暗号化（または少なくとも私の知識）がもはやあなたを助けないところです！

整合性に関する追加：

他の誰もあなたの秘密鍵にアクセスできないと仮定した場合、変更を確実に検出するには、CRC、ハッシュ、またはHMACで十分です。メッセージの本文を取得し、CRC、ハッシュなどを計算して、フッターとして追加するだけです。復号化時にハッシュが一致しない場合、メッセージは変更されています。

秘密鍵が秘密のままであるという仮定は非常に合理的です。特に、いくつかのメッセージの後に新しいメッセージを生成する場合。SSHとWiFiのWPAはどちらも定期的に新しいキーを生成します。

秘密鍵が秘密であると想定できない場合は、PKIにアクセスしてメッセージに署名する必要があります。悪意のあるサードパーティのAESキーを使用すると、キーを使用して必要なメッセージを生成するだけです。

RNGに基づいてメッセージにシーケンス番号を含めることには多少のマイレージがあるかもしれません。両方のパーティに同じRNGと同じシードを使用する場合、次に来るシーケンス番号を予測できるはずです。サードパーティは、元のシードを傍受し、有効であるが偽造されたメッセージを送信するために送信されたメッセージの数を知る必要があります。（これは、メッセージが失われたりドロップされたりする可能性がないことを前提としています。）

于 2011-12-18T22:26:19.973 に答える