Integrity of Things
Supercharge your hardware security in IoT devices
The IoT marketplace moves fast, and device vendors continuously struggle to balance speed to market with implementing proper security measures. When devices cross over between industrial control systems (ICS) and IoT connectivity (often referred to as Industrial IoT or IIoT) ensuring deployed devices are properly secure becomes paramount to company survival.
Integrity will be is King in IIoT
Today, ‘Confidentiality’ is King in the IT world and ‘Availability’ is King in the ICS world. But as control systems become more connected and migrate towards IIoT, ‘Integrity’ will be the future King in operational environments. ‘Integrity’ typically refers to data integrity or being able to verify that data has not been modified. In the context of IIoT, I propose that ‘integrity’ refers to system integrity, or the ability to validate that critical system functions, especially functions which have direct control over something physical, are 1) running only software as intended and 2) only allow commands to physically interface from a trusted source.
Increased automation and external connectivity in ICS devices will make system integrity a higher priority than availability and confidentiality. With an eye towards reducing liability and increasing safety, customers will demand that connected systems fail safely if compromised, and that IIoT devices do not allow system changes that would permit an attacker to cause physical infrastructure damage or loss of life. In this manner, integrity of the device, by way of the software and hardware validation, will be the prominent leg of the security triad. In short, integrity of the system is directly connected to the system’s safety.
Securing the inherently insecure device
Guaranteeing device safety is inherently difficult for devices that are field deployed, as these predominantly Linux based devices are typically run as root. Even in cases where user levels are properly employed, the inability to update these devices to combat newly found vulnerabilities make them particularly susceptible to escalation attacks, ultimately giving the attacker the ability to read and write to physical devices connected or controlled through the IoT device.
Thankfully, many ARM devices can provide high levels of hardware security. However, as we will discuss below, these features are rarely implemented in current embedded devices. The cornerstone ARM device security comes from ARM TrustZone security features. TrustZone features are not new to ARM – in fact, they’re over a decade old. However, embedded device vendors have been slow to adopt the full suite of security features.
In the past five years, ICS security practitioners have focused on running validated software via the Secure Boot / high assurance boot features in TrustZone. This has been an important and welcomed first step in securing IIoT devices but leaves a large gap in device security. Secure Boot setups provide a cryptographic guarantee that, on boot, the device is running the firmware intended and, if done properly, the operating system and applications within the OS are also validated. Once startup is complete, Secure Boot is no longer a valid method of protection. Web servers have vulnerabilities, authentication methods can be broken, and device configuration interfaces provide an open path that attackers will abuse. Since ICS devices are rarely restarted, this allows an attacker to gain a foothold in the device. Even when the device is restarted, and the Secure Boot is implemented well enough to kick-out the attacker, a predetermined path to re-acquiring your device has already been established. Make no mistake – for most organizations, brute force attacks on keys or password crackers will not be the point of entry for an attacker of an embedded device – it will be the exploitation of out of date software installed on the device.
Trusted execution for embedded devices
Trusted Execution Environments (TEE) provide a manner to protect your valuable runtime resources. TEEs, again, are nothing new. They are common across server and high-end desktop environments, are present in HSMs, and are the basis for virtualization, segmentation and containerization. They have existed as part of the ARM TrustZone too but are very rarely used.
In a TEE, a hardware validated portion of code runs under the operating system, and provides a hardware validated gatekeeper for any resources you create as protected. Since TEE operates below the device kernel, even root users are not able to access protected resources within the system. While resources can be directly protected, TEE will also run and protect applications which are validated. If validation is used on a system watchdog application, that watchdog can, in turn, continually validate essential runtime apps and protect your system core. Using TEE to protect your run-time environment supplements the gap left by Secure Boot.
Why isn’t everyone using TEE?
TEE is very challenging both technically and from business perspectives. Since it is used to protect physical memory locations, hardware interfaces, and other internal hardware, the TEE kernel mapping is unique to each processor. For desktop and server class processors, manufacturers have gigantic development budgets for each processor line and corresponding customer demand for security features justifying the cost of TEE support (SELinux, VM-x extensions) immediately upon launch. Conversely, most System on Chip (SoC) manufacturers have not developed a TEE for their processors and have left development to product integrators if their product demands it. There have been takers – both Samsung, with their Knox Offering, and Motorola / Arris, with content delivery protection, have developed secure application TEE environments. Until recently, you needed an expansive security budget to develop TEE for your device.
[Note: If you want to see TEE done right, look at the Samsung Knox whitepaper – with this implementation, Samsung became the first commercial off-the-shelf mobile platform rated to process Top Secret data by DoD/NSA.]
OP-TEE – Open Source TEE
The Open Portable Trusted Execution Environment (OP-TEE) project is led by Linaro and Wind, with the express purpose of making lightweight TEE (or Secure World OS) available for common SoC platforms. They support most major SoC manufacturers and you can even get a version to try on your Raspberry Pi (RPi). RPi’s are a great example of why one must know about their physical hardware configuration, and how it’s implemented on the carrier board. While the Broadcom chipset in the RPi itself supports ARM TrustZone, the implementation in the carrier board prevents the Secure Boot from being setup, which is a prerequisite for proper TEE validation. Without this hardware root of trust, TEE can never be truly secure on a RPi.
With the growing knowledge and community support of OP-TEE, small and medium IIoT product developers can now leverage open source developed security without having to sacrifice schedule and budget. If your board is already supported by OP-TEE, it’s not unreasonable to get your first Secure World app up and running within a few weeks with a single developer.
More to come on this topic. Watch for updates as we continue our deep dive into TEE development, discuss the need for a hardware root of trust, identify some pitfalls, and talk best practices for securing your IIoT.
Subscribe to the blog for these and other timely cyber security updates.
About the Author
Jon (CISSP, GICSP, GRID) has over 15 years’ experience in device engineering, development of secure devices, security, and IoT infrastructure. Jon is currently the Principal Cyber Security Consultant for Embedded Systems OT Services Sr Manager and Principal Consultant with Revolutionary Security. His work focuses on ICS and IoT clients as they update critical infrastructure to adapt to modern communications and security principles. Jon began his professional career as a system engineer for machine communications devices at Caterpillar and was central in the development of their remote telematics machine program. In his last position with Caterpillar, Jon was the program Security Architect for Caterpillar’s autonomy products. Jon has also served as Lead Engineer and CISO for Monico Inc, a remote data monitoring hardware company.