feature article
Subscribe Now

Silicon IP Security Proposal

Accellera’s IPSA Working Group Puts Forth a Flow

The upshot: Accellera has published a whitepaper on the topic of silicon intellectual-property security, and they’re soliciting comments.

Last summer, there were a number of security-related topics at the annual DAC conference, which we covered in August. That activity included Accellera diving into the issue of security surrounding silicon design and, in particular, risks associated with intellectual property (IP) – meaning pre-designed circuits purchased or re-used. It was there that they announced a new working group called the IP Security Assurance (IPSA) group.

A Specific Process

IPSA has made progress since then, publishing a whitepaper on its proposed approach to identifying and mitigating security risks during the silicon design process. This approach modifies the standard high-level design flow and establishes a database referred to as CIPSCE (which I assume to be pronounced “sipsey,” and which stands for “Common IP Security Concerns Enumeration”). We’ll work through the high-level notions here, referring you to the whitepaper for details (link at the end).

Their modification to the design flow is shown below, with the addition of four elements (in yellow):

  • Defining “assets” that might be at risk,
  • Including references (or “associations”) to the CIPSCE database,
  • Defining the vulnerable attack surfaces, and
  • Building a threat model.

 

(Image courtesy Accellera)

In this situation, “assets” refer to components within the IP that could be of value. There’s literally a list of 17 families of asset – things like Audio/Video, Microcontroller, and Test/Debug. The attack surface, by contrast, lists the various vulnerabilities that might exist – ways that someone could try to break in. For each asset, one identifies various ways in which someone might try to compromise the asset.

This then works hand-in-hand with the CIPSCE database. Each CIPSCE entry includes a “consequence” characteristic (confidentiality, integrity, or availability), how the threat might be introduced into the design, and how risk from that threat can be mitigated. Each such threat is also mapped to the various asset families to which it applies.

The idea, then, is that well-understood issues and their resolution can be captured in this knowledge base for others to benefit from. It very much resembles other lists of common concerns for cybersecurity. But this also makes it a living list – as new threats are understood, they can be documented there. While useful, this also creates a challenge: between the time analysis on a circuit is done and its use, there’s the possibility of missing threats that might have been identified later. It’s tough to keep designs up to date with respect to all vulnerabilities. IPSA is soliciting feedback and comments regarding how this concern could be resolved.

Roles and Responsibilities

The next high-level question is: who performs all of these tasks, and are they done manualy? It’s important to remember that there are two main design phases that involve IP: the design of the IP itself and the integration of that IP into a larger design. 

Much of what’s discussed in the Accellera paper relates to the IP design process. The information assembled can then be of use to someone integrating the IP. Yes, there’s value to establishing this as a discipline for good IP design, resulting in IP that’s more secure. But there’s also value to providing IP users with information on where the vulnerabilities are and how the attack surfaces can be blocked.

One of the take-aways from this summer’s discussion was that, for the time being, the security design process for any design project starts from scratch, with no benefit from prior learning or automation. This new security process might help to address that concern, both by establishing the knowledge base and by providing options for automation. Of course, Accellera as an organization wouldn’t be doing the automating; EDA companies would.

Specifically, they suggest that the CIPSCE associations and identification of attack surfaces could be done by an EDA tool that parses the IP design. Having a robust way of doing this analysis automatically would remove a hugely error-prone manual component of the process. Exactly how that analysis would work, however, is out of the scope of what Accellera would do; this would be up to the EDA companies to find the best techniques.

A number of responsibilities would remain with the IP designer, starting with the initial identification of assets. The proposal includes a table that the designer would fill in – including CIPSCE associations and attack surfaces. If EDA automation of those last two materializes, then the designer could leave those entries blank when doing the manual work, relying on the EDA tool to fill them in.

The designer would then need to package all of this up into the collateral that would accompany the IP for sale (or for re-use). They suggest that this collateral-creation process could also be automated – something that would apply a clean, consistent, and recognizable format for the designers integrating the IP into their larger designs.

That integrator would have a couple of options when acquiring the IP. First, they could use the security documentation as is to decide which of the CIPSCE elements listed applies to the specific system where the IP is used and to test the attack surfaces. Alternatively, they could completely run the EDA tools again to confirm the original list by recreating the CIPSCE associations and attack surfaces as a way of verifying the collateral. They would then also be able to review the latest CIPSCE list to make sure there wasn’t anything that the original analysis missed.

The good news is that this whole process – in whatever final form it eventually takes after feedback and revisions – should add some welcome rigor to what is now pretty much a scattershot process that’s being reinvented daily. The bad news is that, for designers who aren’t worrying about security at all today, this does involve some extra work – even if some automation is available. But, frankly, it’s work that they probably should already be doing, and this will make it easier.

Of course, not all designs are equally at risk. Obviously, designs intended for, say, DARPA will need to be as rock-solid as possible. Other systems, like PC peripherals, might seem to be of less concern. But it’s hard to imagine anything that would be of zero concern. Most components – like peripherals – attach to systems that are connected to other systems, and those innocent, unassuming components might be just the way to break in – not for what’s in the component itself, but for the access it gives to the rest of the system, where more attractive goodies might be found.

The IPSA proposal is open for comment; you can read it in detail at the link below.

 

More info:

Accellera IPSA whitepaper

 

One thought on “Silicon IP Security Proposal”

Leave a Reply

featured blogs
Jun 18, 2021
It's a short week here at Cadence CFD as we celebrate the Juneteenth holiday today. But CFD doesn't take time off as evidenced by the latest round-up of CFD news. There are several really... [[ Click on the title to access the full blog on the Cadence Community sit...
Jun 17, 2021
Learn how cloud-based SoC design and functional verification systems such as ZeBu Cloud accelerate networking SoC readiness across both hardware & software. The post The Quest for the Most Advanced Networking SoC: Achieving Breakthrough Verification Efficiency with Clou...
Jun 17, 2021
In today’s blog episode, we would like to introduce our newest White Paper: “System and Component qualifications of VPX solutions, Create a novel, low-cost, easy to build, high reliability test platform for VPX modules“. Over the past year, Samtec has worked...
Jun 14, 2021
By John Ferguson, Omar ElSewefy, Nermeen Hossam, Basma Serry We're all fascinated by light. Light… The post Shining a light on silicon photonics verification appeared first on Design with Calibre....

featured video

Kyocera Super Resolution Printer with ARC EV Vision IP

Sponsored by Synopsys

See the amazing image processing features that Kyocera’s TASKalfa 3554ci brings to their customers.

Click here for more information about DesignWare ARC EV Processors for Embedded Vision

featured paper

Carmakers charge ahead with electric vehicle powertrain integration

Sponsored by Texas Instruments

When we advance EV powertrain architectures, carmakers can cut system-design cost in half while maximizing power density, increasing efficiency, improving reliability and making EVs more affordable for more people.

Click here to read more

featured chalk talk

Silicon Lifecycle Management (SLM)

Sponsored by Synopsys

Wouldn’t it be great if we could keep on analyzing our IC designs once they are in the field? After all, simulation and lab measurements can never tell the whole story of how devices will behave in real-world use. In this episode of Chalk Talk, Amelia Dalton chats with Randy Fish of Synopsys about gaining better insight into IC designs through the use of embedded monitors and sensors, and how we can enable a range of new optimizations throughout the lifecycle of our designs.

Click here for more information about Silicon Lifecycle Management Platform