Author: Aljosa Pasic, Senior Consultant at Eviden
The first half of the CROSSCON project is about to finish, and it is time to show what do we have in stock.
The CROSSCON is a research project that targets developing research ideas into practical techniques and supporting prototypes, and the level of ambition is to validate results in lab conditions that are representative of a complex IoT system (i.e., technology readiness levels TRL 4 and TRL5). We can imagine this complex IoT system as a kind of “stick” and each IoT device, as a piece of food on that stick (see Figure 1, but do not look for too long at it, there are side effects 😊).
IoT system “stick” might contain (i) bare‐metal devices equipped with low‐power microcontrollers (MCU), few kilobytes of RAM, and tens kilobytes of Flash memory to (ii) devices equipped with powerful application processing units (APUs) with multiple cores and (iii) reconfigurable hardware, in which the functionality of the logic gates is customizable at run‐time, or devices using domain‐specific hardware architectures that efficiently implement ML engines. Tasty, isn´t it?
Users of such a stick might have strict security requirements, related to device management, updates or other, and this is where we introduce CROSSCON stack. The concept is closely related to Chains of Trust (CoT), which are the fundamental mechanisms to guarantee trust and security in a typical IoT system comprised of multiple layers. The idea is that each layer can rely on the security of the previous layer has already been explained in the previous CROSSCON blogs.
Imagine that “IoT stick” operator has a need to use remote attestation, or other security service such as device-to-device authentication. He will be relying on underlying security features and services provided by IoT device manufacturers and/or IoT device platform management, that in their turn rely on even more basic or atomic features and mechanisms. Some of these are provided by IoT hardware manufacturers, but as we already said…not all IoT “pieces” on the stick are the same.
If we turn CROSSCON Stack the other way round, we can also start with hardware-enabled security, or from Root of Trust (RoT).
At the lower levels of the CROSSCON stack, we have the Instruction Set Architecture (ISA) that varies depending on the CPU architecture families (E.g., RISC-V, Arm with all their variants), with the possible presence of firmware (that may exist or not, depending on the CPU architecture and the above layers of the stack). For some IoT devices, it will be the CROSSCON Hypervisor that leverages improved security via second stage memory isolation, a sort of additional protection to the first stage isolation between the various applications, that is already enabled by the OS. In the other types of IoT, it will be Trusted Execution Environment (TEE) that provides advanced isolation primitives (e.g., TrustZone), and the CROSSCON Hypervisor will leverage them to create a separate TEE, creating in this way the third stage isolation.
Most device manufacturers already provide each device with a secure stack that includes some basic security mechanisms which IoT device integrators and application developers can leverage to implement the higher order security services they need. However, such a secure stack is usually tightly coupled with the hardware and underlying security primitives and services. In other words, you can hardly “mix and match” different flavors on your “IoT stick”.
The goal of CROSSCON secure stack is to lower these barriers to have secure services and applications across different architectures, on various devices and multiple hardware platforms.