A blog that informs about security topics in the small intersection between IT and OT.

If you not interested in the historical reference jump down to the Secure Boot heading.

The first historical evidence of humans using locks and keys to protect their valuables or secrets dates back 6000 years to Nineveh. In Sweden we even have a king named for the practice of using locks and keys, Magnus Ladulås (1240-1290), which translated means barnlocks.

He got the name after he stifled the nobilities right to, when travelling the country, demand to be housed and fed by the local farmers they passed by. In essence putting a lock on the barn. But the story about keys in medieval Sweden does not end here. Magnus had three sons and as was customary they could not keep the peace and started fighting over who should be king.

The oldest son, Birger, and king of Sweden receives his two brothers, the dukes Erik and Valdemar, as guests in what later became known as the Håtuna games. The two dukes had in secret armed their followers and as the evenings party slid into the night they came in and captured the king and his queen. This ended up with Sweden in essence being split in three parts.

But Birger was brooding on his revenge and 10 years later he invited his brothers to Nyköpings Banquet. The evenings party was lavish and the dukes got very drunk. They were supposed to spend the night in the city but Birger called for his knights and with the in Sweden famous phrase Remember the Håtuna games (“Minnes I Håtunleken”) he rushed in and arrested the dukes. They were taken and locked up in the castle prison. With king Birger obviously holding on to the key!

As we can see, the lock and key, can play a crucial role in history and that still holds true when we now jump forward and look at the modern world and in particular cryptographic keys.

Secure Boot

If you want to know more about what Secure Boot is see here.

Now that we know what secure boot is we understand that it is a really strong security feature that you want to add to your security posture. When we implemented secure boot at Westermo it was obviously a lot of discussions regarding the technology. What chip to use, key length, hardening of the bootloader etc.

The hardest questions for us was actually not related to the product itself but rather others, especially since our customers are mainly in critical infrastructure, or OT if you will, that will differ in needs compared to a regular

  1. How should we handle the private key?
  2. Will our process both handle the Confidentiality and Integrity of the private key but still enable the Availability needed?
  3. Can we ensure the lifespan needed for our products? (Typically 25+ years)
  4. In an environment without time sync can we still guarantee security? (Embedded, OT, sometimes offline)

Handling of the Private Key

Basically there are two ways to do this. You can either keep everything to yourself, keeping the private key completely internal or you can rely on external services offered by different vendors. I would like to argue that you should keep the key to yourself, a private PKI. 
 
The reason I argue for that is if you are looking to buy products for critical infrastructure there are a few things to consider:
  • You are buying a product to be used in maybe 20+ years, pick a vendor that can deliver this and is not reliant on anyone else to do it
  • With extremely limited possibilities to work with revocation can you trust the vendor?
  • In many industrial systems there might be no way to trust the time, essentially removing the use of certificates. Considering this, can the products you use uphold the security posture you want?
With this is mind we decided to keep the key internal, under our full control, and build a very resilient process handling the use and lifespan of the keys. But that led us to the next question, with a very rigid and secure process how can you make use of the private key in an still efficient way?

A Functional Internal Process

When delivering products with secure boot there is always a clash between interests of quick and effortless releases and the need to have a very rigid and secure process to keep the private key safe. So how did we manage this?
  • Split the trust chain in several parts. This means that access and control is more strict the close to the HW you get. The signing of the bootloader is still very cumbersome.
  • The split enables a build environment that can have a private key behind security measures (data diode) to enable quick signing of the firmware releases.
  • Signing of the bootloader kept in an offline environment, a lot less frequent and the need for security is higher.

Summary

Before concluding my thought regarding secure boot you might wonder what happened to the two dukes that were locked up by their brother Birger, the King? Well, he did as I advice you should do with the secure boot key, he kept it close in person and never gave or showed it to anyone else. This was unfortunate for the dukes since they starved to death in the prison.
 

Leave a comment