I'm currently working on a project where I want to establish a secure and authenticated communication channel between to entities, using Elliptic Curve Cryptography. Now I'm not really sure how to proceed after the key exchange. The current exchange looks like this:

  • $Alice$ sends her public key $K_A$ to $Bob$
  • $Bob$ sends back his public key and a signature, containing both public keys and her identity: $K_B, Sig_b(K_B, K_A, A)$
  • $Alice$ replies similarly with her signature: $Sig_a(K_A, K_B, B)$

As I see it, this authenticates Bob to Alice in a way that he now encrypts a message with Alice's public key and can sure that Alice is the correct recipient. So here are my assumptions at this point:

  1. This does not guarantee to Alice that Bob is indeed the sender.
  2. Therefore Bob would need to either sign every message to Alice, or use a shared secret.

Am I correct about that?

If so, then would there be any benefit in signing every message over generating a shared secret from the keys? I assume that a combination of ECIES and ECDSA is far more expensive than simply running AES. Since I'm working with very resource constrained devices, I'd like to keep the overhead as small as possible. Although I probably should use random padding and a KDF to increase the security in the AES scenario.

  • $\begingroup$ How does Alice know that $K_B$ is indeed Bob's and not Bryan's? Is Bob's identity contained in the public key? If so, who certified that Bob is indeed Bob? $\endgroup$ – mikeazo Apr 29 '14 at 19:59
  • $\begingroup$ Unless this is for fun or homework, the right approach is to use standard protocols/approaches. For example, you could use OpenSSL to establish a secure and authenticated communication channel between two parties (you can even use elliptic curves). $\endgroup$ – mikeazo Apr 29 '14 at 20:02
  • $\begingroup$ @mikeazo Well, it is a fun / research project, nothing that will be used in a production system. I was starting with the Basic Station-To-Station Protocol, which should provide "mutual key and entity authentication". There is indeed no guarantee about the real identity of Bob, but I had to start somewhere. $\endgroup$ – Nariox Apr 29 '14 at 21:12

ECDH or DH for that matter doesn't provide any authentication of a user. ECDSA as a public key scheme does provide authentication, but lacks validation. You need to certify that the exchanged public keys are indeed from Alice or Bob. So Alice and Bob must let an authority certify their own public keys such that Alice trusts the authority of Bob and Bob trusts the authority of Alice. The authorities might in fact be the same authority. You can call it certificate authority.

A possible attack might be a man-in-the-middle attack where

  1. Alice sends $K_A$ to Bob, but Martin intercepts $K_A$ and sends a newly generated key $K_{MA}$ to Bob
  2. Bob sends back his public key and a signature, containing both public keys and her identity: $K_B,Sig_B(K_B,K_A,A)$, but Martin intercepts it and sends a newly generated key $K_{MB}$ and re-signs with its private key $Sig_{MB}(K_{MB},K_A,A)$
  3. Alice replies similarly with her signature: $Sig_A(K_A,K_B,B)$, but Martin intercepts it and re-signs $Sig_{MA}(K_{MA},K_B,B)$ with the private key $MA$ from #1.

This is applicable to ECDH and ECDSA.

  • $\begingroup$ I see your point. But what if I don't have a certificate authority? I'm starting with a simple setting: one data collector who is periodically sending data to a receiver. All I want to achieve is to keep this connection secure. $\endgroup$ – Nariox Apr 29 '14 at 21:26
  • $\begingroup$ Can you distribute the keys beforehand yourself? If you can, then you could hard-code the public keys or establish symmetric key between A and B, but then you run into revocation problems. $\endgroup$ – Artjom B. Apr 29 '14 at 22:11
  • $\begingroup$ It will probably best to create your own certificate authority and hard-code its key into Alice and Bob. When you create Alice and Bob-like clients, you can certify them and let the certificate chain be checked by Bob when he receives the key from Alice and the other way around. But it all depends on how you create your clients. You could also have a central client C whose public key is embedded in Alice and Bob. C will then distribute the public keys. $\endgroup$ – Artjom B. Apr 29 '14 at 22:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.