As we rapidly advance to the new world of the Internet of Things, security is slowly but surely starting to be talked about. Managing keys is an important part of this discussion.
If we break the IoT down to its fundamental building blocks, it’s about “things” talking to other “things”. For this to work reliably then there needs to be integrity in this communication – the data flows need to be trustable.
A fundamental building block of integrity on the Internet is public key technology.
(It is important not to confuse public key (PK) technology and public key infrastructure (PKI). There are PK models that work in the absence of PKI.)
We see this in TLS transactions, methods to protect email and it’s the underlying principle in blockchain technologies.
Public key technology works on the basis of two items of information, one that can be made public and one that must be kept private – shared with no one, ever.
Sadly, in far too many cases of IoT security failure, it has been the private keys that the attackers have found. They’ve been seen in unprotected text files; built-in SD cards; or password protected, but with a hardwired password. If the IoT is to succeed and become trustable, this has to stop.
When designing an IoT solution, you need to take really good care of these private keys – and back to my hobby horse, manage their lifecycle.
Key points to consider:
Design
- Choose the right algorithms, and key lengths. As processing power increases, and crypto analytic techniques advance, the strength of algorithms deteriorates. If you anticipate your device being in the field a long time, this matters. You either need to choose an algorithm and length that is likely to outlive your device, or build in an update mechanism.
- How will the private keys be stored and protected from unauthorised access; how robust is the mechanism to attack? Do you need specialised hardware components?
- How will authorised users be granted access to the keys, and how will misuse be prevented?
- Provide information to users and relying parties – they have a right to know how you are protecting their systems. Security by obscurity has been shown to fail many times.
Creation
- Pay attention to how the randomness (entropy) used to generate the private keys is generated. This is one of the hardest aspects of security to get right, and the cause of many documented failures.
- Make sure you understand where the private key is generated, how it gets onto your device, and how the integrity and privacy is maintained during that process. In mass-market IoT devices this is not necessarily a trivial exercise.
- The previous bullet is specifically important in long supply chains – how can you validate there are no copies of the key in the supply chain? Conversely how can you be sure the key has not been switched in the supply chains (key integrity)?
- Related to this, how are you validating the integrity of any hardware of software used, to be sure they don’t keep (or communicate remotely) unexpected copies of keys?
Operation
- How is integrity of the key validated before it is used?
- At some point in the device’s lifecycle, something will go wrong. Make sure you have a recovery plan. Do you need to revoke credentials; have a black list of devices or some other disabling mechanism?
- Having a recovery plan, most likely involves having an asset list. What keys are where?
- Is your solution using certificates? If so, how are you tracking when these expire, and what is your update plan?
Destruction
- Think about how the device will be disposed of at the end of life. How will the private keys be put securely “beyond use”?
This is unlikely to be an exhaustive list; as specific design factors will also have a bearing. In summary:
Don’t try and do this on your own, seek expert help, it’s too easy to get wrong and the consequences very expensive indeed – more expensive than the expert help needed to get it right in the first place.
Once Upon a Camayoc 