Cyber Threats Multiply With Commercial Chiplets

The commercialization of chiplets will significantly boost the potential for attacks on hardware, requiring a much broader set of security measures and processes at every level of the supply chain, including traceability from initial design to end of life.

Much progress has been made in recent years on security measures, including everything from identifying unusual data traffic inside a chip to complex obfuscation techniques. But chiplets multiply the number of possible attack vectors, and the more chiplets there are in a design the harder it is to protect a device since there is more data being processed, moved, and stored, and more components are involved in making that happen.

“Even if all chiplets within a device have a secure element, such as a root of trust (RoT), there is no guarantee they will easily communicate with each other,” said Lee Harrison, director of Tessent automotive IC solutions at Siemens EDA. “And this runs the risk of compromising the overall security at a device level.”

One problem with RoTs is they consume significant silicon area and power. So unless all the chiplets in a system are of significant size, the overhead of having a dedicated RoT for each chiplet may be unrealistic. “There are a number of working groups and chiplet alliances that are working to solve such problems, one being the Automotive Chiplet Alliance (ACA) headed up by imec,” said Harrison.

Individually, chiplets are no more susceptible to hacking than any other die. The problems arise when there are multiple chiplets packaged together.

“A chiplet is just a chip that’s packaged differently,” according to Scott Best, senior director, silicon security products at Rambus. “Most chips don’t get their own package. But now it’s like chips with roommates. It is a fun and interesting packaging problem that you’re not just packaging a chip by itself anymore. However, now it has to talk to all of its roommates, and then one or several of the roommates are talking to the real world through the I/O, and that gets interesting.”

Chiplets share the same security problems as any other chips. “There are 20 different attack vectors, all the way from stealing the database, bribing people who are in the design team or verification team to insert malicious circuitry or share design secrets, to the human aspects, and whether the chip has any secrets that are protecting confidential information,” Best noted. “The attacker wants to steal those secrets, or reverse engineer the circuits that are protecting them, or do some sort of power analysis side channel to cause information leakage out of the chip. There’s a wealth of ways that chips and chiplets can all be attacked.”

Others agree. “Essentially, we’re trying to assure that when you stitch the system and package together, that all of the things that show up on the interconnect are authorized to be there, and that they’re the exact unit you were expecting to find if you break it down to its individual identity,” said Mike Borza, scientist and principal security technologist at Synopsys. “If you can do that, then you have some assurance that the system has initial integrity.”

Depending on what other security attributes are assigned to those links, the security can be maintained over the lifetime of the session. “From reboot to power down is the biggest thing to assure that you know what is attached to the interconnect,” Borza said. “You can make that interconnect confidential by encrypting the data on it, but in many cases it’s sufficient to just assure that the individual devices that are present are the ones that should be there, that communications between devices remains intact and has integrity from packet-to-packet, or over the course of a session. Confidentiality is an optional consideration, but many people think it’s unnecessary to go that far to encrypt all the data at high speed, since encryption adds some latency. It’s possible to do it at full speed, but that adds area to the solution and power consumption.”

Know thy source
With chiplets increasingly being sourced from multiple vendors, it’s important to understand who developed those chiplets, where they were manufactured, and whether the supply chain has any weaknesses.

“The supply chain for devices containing many different chiplets is a lot more vulnerable than the regular supply chain for monolithic devices,” said Siemens’ Harrison. “There are more vendors as part of the supply chain, and silicon die are being provided by potentially many different suppliers.”

While most of the chiplets in use today are internally sourced, that is starting to change, particularly with I/O and memory chiplets.

“You need to be able to track these identities and manage them throughout the whole supply chain process,” noted Dana Neustadter, senior director of product management for security solutions at Synopsys. “All of this ties into what foundational security means. You have to think about some means for tracking, and that might also expand into some form of sensors, or physical unclonable functions for providing identities or a form of watermarking. There are some other elements that can be added, but this supply chain security is a whole other level compared with a typical SoC process versus multi-die.”

The U.S. Department of Defense is extremely concerned about having the ability to pull a system or a board out of a fielded system. “When there’s a U.S. or allied war fighter out there somewhere, and they have a microelectronic subsystem in their pack, there are boards, chips and software,” Best said. “The DoD would like to be able to pull the board out of that microelectronic system and say, ‘Do all of these chips belong here? What is the provenance of every one of the chips in the system?’ They can’t answer that, and that terrifies them. ‘If we don’t have the traceability in our supply chain, how do we know this is an authentically manufactured chip?’”

