Tools, operating systems, platforms, and services help open new doors for developers building security into their connected, modern-day IoT infrastructure.

WARREN KURISU | MENTOR GRAPHICS

Industries increasingly rely on their connected devices and networks, and they are also becoming aware that they must deter or prevent cyber attacks. It is nearly impossible to field an IoT device that is 100% secure, but software developers and architects can do their part to minimize the chances of a data breach or attack. Many of the precautions required are readily available. In some cases, the thing that needs to be addressed is the mindset around designing for security.

Essentially, security can no longer be approached as an after-thought to embedded system design. Security must be considered from the first day a concept begins. The process of building security into a design must be thought of as an investment, rather than a cost nobody cares to cover.

Clearly, security is a broad topic that begins with device conception and spans planning, process, activities, and technology. A few key technology topics are useful, if not critical, when building secure IIoT infrastructures. The focus is on IIoT endpoints or edge devices.

Code authentication is essentially binary operating system (OS) image authentication. Developers can set up their system to check whether data coming in originated from the original equipment manufacturer (OEM). Further, as the developer, you need to investigate whether any of the code has been modified. Code authentication and secure-boot authentication are some of the most basic steps developers can take to secure their embedded IoT device.

Once the initial boot stage has been confirmed, the process can continue to create a chain of trust. By using the same Public/Private key approach, subsequent executable modules can be downloaded, verified, loaded, and run. This approach becomes particularly interesting in the case of complex devices that might be loading different operating environments and applications, depending on the functional requirements required at any given time.

Software developers will be challenged to field complex applications using limited memory resources while also minimizing size, power consumption, and cost. And this situation is where process separation can be used. Process separation that makes use of a system memory management unit (MMU) or memory protection unit (MPU) does not guarantee security. But it does help contain misbehaving applications and keep them from harming other process applications or the kernel itself.

SPACE PARTITIONING

In a full-featured RTOS, such as the Nucleus RTOS from Mentor Graphics, the process model capability offers a light-weight approach for space partitioning that creates protected memory regions. This partitioning, in turn, offers full isolation of kernel and middleware resources. Consequently, scribblers, stack overflows, rogue pointers, etc., in application code cannot corrupt or interfere with system software operation.

Utilizing the MMU or MPU, the Nucleus process model partitions memory to create protected memory regions without virtualizing memory – which is extremely important for performance and in constrained spaces where a minimal footprint is essential. Space partitioning provides the framework to load new applications using cloud services, or the ability to partition large algorithms into smaller components that load slightly ahead of execution time.

As with using a process model, running a safety-certified operating system by itself does not guarantee security. However, by building on top of a safety-certified foundation, developers have an additional level of confidence that the code will behave as intended, which improves system reliability. Safety-certified environments also help avoid situations that might result from software faults that could cascade across the system and result in security vulnerabilities in unrelated sections
of code.

Nucleus SafetyCert RTOS allows developers to shorten the path to regulatory certification. It encompasses a complete certified solution that includes artifacts required for the development of mission-critical applications. This safety-certified RTOS has been documented to meet the certification requirements for IoT devices requiring International Electrotechnical Commission (IEC) standard 61508 SIL 3 certification.

SECURITY THROUGH ARM TRUSTZONE

ARM TrustZone architecture carves out or segregates a hardware subset of the SoC. It does this by defining processors, peripherals, memory addresses, and even areas of L2 cache to run as “secure” or “non-secure” hardware. An SoC that utilizes ARM TrustZone technology can dynamically, with only a few clock cycles delay, transition a system into “secure world” processing, where a subset of the hardware is partitioned, and data and processing are completely invisible to the rest of the system.

The normal world (or non-secure world) created and enforced by the ARM TrustZone can be used to define a hardware subset of the SoC. ARM TrustZone ensures that non-secure processing can access only non-secure resources and receive only non-secure interrupts. For example, a normal-world hardware subset might include the UART and USB interface but exclude Ethernet access. The Ethernet might instead be dedicated to the secure world where a separate RTOS or application runs for the sole purpose of managing all Ethernet traffic, independent of the normal world software stack.

ARM TrustZone architecture contributes to the overall system security by preventing normal-world software from accessing the secure-world resources. It is important to understand that ARM TrustZone does little to improve the safety or security of the software that runs in the secure world except to prevent unwanted secure-world access by normal-world software. It goes without saying that for the secure world to be completely trusted, the system must initially boot in a trusted state (see the earlier discussion about trusted boot). Beyond that, it is the developer who determines which software is “trusted,” typically through rigorous development processes, testing, certification, and supporting a “chain of trust” strategy in the secure world.

All in all, IIoT system security is a complex subject. Security for an IIoT edge device involves secure boot, code authentication, chain of trust, and several other well-known measures. These fundamental security capabilities should be part of any connected device development.

RESOURCES
Mentor Graphics, ARM-based design