The semiconductor ecosystem is abuzz with the promise of chiplets, but there is far less attention being paid to security in those chiplets or the heterogeneous systems into which they will be integrated.

Disaggregating SoCs into chiplets significantly alters the cybersecurity threat landscape. Unlike a monolithic multi-function chip, which usually is manufactured using the same process technology, chiplets can be developed anywhere and at any process node. In fact, among the key reasons for developing heterogeneous chiplets are that not every function benefits from the latest process technology, and not all of them can be crammed onto a single die. But that also raises the threat level, and the industry is struggling to deal with security issues in a repeatable and cost-effective way.

“Some of these are built in a way that they can be affordably reverse-engineered or re-manufactured, with some malicious functionality added to the chiplet because it’s a much smaller die,” said Scott Best, senior director, silicon security products at Rambus . “It’s not a 20 x 20mm die anymore with 50 billion transistors. It’s a million transistors and it does a very specific function. There are state-funded actors around the world that could clone that functionality, put it into a compatible process node, and add a malicious capability to it. And now the risk is they somehow insert that malicious component into the supply chain, and it gets inadvertently integrated. It’s a little bit scary, especially in its do-ability. I’m not sure a lot of people fully appreciate how easy it is to clone small chips built in trailing-edge technology nodes. Trailing edge starts to mean more and more things as time goes by. Even 22nm, which was once state-of-the-art, is three or four generations behind us now. They become very appetizing targets, especially if coming up with that chip gives an adversary access to a much larger end market.”

A key challenge is to develop a supply chain with robust traceability. “Let’s say a customer is concerned about whether security is built into a chip,” said Tony Mastroianni, advanced packaging solutions director at Siemens Digital Industries Software. “A lot of the die-to-die interfaces have security built in. But there are other considerations for traceability, which is a different issue. We want to make sure that for the whole design process you’re not compromised, and that requires covering all the way from RTL design to manufacturing delivering the parts. It’s a whole different beast.”

Integrating multiple chiplets into a heterogeneous package opens the door for security breaches and potential risks associated with malicious modifications or attacks on the individual chiplets during design, assembly, or test. “Also, because chiplets are often designed and manufactured by different vendors, there is a risk that a malicious actor could compromise one of the vendors and use that access to compromise the entire chiplet-based system,” Mastroianni said.

Some of these concerns began with SoCs, but chiplets are raising them to a whole new level. “Security issues still exist, but with chiplets they can be much harder to prevent,” said Guillaume Boillet, senior director of product management at Arteris IP. “Now, coordination is needed across who’s doing the chiplet since some countermeasures require the chiplets and the software to work hand-in-hand. Beyond that, with chiplets, there is a bigger surface of attack, and out of this, two categories of problems emerge. First is hardware Trojans. In heterogeneous systems where the chiplets could come from different companies, the idea that some companies will reverse-engineer some of the chips that comprise the chiplet and replace it with a malicious one — that sounds like science fiction. But this threat exists, especially when it comes to IoT and all those things is probably more achievable than it is for a big system.”

The second problem is a wider attack surface, in part because the connections between the chiplets are a lot easier to track. That creates the possibility of a man-in-the-middle attack.

Some of this depends on the complexity of the supply chain for chiplets. Companies like Intel, AMD, and Marvell develop their own chiplets, which minimizes supply chain threats. But companies assembling and integrating commercially developed chiplets will have a much tougher time.

“Chiplet authentication is not such a problem if you’re a single company,” said Mick Posner, product line senior group director, High Performance Computing IP Solutions at Synopsys. “You’ve disaggregated your SoC, you own both sides, you are familiar with your supply chain, so the potential for a malicious chiplet getting into your supply chain is probably pretty low. You’ve created a package that has your die and some third-party die, and they need to communicate with each other. One of them has to take the lead and say, ‘I’m the manager, you’re the sub. Please declare you are an authentic chiplet.’ Today, there is no standard around that. It is mentioned in the UCIe spec as something to be addressed in the future.”

It’s a different story with a chiplet marketplace. “At the moment, because there’s not really mixing and matching of die, it’s really not an issue,” Posner said. “But it will be shortly. To alleviate a malicious die getting into your supply chain, you have to have some form of authentication, and now that you’re an authenticated system, what if someone’s trying to do a hard hack where they’ve taken the package apart and somehow are getting access to the links between those two die? What sort of encryption or protection is put in place to go over those links?”

Others agree. “This mixed supplier ecosystem doesn’t yet exist, i.e., an ecosystem in which suppliers are supplying some standard functions that can be reused in a lot of systems, and the primary vendor of the integrated package is buying those from one of several potentially competitive suppliers to include into their package,” said Mike Borza, Synopsys scientist. “You can imagine things like system controller chips and TPNs and all kinds of stuff like that being good examples of things that will be integrated in this way because they have well-defined functionality and there are protocols around them.”

