0

多くの頭痛の種と人々が停止するようアドバイスした後、私は最終的にサーバー/クライアント アプリをこの API で動作させ、必要なキー、つまりセッションと Exchange を作成することができました。

公開鍵をクライアントに送信すると、鍵が正常にインポートされ、その鍵を使用してメッセージも暗号化されますが、サーバーに戻すと; セッションキーを使用してメッセージを復号化しますが、メッセージはガベージとして返されます (うーん.. 秘密キーが必要です!)。これは、暗号化されたメッセージを rpc 経由で返す方法が原因である可能性がありますが、何か別のものであることがわかります。理想的には、私が現在取得している情報はかなり混乱しているため、これらすべてのキーを使用して何をすべきかについての明確でわかりやすい説明が必要です。

メッセージを暗号化し、復号化のために返すことができるように、交換公開鍵をクライアントに渡しますか?

または:

クライアントのセッション キーをサーバーの公開キーで実際に暗号化し、それを返す必要がありますか? (これは私には正しく聞こえませんが、私はすべての耳です!!!)

コメントを残して別の API に移動するか、MSDN から貼り付けをコピーしてください (私は既にすべて読んでいます)。私はCrypto APIを使用していますが、サーバーがクライアントに渡す必要があるキーと、クライアントが何をして何を返すべきかについて明確な説明が必要なだけで、最終的に先に進むことができます...

4

1 に答える 1

2

あなたが本当にそのAPIに固執することを決意しているなら、あなたは正しい軌道に乗っているように聞こえます:)

暗号化には、2 つの異なる暗号化アルゴリズム ファミリがあります。1) 対称鍵を使用するものと 2) 非対称鍵を使用するもの。対称鍵アルゴリズム (AES、DES など) は非常に高速であり、クライアントとサーバーの両方が同じ鍵 (つまり、セッション鍵) を持ち、他の誰もアクセスできないことを確認する安全な方法がある限り、使用する必要があります。その鍵。一方、秘密鍵/公開鍵アルゴリズムとしても知られる非対称鍵アルゴリズム (RSA など) は、計算コストがはるかに高くなります。それらには、データの暗号化にのみ使用できる 1 つのキーと、データの復号化にのみ使用できる 2 つ目のキーがあります。お気づきのように、これらのアルゴリズムは、最初のハンドシェイクとセッション キーの交換に最適です。サーバーは公開鍵と秘密鍵のペアを作成し、クライアントに公開鍵を送信します。誰でも傍受でき、しかし、クライアントがセッション キーをエンコードして送り返す場合、盗聴者がセッション キーを見つけたい場合、pbulic キーは役に立ちません。サーバーは秘密鍵を保持している唯一のエンティティであるため、メッセージをデコードできるのはサーバーだけです。したがって、最初の問題は、メッセージが戻ってきたときに、ペアの秘密鍵を使用する代わりに、同期セッション キーを使用していたため、ガベージが発生していたことでした。

基本的に、SSL が行う基本的なハンドシェイクを実装しただけです (OpenSSL ライブラリを使用する場合は、ほんの数行のコードで簡単に実装できます)。

ハンドシェイクが実行されると、クライアントとサーバーの間に安全なチャネルが確立されます。唯一の問題は、誰かがあなたのサーバーの IP アドレスに便乗して、実際のサーバーであるかのように偽装し始めたらどうするかということです。クライアントは、実際のサーバーと通信していると認識し、鍵交換を行い、安全な情報を送信し始めますが、攻撃者の PC が相手側にある場合、その情報はすべて悪意のある人の手に渡る可能性があります。

ここで、SSL による証明書の使用が登場します。証明書は、公開/秘密キーが使用される別の例です。信頼できる機関は秘密鍵を使用して証明書のハッシュ コードに署名し、証明書の ID データに対して公開鍵を添付して使用することで、証明書が有効であることを誰でも確認できます。これにより、攻撃者がサーバーの IP アドレスを乗っ取ったとしても、サーバーの証明書を偽装することはできません。

于 2011-05-08T06:32:09.457 に答える