3
$\begingroup$

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.

Improve this question
$\endgroup$
3
  • $\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
    Commented Apr 29, 2014 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
    Commented Apr 29, 2014 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
    Commented Apr 29, 2014 at 21:12

1 Answer 1

Reset to default
3
$\begingroup$

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.

Improve this answer
$\endgroup$
3
  • $\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
    Commented Apr 29, 2014 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.
    Commented Apr 29, 2014 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.
    Commented Apr 29, 2014 at 22:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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