On 11 August 2016, chip vendor Microchip introduced an integrated solution in partnership with Amazon to help make IoT cybersecurity less complex for devices connecting to Amazon’s AWS IoT cloud. The announcement marks the continuing industry efforts to enhance IoT device security through device cybersecurity solutions. However, focusing solely on device security will be a sub-optimal approach. Rather, stakeholders must take a holistic, end-to-end view of securing systems comprehensively.
- On 11 August 2016, chip vendor Microchip introduced a solution to help make IoT cybersecurity less complex.
- Microchip integrated solution was developed in partnership with Amazon to run on Amazon’s AWS IoT platform.
- Microchip’s 3x2 mm AWS-ECC508 device is pre-configured to recognize and securely interact with the AWS cloud without much of the custom development work typically required to establish secure connections.
The “gold standard” for ensuring IoT end-device cybersecurity is the use of hardware-based mechanisms. Such mechanisms have traditionally included: secure elements (which store cryptographic keys but do little else), secure co-processors (which store keys and can also run security code), and secure MCUs (which run application code, and also have separate security IP). Software-based mechanisms are always vulnerable if the attacker can break into the shared memory; hardware-based security isolates the device’s encryption keys, making it much harder for the keys to be compromised. Unfortunately, most current product designs do not incorporate hardware-based security elements.
Product OEMs need motivation to integrate hardware-based security mechanisms into their designs. Apart from the obvious sunk costs of investments made in their existing designs, there is the less obvious lack of cybersecurity expertise in many of the far-flung corners of the IoT. Sure, electronic point-of-sale terminal vendors, medical device makers, and the like may have a regulated driver to develop the needed expertise, but what about makers of connected toys? Or makers of environmental monitoring sensors in non-mission critical applications?
Apart from regulatory mandates, the primary motivating driver is likely to be the increasing awareness of IoT cybersecurity risks among consumers as well as enterprise IoT customers. This increasing consumer awareness is signified by the growing tempo of media report of sensational IoT cybersecurity exploits, such as the 2015 Jeep Cherokee “white hat” hack that led to the recall of 1.4 million Chrysler vehicles. On the enterprise side, surveys conducted by IHS show that within the past several years “privacy” and “security” have become the top concerns for enterprise IoT customers, ahead of the perennially top-of-mind “cost” and “complexity” concerns.
At present, there appears to be several likely paths toward widespread adoption of hardware-based security elements in IoT end-devices. First, the Trusted Computing Group is moving quickly to extend its Trusted Platform Module security co-processor standard from the PC and server markets to IoT applications, with automotive telematics being an initial use case. Microchip’s announcement with Amazon of a custom security co-processor designed as essentially a turnkey security module for devices connected to Amazon’s AWS IoT platform, is a second viable approach. Finally, several security chip vendors are developing integrated solutions that combine security-specific IP into an MCU meant to run application code.
All of these solutions are a much-needed leap beyond the current trend of connected devices with little or no hardware security in unregulated markets, but simply embracing embedded security isn’t necessarily the whole solution. According to Eustace Asanghanwa, Strategic Marketing Manager of Microchip, “many embedded security modules use industry-standard protocols citing use of well-known and trusted security protocols like TLS and algorithms like AES, but what they fail to mention is protection of the underlying keys (Private keys for TLS and Secret keys for AES), which is really what imparts trust in solution
“These solutions will work as long as nobody tampers with them but security is really about preventing all tampering i.e. hackers always try to subvert intended functionality. With standard MCU’s it is as easy as paying a service sub $1000 to extract keys from such solutions and then using the keys to spoof an identity with which to gain malicious access into a network of great value. The same argument is true with secure boot whereby a hacker’s access to boot keys will lead to the ability to replace firmware/software with malicious versions that thwarts the secure boot process. The addition of cost effective tamper resistance for the protection of keys and secrets is one of the value propositions of the ECC508A for securing IoT devices.” Asanghanwa admits that tamper resistant MCUs do exist, but the standard MCU, even ones with crypto accelerators, can be susceptible to physical tampering, and those that are tamper resistant can be very costly in both component price and development costs.
Another aspect of this physical tampering concern that remains to be addressed in IoT device development is how communication modules will secure the entire system. Many developers have adopted the modular approach to connectivity, using packaged modules or daughter cards to house communication modules. This popular approach enables economies of scale that can accommodate connectivity variations. Scenarios include devices that may need to address different connectivity standards due to regional distribution or use case can use a single main board with an optional connectivity solution for different SKU variants rather than geometrically expanding product lines. This is a very scalable and practical solution, however, it begs the question of how this might be exploited by physical tampering. If the module is only securing its own boot process and authenticating the communications that are designed to communicate with it, does it leave room for physical intrusion by attacking the connectivity between module and motherboard? Without a systemic authentication between the module and device in which it is installed, an intruder could place a man-in-the-middle attack between the secure connectivity module and the motherboard, clone a device by stealing and reusing a trusted connectivity module, or other similar cybercrimes.
Given the fragmented nature of the IoT, it’s unlikely we’ll see an immediate charge along one path or another. Rather, over the next two to five years we’d expect to see many makers of large industrial systems gravitate to standards-based solutions like TPMs. Meanwhile, consumer IoT device makers may be quicker to jump into turnkey ecosystems like the Microchip/Amazon partnership. Finally, for the long-tail of devices that will be updated over time with new MCUs, the use of MCUs with integrated security IP will be an increasingly attractive option. The embedded security market is just emerging and the IoT will generate significant demand for a holistic view of device security rather than a focus solely on the latest secure communications or secure boot technologies.