Bench Talk

Security consultants have long advocated “layers of security” for both physical and data systems. The strategy still applies when you are protecting the remote IoT and IIoT devices that are outside of your immediate control. Protecting the MCU, data, physical devices, and the network are key to securing your IoT and IIoT environments. In Part 1, we’ll examine securing the MCU and boot process.

Securing a device begins with securing the MCU and the boot process. Most of today’s secure platforms are built using the Trusted Platform Module (TPM) specifications published by the Trusted Computing Group (TCG). The TPM provides resources to the system that help with encryption, authentication and management of security keys. Keys are stored in dedicated, non-volatile memory on the TPM chip, which prevents code on the MCU from inspecting them.

A secure boot system would first execute microcode or non-readable code that performs a cryptographic hash on the boot code stored in flash. Only if the signature of the boot code matches that stored on the TPM would the boot process proceed. At this point, the boot code is considered “trusted” because the contents are confirmed to be in a previously trusted state.

The boot code itself can perform similar checks on any additional software that is loaded, creating a “chain of trust” that holds if all the links in the chain are verified. A secure boot process makes tampering with the device software extremely difficult, if not impossible.

MCUs also provide additional features to enable secure computing. The code security module (CSM) allows developers to secure on-chip memory by writing a 128-bit passkey to a specific location. Once the code is secured, the chip will permit instruction fetch operations on the secure addresses, but not data read or write operations. An option to permanently secure the memory is also available, after which the memory cannot be read regardless of the passkey entered.

Protecting the boot code and the MCU does not happen automatically. These are conscious decisions made by the device designers and may have consequences, such as a bug in the secure boot code that cannot be corrected once memory is permanently secured.

Up next in Part 2, we’ll look at protecting data and physical devices. Then in Part 3, we’ll examine network protections.