Certificates, Keys and Hashing - Some Insider-Basics

With this blog, we reached the middle of my security series - some problems were pointed out and solutions were given. Let´s now look a little bit deeper into the topic and let me explain in my words (I promise to keep it crispy) some basic security mechanisms. And after that - within the next post - we will see, how these mechanisms are involved and in which solution they are integrated. 

Nearly all common asymmetric encryption is based on prime numbers, because – don’t worry, I spare you the details – the basic thought is, that since it is a prime number there is no smaller divider, so a brute force attack cannot happen (by using a small divider). So, if an attacker is trying to brute force a key, he or she would need to compute a lot of big numbers, which is making an attack very inefficient.

Another important credo: One key is good, but 2 keys are better. The thought behind this is: Where parties communicate, a key basically consists of two keys: a private and a public one. As the name suggests, the public one is known by everybody, allowing everybody to encrypt a message of the owner of the corresponding private key (which decrypts the message).

Also an important term: Certificate. Basically, a certificate wraps some meta information in a key (in most cases the public one). A key can be bound to e.g. a different key, allowing to build hierarchies, while other information can be an internet URL or the information of a file.

This (public/private keys + Certificate info ) has already big impacts and side effects:

• This building of hierarchies allows to establish trust over third parties (a new certificate can refer to the oldest certificate in the hierarchy and the older certificate can confirm the credibility of the newer certificate). This process is addressing security in an “open world” where new parties can participate. 

• So, for example a normal laptop is shipped with some generic certificates from VeriSign or Microsoft. Let´s assume, you upgrade it with a brand-new component that requires a special driver to run properly, although your laptop does not know the certificate of that new driver. But the laptop already trusts the Microsoft certificate on the laptop. This is why the driver manufacturer signs his driver with his certificate AND links it to the Microsoft certificate -> the driver is allowed to load!

• This is not needed and would create a management overhead, if you just want to secure device communication over the internet. Here the mechanisms are the same, but you don’t need to involve 3^rd parties in the authentication process, since server and device are well known.

• Move with the time, some companies evolved like Verisign or Globalsign selling  certificates and link them to those root certificates integrated into devices. Typically, they request you to exchange your certificates all 2-4 years, because they expire and of course you have to pay for that. While this makes sense in the open internet for e.g. internet banking, this is not tailored for embedded devices. Here, a linking to these root certificates is not needed or not wanted (so you have in fact more control and can exclude unwanted SW). Aside of stretching the expiring date (always have in mind, which things need to be protected) of the certificates, you don´t have to pay for those certificates because you can generate them in a private CA.

Some sad truth and the reality:

• This way of en-/decryption is very CPU-time consuming. In order to gain performance, files are not encrypted, they are plaintext. A one-way function is applied to them, so that you get an almost unique fingerprint of that file. That’s called hashing and ‘one-way’ it is called, because you cannot reverse calculate that fingerprint. Only that hash is integrated into the certificate and it’s a sort of tamper protection.

• As mentioned, that type of en-/decryption is very CPU-intensive. So, when a file or email is encrypted, this is typically done with symmetric encryption. Symmetric encryption is working like most WIFI access points. It’s in fact a common shared secret, called the WIFI password. Coming back to our encrypted file or email, only the “password” for that is kept in the more sophisticated asymmetric (public + private key) way.

• Nevertheless, there is a way to “encrypt better” and already a lot of tools can bring comprehensive security to connected device. Not long ago, most existing installations only had one certificate for the whole installation, so there was (usually from what I saw) not one dedicated certificate per device. This results simply from the fact that, in former times, it was quite time-consuming to provision devices individually. However, that changed and today, at most embedded manufacturers, it only costs a small service fee. And yes, of course S&T / Kontron offer this.

Invented for that device-to-device-communication, certificates and other security mechanism have found their way into the hardware of todays embedded system- how they are integrated, I will cover within my next two blogs.