The Case for Auditability

Posted on Feb 18, 2021

Seeing is Believing

Without the design files for your computer processor, how do you know that:

A. it does only what you tell it to

B. it respects your privacy

You don’t.

As of the time of writing, there are currently no modern auditable computer processors on the market.


An easy way to prove your system doesn’t have backdoors is to release it’s designs for extensive auditing.


Auditing designs can sometimes take a lot of time, and a lot of capital. There is however, a niche set of systems that permeate virtually all aspects of modern day life, which aren’t particularly complex. This means that auditing such systems is not particularly difficult.

The PHYS and controllers for SOC peripherals comprise one such niche. Below are some example peripherals.

  • USB Controller and PHY
  • Ethernet RGMII Controller and PHY
  • Ram DDR4 Controller and PHY
  • PCIe Controller and PHY


Most if not all of those components are found in virtually all modern day electronics. Certainly, DDR PHYs and respective controllers can be found in 90+% of all modern day electronics.

One thing that the aforementioned components tend to have in common is that they need to be initialized first before the CPU in the SOC boots a kernel. Initializing these peripherals requires running software/firmware. This process is commonly known as system bringup.

The firmware that peripherals run is almost exclusively provided by EDA vendors in an un-auditable binary format. Given that controllers for peripherals often have access to the entire system memory space, it is quite conceivable that bringup firmware could write malicious code to a system hard-drive to be later booted by a $2^{nd}$ or $3^{rd}$ stage bootloader.

Given that the firmware for bringing up SOC peripherals is not particularly complex in nature, it is quite easy to audit the firmware source code for malicious code that could for example, write malware to a hard-drive. In fact, in source form, such exploits are quite obvious, where-as in binary form, such exploits are quite elusive.

Its not un-reasonable to trust that EDA vendors don’t put malicious code in their firmware - they probably don’t. It is un-reasonable, however, to expect that man-in-the-middle firmware upgrade attacks won’t result in compromised firmware.

Historically - industry has addressed this problem by requiring firmware to be vendor signed. As hinted at in the article Just How Bad Are Backdoors, once an attacker gets access to the vendor signing keys, its impossible for the end-user to distinguish between trustworthy and compromised firmware.

A simple solution to this problem is just to release the firmware sources.


Auditing firmware is low-hanging fruit that can easily be accomplished should EDA vendors make available their firmware sources, rendering malicious code or backdoors inserted by man in the middle attacks virtually impossible to execute, without being easily detected, especially since SOC peripheral firmware codebases are quite small and are fairly easy to read through in their entirety.

The majority of modern digital hardware is designed using Register-Transfer-Logic(RTL). RTL codebases for modern hardware such as CPUs are quite large, much larger in fact than SOC peripheral firmware.

Auditing the RTL codebases for CPUs and GPUs for example, would require substantial capital and perhaps time. It is up to any specific entity to decide whether the potential costs in legal fees or fatalities exceed those of auditing the hardware they use. For security conscious institutions such as banks or defense, the answer is almost always: NO.

Case Studies

Still not sold on auditability?

Man in the middle attacks do occur. The following article provides an example of a man in the middle attack related to SuperMicro’s PCB supply chain that exposed potentially up to 30 companies in the U.S. to bad Chinese actors including Amazon.

And intentional or not, modern day SOCs, especially BMCs and most intel chips do have backdoors. The following article details one of multiple backdoors present in ASPEED’s ast2400 and ast2500 chips. The particular backdoor described in the following link exists in the AXI bus bridge of ASPEED’s chips.