While the price of modern microcontrollers gets lower and lower and powerful computing units get smaller in size - more and more devices get smarter and become integrated into the world wide web network every year. It will come as no surprise if some smart plate or spoon will be invented tomorrow. However, it will definitely require an internet connection so it can provide additional smart services. For example, it can give statistics on what and how much you have eaten. Unbelievable? Check it out yourself, maybe, it’s already there...
In a world where most of the devices around us can be controlled remotely - their security becomes very important, if not critical. Imagine a situation when you smart hoover gets hacked and it starts chasing your cat or when your smart car leaves without you. No one would like that.
But it can get even more serious. For instance, a health-supporting device in a hospital could get out of control or switch off at a critical moment. It’s not funny at all. Unfortunately, it will become a reality if manufacturers of IoT devices don’t think about security aspects at every stage of device production. Apart from safety, there is also another important thing that should be considered. It’s the protection of private data. By the way, are you sure that your home surveillance camera is streaming only for your needs?
The solution: Idea
So how to protect your customers, your reputation and avoid legal claims? Although each product is unique and requires thorough analysis in terms of IoT security, we will try to provide a few hints on what to do to stay on the safe side.
Let’s imagine that you have got a great idea and started to think about the requirements for your future product. That’s the point when security must be taken into account because different aspects will sooner or later affect your product. However, it’s cheaper to handle IoT security issues at early stages.
For example, from a security point of view, it is important to think carefully about the device’s API - so that exposed functionality is not wider than really needed. Let’s consider this using a far-fetched example of a smart kettle. There is no need to give access to a heater unit directly because if the cloud part is compromised, a hacker will be able to destroy the device by overheating it. Potentially, it may do even more damage to the surroundings. Therefore, it is better to expose a few high-level programs that just instruct the kettle to cook different types of tea. And vise-versa, a device shouldn’t be authorised to do more than required inside the cloud system so that it could not be used as a weak point to breach the system.
And remember that the overall level of security of your IoT device infrastructure is always not higher than the security level of the weakest element.
In order to ensure privacy, it is a good idea to provide visual indicators where possible that might inform the users that the device is recording information. For example, if your product has got a built-in camera or a microphone - a led indicator (that cannot be controlled from the outside) could expose unauthorised access to take measures asap. The possibility to manually close (using the shutters or similar) such sensors might also be useful so that users didn’t need to use duct tape for protection.
In case of network-based systems where the product consists of several devices or sensors, your IoT developers should think about smart and reliable procedures of adding and replacing devices, keeping in mind the possibility of “man in the middle attack” when a compromised device is easily connected to the network and can intercept all the traffic even if it’s encrypted. That’s why, communication keys should only be shared if the device was added explicitly using, for example, a serial number of the device and some secret code (e.g. the admin password).
The solution: Hardware
So you have got a more or less detailed vision of your IoT device or system. The next step is to select the microcontroller or microprocessor for your device. Luckily, there is quite a wide choice in the market. But what features should you pay attention to, from a security point of view?
As we will discuss further, encryption is the core player that helps to protect your IoT device and infrastructure. Thus a Cryptographic accelerator - an additional cryptographic processor, is an important feature that can significantly reduce the load on the main processing unit and help with encryption tasks. While MCU can focus on the key tasks and provide a smooth user experience. It’s also worth paying attention to the encryption algorithms supported by the accelerator: AES and RSA are the most common ones. And SHA-2, MD5, HMAC are popular HASH algorithms.
Your IoT developers should pay attention to another essential feature. As encryption depends heavily on the random numbers to generate encryption keys, the availability of a True Random number generator (TRNG) is a good sign that you are on the right track with the selected hardware. It will prevent hackers from generating the same key in parallel in case the RNG unit of the device is easily predictable. To keep all your private data secure (private keys, passwords, etc.), you also might want to include Secure EEPROM, which will make it harder to pull out secret information.
In case you would like to raise the cost of a possible attack even higher - a secure chip is even a better option. It’s a separate processor with a dedicated memory running its own operating system that is fully isolated from the rest of the environment. This solution allows keeping your critical data safe even if your main operating system gets compromised by malware and it gets access to everything on your device. For example, Google is using a similar approach inside its Pixel phones, with a chip called Titan M.
The solution: Software
Software for an embedded system is probably the most complicated and the biggest topic speaking about security. There are lots of things to consider. In some cases, to stay on the safe side, you should behave like a paranoiac, up to a point when you thoroughly analyse each new feature that is added into your device to make sure it doesn’t open new holes in your security system. The more complex your embedded system is, the more sophisticated protection should be used. Let’s go through a few common protection mechanisms that most IoT devices should have.
Let’s start from the beginning - booting of your device. A bootloader should make sure that only trusted code is executed. Embedded engineers can achieve this by checking the cryptographic signature of every next component that is being loaded for execution - a so-called secure boot chain. Usually, bootloaders use your company’s certificate authority public key that is fetched from read-only memory to examine the signature. The boot process should be stopped in case any untrusted code is met.
Another important part is the software update. There is a lot of discussion on the internet about encrypting upgrade binaries. Our recommendation is simple - you should do it if you don’t plan to open your codebase. It will raise the attack price anyway. Also, your embedded software developers should forbid downgrades as some already known security vulnerabilities fixed in the recent versions might be exploited using the older version of the software. Since users usually update software only when some issues arise, automatic update is a must-have feature to keep the device up-to-date with all security fixes onboard.
Communication is another massive field to consider. Whether it’s about traffic between the device and the cloud or between the network nodes or even between different components inside the device - it should be encrypted. You can use TLS or a similar protocol based on hybrid encryption. It should be good enough for most cases. Additionally, in order not to compromise encrypted communication, your embedded engineers should implement reliable authentication and authorization procedures. By the way, TLS 1.3, which has got a bunch of security and performance improvements, is already available.
And last but not least, you should not underestimate the testing process. It should be also set up keeping security in mind. Even such a quite common thing in the C/C++ world as “buffer overflow” can be easily used to change the execution flow and breach your IoT system passing through all your hard effort.
The solution: N-iX
As you can see, it’s not a simple task to create a secure IoT product. There are lots of IoT security issues to think about and handle at every stage of product development. If you don’t have the right expertise, don’t want to risk or just don’t have enough capacity to deal with all that, you can always contact N-iX and we will gladly help you using our embedded expertise.