Security for the Internet of Things (IoT) is currently in the spotlight and this is not without reason. With the IoT, the digital world is getting a grip on our physical world. This provides innovative and practical solutions for interesting problems, but it also makes us vulnerable for new ways of misuse. The product developers of professional IoT applications have the responsibility not only to think about functionality, but also think about the security of their products for the entire lifespan of said product. Moreover, the basis has to be a proper hardware design.
Article from Bits&Chips #9, November 2015
The IoT is hot and therefore security for the IoT is also hot. The software libraries and IP blocks in order to secure the IoT are popping up everywhere. We are following this development with some suspicion. Security is like quality: it is not something that can be added later but needs to be implemented right from the get-go. This cannot be solved by an IP block or IoT library and it is not quite the same as adding encryption to an IoT product.
These past few years, with great regularity, new hacks have been mentioned in the media. Think for example about stolen bank and/or credit card information, ransomware making vacation photos illegible, registration information of a dating site for happily married people being published or business secrets being leaked to the competition.
The IoT adds a new dimension that can potentially lead to much greater damage. For the IoT consumer concerning refrigerators, lights and gimmicks, the damage will be limited, but the IoT also includes professional safety critical systems: cars, tunnels, medical equipment, robots and industrial controls. A hack can not only gain by imposing financial or reputation damage, but possibly even make a difference between life and death. Far fetched? The American government thought it wise, several years ago, to deactivate the wireless connection that granted access to the the pacemaker of former vice-president Dick Cheney. But also the friendly hacks in, for instance the Jeep Cherokee, make us think again.
Moat and castle wall
Security is a delicate operation. You need to carefully consider threads, vulnerabilities and measures. You also need to take into account the effort, knowledge and money that are required to misuse a weak spot in your product. Motivation of the attacker is also another factor to keep in mind. Sometimes you will have to deal with a bored student who want to play a prank, but it could also be a criminal who wants to make money or a hostile group that wishes to make a statement. In addition, the size of the scale is important. It makes a big difference if you can control only one or perhaps all the flood gates or pumping stations in the Netherlands.
When we at Technolution start with a project, we like to make a risk analysis with the client so we can assess the threats, vulnerabilities, impact, measures and reasonable additional risks. Based on this assessment, we determine the security measures that need to be taken during the development of the product.
These consist initially of prevention measures: securing accessibility - establishing a moat and castle wall - and the limitation of an impact - the dividing of the gold stash over several castles. But just like real castles, preventative measures are often not enough, you will need active security. This security needs to be done by a Security Operations Center (SoC). The SoC notices suspicious communication on the IoT network, analysis it and will step in when necessary. This way attacks can be detected early and the impact can be limited. Some security companies are specialized in the constant guarding of mission critical networks and have their own SoC available.
OV-Chipkaart (Dutch public transport chip card)
During the development of secure IoT systems we go by a few basic principles. It is important to use open standards for cryptographic algorithms. These were established through years of research by universities from all over the world. Individually designed algorithms and protocols are not as heavily tested as the open algorithms and are therefore prone to more weaknesses. In practice, the notion of 'security through obscurity' has a limited life span. The Dutch public transport chip card is a good example.
When cryptographic algorithms are used, there are proper procedures concerning generation, distribution, storage and replacement of the used keys that are very important. However, often the key management is underestimated or not even considered during the development of the product. Sometimes it happens that all IoT devices in the factory are provided with the same cryptographic keys. In that case if only one key leaks, it will provide access to all the devices - and for a criminal it becomes much more interesting to get his hands on that one key. In other words: each IoT device needs its own unique key.
Diversity is also a crucial factor when it comes to keys. A criminal must not be able to guess a key or use the brute force method. This means that the digital keys should be of sufficient length, but also that each possible key needs to have an equal chance of being generated. It is important to take such issues into careful consideration during the lifespan of a product or service. Suppliers could already start this process during the development stage of the product.
Each hype is entitled to a great slogan, so hereby we are stepping up: 'no professional security in the IoT without secure hardware'. We are convinced that critical security components need to be implemented in hardware. Hardware has an intrinsic separation of responsibilities (separation of concerns). This makes sure that two independent components cannot influence each other in any way possible. In software, this is not an absolute guarantee. A weakness in one application can result in losing control over the computer and therefore also other applications.
In hardware, side-channels need to be prevented because in hardware you can have total control over the electrical behavior of the circuit. A side-channel is an unintended channel which is leaking cryptographic algorithm information on, for example, a used key. These unintended channels often form in the low level implementation of the function, for example the electric circuit. A fascinating example is an attack during which researchers found a cryptographic key by listening to a PC with a microphone - during the encryption the PC made sounds in the ultrasonic spectrum. Other examples of side-channels are power consumption, execution duration, electronic emission and memory usage. Side-channel attacks are often done with cheap measuring equipment (below EUR 300) and are therefore easily accessible.
A proper hardware design with an eye for potential threats can help prevent side-channel attacks. Think for instance about proper EMI shielding. When properly designed, asics are fundamentally very secure components. But not every IoT application will be able to afford their own asic. The alternative is to use a FGPA that also has the benefit of being programmable. It is important because security measures only have a limited lifespan - just look at the number of security updates your PC performs on a weekly basis. For IoT devices the need for updates is not as great. With the increasingly powerful digital tools - and later perhaps even the rise of quantum computing - the current security methods that are now covering the load, will probably not cut it anymore in a couple of years.
Willem de Boer is a security expert at Technolution. He has nearly twenty decades worth of experience in analyzing, advising and solving security issues. Jonathan Hofman is a technology manager at Technolution and has over a decade worth of experience in programmable logic designs and architecture. Both are currently pioneers of the Defense, Safety and Security activities at Technolution.
Editors: Pieter Edelman