Home Blog Industry Updates Approaches to detect a hardware implant

Approaches to detect a hardware implant

Author: Jasper van Woudenberg

Though hardware implants have been a big topic of discussion in the past weeks due to the Bloomberg story, they have been researched for many years. There is a body of academic literature on “hardware trojan detection”, which varies from Trojans implanted in the silicon of a chip, to PCB-level implants. There is no doubt that hardware Trojans and implants are a technical possibility. However, the practicality of such methods to control hardware is, at least, questionable.

I don’t claim to know how nation-states think, but for now, I’m skeptical of the usefulness of hardware implants at the PCB level. If anything, it is not the easiest technical means to remotely control a system; rewriting firmware is much easier from an engineering perspective. So, if these implants exist, there will be non-technical reasons for it, which are beyond my scope of expertise. At the same time, I think the possibility should be considered that non-nations states can pull off simpler supply chain hacks. After all, what is really the cost of motivating a developer or a manufacturer to hide and inject a piece of malicious software or hardware?

Back to technology. In terms of detection, as with any security evaluation, the question is very much one of assurance; i.e., how sure do you want to be of the absence of an implant/Trojan. This assurance is also directly related to the effort involved in evaluating that question. There are various levels of activity with different effort and assurance:

  • Analyze all nonvolatile memories (flash/EEPROM).
  • Optically analyze a PCB.
  • Identify all ICs on a PCB by their markings and packaging type.
  • Measure side channels or response to faults of all ICs.
  • Identify all non-IC components on a PCB by their markings and packaging type.
  • Decap ICs and analyze them.

For each of these, the ‘easy’ way is to perform an analysis against a known-good ‘golden’ system. By definition, any differences from this ‘golden’ system are suspicious. These comparisons are amenable to automation and scaling. When such a ‘golden’ system is not available, an analysis based on specifications, source code, etc can be performed. This is more complex and currently requires manual analysis. Once this manual analysis is performed, the system can be considered ‘golden’ and further systems can be automatically compared. The most complex situation arises when specifications are not available, and implants or Trojans need to be found without a definition of what the system should be. This requires extensive analysis.

Finally, for each of the detection activities, there are ways to circumvent them; techniques can be borrowed from the field of anti-forensics and anti-reverse-engineering. For instance, a flash controller could try to detect reads caused by a device boot versus reads caused by an external reader, and present a different image. Small chips can be hidden in PCB layers, and PCB markings can be easily changed. Additionally, circuit camouflage techniques can be used to make gates physically appear like a different gate (for instance an AND gate would look like an OR gate), and thus hide trojan logic.

As such, the question once again boils down to who the attacker is and what means (and motives!) they have in modifying their target. However, this is security as it is everywhere: attackers and defenders pushing the boundaries in (avoiding) detection.

Thanks to Mafalda Monteiro Oliveira Cortez for additional thoughts.

Share This