How would one write a private/public key system for a server authentication?

Question

Hi all,

I guess this might have been posted somewhere, I did search, but couldn't find anything.

I have this server on which I run a game server, and where I want to have some TCP server (possibly written in Ruby) that will provide a pseudo-session with few commands available (like restart the game server, send the logs, etc.)

What I want is an SSH-like authentication, where people have public & private DSA keys (which I know how to generate), and the public key is recognized by the server as correct authentication.

I am not looking for code implementation, but mainly how this should be architectured.

What I was thinking was something like:

• [Client] Connect to the server
• [Server] Send public key
• [Client] Send public key encoded with server's public key
• [Server] Compare the key with a database of authorized clients
• [Server] Generate session key, send it encrypted with client pub
• [Client] Decodes session key and starts sending messages always accompanied by the session key

But I feel like this is missing something. Especially, when looking at DSA and PK systems, I keep seeing message signing, and I'm not sure I understand how different it is than using pub keys to encrypt and the session key?

If my question is not clear, I'd be glad to edit my post of course :-).

Answer 1

If you want a SSL like implementation, then why not just use SSL?

Answer 2

Instead of SSH-like, why not use SSH? Or use SSL, which has nearly ubiquitous library support for any platform?

First, it's easier. The code is written, tested, reviewed, and maintained.

Second, it's safer. If you don't understand why messages need to be signed, what else might you be overlooking? Honestly, even TLS (SSL), which has had a lot of scrutiny, had a serious flaw in the renegotiation bug that was recently publicized. Even when you know what you are doing, designing a secure protocol is hard.

By the way, SSH and SSL compute a message authentication code for every protocol record so that a man-in-the-middle cannot tamper with the message content.

Answer 3

If you do choose to go the route of implementing your own layer of security (which is sometimes the right answer), there are a lot of subtleties to be aware of. Start by reading what I consider the definitive tomb on the topic:

Bruce Schneier's Applied Cryptography