Securing Offload Engines For A Robust Secure SoC System

Welcome to the Securing Offload Engines blog series where we will explore different approaches to security implementations and look at system examples involving Cadence Tensilica Xtensa Processors. In this blog, we will look at why it is important to build a robust secure SoC and introduce some of the common approaches to securing the offload engines. In subsequent posts, we will look at each of these approaches in detail.

Today, security is not an afterthought but an important design challenge. It needs to be designed in with rest of the SoC. An SoC must be protected from several types of attack like software-based attacks that include malicious code, memory buffer overflow attacks, physical attacks that include bus attacks, pin tampering, brute force access to debug port and side channel attacks based on timing, power analysis, and so on. The common goal of these attacks is to gain access to the IP and sensitive data, gain control of the system and cause disruption of a service.

A typical SoC comprises a host CPU and one or more DSPs acting as offload engines. Since these processors can be reprogrammable, hackers try to introduce malware targeting the application software and try to steal the proprietary IP, read the memory content or access data off an interconnecting bus. Software-based security is inadequate to protect against these attacks. Security needs to be implemented by combining both software and hardware solutions.

Some of the most commonly employed security measures that can be implemented to counter above mentioned threats are cryptography, hardware partitioning and isolation, and hardware root of trust (RoT).

Cryptography

Cryptography is not a new concept. It’s been around for ages. Cryptography can be employed as a countermeasure to protect against attacks to gain access to memory and bus and read the content, including firmware, IP, sensitive data, etc. The main goal of cryptography is to ensure confidentiality, integrity and authenticity. Often, the firmware, IP and data are stored in encrypted form for confidentiality and signed by the hash of the asset for integrity and authenticity. When required, the encrypted image is authenticated against its signature and then decrypted for use.

Cadence Tensilica Xtensa processors can run cryptographic algorithms natively or through use of custom instructions using the Tensilica Instruction Extension (TIE) language. Cryptography can also be implemented in Xtensa processors through use of eTIE accelerators that act as closely coupled autonomous accelerators with fixed RTL like performance. Another approach is to use dedicated cryptography engines from third-party partners.

Hardware partitioning and isolation

A hardware-enforced isolation of assets is made possible by partitioning the processor core into two virtual worlds, the secure world and the non-secure world. Memory regions that store software IP, sensitive data, and resources that need protection can be grouped into the secure world while rest of the resources are grouped into the non-secure world. Only the trusted code is run in the secure world and has access to all the processor resources while untrusted code will be part of the non-secure world and will have access to only those resources that are part of the non-secure world.

Xtensa LX processors support Xtensa LX Secure Mode (XLS) that support hardware isolation. XLS created two partitions in the processor, a secure mode for executing the authenticated code and a non-secure mode for untrusted third-party code. Code running in secure mode has access to all the processor resources while the code running in non-secure mode only has access to non-secure resources.

Hardware RoT

Hardware root of trust (RoT) functions as the foundation for all secure operations in a system. RoT ensures the system always boots from an authenticated boot image and boots into a known state and then executes only trusted firmware. Some of the components of a RoT system include:

• Hardware cryptographic engine
• E-fuse memory or OTP memory for key storage
• Optional TRNG/PUF for generating keys
• Secure JTAG for debug

RoT can be provided by the host CPU or a dedicated hardware secure module, but such a solution may not be secure in all cases. For a more robust secure system, it is worthwhile to extend the RoT capability to offload engines.

Cadence has partnered with Beyond Semiconductor to provide secure boot subsystem around Xtensa processors. The secure subsystem is based on GEON security platform, enables secure boot and secure JTAG, and offers cryptographic engines that support various crypto and hash algorithms.

In the next blog post, we’ll look at cryptography in more detail and look at some examples of how cryptography can be implemented.