このシナリオは安全ですか？

Question

RSAを使用して、サーバーとクライアント間の通信を暗号化します。 キー1とキー2の2つの非対称キーがあるとしましょう。

サーバーには最初からkey1（プライベート）があり、クライアントにはkey1（public）があります

これがシナリオです：

1. クライアントがkey2を生成します
2. クライアントはサーバーに接続します
3. key1（public）で暗号化されたkey2（public）を送信
4. これ以降、サーバーはkey2（public）で暗号化されたすべてのデータを送信します
5. クライアントはランダムなデータをサーバーに送信します
6. サーバーはハッシュされた同じデータを送り返します
7. クライアントはデータが正しいことを確認します

これを見る限り、中間者攻撃を防ぐことができますか、それとも何か不足していますか？ ポイント7で、クライアントは誰かがサーバーに暗号化するための間違ったキーを与えようとしているかどうかを知る必要があります。

セキュリティを改善するためにできることがあれば、教えてください。

Answer 1

セキュリティを改善するためにできる最善の方法は、既存の設計を使用し、車輪の再発明を試みないことです。私があなたがしたことは必ずしも間違っていると言っているのではありませんが、あなたと私よりずっと賢い多くの人々がこの問題について考えるのに多くの時間を費やしているだけです。代わりにTLSを使用してください。

Answer 2

key1（プライベート）がサードパーティによって何らかの方法でインターセプトされていない限り、シナリオは安全に見えます。

実際に論文のどこかで見たと思う。その中で、アリスはボブにロック解除されたボックス（キー1パブリック）を渡し、ボブは彼自身のボックス（キー2パブリック）をたくさん入れてロックし、アリスに送り返します。その後、アリスはボックスを開き（キー1プライベート）、ボブがちょうど与えたボックスを安全に封印できるようになりました。

ボックスの類推にもかかわらず、それは基本的にあなたがしていることなので、安全だと思います。

Answer 3

同意します。TLSを使用します。

また、ステップ5から7はどのような価値をもたらしますか？ステップ1から4の後に機能する攻撃を実行するMITM（たとえば、nトランザクションを通過して停止し、最初からリトライを強制することによる何らかのDoS）は、5から7の後にも同様に実行できます。彼らは何を追加しますか？

-MarkusQ

Answer 4

いいえ、このプロトコルは安全ではありません。

サーバーがクライアントを認証したり、メッセージの整合性を検証したりするメカニズムを指定していないため、man-in-the-middleはクライアントから送信されたデータをインターセプトして、サーバーに必要なものを送信できます受け取ります。

もちろん、これらの明白な問題を修正するためにプロトコルを修正することもできますが、他にもあります。それらをすべて修正した場合、TLSまたはSSHにマップするものがあるので、なぜそこから始めないのですか？

---

@ Petoj＆＃8212;私が注目していた問題は、受信したメッセージを信頼するサーバーの問題でした。あなたの提案はそこでセキュリティを提供していません。ただし、機密性が心配な場合は、クライアントメッセージにプライバシーがないため、MITMが探したいものを見つけるまでメッセージを変更せずにやり取りする可能性があるため、依然として問題があります。

あなたの提案は、クライアントからのメッセージの整合性を確保することを目的としているようです。クライアントが攻撃とネットワーク障害を区別できないポイントまでプロトコルを開発しました。サーバーが改ざんされたメッセージに作用したかどうかをクライアントが判断するのを助けるのではなく、サーバーがメッセージに作用する前にメッセージの整合性を検証できるようにします。

Answer 5

あなたは車輪を再発明しているということにグレッグに同意します。基本的に説明しているのは、キー交換の基本的な形式です。ちなみに、中間者攻撃に対して安全であることを保証するために、サーバーの身元を確認する必要があります。つまり、クライアントがパブリック（key1）であると信じるものが確実にわかるようにする必要があります中間者ではなくサーバー（たとえば、CAを使用するか、クライアント側の安全なストレージにサーバーのpublic（key1）を保持します。）

さらに、次のようなシステムの観点から注意する必要がある追加の考慮事項があります。

• 非対称キー暗号化は対称キー暗号化よりも遅い。これが TLS は、一時的な対称キーをネゴシエートするためにのみ非対称キー暗号化を使用し、その後、チャネル暗号化に使用されます。
• サードパーティによるトラフィック分析が一時的な対称キーのクラッキングに成功した場合、非対称キーペアを侵害していません。この理由により、比較的頻繁に一時キーの再ネゴシエーションを奨励されます。おそらく、シナリオで新しい key2 を生成すると、この側面が緩和されます。