2

.NET アプリと組み込みデバイス間のキー交換ソリューションを探しています。2 つのエンドポイントには共有の秘密鍵があるため、楕円曲線 Diffie-Hellman (ECDH) アルゴリズムは、セッションのマスター シークレットを安全に交換するのに優れています。

ECDH を実装し、組み込みデバイスに適した優れた C++ ライブラリcrypto++があります。ただし、ECDH の実装は、Mirosoft のECDiffieHellmanCng実装とは異なります ( FAQで言及されています)。.NET セキュリティ アルゴリズムとの互換性を維持して、PC アプリのマネージド コードを使い続けることができるようにしたいと考えています (現在、または CNG を使用している場合は、いつか XP を廃止するとき)。

Microsoft と互換性のある Microsoft 以外の実装を見た人はいますか? または、.NET コードと埋め込み C++ コードの間で事前共有キーを使用するための優れたキー交換ソリューションは他にありますか?

更新 2010-01-27: 明確にするために、ECDH を使用して、2 つのアドホック エンドポイント間で双方向認証とキー交換の両方を実行しようとしています。これらのエンドポイントは、同じ秘密を共有していることを確認するまで、お互いを信頼しません。これは、共有シークレットが帯域外で交換される Bluetooth ペアリングのシナリオに似ています (ただし、私の場合、デバイスが互いに近くにない可能性があります)。

4

3 に答える 3

1

相互運用性のためには、RSA を使用したほうがよいでしょう。特許地雷原のため、ECC の無料の実装は多くありません。

一方がランダムな鍵を生成し、もう一方の公開鍵で暗号化し、独自の秘密鍵で署名するのはどうですか。次に、反対側で署名を検証し、共有キーを復号化できます。

リプレイ攻撃が心配な場合 (使用を計画していた ECDH スキームではそれらを防御できないことに注意してください - 一時的なキーを使用する予定がない限り)、両側でランダムなキーを生成し、反対側の暗号化で暗号化することができます。公開鍵を作成し、2 つの鍵を何らかの方法で結合します。

おそらく、いくつかの標準プロトコルを使用することをお勧めします。クライアント証明書の検証で TLS を検討してください。クライアント証明書とサーバー証明書をハードコーディングできます。

于 2010-01-25T22:00:45.310 に答える
1

あなたが引用したFAQには、CNGの実装を何らかの方法で参照しているものはありません。FAQ の記述、特に特許の状況は概ね正しいと思います。ただし、いくつかの標準があり、特に米国 NIST がいくつかの標準を公開しています。たとえば、離散対数暗号を使用したペアワイズ キー確立スキームの推奨事項を参照してください。

于 2010-01-26T00:02:11.557 に答える
0

OpensSSL には Visual Studio へのポートがあります

于 2010-01-25T16:15:05.283 に答える