The Problem
I’ve previously written about the home automation framework I’ve been writing. Since I started, all communication between the broker and clients (devices and proxy clients) have been unencrypted – this is something I’ve been wanting to change for a while and think it’s quite important if other people are going to start using it.
Secure Socket Layer (SSL)
Basics
SSL is a network layer that sits underneath, and provides encryption for, well-known protocols like HTTP or any custom communication protocol.
When using SSL, the server creates a keypair containing a public key and private key. A certificate which contains the public key is given to clients by the server as they connect. Clients then use the public key to encrypt all network traffic to the server. SSL uses some funky maths to provide a trap-door function for the encryption. Once data is encrypted with the public key it is extremely difficult (extreme enough to be considered impossible) to decrypt unless you have the private key. Therefore, the private key (as the name implies!) should never be given to anyone else, ensuring that only the server can decrypt the data. So with SSL, you mean a client can send data to the server that only the server can decrypt! Yes, but …
What’s in a Certificate?
As well as the public key, a certificate also contains a Distinguished Name (DN) and a hash. The DN contains information such as the company name and address, contact details, URL of the server etc. The hash is used to determine that the information contained in the certificate (DN and public key) hasn’t been altered.
Certificate Authorities (CAs)
Before explaining why we have CAs, I want to give an example of how a man in the middle attack works….
Situation 1 – Client C1 wants to send some data D to server S who has a certificate SC and private key SP
- C1 initiates a connection with S and S responds with SC.
- C1 encrypts D with the public key in SC and sends the encrypted data.
- S receives and decrypts it with SP to get D.
- S sends a “success” message back to C1.
- Everyone’s happy.
Situation 2 – Client C2 wants to send some data D to server S who has a certificate SC and private key SP.
- C2 initiates a connection with S but this time a middle-man M intercepts the connection (M has a certificate MC and private key MP) (don’t ask me how M intercepts – I just know it’s possible).
- M initiates a separate connection to S and S responsds with SC.
- M then returns MC to C2.
- C2 encrypts D with the public key in MC and sends the encrypted data.
- This time though M receives it and decrypts it with MP to get the original version of D.
- M saves D somewhere.
- M encrypts D with the public key in SC and sends the encrypted data to S.
- S receives and decrypts it with SP to get D.
- S sends a “success” message back to M.
- M sends the “success” message back to C2.
- C2 thinks it’s sent encrypted data to S that only S can read so everyone’s happy, especially M!
From C2′s point of view, the steps he took are exactly the same as C1 did in Situation 1. From S’s point of, the interaction with M is exactly the same as with C1 – M is just another client and S knows no different.
Does this mean SSL is completely useless? Not quite. Notice that in Situation 2, C2 received MC instead of SC. This is why we have CAs. CAs “sign” certificates so they validate that eg SC is indeed for S. Now the client, when he receives a public key, can check if it’s been signed by a CA as being the correct certificate for that site. This way, C2 would have rejected MC as MC != SC.
The process of getting a signed/trusted certificate is:
- Create a keypair and certificate – must specify all information for the DN
- Create a certificate signing request (CSR)
- Send the CSR to a CA and pay them some amount of money
- Wait for CA to verify that the information you specified in the DN is correct
- SSL enable you server!
Trust Stores
CAs are all well and good, except that anyone can create them. For example, using situation 2 above, M could create a CA and sign MPu as being valid for S. Now, when C2 gets MPu, he’d accept it as a valid public key for S because it’s signed. So, we’re back to square one, how do we trust certificates? It’s fairly simple – we have trust stores. A trust store is a file that contains information about trusted CAs. If the public key is signed by one of these trusted CAs, then we trust the certificate. Getting a certificate signed by one of these trusted CAs costs money, but means clients can be sure that the public key they want to encrypt information with for the server is the correct one.
Generally, each system or browser contains a trust store that is set up at install time.
What’s in a Certificate?
As well as the public key, a certificate also contains a Distinguished Name (DN) and a hash. The DN contains information such as the company name and address, contact details, URL of the server etc. The hash is used to determine that the information contained in the certificate (DN and public key) hasn’t been altered.
Certificate Chains
In real life, a CA is just another certificate. A certificate could be signed by a CA that itself is signed by another and so one, creating a chain of certificates. In this case, the root CA is the one at the top of that chain, the end certificate for the server itself is at the bottom. To decide that a certificate should be trusted, we only need to trust the root CA.
My Solution
Each person’s “devices” in their home automation system connect to a broker that is unique to them (or their house, or their family etc). To encrypt information between the broker and any device or proxy client connection, the broker needs to have a keypair. This keypair should be unique to the broker, otherwise all brokers would have the same private key and could all decrypt each other’s data.
So when a client connects to the broker, it gets the broker’s public key. We don’t want every broker owner to have to pay to get their broker’s key signed so it can be trusted though. Instead, we create a new CA for all brokers to get their certificates signed by. The client libraries would come pre-installed with a trust store that just includes this CA. Therefore, all clients can trust their broker’s key and each broker can have a unique keypair.
There’s still one small issue. A client connects to a broker and gets a certificate which is signed by the new CA so it trusts it and communicates with the broker. However, the client doesn’t know that the broker is actually the one you wanted to connect to or not. The solution is the same way that a client can verify that a certificate is the correct one for a site – by checking the DN. A broker will need to have a globally unique name which will form part of the DN. One of the client’s properties will be the name of the broker it should be connecting to. As a client connects, it will check that the certificate is signed by the new CA and that the broker name in the DN is correct.
If you trust me to look after the CA and make sure that each broker name is unique, then you’ll be able to trust that all your client-broker communication is secure.