Supply chain issues
The more suppliers of chiplets, the harder it is to secure everything.

“You’re going to have more vendors involved,” said Steve Carlson, director/architect, aerospace and defense solutions at Cadence. “You have multiple chiplets, so you probably have a new interposer vendor, as well as new packaging and test folks everywhere along the supply chain. Even before that, with the IP blocks that go into the chiplets, there’s potential for malfeasance or errors. Additionally, there are issues with the interoperability of the chips with regard to their safety protocols, and what are ‘safe use’ models. Those things aren’t always communicated clearly, so when you connect two secure chiplets together, it may be done in a way that undoes the chips.”

Fig. 1: Why chip companies are looking to adopt chiplets. Source: Cadence

This is particularly true for interconnects.

“You have exposed those interconnects between them to be more easily exploited,” Carlson said. “Along with these high-level considerations, there are the traditional issues, as well, having to do with Trojans. You could produce things that are out of spec with regard to the materials and the interconnect on the interposer, overproduction, counterfeits, reverse engineering, side channels, and recycling kinds of things.”

System-wide security
Approaches to improving chiplet security vary greatly, but first and foremost there needs to be a focus on system-wide security.

“System-wide security review has now become an integral part of the development cycle of any product that has any interaction with customer data,” said Rajesh Velegalati, senior security analyst at Riscure. “Certification entities like Common Criteria and EMVCo also play a crucial role in ensuring these products adhere to security standards.”

However, if these security reviews are conducted in the latter phases of the design cycle, “even if vulnerabilities are found, fixing them might become an issue in itself,” Velegalati said. “If the vulnerabilities are found in the hardware or the immutable ROM code (the first piece of code which the product executes on powering up), patching in mitigations would be difficult and may be downright impossible. In this scenario, the product might be released with vulnerabilities, and the manufacturers are only able to patch it in the next iteration of the product. The next iteration will depend on the product lifecycle, which could be a minimum of one to several years.”

Complicating matters is that every customer has different concerns about security and trust, and has different approaches to address those concerns.

“DoD customers are all about security, and know more about security than we do, including encryption and decryption, and so on,” said Geoff Tate, CEO of Flex Logix. “When an FPGA is embedded inside the chip, the customer can put a lot of security around the FPGA. The biggest concern that commercial customers have is people with packages can snoop and see data coming in and out of the package. But the DoD is worried about people even using sensors to detect stuff happening inside the package. Those guys are very concerned about security, but they don’t need us to provide solutions. With commercial customers, people use embedded FPGA first from a security angle because they can reprogram stuff. So if they have an encryption algorithm, and it gets broken, they can reprogram the encryption algorithm if it’s an embedded FPGA. They can’t if it’s hardwired.”

The notion of secure communications between chips is something that has been studied with anti-snooping measures, unauthorized memory accesses, and other approaches.

“Those issues have been worked on, and are being worked on,” Cadence’s Carlson said. “Security in the past has been a one-off project per program endeavor. Now we’re looking to standardize those things, and it’s very difficult because with the DoD — whether it’s a civilian system or not — when something gets exploited, they like to classify the data and make it secret. MITRE CWE is the rallying point that we can work on. It’s an abstracted view of what the vulnerabilities are, and they can talk about some common mitigation techniques at that level. The hope is that will help drive things toward standardization more quickly as people agree upon what the threat vectors are that are most important to protect against.”

Moving forward, Riscure’s Velegalati said the best way to address this issue is to include security reviews in the design phase of the product itself. “In other words, finding and fixing vulnerabilities pre-silicon, so that after the chips are fabricated, hopefully they won’t have any of the identified vulnerabilities. This might require a cultural change in the way a development cycle itself is executed.”

There are several commercial tools available to detect vulnerabilities in software using static and dynamic analysis techniques.

“Deployment of security agents can help ensure system bring up integrity, operation and the detection and recovery from compromised events,” said Siemens’ Mastroianni. “Additionally, ensuring the source integrity and traceability of the chiplet components throughout the full supply chain will become a critical requirement for new and existing products. By ensuring the source and integrity of each chiplet can be verified and traced back to its source, it becomes easier to identify and respond to any security or trust issues that may arise.”

Levels of chiplet security
Another way to approach chiplet security is with a layered approach.

