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
Jul 1, 2022
We all look for 100% perfection and want to turn our dreams (expectations) into reality as far as we can. Are you also looking for a magic wand to turn expectation into reality? The story applies to... ...
Jun 30, 2022
Learn how AI-powered cameras and neural network image processing enable everything from smartphone portraits to machine vision and automotive safety features. The post How AI Helps Cameras See More Clearly appeared first on From Silicon To Software....
Jun 28, 2022
Watching this video caused me to wander off into the weeds looking at a weird and wonderful collection of wheeled implementations....

featured video

Demo: Achronix Speedster7t 2D NoC vs. Traditional FPGA Routing

Sponsored by Achronix

This demonstration compares an FPGA design utilizing Achronix Speedster7t 2D Network on Chip (NoC) for routing signals with the FPGA device, versus using traditional FPGA routing. The 2D NoC provides a 40% reduction in logic resources required with 40% less compile time needed versus using traditional FPGA routing. Speedster7t FPGAs are optimized for high-bandwidth workloads and eliminate the performance bottlenecks associated with traditional FPGAs.

Subscribe to Achronix's YouTube channel for the latest videos on how to accelerate your data using FPGAs and eFPGA IP

featured paper

3 key considerations for your next-generation HMI design

Sponsored by Texas Instruments

Human-Machine Interface (HMI) designs are evolving. Learn about three key design considerations for next-generation HMI and find out how low-cost edge AI, power-efficient processing and advanced display capabilities are paving the way for new human-machine interfaces that are smart, easily deployable, and interactive.

Click to read more

featured chalk talk

Hot-Swap and Power Protection -- Mouser Electronics and Analog Devices

Sponsored by Mouser Electronics and Analog Devices

When it comes to our always-on, critical systems we need to carefully consider power protection and maintainability. In this episode of Chalk Talk, Amelia Dalton and Dwight Larson investigate the issues that surround hot-plugging into an energized power supply, the best solutions to consider, what the different hot-swap circuit topologies look like for a variety of applications and why the MAX15090B/C with its innovative current foldback startup may be the best solution for your next design.

Click here for more information about Maxim Integrated MAX15090B/MAX15090C Hot Swap ICs