Putting A Hardware Root-of-Trust To Work In An Anti-Counterfeiting IC

Going beyond a software-based approach to chip authentication.

popularity

An anti-counterfeiting security IC is conceptually rather simple: during manufacture, it is securely programmed with some secret data. Then during operation, it can prove to a verifying host that it knows that secret data. This “proof of knowledge” is often all that can be expected of a low-cost security IC.

This prove-you-know-the-secret authentication process between the security IC and a verifying host can be implemented in many ways, from incredibly simple to incredibly secure. For example, the security IC might contain nothing more than non-volatile storage, and the verifying host could simply read the secret data to confirm that the security IC is authentic. Obviously, this is in no way secure – an adversary who wished to impersonate an authentic chip (e.g., to ship a cloned or counterfeit consumable product, such as a cellphone replacement battery) would simply have to monitor the data exchange between the verifying host and the security IC in order to learn the secret data.

A more secure proof-of-knowledge protocol of course involves cryptographic functions, and there are as many possible protocols as there are cryptographic functions. But one aspect all secure protocols have in common is the concept of “challenge response”. That is, a verifying host creates a random challenge and delivers that message to the security IC. The security IC then uses its secret data to operate on the challenge in some cryptographic manner, and then returns a response. An adversary who was monitoring the communication between the verifying host and the security IC would see only random challenge values and the cryptographically-secure outputs, which, by definition, also appear random (i.e., uncorrelated to both the challenge and secret-data input values).

Despite the strength of the cryptographic primitives used to secure a challenge-response protocol, a determined adversary will be merely delayed, not defeated. Some markets for electronic consumables (e.g., printer ink and toner cartridges) are worth more than $50B USD annually, creating high incentive for skilled adversaries to penetrate the security barriers. There are well more than a dozen techniques in the adversary’s arsenal, and most of them rely on a simple truth: in order to prove that it knows the secret data, the security IC must perform a calculation involving that secret key data. And while cryptographic functions are provably secure at the mathematical level, that perfection is compromised when the math is executed in circuits – semiconductor processors utilize structures that are typically not reflected in the math, including power delivery, data busses, clocking, setup and hold margins, etc. All of these imperfect transformations between math and circuit create “side channels” that can be exploited by an adversary to determine the secret-key data utilized during a challenge-response calculation. The Cryptography group of the Rambus Security Division, for example, pioneered the Differential Power Analysis (DPA) technique as well as the most effective countermeasures to prevent information leakage due to that side channel.

Once a side-channel attack is effective and the adversary has obtained the secret data of an authentic security IC, are counterfeits close behind? The answer is usually yes: while there are as many different challenge-response protocols in market as there are anti-counterfeiting security IC vendors, they almost all rely on standard cryptographic algorithms (e.g., AES, SHA, Elliptic Curve, etc.). So once an adversary has obtained the secret-data, it is relatively straightforward for them to program a low-cost, off-the-shelf MCU to imitate the challenge-response behavior of an authentic chip.

These types of anti-counterfeiting solutions can be broadly categorized as software root-of-trust systems. That is, their security depends on algorithms and data, which – though the algorithms execute in hardware and the data is stored in transistor-based non-volatile memory – can be effectively executed and represented in software. And it is the nature of software that it is readily copied. Said another way: if a security IC can be mimicked by a general-purpose MCU simply by copying embedded software and data from one to the other, it is a software root-of-trust.

A more difficult-to-copy solution is known as a hardware root-of-trust. In this approach, part of the cryptographic processing is performed in a circuit that cannot be cost-effectively executed in software running on a low-cost MCU. Suppose for example that the anti-counterfeiting security IC contained a customized processor that could complete the equivalent of one-billion 128-bit transformations every few milliseconds. Suppose further that this processing engine applied its algorithm to every input challenge. In this case, even if the adversary learned the chip’s secret-data, they could not program a low-cost off-the-shelf MCU to mimic the transformation circuit necessary to mimic the protocol. Well, they could, but the low-cost MCU would require several hours to complete a single challenge-response calculation. In this way, a hardware root-of-trust can add a “proof-of-work” layer in addition to proof-of-knowledge security.

Most importantly, an adversary can no longer copy a hardware root-of-trust security IC simply by copying the software and data – they must expend the effort to copy the customized hardware itself. And of course, semiconductor hardware is much more expensive and time-consuming to copy than the software and data within the semiconductor. This is how anti-MCU, or anti-emulation transformation circuits elevate typical software root-of-trust solutions into more robust hardware root-of-trust anti-counterfeiting solutions, and how such solutions can deter and delay an adversary’s introduction of counterfeit products into the market.



1 comments

Milton Moss says:

Show Me The Money $$$$$$

Leave a Reply


(Note: This name will be displayed publicly)