System-On-Chip (SoC) Security Policy Enforcement

Vedant Ghodke, 30th May

As we saw in the last blog, System-On-Chip (SoC) Security Policies, there are several security policies that have been demarcated for the purpose of prevention of attacks on SoCs. However, these policies require stricter enforcement for improvement in the pre-existing security systems.

The topic of Security Policy Enforcement is vital for enforcing security policies that are imperative for ensuring security at the hardware level. The following sections discuss a number of security policies and a “Centralized Policy Definition Architecture,” which is responsible for enforcing security policies.

SoC security architecture based on E-IIPS for efficient implementation of diverse security policies.

Centralized Policy Definition Architecture

Current industrial practice in implementing security policies follow a distributed ad-hoc implementation. Such an approach, however, typically comes at high design and verification cost. Recent work has attempted to develop a centralized, flexible architecture called E-IIPS for implementing security policies in a disciplined manner. The idea is to provide an easy-to-integrate, scalable infrastructure IP that serves as a centralized resource for SoC designs to protect against diverse security threats, at minimal design effort and hardware overhead. The figure above shows the overall architecture of E-IIPS.

It includes a microcontroller-based firmware upgradable module called security policy controller (SPC) that realizes system-level security policies of various forms and types using firmware code, following existing security policy languages. The SPC module interfaces with the constituent IP blocks in a SoC using “security wrappers” integrated with the IPs. These security wrappers extends the existing test (for instance, IEEE 1500 boundary scan based wrapper) and debug wrapper (for example, ARM’s CoreSight interface) of an IP. These security wrappers detect local events relevant to the implemented policies and enable communication with the centralized SPC module. The result is a flexible architecture and approach for implementing highly complex system-level security policies, including those involving interoperability requirements, and trade-offs with debug, validation, and power management. The architecture is realizable with modest area and power overhead.

Centralized Policy Definition Architecture (reference)

Furthermore, more recent work has shown that the existing design instrumentations, such as for DfD, could be exploited in implementing the architecture. Of course, the architecture itself is only one component of the policy definition. Several challenges remain, including:

1. Defining a language for security policy specification that can be efficiently compiled to SPC microcode
2. Study of bottlenecks related to routing and congestion across communication fabrics in implementing the architecture
3. Implementing security policies involving potentially malicious IPs (including malicious security wrappers or Trojans in the SPC itself). Nevertheless, the approach shows a promising direction toward systematizing policy implementations.

Moreover, by enclosing the policy definitions to a centralized IP, it enables security validation to focus on a narrow component of the design, thereby potentially reducing validation time.

Secure SoC Design Processes

Early Security Validation:

Secure development lifecycle of System on Chips

Pre-Silicon Security Validation

Illustrative SoC model depicting secure/insecure information flow

Post-Silicon Security Validation

Three important stages of SoC validation: pre-silicon validation, post-silicon validation, and on-field survivability

After all, what can actually be inferred is the ability to weigh out these disadvantages and educate ourselves on the mentioned security vulnerabilities and enforce the newer security policies to prevent unwanted data breaches and security risks!

This article is the last article from me, Vedant Ghodke, in this series of Security Risks In System-On-Chips (SoCs) and I hope that this publication served its purpose to have a review on the existing and upcoming security risks and policies!

Stay well, stay safe and stay updated!