In our Industrial IoT work at Juxtology, device security is always top of mind for our customers. And, with the vastly increased risk of connecting industrial assets over consumer devices, this concern is spot on. With industrial IoT connectivity, we create opportunities for huge efficiencies in operations as well as new service capabilities, but we must have high confidence in our approach to security to offset real business risks and data security exposures.

With extensive industrial IoT asset connectivity, we are dramatically increasing the exposed security attack surface, and if we use multiple IIoT suppliers it is very difficult to understand when the solutions we deploy are truly secure. With the sophistication of today’s hackers and the tools available to them, solutions that were “good enough” in the past are not sufficient today. Today, using reverse compilers, a logic analyzers, JTAG interfaces and experience, hackers can discover how to take control of the system administrative features, data, or the operating system itself.

This article provides a brief summary on using Secure Root of Trust to address this issue. While any security implementation is only as good as its weakest link, Secure Root of Trust technology is fast becoming “table stakes” for reliably secure IoT devices to connect assets.

To clarify the issue, for any device that we can securely connect to our IoT stack, we need to be confident that it is always running under the following conditions:

  • The device is operating as designed and expected
  • The device firmware and applications are intact and as intended
  • The device has not been tampered with in any way

Using device to device authentication and encryption alone is not enough to guarantee these conditions. But we can maintain these conditions with the application of secure root of trust methodologies. The concept of a secure root of trust is not new, but the importance of its application to Industrial IoT connectivity is now very clear. The root of trust, or chain of trust, concept is simple:

  • At the core of any embedded system, a secure root of trust module exists that uniquely identifies that module.
  • This module contains cryptographic capabilities and NVRAM to store PKI information for the module, an encrypted hash of the boot code, as well as other secret device information.
  • The contents of this device can only be modified by an application that satisfies the authentication credentials in the module.
  • On device boot, the device validates the boot software against the secure hash and halts execution on a mismatch.
  • Subsequent software can be executed then, using the secure boot as the “root of trust”, with each trusted software load validated against the root of trust in turn.
  • Finally, the root of trust module will include features that allow for secure re-configuration of the NVRAM (for device lifecycle maintenance) only by validated applications.

Extending this, once booted, the device can authenticate with the network using PKI (Public Key Infrastructure) mechanisms, using a protocol such as Transport Layer Security (TLS) or DTLS. The digitally signed certificates stored within the module validates to remote servers that they are communicating with a known resource. On the reverse path, the IoT edge device uses certificates stored in the root of trust module to validate to ensure it only communicates with authorized systems.

The overall trusted boot process is illustrated with the following diagram from Microsemi (http://www.microsemi.com/products/fpga-soc/security/secure-boot):

There are multiple hardware solutions available that support secure root of trust implementations. Called TPMs, for Trusted Platform Modules, these devices are available from Synopsys, Microchip, Atmel, Microsemi, Infineon, and many others. Per the Trusted Computing Group’s analysis, independent / isolated hardware TPMs are the most secure, TPMs integrated into SoC solutions, such as the ARM solution below are next, followed by firmware and software TPMs. While firmware and software TPMs can offer significant security improvements over solutions that do not leverage the secure root of trust concepts, these solutions are understandably much more vulnerable to hacking than systems that provide hardware level security and isolation.

TPM stand-alone hardware solutions are typically low-power / low cost / small-footprint devices that seamlessly connect to a host processor, and often include an embedded ARM core, embedded crypto, NVRAM storage, and life-cycle features. These stand-alone TPM solutions provide a complete, reliable and self-contained, providing protection against device counterfeiting, user data corruption, device malfunction, and service & network access corruption.

ARM has also introduced the its integrated ARM TrustZone as an integrated TPM capability. Arm’s TrustZone can be integrated into any ARM based system. TrustZone can be used to protect authentication certificates, cryptography key material, device specific details and encrypted hash codes for trusted software modules, and execute the secure boot and application execution sequences outlined above.

Referencing the above diagram, applications that run in the TrustZone secured area are called Trusted Apps. This root of trust module, or CryptoCell, provides in-hardware platform level security and security acceleration and offloading. Features include cryptographic engines, secure boot, and tools to update digital certificates, PKI information, applications hashes and lifecycle management, and all integrated with the ARM SoC implementation. Intel provides integrated TPM as well since the launch of its 4th generation core processor platforms. The Intel integrated TPM also prevents unauthorized access from replacing or tampering with valid software loads and applications. Intel’s Boot Guard, in its “Verified Boot Mode”, cryptographically verifies the boot block prior to execution, as well as offering full TPM life–cycle functionality as outlined above.

The table below, from the Trusted Computing Group (the go-to resource on this subject) provides a summary of the differences between hardware, integrated, software and firmware TPM solutions and the relative levels of security they provide.

This has only been a brief overview of this subject, but hopefully, with brevity comes some clarity. Given the importance of establishing a secure perimeter around our Industrial IoT deployments, understanding the best tools and techniques to accomplish this is certainly critical.

So, I summarize with these key points:

  • With the expanded attack surface that is a necessary consequence of our IIoT deployments, we cannot afford to deploy devices with “old school” or incomplete security solutions. They are simply too insecure and too great a risk.
  • As multiple suppliers step forward to offer many disparate solutions for IIoT connectivity we are at risk of unwittingly opening holes in our defenses as some security solutions may be lacking. We need to understand the implementation details of our perimeter defenses very well.
  • Root of Trust implementations will continue to mature, but currently offer tremendous improvements over alternatives (or altogether missing solutions). Hardware TPM solutions, whether integrated in SoC technology, or as stand-alone devices, provide vast improvements on device security. Software TPM, at a minimum, is required.
  • As we deploy IIoT edge-connection solutions, we must explicitly require modern security provisions and understand how suppliers are integrating root of trust security protection.

With the right focus on securing our edge connections, we can realize the huge IIoT efficiency gains new service capabilities, and maintain high confidence in the privacy of our data and the reliability of our systems.