The Flexomizer

Dave Whitney's Random Thoughts


Just how does the password authorization and encryption work in the Remote Guide app/server?

As promised, here's a breakdown of the security system I implemented for my Remote Guide server. The basics are this: you enter your password on both the client (phone) and the server (PC). When the client connects, it requests a session token. The server generates a large random number and returns this to the client. Then, both the client and the server generate a session key by hashing the password and the random number using the algorithm specified in RFC 2898. The astute among you may notice an opportunity for a man-in-the-middle denial-of-service attack. In other words, an evil-doer could intercept the random number returned by the server and replace it with another one before sending the response on to your phone. At this point, a very determined adversary could potentially determine your password once your client starts making further requests against the server. The more likely outcome is your client will simply fail to communicate with your server since it won't be keying off the right random source material.

This session key is used in the authorization header passed between the client and the server. For each request made by the client, the parameter data is hashed, along with the session key and the resulting hash is sent to the server. The server is then able to verify the hash and prove to itself the client knows the password.

All communication between the client and the server is also compressed and encrypted. For each message sent (either sent from the client or sent in response by the server), the sender generates a large random number and again uses this, along with the pre-arranged password, to generate a message key. The random number is sent in the clear, immediately followed by the compressed and encrypted message. The other side is then able to decrypt the message using the received random number and the pre-arranged password.

All encryption is done with AES, all hashing is done with SHA256.

This algorithm isn't bullet-proof, I'm sure. But it's sufficient to keep the casual eavesdropper from reading your TV guide data, and it doesn't expose your password. It also prevents mischief-makers from injecting false commands against the server, so at least you won't find your Media Center suddenly recording every epsiode Barney and Friends.

Add comment

  Country flag

  • Comment
  • Preview