3
\$\begingroup\$

Hey I'm writing a game and have the backend written using a sometimes-reliable UDP scheme. I want to verify that inbound packets are actually originating from the player specified in the packets.

My idea (not original by any means) was to have the player register an account once and then, once per "session", login over HTTPS/SSL by sending username+password to a simple web service. The game client would check validity of my site's SSL certificate to disallow impersonation. The username and password are submitted and the response is a generated random "secret session key".

Matchmaking happens blah blah...

Then, when playing a match/game, the game client sends packets using UDP and attaches a HMAC-SHA1 of the packet payload using the secret session key as secret. I don't care if people can see the contents of the packet -- there's nothing secret there -- so symmetric encryption isn't needed.

I don't see how the packets can be spoofed since the secret session key was transmitted to the game client over a secure channel but I don't know what I don't know, you know?

Thanks for any insights.

\$\endgroup\$
3
  • 3
    \$\begingroup\$ You must have a very famous game, if not, you are wasting your time. In any case, this is more of a general network programming question, voting to close and move it to SE. \$\endgroup\$
    – Maik Semder
    Commented May 29, 2013 at 19:07
  • \$\begingroup\$ Lookup DTLS. Its like TLS (the new name for SSL, what https uses) for UDP. There are OpenSSL, GnuTLS and NSS implementations (OpenSSL has an advertising clause, GnuTLS is LGPL so you would need to ship dll/so, NSS only does 1.0 and its beta). There is also SRTP, I'm not sure if RTP is piratical for games, it does include some rate flow stuff you might have to implement yourself (another possibility would be SCTP which can be layered over UDP, but no encryption). Also look at 'perfect forward secrecy' (not sure if it works with any of these standards) and using elliptic curve crypto. \$\endgroup\$
    – David C. Bishop
    Commented Sep 20, 2013 at 0:33
  • 1
    \$\begingroup\$ The approach described in the question is overall very sensible. There is a few caveats to watch out for. To protect against IP spoofing used for reflection attack the client should choose a random value and send a single packet to the alleged IP address of the peer. Only if the secret is returned can the sending client consider the IP address of the peer to have been validated. Moreover to protect against replay attacks it is a good idea to attach a sequence number to each packet and validate it in receipt. \$\endgroup\$
    – kasperd
    Commented Apr 18, 2016 at 14:26

0

Reset to default

Browse other questions tagged .