Open Source Security

How It Works and Where It’s Going

Alex Pluemer for Mouser Electronics

Image Source: ZinetroN/Shutterstock.com

In an increasingly connected, Internet-of-Things (IoT) driven world, system security is vital if developers are going to embrace open-source development. Embedded systems are vulnerable to hackers and malware that can exploit the weaknesses in overall system security if they’re not sufficiently protected. Open-source ISAs are currently lagging behind their licensed counterparts in this realm ─ however, RISC-V seems determined to catch up quickly.  Let’s take a look at some of the basics of embedded system security and how they apply specifically to open source development:

Security Fundamentals

In order to protect embedded systems from hackers and malware, developers must ensure they have a secure framework to build upon. In an embedded system, the root of trust is the immutable foundation on which all the other security functions rely. The root of trust can be counted on to execute security-related functions ─ as defined by the developer ─ free of interference by bad actors and hackers. The hardware behind the secure root of trust implements and protects the keys and functions used for security: encryption, decryption, authentication and secure boot.

Standardized cryptographic functions provide the basic underpinning for system security. These functions are often implemented with a secure hardware peripheral that can be protected from unauthorized access or snooping. Cryptographic keys, used to protect data and to verify protected data is from a trusted source, must also be protected from unsecured access, and can rely on device-specific characteristics that are very difficult to “crack.”

Once a root of trust is established and cryptographic functions and keys are protected, a Trusted Execution Environment (TEE) can be established that protects an embedded system’s application code from hackers and malware. The TEE can also protect sensitive application data like user login credentials, patient records and financial information. All higher-level application code builds on a TEE to keep the entire embedded system secure. The hardware root of trust must be secure from malicious hackers or malware in order to ensure overall system-wide security.

Software-Based Security

As an added layer of protection against hacking and/or malware, high-level applications often use special protocols to transfer data securely. Application code accesses secure protocol functions (like HTTP, FTPS and STFP) which use lower-level functions for secure communications protocols (Like SSL and SSH). In turn, these protocols access cryptographic functions, often via a library. All cryptographic functions finally execute via the TEE and root of trust to guarantee secure execution and data protection. The diagram below illustrates these relationships graphically:

Figure 1: Security Component Diagram (Souce: Mouser)

Hardware-Based Security

To further protect an embedded system from hacking and other malicious intrusions, hardware can be added to a RISC-V based MCU to help create a secure hardware environment that protects sensitive memory, peripherals, and even other processor cores in a multi-core system from the most aggressive attacks. The diagram below, adapted from a description of the SiFive WorldGuard security model for protecting MCU resources, shows one approach to implementing secure access. The RISC-V ISA-supported Physical Memory Protection (PMP) and Physical Memory Attributes (PMA) functions are used to implement protection of important MCU resources by restricting access to only secure processes. In the implementation below, access control (AC) blocks use PMP and PMA functions to detect and prevent unsecure access to protected cache memory, internal memory regions (Flash or SRAM), peripherals (like cryptographic hardware and key storage), other processors, bus masters and other peripherals as needed by the embedded system. Access violations can trigger an interrupt that the security system can respond to ─ perhaps by logging and reporting it as a potential security attack and taking preventative measures.

Figure 2: Open Platform Architecture (Souce: SiFive)

As seen in the diagram above, a root of trust implementation can rely on the RISC-V PMA and PMP capabilities to protect cryptographic keys (by placing them in protected memory regions) and protect cryptographic hardware from non-secure access. Protecting cache memory is also critical so that malicious software can’t potentially “snoop” for secure information that flows between a secure processor and a secure peripheral. Some of the other important elements of an embedded system that should be secured by appropriate protection measures are:

Peripheral Protection

Protecting important peripherals from configuration changes and protecting transmitted data from being accessed by a third party are requirements for secure systems. For example, if important sensor data from a dangerous chemical process is being monitored over a serial interface, it would be prudent to protect the interface from non-secure access. A bad actor could potentially modify the sensor data to create a catastrophic failure, thereby damaging equipment and threatening human life.

Bus Master Protection

Protecting access from bus masters is also needed to ensure that malware attacks can’t use bus master-access capabilities to access secret data. Restricting a master’s bus-access capabilities to only non-secure data when needed is a typical approach to protecting secret data from bus master-based attacks.

Debug and Programming Interface Protection

After a device implements a secure root of trust it is important to protect the internal hardware from tampering and unwanted inspection or modification. Often devices have debug and programming interfaces, such as JTAG, that allow access for debugging purposes. This type of access must be disabled or protected cryptographically prior to system deployment or a hacker could directly access secret data or protected IP.

Secure Boot by Attack Mitigation: Side Channel, Physical Attacks, Tamper Protection, etc.

Depending on the level of security required, additional hardware capabilities can be added to a RISC-V-based MCU. One of the more advanced classes of security attacks uses a device “side channel,” like power or clocking. For example, sophisticated power analysis can be used to determine when cryptographic functions are being executed. When combined with careful statistical analysis of power use over many operations, a hacker can actually determine the keys used during the calculations, based on momentary power spikes associated with the cryptographic computations. Determining cryptographic keys will give the hacker access to the root of trust and completely compromise the system. Some devices are even susceptible to physical attacks where the root of trust hardware is “de-capped” and subjected to microscopic analysis to discover cryptographic keys or other secrets. The most robust hardware roots of trust employ tamper protection measures that detect when a hacker attempts to de-cap a device or tries to cut traces on a board as part of a physical attack. When these attacks are detected a system can quickly erase all data within the device as a precautionary measure.

Conclusion

This has been a comprehensive summary of the security features you might find in a RISC-V-based embedded system – taking the actions described herein will thwart even the most persistent of attackers.  Security may be the most important hill for RISC-V to climb if open-source ISAs are going to become the standard in embedded system development, and while RISC-V still has a long way to go in this regard, the investment being put into enhancing security features and capabilities within the larger RISC-V community is a good omen for significant progress being made in the near future. A truly connected world is a minefield for hackers and other bad actors – system security will be absolutely essential to keeping that world functioning and operational.