Traceability may not be the number one chiplet concern, but it is in the top five, Best said. “This is because when the DoD is looking at doing a state-of-the-art system, it’s high-cost and low-volume. They don’t need millions. They need dozens. And in order to get state-of-the-art performance, they are willing to do multi-chip packages (MCPs). They are on the forefront of what I call heterogeneous multi-chip packages, meaning multiple different vendors are all contributing silicon into the MCP. Commercial industry doesn’t really do that. Commercial still has this homogeneity for their MCP. For example, if you take apart one of AMD’s MCPs, there might be six or seven chiplets inside a single package. Two of them are HBM DRAMs. The rest are all AMD silicon. They integrate their own chips as chiplets with HBM for some very high-performance GPU, TPU, XPU systems that they deploy. Commercial systems are primarily working in that homogeneity approach. They control all the chiplets in an MCP. The DoD and the U.S. government are definitely leaning forward on the heterogeneity and the traceability of the chiplets. If you’re putting eight chiplets into an MCP, the traceability problem is now eight times as hard. You have eight different semi-secure supply chains leading to that one MCP. It scales by the number of chiplets that are in there. If there are 12 chiplets, it’s 12 times as hard.”

Automotive chiplet security issues
In the automotive sector, systems developers are eyeing the benefits of an open marketplace of chiplets, and the security implications of that approach.

“A Tier One or an OEM may say, ‘Instead of buying a chip from Renesas or TI or whomever, I’m going to package my own chip based on an array of chiplets that I get from an open marketplace,'” said Rob Fisher, senior director of product management at Imagination Technologies. “And if you consider that as being the future of where this might go, then there are equal, if not more, security threats in the supply chain than there are about the physical attack surface that a chiplet architecture presents.”

The key here is trusted sources. “On a monolithic chip, if you hold the RTL, you’ve got a pretty good idea of its provenance and you can test it,” Fisher said. “But if you’re taking a chiplet from a third party, you need to know that it’s come from a trusted source. And you need to know that all of the chiplets that you’re using are from a trusted source and there’s no malicious hardware designed in, so you get a quite complex supply chain tracking issue there. Another aspect to this comes back to knowing where the chiplets come from and where the design comes from, and knowing all of the players who have gone into producing it, because the chiplet is more than just a piece of RTL. It goes through many stages and many hands before it reaches a system integrator, so there are quite a lot of concerns around that.”

There are other concerns, as well. Because the system is created out of individual blocks, communications between these blocks can be probed, and the data transferred between chiplets may more easily be accessed than on a monolithic die.

“This is probably an easier thing to solve than the supply chain issues, but still not easy to solve,” Fisher said. “With SoCs, there’s a tried and tested way of securing an SoC. You have a RoT, something that you know is intact and cannot be molested. Then you build up on that. You boot all of your system based on that RoT protection, and you build your security by that. However, in a chiplet architecture where you have individual pieces of silicon, that becomes quite challenging. The way that needs to be solved is by applying to each chiplet the techniques you would apply to an SoC. And then you need something additional in the end device, the end SoC, to orchestrate that security profile for the whole collection of chiplets. So each chiplet probably ends up needing its own root of trust and its own secure boot procedures, and that will allow the chiplets to communicate with each other securely using encrypted protocols. But there also needs to be something else at the higher level to set up all of that security.”

This is why some current implementations of commercial chiplets involve pre-integrated modules with defined boot-up sequences and built-in controllers.

“You have a host, which is your application processor,” said Erik Wood, senior director for cryptography and product security at Infineon Technologies. “It is in charge of the key operations. It is in charge of boot, which sets up access rights to debug ports. It sets up the lifecycle state of the product. It sets up all the configurations of the security that you’ve done prior to moving the host processor into the secure life cycle state. It’s got everything there, and the chiplets that are then attached to the application processor are subsystems to that device. So if there’s any firmware that needs to be updated on the chiplet, that host is responsible for doing that update onto the chiplet. Similarly, the application processor boots up, first doing its own secure boot, then it boots up the chiplet, which is almost a companion. Think of it as driving down the road. You’re in charge. You’re the primary application processor, and then you have your five-month-old baby in a car seat in the back. That’s your chiplet. So you’re responsible for security.”

This is akin to what happens with external flash or memory. “It’s a similar paradigm, and so you want to have reliable controllers,” Wood said. “For example, in the external memory there’s security in terms of the physical aspect of it, and security in terms of a logical aspect of it. You want to have a controller in your host processor that manages the interface functionality to the other device. And in terms of external memory, you want to be able to do an authentication and a decrypt from external memory at the same time. So there are logical considerations, as well as the physical construct of how you put those die together.”

