1
$\begingroup$

I have to find a solution to this problem: I have a network composed by 1 server and some client. The server has a couple of keys (public and private) and it shares a secret key with each client. My goal is to exchange a session key between the server and the clients.

I've evaluated some solutions, but I am unsure if my reasoning is correct.

I started thinking about DH, looking for a solution making it secure. And then I realised that maybe the client could randomly generate the session key and then it could send the key to the server in a secure way. In particular, my “secure way” consists in calculating the MAC of the session key using the shared secret key between client and server, and then encrypting $(MAC || session key)$ with the server's public key. In my opinion this “protocol” provides confidentiality, integrity and a sort of authentication using the secret shared key.

To conclude the protocol the server should send an ACK if the exchange has worked.

To recap:

Client:

  • generate $k$ // random session key
  • $t \leftarrow M(k,s)$ // calculate MAC using s(shared secret key)
  • $c \leftarrow E(es , k||t)$ // Encrypt $k||t$ using server's public key
  • Send $c$

Server:

  • $k||t \leftarrow D(ds , c)$ // Decrypt c using server's private key
  • $t´ \leftarrow M(k,s)$
  • $(t == t´)$ ? OK : ERR

I'd like to know if my reasoning is correct.

$\endgroup$
  • $\begingroup$ What do you mean with "and it share a secret key with each client"? $\endgroup$ – Maarten Bodewes Jun 18 '15 at 17:28
  • $\begingroup$ Each client has a secret password shared with the server. Thus, the server has a table containing a password for each client. This is an information that I can use for my protocol, I have not to consider how client and server exchange this password, I have this additional information to create my protocol. $\endgroup$ – Jon_Snow Jun 18 '15 at 22:18
  • $\begingroup$ So you could also use the same authentication protocol as a TLS handshake with PSK (pre-shared key) for authentication on top of the other ones... $\endgroup$ – Maarten Bodewes Jun 18 '15 at 22:21
  • $\begingroup$ TLS handshake is very similar to my idea, the difference is that in my project I can ( or I must, i don't know yet) avoid certificates. So, I can use TLS handshake, but the problem is to guarantee the authentication. I think that the solution is using the secret key to authenticate the client. Can this solution has a little sense? $\endgroup$ – Jon_Snow Jun 18 '15 at 22:35
  • $\begingroup$ From wikipedia: "Pre-shared keys may be more convenient from a key management point of view. For instance, in closed environments where the connections are mostly configured manually in advance, it may be easier to configure a PSK than to use certificates. Another case is when the parties already have a mechanism for setting up a shared secret key, and that mechanism could be used to “bootstrap” a key for authenticating a TLS connection." $\endgroup$ – Maarten Bodewes Jun 19 '15 at 0:27
1
$\begingroup$

This is basically the difference between e.g. the RSA_ ciphersuites and the DHE_/ECDHE_ ciphersuites in the TLS protocols. Currently the standardization moves towards ECDHE_ because it provides forward secrecy: even if you factor the RSA key you can still not decrypt previous transmissions.

Note that you don't have to MAC the session key before encryption with the RSA public key. You do however need to MAC your ACK with the session key so the client can verify the that you both have calculated the same session keys.

I'm saying keys because you should try and create at least session keys for sending and receiving. In addition you could create keys for session encryption, session authentication and possibly even the initial authentication, depending on the rest of the protocol.


You can forget all the text above if you study TLS, or if you use (D)TLS in favor over your own protocol of course. No need to climb an ice wall, somebody already dug a tunnel.

$\endgroup$
  • $\begingroup$ Thanks for your answer. My goal is to create a protocol using only the previus information. I know that i could do a better work adding some features, but my work consists in using these information o setting up a working and secure protocol. $\endgroup$ – Jon_Snow Jun 18 '15 at 22:21
  • $\begingroup$ I don't know how much help you want in that case. Studying existing protocols is really helpful. RSA encryption can indeed be used and is probably easiest to implement, but you could take a look at NIST SP 800-56A for the various Diffie-Hellman key agreement options. Wishing you good luck with that may be in order though, it gets a bit technical. $\endgroup$ – Maarten Bodewes Jun 18 '15 at 22:25

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.