In our security series we’ve already explored SSL/TLS as well as Wi-Fi link layer and WPAN link layer security as tools for securing our IoT infrastructure. In this final post of the series we are going to look at how we can secure the embedded devices of our IoT infrastructure.
Embedded devices will likely make up much of the low level sensors and controls of your IoT infrastructure – think motion sensors, environmental monitoring and device control. Embedded devices are ideal for this role. Their low power requirements means that devices can be powered from battery – and so positioned independently of a building’s power points or indeed be an outdoor, isolated and possible mobile unit – and their low cost means that you can provide a cost effective product line that will allow your customers to build out their IoT system.
All that said embedded devices also come with very specific security requirements. In addition to being vulnerable to all of the attacks common in server, desktop and mobile devices (namely securing our data), embedded devices are also vulnerable to more advanced hardware attacks. Let’s take a look at some of the issues that we might face as we build out our embedded device of our IoT product.
Securing data in embedded devices is treated very similarly to securing data in servers with a few caveats. A consequence of embedded devices’ low power and low cost is of course limited computational resources. Typically embedded devices will have limited available program space, CPU and RAM. These constraints will directly affect your security considerations. In particular, they may mean that you are unable to make use of the security libraries that you used to build out your server side, hub or mobile device functionality. But if your embedded device needs to use application layer encryption, access to a cryptographic library is a must.
This requirement can be addressed by using cryptography libraries designed specifically for embedded devices – for example wolfSSL or the underlying wolfCrypto. Such libraries provide the small footprint required by embedded devices while retaining all the security of their computationally more capable cousins.
Depending on your project you may need to pay a commercial licence fee to use the libraries in your product. In the face of commercial licences, it may be tempting to try to implement your own encryption stack. However, this option should only be explored by development teams with dedicated security experts. Implementing security libraries is notoriously difficult. Implementation mistakes are common and can lead to a costly user data breach – which your IoT company doesn’t need.
Another option for adding cryptographic functionality to your embedded device is the use of a cryptographic coprocessor; for example Atmel’s CryptoAuthentication range. Such coprocessors offload cryptographic functionality from the application processor to an additional dedicated processor.
Over-the-air – or Firmware-Over-the-Air (FOTA) – updates aren’t technically a security feature. Indeed, it could be argued that if improperly implemented they could actually cause security vulnerability. However, if implemented correctly FOTA allows you to update the firmware – and more importantly to our discussion the security firmware – on devices already shipped.
Consider the case where a bug is found in your encryption stack after 10 million devices have already been sold to customers. A resultant security breach will leave you with either unsecured and unhappy customers or a massively costly recall. The ability to patch all of these devices over the air could turn a possibly disastrous situation into a tough week or two for the development team. Even as an engineer, I prefer the sound of the second one.
A useful step that can be taken to secure your FOTA system is to ship your devices with a public key that can be used to authenticate signed code updates. With this mechanism you can ensure that only officially signed updates are applied to your device. However, it’s worth noting that this signature method is only as good as it’s implementation. Trammell Hudson’s Thunderstrike attack exploited a vulnerability in the Thunderbolt Option ROM to circumvent such checks in Apple’s EFI firmware update routines. The attack allowed untrusted code to be flashed to the boot ROM as well as the over writing of the public RSA key used to authenticate updates. While the initial attack requires physical access to the machine, by over writing the RSA key future updates can be achieved remotely.
Advanced Attacks – Side-Channel Attacks
Side-channel attacks refer to any attack on encryption that relies on physical information. For example, power consumption or electromagnetic emissions. Simple Power Analysis (SPA) and Differential Power Analysis (DPA) are examples of such attacks. Carrying out an SPA or DPA attack involves monitoring the power consumption of the device – which will vary with microprocessor operation. The variation in power consumption allows an experienced attacker to extract information about the encryption. Ideally, the attacker wants to obtain the encryption keys as then they can simply monitor transmissions and decode as required.
Clearly side-channel attacks require the correct equipment as well as specialist knowledge. As such it is unlikely to be used by an inexperienced cracker. However, if your IoT product has a high security requirement and could potentially be attacked by an advanced cracker it is an issue that should probably be addressed.
Advanced attacks – Vulnerable Interfaces
A slightly easier hardware attack vector are vulnerable interfaces. Joint Test Action Group (JTAG) interfaces are often used to test and debug embedded systems. They are clearly of huge benefit to development teams working at the prototype phase. However, they become a huge security risk when present in production phase devices. Shipping your device with a JTAG interface opens up an attack vector that would be hackers will only be too willing to exploit. As a rule you should remove JTAG interfaces – and indeed any other debug interface that is not absolutely necessary – from your shipped products.
It is also worth noting that blown fuses or cut traces will not serve as a sufficient technique for removal. Don’t underestimate your attackers. In this scenario they know enough to access your debug interface. There is no reason to assume they would be unable to repair your interface.
Advanced Attacks – Physical I/O Scan Attacks
Analogous to an IP port scan, this type of attack involves probing input pins with all possible input combinations and then monitoring the outputs. An I/O scan attack could cause any number of unforeseen results. This type of attack can at least be easily detected – at least in some cases. A developer can make use of unused input pins in the embedded system. Monitoring these pins for input will let the application know that someone is trying to use the embedded device in an unintended way – like carrying out an I/O scan. Once this attempt at unintended operation is detected the application can take appropriate countermeasures to prevent any unauthorised activity from taking place.
It is clear that security in embedded systems requires some special considerations when compared to server side development. Limited resources require optimised encryption stacks. Potentially exposed hardware require hardware specific security measures. Deciding which security measures are required by the embedded devices of your IoT system is very much a platform specific consideration. The risk of side-channel attacks on a residential IoT device is probably not as high as the risk on a critical infrastructure IoT device – for example, deployed in a power plant. Hence, the necessary protections will differ.
Remember increased security brings with it increased cost and complexity. This in turn causes increased cost to the consumer. You will need to balance cost to the consumer with a need for security to ensure you provide a quality product at a price consumers can get on board with.