Anyone who has been paying attention to the tech world over the last few years knows that IoT is popular and growing rapidly, including its industrial twin IIoT. This growth is fueled by the oncoming implementation of another technology trend: 5G networking. Billions of IoT devices will come online in the coming years, and securing those devices against unauthorized access is a serious concern.
We’ve all heard the story about the Las Vegas casino hacked via an IoT-connected aquarium and millions of connected vehicles being recalled due to hacking problems. Further, network security experts have implemented honeypot tests that have determined that devices connected to the Internet have approximately five minutes of safety before being probed by bots to determine their level of security, which — in most cases — is nonexistent. This is because users often neglect to change user IDs and passwords from their default settings.
Cyberattacks threaten IoT
Cyberattacks are on the rise, and component firmware is an increasingly popular attack vector for cyberattacks. In 2018, security vulnerabilities rendered over 3 billion chips in systems of all types unprotected via the exploitation of firmware weaknesses. Unsecured firmware can lead to data and IP theft, product cloning and overbuilding, and device tampering or hijacking.
This type of security is no mere annoyance. Unsecured firmware can expose network OEMs to the financial and brand reputation risks associated with device hijacking — used in distributed denial-of-service attacks — and device tampering or destruction. Failure to address these risks can negatively impact a company’s reputation and financial performance.
Disturbingly, security threats are no longer confined to systems in active use. Attackers target components anywhere in the product lifecycle, from initial component manufacturing and shipment to a contract manufacturer to system integration and on through its entire operating life. Because of this, OEMs need a robust security solution that protects hardware from these threats across every stage of a system’s lifecycle.
Root of trust devices help address security risks
How can OEMs address this problem? An increasingly attractive option is the establishment of one or more hardware Root of Trust devices, which can be used as a platform to provide the ability to secure all device firmware in a system. Such a platform can support a range of security protocols such as data encryption, data authentication, firmware authentication, system authentication and code/configuration encryption.
A root of trust device is the first link in a chain of trust that protects the entire system. Once designers have identified the first trusted device, which is usually a programmable logic device, field-programmable gate array (FPGA) or multipoint control unit (MCU), it can confirm it’s operating in a trusted state from the moment it boots, and then serve as the root of trust as it checks and boots other system hardware. root of trust devices must contain the hardware necessary to verify their own configuration and should be the first digital devices to boot at power up, and the last to shut down at power off.
A look at different security architectures
Some system designers might ask themselves this: What kind of security architecture is required when both the number and sophistication of threats is constantly rising? First and foremost, any solution must be robust enough to protect against new and existing threats to firmware. To help designers measure the capability of their solution, the National Institute of Standards and Technology (NIST) recently defined a new uniform security mechanism. The NIST SP 800 193 Platform Firmware Resilience guidelines were designed to comprehensively ensure a root of trust is established to all system firmware.
Developers of the new specification were driven by three guiding principles:
- Protection: Protect non-volatile firmware memory through access control.
- Detection: Cryptographically detects and prevents booting from malicious code.
- Recovery: In the case of corruption, the system recovers to the latest trusted good firmware.
Ideally, an engine that provides hardware security should consume little power, offer a high degree of design flexibility, be scalable and occupy a small physical footprint. A MCU offers excellent computational resources, but typically doesn’t offer the comprehensive capabilities needed to help boot other system processors or components. Furthermore, once an MCU is running, it’s hard for it to monitor its own boot memory.
FPGAs offers a significant advantage relative to MCUs. FPGAs are often used to enable power and system management functions, which often makes them the first on and last off hardware component in the entire system. This also makes FPGAs an ideal platform to establish a root of trust. Designers can exploit the parallel nature of FPGAs to check multiple memories in parallel, which can lead to significant boot time improvements. And unlike MCUs, FPGAs can protect non-volatile storage by providing real-time monitoring. Lastly, they provide the logic and interfaces necessary to enable firmware recovery in case of system corruption.
All IoT Agenda network contributors are responsible for the content and accuracy of their posts. Opinions are of the writers and do not necessarily convey the thoughts of IoT Agenda.