Accellera IP security group expects standard by year end

The chair of Accellera’s IP security assurance working group expects the draft standard for hardening hardware core to be out by the end of the year.

The IP Security Assurance (IPSA) standard is being designed to provide a means to let IP developers communicate the security aspects of their products to integrators in a consistent way and one that lends itself to automation. In a session on design for security at DAC, Brent Sherman, working group chair and principal engineer at Intel, provided more detail on how the standard is likely to work since the publication of a white paper last autumn.

Sherman said there are limitations to a security standard like this. “The standard can be used to harden trust but not establish it. Also, Trojan detection would not be addressed by this methodology.”

As described in the white paper, the core of the standard’s approach is a knowledge base of security issues called the Common IP Security Concerns Enumeration (CIPSCE), which itself is based on a curated collection of known threat types maintained by The MITRE Corporation.

An example of the kind of threat detailed by the Common Weakness Enumeration is CWE-1209 – Failure to Disable Reserved Bits. In this situation, an IP vendor might have reserved locations in a control register to control functions that may be added in the future that are not explicitly disabled in the core itself. Surrounding hardware implemented by the IP integrator would need to include logic to block writes to these bits in case they trigger unintended reactions, ensure that any outputs are disabled or raise an exception on the attempt.

The key to automation in the standard lies in the decision to connect security concerns to ports and configuration settings. If an IP vendor sees a potential issue for security that could arise after integration if the problem is not explicitly blocked they create an asset definition that identify the vulnerable port and its likely weakness assigned from the relevant listing in MITRE’s CWE. A compilation tool then creates what the standard calls an element and in turn an attack surface security object (ASSO).

The elements associated with the IP core are compiled into a JSON stream that is provided alongside the asset definitions and the IP itself so they can be used to check the security concerns are up to date. The idea is that on receipt a tool would examine the RTL and the asset definitions to build a set of elements independently. If the two sets of elements do not match, it signals a problem with the delivered assets.

If the elements databases match, then the integrator would be expected to examine the ASSOs to work out whether they fit the intended use. It may be the case that users would not have direct access to configuration registers and so have no ability to toggle reserved bits to see what they do. “They may also identify additional objects that are relevant: the IP provider may not have prior knowledge of what the IP would be integrated into,” Sherman said.

Sherman claimed the standard fits the initial requirements of having a low overhead with minimal tooling needed. “We also wanted it to be flexible and scalable and to have some kind of verification. This methodology can apply to legacy designs but we also provided for expansion in the objects with user-defined fields.

“We aim to have public candidate by the end of the year. We are almost there now, to be the point we might even be ahead of schedule,” Sherman concluded.