How to approach chiplet security, traceability
One way to account for chiplet security is to have a single RoT solution, with the secure element situated on the base die of the device. Then, using techniques such as attestation, each of the chiplets checks in with the RoT on the base die upon power-up.

“With each chiplet creating a dynamically generated attestation token, this ensures that each chiplet self identifies with the base-die before it is enabled,” Siemens’ Harrison explained. “This approach assumes a zero-trust environment, similar to what is seen in many other communication domains today, where every element is treated as a zero-trust element until it has been authenticated. This both ensures that the chiplet token ID cannot easily be captured, as it is dynamically generated by the chiplet on power-up as opposed to being hard-coded. Also, not being enabled until the full authentication is complete protects against many levels of attack within the semiconductor supply chain.”

Functional monitors provide a way to generate the attestation tokens as part of the authentication process. The functional monitors can build a profile of monitored data over time, such as a secure boot sequence. This dynamically generated signature includes elements of both functionality and time, making it extremely hard to crack.

Fig. 1: Zero trust supply chain for chiplet-based devices. Source: Siemens EDA

“If I was building an SoC and it was going into an automotive platform and the automotive provider said, ‘We’re going to require some verified traceability [provenance] of the chips that you deliver to us,’ I might not have verified traceability, but it’s my chip,” said Best, ” so I can go into my supply chain, and figure out what I have to add to wafer sort, to final test, and to in-system test. What components do I need to add to get the traceability secure enough that my customer agrees I have achieved verified provenance, verified traceability, and it’s now at the point where they’re willing to accept that product? I only have one supply chain I need to affect if I’m a traditional SoC maker. But if I’m making an MCP that’s combining 12 different chips and I have a traceability problem, how do I fix that? Now I have to go to 12 different vendors, who all have 12 different traceability solutions. Some of them probably are state-of-the-art. But others may say, ‘No, we don’t have a state-of-the-art verified traceability solution. So now I have to, as an MCP integrator, reach across a business barrier to cause a supplier to start. And if I’m not pulling enough volume like an automotive system, or if I’m not defining Federal Acquisition Regulations like the U.S. government, it is really difficult to cause your vendors to modify how they’re doing supply chain security.”

Chiplets create additional security risks, as well.

“The design engineer is dealing with more power dissipation, which has higher emissions, and this increases the potential for side-channel analysis attacks,” Synopsys’ Neustadter said. “And when the attackers are really incentivized, they can find different means to attack a multi-die system. Then, another kind of threat that we haven’t dealt with before, is that when there are multiple chiplets — and those chiplets end up in totally different end products, like in a vehicle and in a smart home device or a data center — imagine that one of those chiplets is compromised. In that case, you don’t just compromise one family of products. You can compromise a whole slew of different families of products. This is something quite unique in terms of a potential attack vector that can happen.”

This is where some experts believe organizations like the Universal Chiplet Express consortium can play a significant role, setting standards for how to securely stitch components together. “Standardization prevents fragmentation,” she said.

The problem is that standards take time to put in place, and the industry’s adoption of chiplets is moving quickly. “I’m not certain that the standards are moving fast enough to catch up with the eagerness to do it,” Best said. “Security is often one of those things that people say there’s always room to solve. There’s always time to layer security on top of this, until you get attacked, and something that has been fielded is now deeply compromised. If a billion devices are out there that have been shipped, and they all have this weakness in them, and some of those chips have gone into critical infrastructure systems, now what do you do? The DoD is worried about this. They do understand that now there’s not just one chip inside of the system that is self-protected. It’s a billion transistors and 10,000 wires, but they have to disaggregate the system and they need to maintain end-to-end privacy and authentication of the data — especially for some really valuable data. This includes AI models. If you are going to be putting AI models into memory, it had better not be sitting there in plain text if it’s worth tens of millions of dollars.”

Conclusion
The advent of chiplet design marks a significant shift in semiconductor technology to enhance performance, scalability, and flexibility. However, chiplet systems also introduce unique security challenges that must be addressed to ensure the integrity and reliability of multi-chip packages.

Verified traceability, robust cryptographic solutions, and industry-wide collaboration are essential to mitigate the risks associated with chiplet security. As the industry continues to evolve, stakeholders must prioritize security measures to protect against potential vulnerabilities and ensure the safe deployment of chiplet-based systems. Only by understanding and addressing these challenges can the risk be managed for a commercial chiplet ecosystem.

Related Reading
Chip Security Now Depends On Widening Supply Chain
How tighter HW-SW integration and increasing government involvement are changing the security landscape for chips and systems.