Technical Overview

Thyth · February 2009

The vast majority of you will be uninterested in the technical details, but... for those that are, here is a (work in progress) technical overview of how the TribesNext systems operate.

Accounts:

The account system used by TribesNext is conceptually similar (but not identical) to the original WON based authentication used as part of the official servers.
In order to accommodate a large number of users, and to minimize the impact of any potential centralized system downtime, I based the design of the system on the certificate architecture used by SSL/TLS to enable positive identification of a domain for secure communication over SSL.
As with every SSL certificate hierarchy, there is a certification authority that all clients and servers know. This authority is the account server, which validates account requests, and issues signed certificates.
Once a client has a signed account certificate, any other game client or server has the ability to determine the validity of the certificate using the account server public key hard coded in the DLL. No communication with the account server is necessary to validate an account.
From the standpoint of the web SSL architecture, the account server is the primary (and only) certificate authority. The players are SSL "authorized parties". The game servers are SSL "clients". Game servers validate that the player is who they say they are in the same way that a user's web browser validates https://www.amazon.com/ is really connecting to Amazon's secure webserver.
RSA4096+SHA1 is used to digitally sign player account certificates. RSA512/RSA768/RSA1024 encryption is used by the game server to issue an identity challenge, depending on the size of the player's account key.
SSL has stood the test of time, and shown no significant protocol weaknesses, thus it is an acceptably secure design basis for an authentication system.

Player Account Certificates:

PACs contain five (tab delimited) fields. The first is the player's account name, and what other players see in game. The second is a 7 digit semi-sequential unique identifier, used to populate the GUID field used for admin identification, and some ban lists. The third is the public RSA exponent that the player generated when creating the account. The fourth is the RSA modulus that the player generated when creating the account. The fifth is the 4096-bit digital signature from the authentication server.
The digital signature field is composed of a signed SHA1 sum of the first 4 fields, with tab delineation between them. Game servers compute the SHA1 of the fields, and perform an RSA verification operation on the signature to see if they match. Only accounts signed by the account server's private key will pass this check.
PACs for every account on a computer are stored in GameData/public.store, with one account per line.
The PAC for the active account is sent to whatever server the player joins, and it is not secret information.
A player's game also stores encrypted versions of their RSA private exponent in the private.store file.
The private key store has three fields. The first is the account name for the given private key. The second is a SHA1 sum of the unencrypted RSA private exponent. The third is a symmetrically encrypted version of the RSA private exponent.
The private key is encrypted with RC4-160(2048), where the RC4 key is the SHA1 sum of the user's password, salted with the SHA1 sum of the unencrypted RSA private exponent. Decryption verification is performed by calculating and comparing the SHA1 sum of the decrypted exponent with the stored value.
On login, the unencrypted private exponent is encapsulated into a Ruby RSAKey object, and protected from reading. Thus, preventing the private key from being stolen by a malicious client side script.

Community Enhancement Certificates (RC2):

CECs are a special type of supplemental certificate with a built in time limit.
These supplements contain the current account name, current active clans, and the list of clan memberships for the player. The certificates are time limited so the data in them can be changed.
Server side support for CECs was added in RC2, along with client side transport support.
The delegated community enhancement (DCE) server to handle browsers, mail, and generating these CECs will be unveiled in RC3.
A CEC will last for a limited time period (i.e. 12 hours), after which point the client program will fetch a fresh one from a DCE. In the event a player makes a change to any of the data in the DCE (i.e. leaves a clan, joins a clan, changes name), they will immediately be given a fresh CEC.

Authentication Handshake:

(ToDo) Describe how the server does a client identity proof challenge on connection.