Pim Tuyls, CEO of Intrinsic ID, points to three layers of chiplet security. “One is that you say, ‘We are going to make sure that every part can be identified,’ and use a physical unclonable function (PUF) as an identifier. The advantage of that solution is it’s lightweight. Second, you say, ‘We need a little bit more. Namely, we need chiplets that can securely communicate with each other, and can authenticate each other. You can do that with symmetric crypto. Here, you implement the PUF on every chiplet with symmetric crypto attached to it. The advantage is that all those chiplets can create their own keys, and can run a key exchange protocol. You don’t have to program every chiplet. Third, you say, ‘We want the highest level of security, and the most sophisticated.’ That could be tough in a public key infrastructure (PKI) system. PKI can be classical PKI as we know it with RSA or ECC, or it could be post compromised PKI. From that point, it means that you’re going to make your system way more complex. Chiplets will have a PUF, will have asymmetric and symmetric functionality, and will be able to do secure key sharing between the different chiplets, as well as create different sets of symmetric keys. Based on that, then we’ll be able to securely communicate. That is the most advanced system, but also the most expensive system.”

Are solutions in place?
One open question is whether the chiplet security solutions will be in place when they are needed.

“We have 100% confidence that the solutions will be available in the timeframe that they’re required,” said Rambus’ Best. “Even if I just look at our anti-counterfeiting experience, we still have customers showing up asking us for anti-counterfeiting solutions. So, the technique of protecting against this are known. The downside is that none of it comes for free. It makes manufacturing 10 cents more expensive for a $5 chip most commercial vendors will reluctantly agree to. Others will negotiate until it’s only a 5-cent cost hit, or maybe less than a penny. ‘How much can I protect this for less than a penny, because I’m on razor thin margins right now?’ One ends up dealing with somebody who’s responsible for procurement and manufacturing. The security architect has long since been taken out this conversation. You can build a very secure product with a very secure supply chain. We absolutely know how to do that. We have this technology, we know how to deploy it, we know how to deploy it cost-effectively. What’s difficult is just the normal decisions about whether we really solve for all of the security problems first, or is ‘perfect’ the enemy of ‘good’ here? Can we just pursue good and see if that’s sufficient and tested?’”

Others point to similar experiences. “Security isn’t done for free, and until you’ve been bitten, you probably don’t want to spend money on it,” Carlson said. “It’s like insurance. The systems companies bear the brunt of the responsibility. In cell phones and automotive, as well as areas that have been public about hacks, they have to do something. They have been hurt financially by security-related issues. In product areas where they haven’t been hurt yet, they really aren’t doing everything they could. They’re not doing nothing, but they’re doing less than they could. Another issue is that you could spend $100 million on security and still get hacked. There isn’t a single, assured solution for that problem. Hackers are really inventive and coming up with new and crazy ways every day.”

Additionally, chiplets can be reverse-engineered. How do you detect whether a chiplet has been tampered with? Arteris’ Boillet said solutions do exist, at least from some providers. “We work with them with our joint customers to help them implement those systems, especially in SoCs, to make sure the chiplets are properly identified,” he said. “In different angles of attack, they all have one idea to address it, but they come with their own challenges. Most will require, for instance, that the two chiplets are really designed hand-in-hand. So when you consider those attacks with the man-in-the-middle, where the connection between the two chiplets could be probed, there is a way to fix that by only sending encrypted messages. But every time you talk about encryption, it needs to be encrypted on one side, decrypted on the other side, and needs to be the same piece of IP. This is quite involved, but it can be addressed if it’s an in-house chip disaggregation, where the two chiplets come from the same vendor. However, if we start talking about an ecosystem where it’s off-the-shelf parts, we’re going to need standardization well beyond everything we have in terms of electrical compatibility. What is apparent beyond all the discussion we have with customers while doing chip disintegration is that it’s the mechanical aspect of it. The mechanical and physical aspect are not really addressed yet.”

New standards
On the standards front, there is a CDX working group in OCP that covers security, and within the UCIe, there is also a working group dedicated to chiplet security, but it is still very early days in both cases. Synopsys’ Borza noted UCIe is coalescing around PCIe and CXL by and large. “That’s an important part of the equation, and means they’ll be able to coast on the coattails of the work that’s being done in CXL and IDE.”

Also, in the realm of chiplet security standards are approaches like security protocol data model (SPDM) to do the mutual authentication of the chiplets across chiplets.

“Once SPDM has run, there are protocols that can use the fact that you’ve got an authenticated connection now to set up an encrypted link to address the other aspect, because integrated parts made of chiplets sit somewhere between chip-on-board and a fully integrated SoC in a single-die kind of solution,” Borza explained. “They are more vulnerable than an SoC to physical probing attacks, but they’re less vulnerable than a chip-on-board. But that vulnerability still exists because it’s much easier to probe a chiplet-to-chiplet link than it is to probe something on a chip itself. It’s not simple by any means, but it’s easier. The way I see this shaking out is that we’re actually going to be able to benefit from some of the other work that’s being done, and we won’t get it for free. It’s expensive to have high-bandwidth links that are running at low latency that are fully encrypted, but it is possible. We’re doing it now with CXL, and we’ll be able to move along that path with chiplets.”