On the last Virtualization Security podcast, our guest was Robert Rounsavall, CEO of Trapezoid. Trapezoid is looking into how to alleviate supply chain security issues; in essence, the security of the hardware. At many a presentation, I have asked attendees, “Do you trust the hardware?” Many times the answer is that they do; at other times, it is that they do not. Whether you trust the hardware depends entirely on your thoughts with respect to hardware security. But what can you do about hardware security? What is the worst that can happen if the hardware is infiltrated?
Defense in Depth: The Worst
The worst that can happen, as we found out on the podcast, is that an attacker could hide malware that could shut down a network at the attackers’ whim, perhaps during critical actions. Or, the malware could copy data over a network for later decryption. In either case, there is a massive failure in hardware security due to the infiltration of firmware, BIOS, and programmable hardware even from supposedly legitimate sources. Does everyone need to worry about these issues?
Perhaps!
Hardware is the basis for all computing. Hardware security, therefore, is the basis for all security. If the hardware has a weakness, then anything built upon it is weak—sort of like building a house on shifting sands.
But what can we do?
Defense in Depth: Hardware Security
Today there are a limited number things you can do to solve hardware security problems. The solutions consist of:
- Verify the firmware checksum from a well-known hardware manufacturer source.
- Verify that all new hardware has its firmware flashed with the well-known good firmware
However, this is not enough. TPM and TXT provide attestation for the operating system software: boot volumes and kernels. We need something to tell us about the hardware’s software: its firmware or BIOS.
Tools like SignaCert are designed to provide certified signatures against which we can measure firmware and software. SignaCert tries to exist as close to the supply chain as possible. However, this is neither continuous attestation nor boot attestation, as it is scheduled, usually when hardware arrives.
To provide proper hardware security, we need attestation on every boot of a bit of hardware, so that before we do any computing the device is verified. This problem is what Trapezoid is attempting to solve. They do this by making use of TPM and the Intel TXT extensions to store values into registers, so that hardware firmware attestation can occur on boot of a host. However, as infrequently as hosts reboot, sometimes we need to think of continuous attestation.
Continuous attestation would happen even after hardware is booted and would quarantine part of the system that does not meet security requirements, perhaps even powering the offending hardware off. Unfortunately, TPM and TXT currently do not support continuous attestation (even while the system is running).
The future is causing the hardware to attest itself while managing the checksums outside the hardware, which is the best we can do. We will need to trust the hardware registers inside TXT, as well as the external store of checksums.