# Session key Exchange, some doubt

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.

• What do you mean with "and it share a secret key with each client"? – Maarten Bodewes Jun 18 '15 at 17:28
• 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. – Jon_Snow Jun 18 '15 at 22:18
• 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... – Maarten Bodewes Jun 18 '15 at 22:21
• 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? – Jon_Snow Jun 18 '15 at 22:35
• 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." – Maarten Bodewes Jun 19 '15 at 0:27