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
Oct 23, 2020
Processing a component onto a PCB used to be fairly straightforward. Through hole products, a single or double row surface mount with a larger center-line rarely offer unique challenges obtaining a proper solder joint. However, as electronics continue to get smaller and conne...
Oct 23, 2020
[From the last episode: We noted that some inventions, like in-memory compute, aren'€™t intuitive, being driven instead by the math.] We have one more addition to add to our in-memory compute system. Remember that, when we use a regular memory, what goes in is an address '...
Oct 23, 2020
Any suggestions for a 4x4 keypad in which the keys aren'€™t wobbly and you don'€™t have to strike a key dead center for it to make contact?...
Oct 23, 2020
At 11:10am Korean time this morning, Cadence's Elias Fallon delivered one of the keynotes at ISOCC (International System On Chip Conference). It was titled EDA and Machine Learning: The Next Leap... [[ Click on the title to access the full blog on the Cadence Community ...

featured video

Demo: Low-Power Machine Learning Inference with DesignWare ARC EM9D Processor IP

Sponsored by Synopsys

Applications that require sensing on a continuous basis are always on and often battery operated. In this video, the low-power ARC EM9D Processors run a handwriting character recognition neural network graph to infer the letter that is written.

Click here for more information about DesignWare ARC EM9D / EM11D Processors

featured paper

Designing highly efficient, powerful and fast EV charging stations

Sponsored by Texas Instruments

Scaling the necessary power for fast EV charging stations can be challenging. One solution is to use modular power converters stacked in parallel. Learn more in our technical article.

Click here to download the technical article

featured chalk talk

Minitek Microspace

Sponsored by Mouser Electronics and Amphenol ICC

With the incredible pace of automotive innovation these days, it’s important to choose the right connectors for the job. With everything from high-speed data to lighting, connectors have a huge impact on reliability, cost, and design. In this episode of Chalk Talk, Amelia Dalton chats with Glenn Heath from Amphenol ICC about the Minitek MicroSpace line of automotive- and industrial-grade connectors.

Click here for more information about Amphenol FCI Minitek MicroSpace™ Connector System