The evolution of devices with system-level security measures has reached critical mass. For example, TI’s CC2745P10-Q1, CC2755R10, and CC3551E offer significant system-level security options based on authentication algorithms for key agreement, encryption, and exchange. These MCUs address not only BT, but Wi-Fi, Mesh, Zigbee, Matter, and others.
Processes within the MCUs implement security features, such as secure key storage and exchanges, mutual authentication, and secure-boot operations with an integrated hardware security module (HSM). These complex protocols are too lengthy to explore in this short piece, but a cursory discussion of some is warranted.
One of the more common security protocols is TrustZone. This mature standard developed by Arm is found in nearly all security devices based on the Arm architectures. TrustZone is a hardware security extension that includes a bus fabric and peripherals. It works by partitioning all of the hardware and software on the system-on-chip (SoC) into separate layers: the secure unsecure.
The secure layer is implemented when security is demanded (such as the boot sequence). The unsecured layer takes over once all security protocols have been vetted, and no abnormalities found. These routines run in hardware-bounded barriers to prevent unsecure layer components from accessing secure ones.
Boot Security
Perhaps the most common example of a security implementation is in the boot operation. This is an operation that runs during the MCU’s startup process. Basically, it runs algorithms verifying the digital signatures of each boot component by comparing it to the public keys of the embedded system (provided by the vendors during manufacturing).
If the keys are valid, the process advances to the embedded public keys; otherwise, it returns to firmware initialization and generally runs an error or halt function. If the algorithm validates the first component’s signature, it steps into the next component in the verification chain and so on until all of the code is verified and loaded. After verifying all boot components successfully, the firmware loads the operating system kernel into memory.
Another weapon is the HSM. As mentioned earlier, it’s the “container”—a physical device that enhances security of sensitive data by generating cryptographic keys for essential functions. These include hardware-accelerated encryption, decryption, and authentication via stored keys.
These devices come in several forms. They can be plugin cards, or may be integrated into other hardware, i.e. the MCU. They’re also available as smart cards for wireless appliances, and external devices. HSMs are agile solutions. Beyond their integration into components, they may be connected to a network server or operated independently offline. And today, they’re also available as cloud services.
Conclusion
In the end, generally, the best solution is to embed security in the SoC, and make it field upgradable, either over the air, or on site. Security is no longer an afterthought and the lower in the chain it can be implemented, the more effective it is.
Thanks to standards, the MCU has taken its rightful place among the best solutions for cybersecurity.
Sponsored Resources
