Tensilica Security

2021 was famous for some of the worst security issues (accompanied by obligatory picture of bad guy in a black hoodie):

• The very first blog post of the year covered SolarWinds. See my post The Biggest Security Breach Ever.
• The middle of the year saw the ransomware attack on Colonial Pipeline leading to gas shortages on the East Coast. See my posts Update: CadenceLIVE India, Ransomware, 2nm, and More, June Update: PCIe 6.0, Ransomware, Mars, Turing Award...and CadenceLIVE, and Evolving Maturity in Ransomware.
• Almost the last post of the year was on Log4J, see my post Log4J: 2021 Ends the Same Way It Began.

Everything needs to be secure, and it is unrealistic to assume that every programmer is suddenly going to become an expert in security. And when I say everything, I don't just mean the obvious things like banking or cryptocurrency. Internet of things (IoT), wireless communication such as 5G and WiFi, automotive (which has its own security standard (see my post Have You Heard of ISO 21434? You Will), and obviously data centers. All of these domains involve network connectivity, over-the-air updates, third-party components, and attack from large organizations operating at scale. For example, see my post linked above about maturity of ransomware and how the bad guys are becoming more professional, which I don't mean in a good way.

It is now generally accepted that security has to start from a hardware root of trust, and that security that is implemented purely in software will never be secure. Here's a common use case, the sort of code that should no longer be used:

• Host CPU is responsible for system booting
• Host CPU then executes the user application and offloads certain tasks to DSPs
• Host CPU and DSPs share on-chip memory and system peripherals
• DSPs perform specific tasks using proprietary piece of code
• DSPs also run untrusted code from different providers
• Sensitive data and proprietary IP is stored in the DSP memory

This does not start from a hardware root of trust, so there are security threats everywhere:

• Host CPU might not boot the trusted firmware image, or an authenticated user application
• Untrusted code might access proprietary IP or sensitive data such a keys on DSPs
• Result: unlawful access, unauthorized OTA updates, theft of IP, incorrect operation

That is just the obvious attacks. There are also side-channel attacks such as differential power analysis or electromagnetic emission analysis. See my posts EDPS Cyber Security Workshop: "Anything Beats Attacking the Crypto Directly" and Hardware Hacking Party Tricks. There are also things like decapping (removing the package) or inspecting die with electron microscopes.

Tensilica Security Strategy

Cadence's Tensilica processor approach combines cryptography, hardware isolation, along with secure boot and hardware root of trust:

• Cryptography
  • Software IP and data that needs protection are stored as encrypted hash
  • When in use, the encrypted image and data can be authenticated and decrypted on the fly
• Hardware isolation of assets/resources
  • Hardware partition of secure and non-secure worlds
  • Assets that need protection are stored in the secure world and protected from access by untrusted software that runs in the non-secure world
• Secure boot and hardware root of trust
  • Ensures system boots from only authenticated code and the code is fetched from a trusted location
  • Secure debug

I won't go into everything here in detail. Cryptography and code-signing is fairly well understood, and although this example is not Tensilica processor-based, the basic principles are the same as explained in my post Google's Titan: How They Stop You Slipping a Bogus Server into Their Datacenter.

Hardware isolation of assets is implemented by partitioning the world into a secure and a non-secure world. Memory regions and resources can be grouped depending on privilege levels. See the image below, which shows the Tensilica Xtensa LX Secure Mode (XLS). The red is the non-secure world, the blue is the secure world. The separation is hardware enforced. In particular, the non-secure mode has no access to secure resources, only non-secure resources.

Additionally, there is the Xtensa LX7 Secure Mode Software Model, consisting of:

Secure boot loader SBL (to set up the MPU and load non-secure executables) and a secure monitor SM (to service system calls made from non-secure mode). SBL and SM are combined into a single executable "secmon". Secure mode isolates SBL and SM resources from the rest of the stack.

Underlying everything is the hardware root of trust (RoT) which ensures that the device boots from a known state and the boot image is authenticated, and then the device firmware is authenticated too. Tensilica processors support RoT and secure boot when combined with external RTL implmenting:

• Hardware cryptographic engine
• e-fuse memory or OTP memory for public key storage
• TRNG/PUF for generating the private key (optional).  [TRNG is true random number generator; PUF is physically unclonable function.]
• Secure JTAG for debugging

Beyond Semiconductor

Cadence has partnered with Beyond Semiconductor to provide a secure boot subsystem around Xtensa, based on the GEON security platform:

• Enable secure boot on Xtensa
• Enable secure JTAG
• Cryptographic engine
• In general, provide a secure subsystem that can be customizable to customer’s requirement

Putting it all together, here is an example secure subsystem combining Xtensa with Beyond Semi's secure boot, crypto engine, and secure JTAG:

 

Sign up for Sunday Brunch, the weekly Breakfast Bytes email.

.