Pong

July 8th 2014, Client Pairing

← July 7th 2014 Installing the Pong Server | ● | July 10th 2014 Testing the Server →

Now that the “Pong” server is running, we would like to upload a single test file to the server and download the same file again. For up- and down-loading we have two applications, the “Ping” upload client and the “Poing” download client.

With the upload client a person can upload data from one place to the central server. With the download client the same person would like to download the files to another place from the same central server. Main question: How is the security of the data stored on the central server guaranteed, if there are multiple users involved?

For that purpose a user registers with the server by creating a secret key. The key is automatically created in a secure way. It is a random string of 1024 characters, so it cannot be determined by testing all possible combinations. That would take forever.

Now all files that are uploaded to the server have a reference to the secret key. Any person that has knowledge of the secret key is able to register with the server and download the previously uploaded files referenced by the corresponding secret key.

But how do we safely pass the secret key from one place to another, in particular from the device on which the upload client is running to the device or PC on which the download client is running? This is achieved by a procedure called “client pairing”. Let’s call the place where the upload client is installed “abroad” and the place where the download client is installed “home”. Then the procedure of “client pairing” follows these steps:

  1. The “home” client tells the server that it is going to be paired with another client.
  2. In turn the server sends a secret “pair code”.
  3. We write the code down, put it in our pocket and walk “abroad”.
  4. When uploading files from “abroad”, we instruct the server to pair the “abroad” client with the “home” client by sending the secret pair code.
  5. In turn the server sends the secret key.
  6. With the secret key the uploaded files can be sent to the server from the “abroad” client, so that the “home” client can download them again, because now they are both sharing the same secret key.
  7. The pair codes are one-time codes, meaning that they become invalid after pairing two devices.

Here is an example of pairing two clients: On the left we have the “abroad” client, in the middle the central server, and on the left the “home” client. Pressing the “Pair Client” button of the right “home” client, the secret pairing code is displayed. After entering the code in the “Enter pair code” text field of the left “abroad” client, the two clients are paired successfully together:

Pairing

Now, we drop a file to be transferred into the drop box area of the left “abroad” client. Then the file is transferred from the client (left outgoing = 1) to the server (middle incoming = 1). If the server is not reachable the file is queued until the server becomes reachable. Finally, the file is transferred from the server (middle outgoing = 1) to the right “home” client (right incoming = 1). If the server is not reachable the uploaded files are stored on the server until the download client connects (middle stored > 0). Finally, the file ends up being stored [in a sqlite database] at “home” (right stored = 1):

DragNDrop

For that to work securely, there are only two requirements:

  • The communication with the server needs to be encrypted.
  • The secret pairing code needs to be kept secret, of course.

Main advantages:

  • The secret key is created automatically, no manual password required.
  • The secret key is neither transferred in plain text at any time, nor does it have to be remembered by the user somehow.
  • The secret key cannot be cracked: chances are $1$:$10^{1835}$ (side note: there are “only” $10^{82}$ atoms in the observable universe).
  • The secret pairing code cannot be cracked, because it becomes invalid after pairing.
  • The secret pairing code can be written down and carried around, since it becomes invalid after the first time of use.
  • If the server is hacked, a user cannot be traced back, because there is no personal information stored on the server.

Potential improvements:

  • Encrypt the data stored on the server:
    • When asking the server for a pairing code, also send a secret encrypting key to the server.
    • When pairing the client, get the secret encryption key from the server.
    • Now use the encryption key on the client side.
    • If the server is hacked, there is no way to decipher the stored data, because the encryption key is not present on the server.
  • Expiration of pairing codes
    • To minimize security holes, limit the life time of pairing codes to a certain time range (let’s say an hour).
  • Expiration of transmissions
    • To minimize potential abuse of the server, limit the life time of stored and undelivered transmissions to a certain time range (let’s say a month or two).


← July 7th 2014 Installing the Pong Server | ● | July 10th 2014 Testing the Server →

Options: