Chiplets and IP and the Trust Problem

Perforce recently hosted a webinar on “IP Lifecycle Management for Chiplet-Based SoCs”, presented by Simon Butler, the GM for the Methodics IPLM BU. The central theme was trust, for IPs as much as chiplets. How can an IP/chiplet consumer trust that what they receive has not been compromised somewhere in the value chain from initial construction to deployment in an OEM product?

What is the trust scope?

This feels like a big problem to tackle. On a quick search I see multiple proposed solutions to address different classes of attack:

• Late stage added hardware trojans, against which a physical inspection certification authority has been proposed,
• Known good die tagging with a PUF, where the correct tag is not reproducible in a fake die,
• Zero trust chiplets which assume they are operating in an insecure environment; good for them but doesn’t necessarily fix the total system,
• In the pre-silicon part of the chain mechanisms to fingerprint an IP component along with metadata for validation on receipt.

The Perforce approach to trust management

The last of these options is the area that Simon aims to address. This centers around the bill of materials (BOM) for the SoC. Each IP and the SoC itself can be characterized by multiple factors: version number, design configuration scripts, tool versions and configuration scripts, and embedded software. This last item can similarly be broken down to top-level code, libraries, and packages, etc. also with version numbers.

Simon advises that for each item in the BoM version numbers should be automatically updated where appropriate throughout the development lifecycle. These version updates are important to support traceability – who made what change, when and why. Metadata should be stored with IP information to track open bugs in each release and the release in which they were fixed and test results for the IP. I wonder if here they could also include a fingerprint for the simulation input and output? The results themselves would be too bulky to store but a fingerprint (like a hash over the testbench and the sim output) would be a tricky thing to fake.

Taken altogether, each component representation, and the BOM should be immutable, ensuring traceability of any changes in the BOM, and should therefore also be easily checkable, so if a change was introduced after the IP or soft SoC was shipped that fact would become apparent immediately.

Blockchain as a ledger management system for provenance

Of course if I am an experienced bad actor I can learn all the ways you generated your metadata and fingerprints and update all checks after I have inserted my malware. Simon’s suggestion to get around that problem is to use blockchain managed signatures for important metadata. Here, blockchain should be integrated into the component management platform so that ledger entries can be made and signed on each release. This is a much more difficult thing to compromise. In fact I wonder if blockchain couldn’t become a part of the larger chiplet trust solution? Interesting idea.

Methodics IP Lifecycle Management (IPLM)capabilities

Methodics provides a comprehensive range of IPLM capabilities, including a fully traceable ecosystem enforcing version immutability through design evolution, release management, IP discovery and reuse features including automatic cataloging of all IP and metadata, workspace management across design organizations and IP-centric planning support enabling different teams to understand characteristics and challenges flagged by other teams, in planning and during development.

You can register to view the webinar HERE.