Ensuring system-level security of complex SoCs

By Nicole Fern and Ruud Derwig |  No Comments  |  Posted: September 3, 2019
Topics/Categories: Embedded - Architecture & Design, IP - Selection  |  Tags: , ,  | Organizations: ,

Using a hardware root of trust and a secure development lifecycle process to form the basis of a better approach to developing and implementing more secure complex SoCs.

True system security begins with hardware. Without hardware security, even the most secure software base will be ineffective at preventing attacks. Processor designers use hardware roots of trust, a minimal amount of hardware and supporting software, to handle security-critical functionality such as device authentication, on-chip encryption, and bringing the system into a known and trusted state. This provides a firm foundation for protecting the wider system.

Ensuring system-level security requires adopting a secure development lifecycle (SDL) process, an approach borrowed from the software development world, to provide a framework of best practices and relevant tools to create more secure designs. Such an SDL starts with specifying the threats the device is expected to face, and then designs and develops the system to protect against them. In addition to making security a first-order design principle, an effective system SDL needs to verifysecurity at every stage of the lifecycle and recommend the most effective tools to do this. Achieving system-level security demands paying attention to hardware, firmware, operating systems, and applications. For modern processors, the interaction between hardware and software is complex and difficult to reason about or analyse with respect to security.

Existing hardware security verification strategies often rely upon manual approaches such as design architecture and code reviews and may only be applied to one part of the design lifecycle.  Other techniques, such as formal verification, have scalability issues preventing the adoption of these techniques for system-level hardware and software analysis. Simulation-based functional verification can scale to larger systems; however, it is difficult to express and verify security-relevant objectives related to confidentiality and integrity of design assets with existing tools. The best way to address this complexity, therefore, is to use automated tools to identify security vulnerabilities, building upon established functional verification environments.  This requires developing and adopting new technologies which are capable of efficiently capturing and verifying security policies, such as Tortuga Logic’s Radix-S pre-silicon security verification platform.

The Radix-S platform can be used to specify and verify security objectives centred around information flows, such as confidentiality and integrity of design assets, for Synopsys’ DesignWare ARC Processor IP, including verification of the ARC SecureShield technology for creating trusted execution environments (TEEs). System-level threat models can be specified and verified within existing functional verification environments that address both hardware and software.

The Radix-S tool also provides a framework for ensuring that ARC processor features are correctly configured and used, and that the processor is securely integrated into a larger system. This is important when software is used to configure hardware features such as memory protection units to prevent unprivileged access to key memory locations.

Trusted hardware and software provide a firm foundation for implementing key security functions such as secure boot, network authentication, and payment services. Software security can be strengthened by handling sensitive operations, such as manipulating and storing secret information, in an execution environment isolated from the rest of the code’s functionality.

Figure 1 shows two ways of doing this. At left in the diagram, a single-processor TEE has a single CPU that executes both trusted and non-trusted applications. On the right, in a ‘hosted TEE’ approach, each environment has its own CPU and other resources and the application processor acts as a host for the TEE CPU.

Two ways to implement a Trusted Execution Environment (Source: Synopsys)

Figure 1 Two ways to implement a Trusted Execution Environment (Source: Synopsys)

The single-processor TEE approach uses fewer hardware resources, reducing cost, but the TEE secrets and processing should still be isolated from the normal, non-trusted processing. The ARC processor IP can achieve this by implementing SecureShield technology, which introduces a new privilege level known as Secure Mode. This gives processors using the technology four privilege levels: normal-user, normal- kernel, secure-user, and secure kernel.

Figure 2 shows how SecureShield uses additional privilege levels and a memory protection unit to separate memory and memory-mapped peripherals into normal and secure partitions. Trusted software running in secure mode can access both sets of resources, while normal software can only access normal memory and peripherals.

SecureShield isolates normal and secure partitions on a processor (Source: Synopsys)

Figure 2 SecureShield isolates normal and secure partitions on a processor (Source: Synopsys)

Figure 2: SecureShield isolates normal and secure partitions on a processor

ARC processors also have security features including hardware stack boundary checking, side-channel protection against timing and power analysis physical attacks, and secure debug.

Another way to separate trusted, secure software from normal, non-trusted software is to run it on a separate core. This stops the general-purpose CPU affecting data being handled by the secure CPU. The memory for each CPU must be physically separated by tightly coupling it to the processor, using separate buses, or using other bus and address-map protection mechanisms. While providing strong isolation, this approach also makes communication between the normal and trusted environments more complex.

Tortuga Logic’s Radix-S tool is designed to make it easier to find and fix security vulnerabilities which exist in hardware or in the usage and configuration of hardware features by software. It analyses the hardware during software execution to find vulnerabilities and their sources, and then offers guidance about resolving them. The tool integrates into existing functional verification environments for ARC processors.

The tool uses four steps which span the entire pre-silicon SDL process:

1 – Specify the security threat model

Tortuga Logic’s Sentinel language enables designers to write rules that specify which assets need protection and the conditions under which they can be legitimately accessed.

2 – Generate a security model

The Radix-S tool imports the design RTL and the security rules and generates a security model for the design (Verilog IP).

3 – Insert security model into the functional verification environment

The security model runs in the existing verification environment alongside the original RTL. Both hardware-centric verification suites as well as processor software can be used to detect security rule violations during simulation. The security model IP is only used during security verification and does not become part of the design implementation.

4 – Analysis

Analysis tools, tailored for debugging security rule violations, enable exploration of the  management of critical assets in the design.

Figure 3 shows how Radix-S fits into an existing design and verification flow for ARC processors. The Sentinel security rules are re-useable and can be applied to other ARC-based systems that share the same threat model.

The Radix-S tool flow integrates with current ARC development environments (Source: Synopsys)

Figure 3 The Radix-S tool flow integrates with current ARC development environments (Source: Synopsys)

Synopsys offers a case study that outlines how Tortuga Logic and Synopsys created security rules to address two common threat models related to secure debug and leaking secret information from the Secure Mode to the untrusted Normal mode.

The first covers verifying that when a design includes a debug port with a security lock, it actually stops unwanted information flow when the debug port is locked.

The second covers verifying that any software running on the normal side of a secure CPU implementation cannot exploit misconfigurations of the memory protection unit to read from or write to memory on the secure side of the design.

Further information

The case study, which includes details of the security rule sets for each scenario, as expressed in the Sentinel language, block diagrams of the architectural features that are being protected, and screenshots of how the results are presented graphically, is available in the white paper, Configure, Confirm, Ship: Build Secure Processor-Based Systems with Faster Time-to-Market.

Author

Nicole Fern, senior hardware security engineer, Tortuga Logic; Ruud Derwig, senior staff engineer, Synopsys

Company info

Synopsys Corporate Headquarters
690 East Middlefield Road
Mountain View, CA 94043
(650) 584-5000
(800) 541-7737
 www.synopsys.com

Sign up for more

If this was useful to you, why not make sure you’re getting our regular digests of  Tech Design Forum’s technical content? Register and receive our newsletter free.

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

PLATINUM SPONSORS

Synopsys Cadence Design Systems Mentor - A Siemens Business
View All Sponsors