Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

In order to encrypt communications from our (custom) client to our (custom) servers our current scheme is a bit like this:

  1. Client uses the bundled public key A to encrypt some random key material.
  2. Lobby server decrypts it with the private key, uses the encrypted key material to set up an encrypted channel with symmetric encryption.
  3. Client gets another public key B1 from the lobby server for login to game server 1, over the encrypted channel. (Game Server 2 would have public key B2 etc, each of these are generated at server restart)
  4. Client connects to game server and follows same scheme as 1-2 to secure communications.

Leaving aside how how the key material is generated and used, would there be any change in security we change it to:

  1. Client uses bundled public key A to encrypt key material
  2. Lobby server decrypts with private key, uses the encrypted key material to set up an encrypted channel with symmetric encryption.
  3. Client connects to game server and follows same scheme as 1-2 to secure communications with THE SAME PUBLIC KEY "A" the lobby used (so both lobby and game servers use the same private key)

In other words, do we get any enhanced security from only using the bundled public key for the lobby login?

A final alternative would be with a separate login server:

  1. We create a login server which the client connects to in the manner of 1-2
  2. The client is then awarded a new symmetric key C and an identifying number D
  3. The client connects to the lobby server, presents the number D in plain-text.
  4. The lobby and client now continues communication using the key (assume C is in a shared db or similar) C
  5. The client connects to the game server, again follows 3-4 to set up an encrypted channel.

Are any of these schemes significantly worse or better than the other? I can't see any huge difference.

share|improve this question

migrated from crypto.stackexchange.com Jan 2 '13 at 2:43

This question came from our site for software developers, mathematicians and others interested in cryptography.

1 Answer 1

up vote 5 down vote accepted

One potentially significant advantage of not using the same private key for both the lobby and the game servers is that, even if one or more of the game server keys is compromised, the lobby server key (whose public half is bundled with the client, making it hard to change) is still safe.

Presumably, the game servers present a significantly larger (and more frequently changing) attack surface than a dedicated lobby server, so it makes sense to design your system to be able to recover from an attack on the game servers, while making the lobby server as hard to compromise as possible.

Your third alternative also shares this advantage, since only the login server needs to know the private half of the bundled key. Indeed, depending what else besides authentication the "lobby" server is doing, separating the critical authentication functions onto a dedicated server may be a good idea.

Also, your third alternative guarantees that clients will not be able to bypass the lobby/login server even if they somehow manage to acquire a copy of the game server public keys (e.g. from another, compromised, client). (The client could still bypass the login server if they somehow acquired another client's symmetric key, but since those keys are tied to client IDs, your servers should be able to detect it.) Depending on your use case, this may or may not be an advantage, but at least it shouldn't hurt.

share|improve this answer
    
Just so that it's clear: The client may authenticate itself, but only over the secured connection after the encrypted channel is created (i.e. stage 2 is completed). However, not all requests to the lobby require authentication, e.g. registration. (Lobby requests are also stateless, so authentication may occur multiple times) –  Nuoji Dec 31 '12 at 17:43

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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