Browse Source

Added spec

dirkson 3 years ago
  1. 60


@ -0,0 +1,60 @@
Commented lines are reserved for future implementation
* When loading, ScrumbleAuth prepares a news packet from data on the disk. We need a file that contains the Full version, the Bleeding Edge version, and the news text.
* The newspacket may not be longer than 512 bytes total.
* Whenever ScrumbleAuth receives a udp packet, it responds with a udp packet containing the NewsPacket.
* Eventually we may want an optional TCP news system, with support for an image or some such. For now, the light news system is preferred.
**Keys involved**
Server Public Key
Server Private Key
Client Public Key
Client Private Key
Server Public signing Key
Server Private signing Key
Authchits should be created using protobuffer. I believe currently there's an implementation using ScrumbleSerialization
**First time authentication**
* Server public key is embedded in Client.
* Client creates a public/private key pair.
* Client sends username and password encrypted with AuthServer's public key and client's own private key. It also sends its own unencrypted public key. If this key is changed, the message becomes unreadable.
* Server checks the username and password by inputting them into the website. (In the future, more than this authentication model will be supported)
* Server parses the resulting webpage to pull out interesting data - Whether or not the authentication succeeded. If yes, preferred hairstyles, etc.
* Server uses this information to create a Protobuf->Authchit structure. It signs this structure with its signing key
* Server stores this public key client provided in a database, (redis?) associated with the username.
* The server stores up to X (3 default) of these public keys, dropping the oldest key every time a new First Time Authentication comes in.
* Server sends authchit to client
**Connecting To GameServer**
* Client asks gameserver for its public key. GameServer replies with its public key.
* Client sends his authchit. He also sends current timestemp encrypted with his own private key and the Gameserver public key.
* The gameserver uses his private key and client's public key to unencrypt the timestamp. Upon doing so, gameserver sees that the Client's public key matches the public key inside the chit the Authserver signed, so this must be Dirkson who encrypted the timestamp
* If the gameserver tried to steal the chit, the gameserver's public key and the authserver's signed key won't match. Must not be dirkson.
* The gameserver should respond with "Wrong time" if the time is wrong, and send the current time. This allows the user to correct his clock if it's the wrong time.
* We can probably have the client report "got wrong time", then wrap up the gameserver's time and send it back to the gameserver, just like a normal authentication
**Renewing authchit**
* When the client's authchit expires, he needs to get a new one.
* Client generates a new private/public pair
* Client sends his expired authchit and his new public key.
* Server authenticates the old authchit. If everything checks out, it replaces the client's stored public key with the one send
* If any more clients try to renew their authchits, the system will be unable to successfully unencrypt the authchit, becuase the server will no longer have the old public key stored.
**Update request**
* The client can request the following updates:
Ideally, these updates should be specified in some sort of options file - They currently are not.
* This request must be accompanied by a valid authchit and timestamp, just like connecting to a gameserver
* The server verifies the login, just like connecting to a gameserver
* If everything passes, it sends the requested file