8

In software, code auditing can be used as a mean to gain trust into a software. Of course closed, proprietary software would complicate this, and require to do reverse engineering. Anyway there seems to be a way for software to eliminate distrust to some extend.

Recent events have once again shown that hardware components in computers have become a powerful attack vector. Indeed the DMA-attack is problematic and can be inside the following hardware components: hard disks and SSDs, PCI, USB devices when they can compromise the USB host controller. Of course the CPUs themselves and the side-microcontrollers, e.g. Intel vPro/AMT/ME can also be backdoored (from a design of IC perspective).

Provided the technology used in manufactoring of the IC it seems doubtful that one can "look into the hardware" in a way that would correspond to the code auditing and or at least the reverse engineering of software.

Are there some best practises developed to audit hardware to some extend against malicious backdoors?

The current way I have found to mitigate the risk of hardware is to connect them with airgaping components or configure them with hardware jumpers, hence providing some sort of isolation. Obviously this is the exact opposite of what an integrated circuit or a SoC (System on Chip) are conceived for.

dan
  • 3,033
  • 14
  • 34
humanityANDpeace
  • 1,412
  • 1
  • 12
  • 24
  • 1
    Read about "formal methods". Intel in particular uses formal methods in their CPU design to mathematically prove the design of their hardware meets specified requirements. Certainly within an IC house, they can absolutely "look into the hardware" and can allow outsiders to perform many types of audits of their hardware designs if they deem necessary. However, if you personally don't trust the hardware manufacturers, and want to audit someone else's hardware, it can be done if you have alot of money and time; Govt's and MultiNationals are well known to reverse engineer hardware. – cybermike Mar 29 '15 at 13:39
  • @cybermike then this is bad luck for me, I have no trust in the manufactorers, and no money either. It anyway suprises me to hear you mention "reverse engineering of hardware" as I thought that is techologically unfeasible for those nice <50nm IC. I will read into what you say, maybe it will eventually allow to provide a definitive answer to this question or at least a good approximation. – humanityANDpeace Mar 29 '15 at 13:46
  • When you are a China or a Russia or a United States with literally Billions to spend, there are alot of things one can do with tunneling microscopes, and most IC companies are not really trying to expend the amount of money (and raise the prices of their products) just to create utterly non-reverse-engineerable designs. As always in business, its a cost vs benefit tradeoff. – cybermike Mar 29 '15 at 13:49
  • An important distinction you need to make is between firmware/microcode (which is still software) bundled with some hardware and the actual hardware. Most of the things you mention (storage drives, USB devices) have all their vulnerabilities in the *software* they run - a true hardware vulnerability would be in how the chip itself is designed. – André Borie Nov 11 '16 at 13:49

2 Answers2

1

In the talk Milking the Digital Cash Cow, the presenter discusses the differences between software and hardware cryptanalysis starting at around 9 minutes into the prezo -- https://www.youtube.com/watch?v=Y1o2ST03O8I

It's interesting to think that hardware-based side-channel attacks can also apply to software, but it's even more interesting to think that classic software fault injection techniques can also work on hardware.

atdre
  • 18,885
  • 6
  • 58
  • 107
1

Software auditing is easier since code is mostly done on standard platforms, whereas HW has at least two components: SW (firmware) and electronic components, which are sometimes proprietary and under patent laws.

Reverse engineering a HW firmware is also possible, however you must deep understand how the electronic components work and what kind of vulnerabilities they have (or could have) from a component as well as from an entire system perspective.

CC - Common Criteria addresses this concern by ensuring that a solution (HW and SW) is delivering what is supposed to (from a security perspective). They even have a classification level to security assurance. However the vendor must explicitly mention against which vulnerabilities they have protection in place.