Discussion of RSA implementation

From WinBolo

Jump to: navigation, search


Example Process

  1. Client connects to server, gets put in "verify" stage
  2. Server sends client a random string of characters
  3. Client encodes it with it's private key and the server's public key
  4. Client sends encoded message along with it's public key to server
  5. Server checks to see if the public key sent by the client is on approved list.
    public key is on approved list: server continues with process.
    public key is not on approved list: server returns a message saying connection declined, please contact proper authorities to get your client binary approved.
  6. Server decodes the encoded message using the public key supplied by the client.
  7. Server checks to see if the decoded message equals the original message
    Messages are the same: client is allowed to connect to server.
    Messages are not the same: server sends message back to client stating something about erroneous keys.

Automatic Generation of Keys

So let's say playerA compiles their own client on Monday and gets it added to the white-list of a server. Then on Tuesday, playerA decides to adjust the source and put a new executable out there to download using the same white-listed public key. What is to stop other players from using this new executable, short of removing that player's public key from the white-list?

Non-Developer Clients

Currently, WinBolo is at version 1.15. You can either play with a pre-compiled client or a client compiled from source. If we implement the above process, that assumes that every client will have the necessary set of keys. That is not currently the case with 1.15. Will there be a new release of 1.16 once RSA is implemented?

John: Yes that is correct. A new 1.16 release will have to be made available.

How to Implement in WinBolo

The netplayer.c module in the server contains network information about each client in the game. One of the fields in the structure hasPassed. This field is used to prevent clients that have not provided a password from sending any packets to the server. This is handled in servernet.c.

void serverNetTCPPacketArrive(BYTE *buff, int len, BYTE playerNum, unsigned long addr, unsigned short port) {
  static char info[MAX_UDPPACKET_SIZE] = GENERICHEADER; /* Buffer to send */
  BYTE *pnt;                                  /* Data Pointer   */

   /* Server password check */
  if (hasPass == TRUE) {
    if (netPlayersHasPassed(&np, playerNum) == FALSE) {
      /* If this isn't a password packet drop them */
        serverNetPlayerLeave(playerNum, FALSE);

 /* Process packet */

Two additional fields could be added to the netplayers structure that include the RSA random data to check and whether the client has passed the RSA check.

The join process in network.c would have to be modified.

In netJoinInit() before or after the password is sent an additional server send/receive is needed. The steps for this would be as the example process above. The list of valid public keys for clients and servers could be stored in the tracker or on WBN. Both the client and the server should check they are valid.

Personal tools