Protecting Chiplet Architectures With Hardware Security

Chiplets are gaining significant traction as they provide compelling benefits for advancing semiconductor performance, costs, and time to market. With Moore’s Law slowing, building more powerful chips translates into building bigger chips. But with chip dimensions pushing up against reticle limits, growing the size of chips is increasingly impractical. Chiplets offer a new path forward by disaggregating large monolithic integrated circuits (ICs) into smaller pieces that can be harnessed together in a system-in-package (SiP).

Additionally, IC size is inversely correlated to yield, so as devices grow larger, their yield drops. Smaller chiplets can be manufactured at a higher yield and lower cost than a functionally equivalent monolithic system-on-chip (SoC). Another advantage of chiplets is that each chiplet can be manufactured on a process best matched to its function. For instance, logic can be implemented on a leading-edge FinFET process node, while a chiplet-based RF transceiver can be manufactured with SiGe technology. Finally, there’s the ability to mix and match with chiplets, leveraging individual chiplet devices across multiple designs which reduces costs and speeds time to market.

Yet for all their benefits, chiplets raise new concerns for security. Why would that be? By disaggregating a system-on-chip (SoC) IC into its equivalent chiplet SiP form, one increases the attack surface for adversaries, and a larger attack surface increases the probability of a successful attack. Compared to their monolithic counterparts, SiPs composed of chiplets, potentially from multiple sources, are at a higher risk of attack from hardware-based trojans clandestinely embedded in silicon.

For a monolithic SoC, it is quite difficult for an adversary to stealthily inject a malicious circuit onto a production mask (i.e., the GDSII design database stream file exchanged between the chip maker and the semiconductor foundry). This action would almost certainly create design errors and significantly impact schedules. Therefore, embedding a trojan without detection is realistic only if injected by an insider (or by malicious EDA software) at the chipmaker itself.

This is obviously not the case for the creation of a chiplet-based SiP that is stitched together in potentially multiple locations and from different companies. With several design teams involved, the opportunity to compromise a team member (or their EDA tool flow) increases. Alternatively, a “cloned” chiplet with trojan circuitry could be introduced into the supply chain to compromise the SiP.

To do this, an adversary would reverse engineer an authentic chiplet and add a hardware trojan to the once-authentic design. Reverse-engineering is a well-known attack by which an adversary obtains a functional netlist from a working chip, often with the intention of fielding a compatible clone product. However, once an adversary obtains the netlist for a working clone product, adding trojan circuitry to the recovered design is a relatively straightforward process.

In addition, chiplet architectures create the opportunity for adversaries to intercept the communications between chiplets for man-in-the-middle (MITM) attacks. An MITM attack occurs when an attacker intercepts communications between two systems to digitally eavesdrop or modify data packets. As well, attackers may record an authentic transaction and replay it in an attempt to induce authentic behavior from inauthentic traffic. MITM attacks can be used to steal login credentials and personal information, to spy, or sabotage communications and corrupt data.

The solution to these heightened security risks is to implement a hardware root of for SiPs that can authenticate the legitimacy of third-party chiplets, as well as protect against a variety of both low-cost and sophisticated attacks. Specifically, this would see a root-of-trust element in the SiP authenticate each chiplet during the initial secure-boot sequence.  In addition, hardware-based countermeasures should be implemented in each chiplet to include anti-reverse-engineering technologies and non-volatile memory (NVM) anti-tamper protections.

For man-in-the-middle attacks, a hardware-based root of trust should be utilized to securely initiate a mutual-authentication challenge response to validate the identity of each chiplet, which in turn serves to verify the legitimacy of the data transmitted between them. A hardware-based root of trust also helps prevent MITM attacks that employ replay techniques.

The benefits of chiplets are too compelling to turn away from. Greater performance, lower cost, and faster time to market are all possible with chiplet implementations. With a hardware root of trust and anti-tamper protections implemented across the chiplets of an SiP, designers can enjoy all the benefits of chiplet architectures with robust security that protects both data and hardware.

Additional Resource:
White Paper: The Importance of Chiplet Security