Two themes monopolized this year’s Arm TechCon: embedded FPGAs and security. For this discussion, we’ll concentrate on security.
The centerpiece was Arm’s Platform Security Architecture (PSA), which targets Cortex-M microcontrollers (Fig. 1). PSA is architecture-agnostic and doesn’t require a full Trusted Execution Environment (TEE), unlike ARM TrustZone found in Cortex-A platforms. It does target Arm’s latest ARMv8-M architecture, but chips built around this architecture are still in the future.
1. A typical PSA implementation includes separate computing environments as well as root support for secure booting and key storage.
The Trusted Computing Group’s Device Identifier Composition Engine (DICE) system is also aimed at microcontrollers, but its specification isn’t as extensive as PSA is in its scope at this point. Much of PSA is still being defined, and it actually includes a growing number of profiles and recommendations for developers. This includes describing threat models and security analysis in addition to providing a common vocabulary for security discussions.
Intel was showing off its Secure Device Onboard (SDO) service (Fig. 2). SDO is designed to make the linkage between an Internet of Things (IoT) device and a cloud service very transparent to the user while maintaining a secure connection. The microcontroller has an Enhanced Privacy ID (EPID) that’s essentially a private crypto key that can be used to generate secure credentials.
2. Intel’s Secure Device Onboard (SDO) service uses an Enhanced Privacy ID (EPID) that’s programmed into hardware when a device is created to pair the device with a management service.
The device is paired with a 128-bit Globally Unique Identifier (GUID) used in tracking the device as it moves through the supply chain to a user. The process is only used to initially link a device to a cloud service. SDO isn’t involved once the device and service are linked.
Microchip Technology and Sequitur Labs had an interesting security demo (Fig. 3). Sequitur Labs’ IoT Security Suite ran on Microchip’s SAMA5D2 with ARM TrustZone support. The demo had two small LCD displays that showed what action was occurring on the unsecured Linux side and the secure enclave. The buttons were used to start off operations like getting a Trusted ID or doing a Firmware Update. The process included actions such as generating keys and using secure communication links to authenticate the firmware update code.
3. A security demo run by Microchip Technology and Sequitur Labs highlighted Sequitur Labs’ IoT Security Suite using Microchip’s SAMA5D2 and ARM TrustZone.
Sequitur Labs’ IoT Security Suite (Fig. 4) includes a number of components, starting with CoreTEE that runs Sequitur’s Trusted Execution Environment (Secure OS), trusted applications, hardware crypto engines with an OpenSSL plug-in for Linux, and security APIs. It also features a packaging tool plus an In-system Provisioning Procedure and Toolset that incorporates anti-replay measures and IP protection.
4. Components within Sequitur Labs’ IoT Security Suite include CoreTEE (1), trusted applications (2), hardware crypto engines (3), and security APIs (4).
The big difference between this demo and many of the others on the show floor was the level of integration within the Suite. This is handled by Sequitur Labs rather than the developer. Security is difficult to do properly, and integrating all of the pieces is prone to errors that become security holes.
Hypervisors were also out in force, isolating bare metal and operating systems like Linux to their own secured computing partition. Lynx Software had on display its LynxSecure Separation Kernel Hypervisor running on Xilinx’s latest Zynq UltraScale MPSoC with quad Arm Cortex-A53s and a pair of Cortex-R5s. The hypervisor runs on the Cortex-A53 complex and supports LynxSecure Applications (LSAs) like LSA.connect, which provides secure communication between domains (Fig. 5).
5. Lynx Software’s hypervisor provides isolation within a system; LSA.connect offers secure communication between domains.
The demo was also the first instance of the LynxSecure hypervisor running on Arm-based hardware. It also operates on x86 platforms. Other hypervisors run on Arm Cortex-A platforms, too, such as Green Hills Software’s Integrity Multivisor. The hypervisor also exposes the TrustZone support to the secure domains by providing secure-boot support. The domains can support bare-metal applications or operating systems like Linux.
