When we announced to bring our RevPi Core to the internet this statement was the measure of all our decisions. We wanted to definitely avoid mishaps like one of the big Smart Home companies experienced lately. But doesn’t this grate with the concept of open source? How can we protect a system against manipulation and hacking attacks when telling everyone your technical secrets?
Well – we surely have not reinvented the “security wheel” but we’ve used the latest technology to combine security with our open source concept. After all, this works fine in every days internet: You may freely read in detail how the HTTPS protocol works and proof for yourself if it fits your security needs. And nonetheless no one (eh – let’s say within a reasonable time and with easy to get instruments) is able to spy out or manipulate your data traffic between browser and server if you use HTTPS as communication protocol.
The basic principle: HTTPS
Yes, most of Revolution Pi’s security is based on HTTPS (Hyper Text Transfer Protocol Secure) which is the encrypted version of the well-known internet protocol HTTP processing all the data traffic between browsers and web servers. If you like to get an introduction into this technique, then jump to the explanation at the end of this blog post (blue letters).
Whenever RevPi Core exchanges data over the Internet using the HTTP protocol we use HTTPS. As you know RevPi Core is based on the Raspberry Pi Compute Module. Its computing power is somewhat limited and the verification of certificates’ signatures as well as calculation of asymmetric keys consume a lot of computing power because they use very secure keys. We do relieve the Broadcom processor from this task by executing most cryptographic calculations using the Atmel’s crypto chip built in the RevPi Core. This crypto chip also securely stores a globally unique key for each device, which we are using for security functions. Other unique keys which we generate during production time are also securely stored on the chip and can’t be manipulated. For example, these keys e.g. help us to securely match third parties’ (e.g. logi.cals’) software license keys to a certain hardware device.
RevPi Core’s web server
Our RevPi Core runs a web server (Apache) which provides access to a login page of the device. This page gives you access to several basic setups of the device. SCADA software (SpiderControl) and other third parties’ software are using the web server as well to present their GUI via browser access. RevPi Core’s webserver uses a unique certificate which authenticates each individual device. A RevPi Core needs to retrieve its certificate periodically from the certification authority (“CA”) “Let’s Encrypt”. This service has the advantage that most browsers will know the CA’s root certificate as trustable using the browser’s built in list of trustable root certificates and – this service doesn’t cost you a single cent. With Let’s Encrypt your RevPi needs to authenticate to this service by writing a key code provided by the service to the Revolution Pi DNS (“Domain Name Server”, another service provided by KUNBUS) and associate it with RevPi’s Domain. Also through this service, only registered and authorized RevPi Core devices can be accessed from outside using a unique (automatically allocated) domain name – if the firewall of your router will allow such access. Don’t worry if the IP of your local Internet access point is not static: You RevPi Core does run a task which will cyclically transmit the actual IP to the DNS (“Dyn-DNS”). But this method to reach a RevPi Core inside a LAN from outside (WAN) will frequently require a re-configuration of your router (which is often against the IT policy of a company). So we have provided another clever method described in the next chapter.
Btw: Each single RevPi Core gets a unique default login password at production time which is derived from the unique crypto chip’s key. You can let this default password be displayed on a HDMI monitor connected to the RevPi Core or “headless” via SSH connection inside a LAN using a small utility program.
How to access my RevPi Core web server from the internet
Many operation sites might have strict IT policies which block HTTP(S) access from outside (WAN) to a server residing inside the LAN. In such cases the router’s firewall simply blocks such connections. Additionally many operation sites will have dynamic IP addresses cyclically changed by their ISP. We solved this problem using the following technique:
If WAN Access is enabled, your RevPi Core tries to get in in contact with the RevPi connection service via the Internet using HTTPS and port 80 (which is not blocked by most firewalls). The RevPi connection service runs on highly available servers administered by the Revolution Pi team. In order to establish this connection, RevPi Core has to authenticate itself using the crypto chip’s unique key. Prior to that you need to login to the RevPi customer Internet platform and enable this service for your RevPi Core(s) using its individual key. Without this authorization the connection will not be established. When the RevPi connection service has approved the rights for connecting a RevPi Core the connection server will establish a so called tunnel. In most cases your firewall will allow such a tunnel. Your RevPi core is then permanently connected to the service and waits for a client (you with your browser) to get in touch.
You need to go to the connection services login page via your browser (using HTTPS), and once you’re logged in you will get a list of your RevPi Cores, which are ready for connection. Just click on one of them and another browser window will open showing the login page of your RevPi Core’s web server. Your browser and your RevPi Core will then communicate using HTTPS and neither our RevPi connection server nor any other computer will be able to spy on or manipulate your data packages. Because your RevPi’s crypto chip’s unique key is used and securely transmitted during connection establishment (using HTTPS) you can be sure that you communicate with your authentic device.
Of course you may use a fixed IP or dynamic DNS assignment to connect to your RevPi Core from outside (WAN) in the old fashioned way (if your IT policy allows this type of access).
Other processes using internet access
There are other processes running on RevPi Core which might need internet access indirectly using HTTPS (like Cloud access of Linemetrics via REST protocol, OPC-UA via SOAP or access to our SMS server). Other processes like the MQTT client driver are using their very own security methods. We will offer more information about this in future newsletters.
How the heck does this HTPPS work?
HTTPS uses data packages which don’t contain readable text to avoid third parties to manipulate or spy out the data traffic. Sender and receiver both use the same so called “session key” (it is only valid for the actual session) to encrypt and decrypt their data. This key is so complex that even today’s most powerful computers are not able to hack it during the period of an internet session. But there is a problem: Sender and receiver do need to both use the same key and no one else should ever get hold of it. It would be insane to send such a key over the internet to exchange it between sender and receiver. That is why HTTPS uses a much more complicated method: When a browser contacts a web server which is able to use HTTPS, both will use the principles of the “Diffie-Hellman-Key-Exchange”. This procedure was the first so called asymmetric encryption method, which was made publically available in 1976. So we are definitely not the first to reconcile cryptography with open source!
Public and private keys
“Asymmetric” encryption means there is no common key at the beginning of a key exchange between browser and server. Instead, there are “public” and “private” keys. Public keys are unprotected and freely exchanged because everyone may know them. The corresponding “private keys” are respectively known to only to one of both parties. A pair of private and public keys functionally always belongs together. But before you get more details about these keys and how they are used, you need to understand another term: There are “one way functions” which play an important rule. You can easily use them in one direction to calculate a result but they can’t be inverted as easily as a function like “x = a * y”. A nice illustration for such a one way function is the good old paper phone book: If you know the name of a subscriber it takes less than a minute to find his number using a phone book. But having just his number it will take you weeks to find his name using just the paper phone book. Such one way functions are so important because public and private keys are using these functions to allow de- and encryption just in one way. If you have encrypted a message with your private key anyone knowing the public key could decrypt and read it but she could not use the public key to encrypt a message. This also works the other way round: If you use a public key to encrypt a message no one but the owner of the matching private key could decrypt and read it. The public key would not help to decrypt and read such a message.
Certificates
There is another important element of asymmetric encryption which is called “certificate”. It is all about trust and confidence. During connection establishment, how can you know whether your counterpart is really who they claim to be? If a browser contacts an HTTPS server, this server sends a certificate to prove its authenticity. Think of a certificate as a letter with a digital seal. Your browser will then ask you whether you trust this “seal” and implicitly the content of the “letter”. You seldom get in contact with this procedure due to the fact that your browser brings a list of “seals” along, which it assumes to be trustworthy. The certificate contains the name of the sender (i. e. the web server’s owner) and some other important information. All this information is “Signed” with a “signature”. The sender has got this signed certificate and the associated signature from a “certification authority” (CA) which is well known and trusted by the communicating parties. This could e.g. be the British Queen, but in reality it is more likely to be a worldwide operating internet company like Symantec or so. The CA uses a private key to generate the signatures of the certificates it releases. The CA is freely publishing the public key of all signed certificates it has given to their customers. Everyone can use such a public key to prove that the certificate’s signature is correct, authentic and the certificate’s content belongs to this signature.
Ok – so the certificate proves with whom you’ve got in contact to establish an HTTPS connection. But now you need to exchange keys between browser and server.
A session key is created
Another important bit of information contained in the certificate your browser has received from the server is the server’s public key. The corresponding private key is the server’s secret and no one else should ever get hold of it. After the browser has verified the certificate to be authentic it uses the public server key to encrypt a “pre-master-secret” (“PMS”, a freshly generated random number) which it sends to the server. No one else but the server could use the encrypted PMS because only the server can decrypt it using his private key. So both by now, browser and server, know the PMS. Both use the PMS and some random numbers which have been exchanged during establishment of the connection to calculate a “master-secret” (“MS”). This MS is used as unique and symmetrical session key which can only be known by the two parties (server and browser): Every data package which is exchanged between server and client is encrypted using this common key and can be decrypted using the same key. No one can spy on data packages or change them without knowing the session key. And thanks to the certificate the browser can trust in the authenticity of the server.