Trust no-one

4 mins read

Over the past decade, concern has grown over hardware Trojans: malicious circuitry placed in chips or boards.

The worsening geopolitical situation has raised those concerns to a new level, particularly when nation states are implicated in ransomware attacks, though these seem to be confined to software-only exploits. With these being so successful for the perpetrators, why go to the expense of trying to compromise hardware as it moves through manufacturing?

Confusion continues to reign over the so-called Big Hack of Supermicro server motherboards reported by Bloomberg in October 2018. The supposed principle behind the Big Hack was similar to that of the use of modchips by gamers who soldered extra circuitry into place to subvert copy-protection mechanisms put in place by manufacturers. Though sources told Bloomberg the culprit was a tiny chip installed in the factory, what is not clear is whether the additional component identified on the Supermicro motherboards actually did what was claimed. Government security agencies on both sides of the Atlantic claimed they could find no evidence of the hardware being compromised in this way.

Though there is little in the way of confirmed instances in commercial hardware, there are plenty of proof-of-concept descriptions that show putting trojans into hardware is entirely possible. In the future, if software-only attacks are closed to them as practices improve in that field, any well-resourced state actor or criminal gang is naturally going to try to weaken the defences of the secure enclave on the target chip or find a way to eavesdrop on it.

Secure supply chains

Much of the focus of the US DoD, which is now putting a great deal of effort into securing its electronic hardware, is on the highly outsourced and global supply chain that now exists. The silicon that goes into weapons is relatively mature and has been able to use local fabs that have gone through extensive auditing to be considered trusted. But the emphasis on advanced compute for simulation, communications and AI means government contractors need to source advanced silicon. And that means relying on untrusted offshore fabs and assembly houses.

At an electronics-focused summit organised by research agency DARPA in 2019, then US undersecretary for defence Lisa Porter, declared. “The trusted-foundry model is outdated and simply cannot provide us the access we need to the most advanced manufacturing capabilities…in order to avail ourselves of leading-edge technology we must develop data-driven security techniques. No matter what size the node and what type of foundry we are using, data not perimeters must be the ultimate arbiter of the trust that we assign to the electronics that we build.”

Porter called for the same kind of zero-trust security model that software architects have begun to embrace. The idea is simple: do not assume that a piece of software requesting access to a resource is friendly even if it has good credentials.

If the software is deemed to have access to one piece of data, that does not confer a right to access some other data next to it without a further check. At the same time, the system monitors access to try to determine whether any of the activity is abnormal.

There is one flaw in the zero-trust approach in software: it has to trust, to some extent, the hardware on which it runs. If the hardware used to check accesses is flawed, the whole system is at risk. For the manufacturer relying on advanced silicon, possibilities for compromised hardware arise both in the delivery of custom silicon and in the assembly of boards and systems that use that silicon. Modifications can go into custom silicon at the level of RTL code or are made post-layout to the GDS II taped out to the fab. The latter is where the sneakiest attacks go. One particularly insidious form of attack is to simply make tiny changes to the masks used to dope the silicon wells under a transistor. This can lead to early failures in the field or in one proof of concept developed by a team at the University of Bochum, reduce the entropy of a random number generator.

This would be in keeping with some of the suspected state-actor attacks on cryptography. Weakened entropy leads to keys being used that are more easily cracked by those with access to high-performance computers and is extraordinarily difficult to spot.

Modchip evolution

Chiplets inside system-in-package (SIP) modules represent a further evolution of the modchip: a compromised assembly provider can easily slip something extra into the package. The defence community may be disproportionately more vulnerable than their commercial counterparts as the ability to mix and match devices inside the package can provide them with the low-volume flexibility they need.

How do you know that has not happened to a board, chip or system-in-package (SIP) you buy in? Today there is no clear answer but options for defence are appearing. Part of the answer already exists in that techniques such as formal verification are now used routinely to check designs not just for bugs but to identify if the post-synthesis layout is functionally different to the RTL fed to the synthesis tool.

Traditionally, a lot of the research interest has been in verifying designs using red and blue team competitions at events such as the Cyber Security Awareness Week (CSAW). That conference’s most recent exercise focused on the idea of logic locking, which was originally developed to help prevent overbuilding but which has potential applications in the defence against Trojans. The techniques typically use obfuscation to make it difficult and preferably impossible to insert or change any functions without them being detected. However, it remains a cat-and-mouse game with no clear winner.

There are other ways to try to spot evidence of tampering. One is to focus more on activities around the design than the design itself. Packaging house Amkor has, for example, started to establish audit trails for the components that go into each package as they flow through the manufacturing facility. This was originally developed to help automotive customers track down the causes of in-field failures. But the same kind of traceability could be used to identify whether counterfeit parts have entered the supply chain or whether and when assembly orders were changed.

Similar kinds of audits may prove to be an effective defence in the steps leading up to final mask production. As many chip-design teams now use environments such as Jenkins to automate regression testing, the option is there to extend them to perform regular analyses of check-ins and updates. Though it risks throwing up many false positives, who has accessed and made changes to the design could, in principle, be checked to determine whether they seem anomalous.

A lot hinges on the amount of cooperation external IP providers and manufacturers will provide: will they let customers access their own audit trails? Though they may balk at delivering full records, anonymised data might prove to be useful in highlighting suspicious alteration patterns.

In the end, the most security-sensitive customers may wind up performing physical reverse engineering on their own chips. They might decap them and probe them to compare the actual circuitry with their “golden” master and perform extensive comparisons of their own simulations with the actual silicon, just in case something like a random number generator has been compromised.

It will be the price of living in a zero-trust world.