System-On-Chip (SoC) Security Policies
Vedant Ghodke, 30th April
As we saw in the last blog, System-On-Chip (SoC) — Security Design And Modelling, SoC security is driven by the requirement to protect system assets against unauthorized access. Such access control can be defined by confidentiality, integrity, and availability (CIA) requirements. The goal of a security policy is to map the requirements to “actionable” design constraints that can be used by IP implementers, or SoC integrators, to develop protection mechanisms. Next, we present two examples of SoC security policies.
- Example 1: During boot time, data transmitted by the crypto engine cannot be observed by any IP in the SoC other than its intended target.
- Example 2: A programmable fuse containing a secure key can be updated during manufacturing, but not after production.
Example 1 is a confidentiality requirement, whereas Example 2 is an integrity constraint. However, the policies provide concrete conditions to be checked by the design for accessing an asset. Furthermore, access to an asset may vary, depending on the state of execution (for example, boot time or normal execution), or position in the development lifecycle. Following are some representative policy classes. They are not exhaustive but illustrate the diversity of policies employed.
Access Control
This is the most common class of policies and specifies how different agents in an SoC can access an asset at different points of the execution. Here, an “agent” can be a hardware or software component in any IP of the SoC. Examples 1 and 2 above are examples of such policies. Furthermore, access control forms the basis of many other policies, including information flow, integrity, and secure boot.
Information Flow
Values of secure assets can sometimes be inferred without direct access, through indirect observation or “snooping” of intermediate computation, or communications of IPs. Information flow policies restrict such indirect inference. An example information-flow policy might be the following:
Key Obliviousness: A low-security IP cannot infer the cryptographic keys by snooping only the data from the crypto engine on a low-security communication fabric. Information-flow policies are difficult to analyze. They often require highly sophisticated protection mechanisms and advanced mathematical arguments for correctness, typically involving hardness or complexity results from information security. Consequently, they are employed only on critical assets with very high confidentiality requirements.
Liveness
These policies ensure that the system performs its functionality without “stagnation” throughout its execution. A typical liveness policy is that an IP’s request for a resource is followed by an eventual response or grant. Deviation from such a policy can result in system deadlock or livelock, consequently compromising system availability requirements.
Time-Of-Check v/s Time-Of-Use (TOCTOU)
This refers to the requirement that any agent accessing a resource requiring authorization is indeed the agent that has been authorized. A critical example of TOCTOU requirement is in firmware update; the policy requires that firmware eventually installed on the update is the same firmware that has been authenticated as legitimate by the security or crypto engine.
Secure Boot
Booting a system entails communication of significant security assets, for example, efuse configurations, access control priorities, cryptographic keys, firmware updates, and post-silicon observability information. Consequently, boot imposes stringent security requirements on IPs and communications. Individual policies during boot can be access control, information flow, and TOCTOU requirements. However, it is often convenient to coalesce them into a unified set of boot policies.
After all, what can actually be inferred is the ability to weigh out these disadvantages and educate ourselves on the mentioned security vulnerabilities and educate ourselves with the newer security policies to prevent any mishaps!
Stay well, stay safe and stay updated!
