c# - SSLStreamなしの暗号化された接続？

Question

送受信されるデータ、クライアント<>サーバー、およびその逆を暗号化する必要があります。

現在SSLStreamを使用できないため、他の代替手段を探しています。

私が持っている代替案について考えている間、私はデータを読み取ったり傍受したりできない方法でクライアントにデータを送信する方法に行き詰まりました。

これが私がそれをすることをどのように考えたかです：

経験豊富な人々から、私がここで必要としていることを行うためのいくつかの新しいアイデアやより良い方法を聞きたいと思います。

SSLStreamを使用せずに、クライアントからサーバーに、またはその逆に暗号化されたデータを送信しますが、十分なレベルのセキュリティを備えています。

クライアントに秘密鍵を持っていることはリスクがあることを理解していますが、まだより良い解決策を見つけることができていません。

score 1 · Accepted Answer

本当にSSLを使用できない場合は、貧乏人のSSLを自分で作成できます。

クライアントはRSA公開鍵を知っており、サーバーは対応する秘密鍵を知っています。

クライアントと通信するために、AESで使用できるランダムなセッションキーを作成します。RSA公開鍵で暗号化し、サーバーに送信します。残りの通信をAESセッションキーで暗号化します。

サーバーはRSA秘密鍵を使用して最初のメッセージを復号化し、セッション鍵を取得します。残りの通信にはこのキーを使用します。

そうすれば、クライアントには秘密は含まれませんが、通信自体はプライベートになります。このスキームに欠けている主なものは、クライアント認証です。

また、サーバー->クライアントとクライアント->サーバーストリームに異なるナンス/IVを使用する必要があります。整合性チェック（MAC）を追加することもできます。

score 0 · Accepted Answer

これを行う唯一の方法は、共有シークレットを使用することです。クライアントとサーバーの両方が知っていることですが、他の誰も知りません。

公開鍵SSLは、証明書（したがって鍵ペア）が特定のサーバー/ドメインにロックされていることを前提として機能します。このサーバー/ドメインは、サードパーティ（署名機関）を介して個別に確認できます。

この前提を取り除くとすぐに、誰と話しているのかを保証できないため（または、少なくとも誰かがメッセージを傍受/中継していないことを保証できないため、公開鍵暗号化による中間者攻撃にさらされる可能性があります。）。

共有シークレットを使用する場合は、公開鍵や証明書などは必要ありませんが、許可されていない第三者があなたのシークレットを発見した場合、あなたは困惑します。

score 0 · Accepted Answer

考えられるアプローチ：

-サーバーには、よく知られている公開鍵と、誰も知らない（クライアントでさえも）秘密鍵があります。

-クライアントは「ハンドシェイク」パケットを生成し、サーバーの公開鍵で暗号化します。ハンドシェイクパケットには、必要な初期化/認証関連のものに加えて、AES暗号化に使用するためにランダムに生成されたパスフレーズ+IVが含まれています。

-サーバーは秘密鍵を使用してハンドシェイクパケットを復号化し、AESパスフレーズ+IVにアクセスできるようになりました。準備ができたことを示す「ACK」パケットで応答します。

-クライアントはAESパスフレーズを使用してデータを送信し、対称的に暗号化できるようになりました。サーバーは復号化でき、その逆も可能です。

クライアントに秘密鍵がバンドルされている必要はありません。RSAは、共有キーを必要としないデータ交換用に特別に設計されています。

3 に答える 3