views:

90

answers:

3

I'm looking for a key exchange solution between a .NET app and an embedded device. The two endpoints have a shared secret key, making the Elliptic Curve Diffie-Hellman (ECDH) algorithm excellent for securely exchanging a master secret for the session.

There is a good C++ library, crypto++, which implements ECDH and is suitable for the embedded device. However, its implementation of ECDH differs from Mirosoft's ECDiffieHellmanCng implementation (as alluded to in its FAQ). We'd like to stay compatible with .NET security algorithms so that we can stick with managed code for the PC app (now, or if we use CNG, when we drop XP someday).

Has anyone seen an implementation besides Microsoft's that is compatible with Microsoft's? Alternatively, are there other good key exchange solutions between .NET code and embedded C++ code for use with pre-shared keys?

Update 2010-01-27: To clarify, I'm trying to use ECDH to perform both two-way authentication and key exchange between two ad-hock endpoints that don't trust each other until they see that they share the same secret. This is similar to the Bluetooth pairing scenario where the shared secret is exchanged out of band (except in my case the devices might not be near each other).

A: 

OpensSSL has port to Visual Studio

Dewfy
My first choice is to use what's already in the .NET Framework, which is why I'm focusing on interoperability, not just portability.
Edward Brey
+1  A: 

For interoperability you are better off with using RSA. You won't find many free implementations of ECC due to the patent minefield.

How about having one side generate a random key, encrypt it with the other side's public key and sign it with its own private key. Then the other side can verify the signature and decrypt the shared key.

If you worry about replay attacks (note that the ECDH-scheme you were planning on using did not protect against those - unless you were planning on using ephemeral keys), you can have both sides generate a random key, encrypt it with the other side's public key, and then combine the two keys in some way.

Even better would probably be to use some standard protocol: consider TLS with client certificate validation. You can hardcode client and server certificates.

Rasmus Faber
The ECDH scheme prevents replay attacks by incorporating new random material for each master secret exchange. In .NET, the ECDiffieHellmanCng constructor generates the random number.I like your RSA idea, but there is the question of how to authenticate (sorry I probably wasn't clear enough about that). Both sides have a shared secret, but neither trusts the other to not be an impostor.I believe certificate-based authentication would be impractical, since there could be thousands of unique instances of both sides, which are untrusted except for having the shared secret.
Edward Brey
+1  A: 

Nothing in the FAQ you have cited references the CNG implementation one way or the other. I think the statements in the FAQ are generally true, especially the patent situation. However, there are some standards, and in particular the U.S. NIST has published some standards. See for example Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography.

GregS