Hardware Security Modules

Some applications require extremely strong security guarantees. For instance, private cryptographic keys used to sign government-issued electronic identity cards or website certificates must not, under any circumstances, leak to an attacker. To protect such high-value data, they are often stored in a hardware security module (HSM). These secure co-processors protect sensitive data against two types of attacks. First, to protect against software attacks, they only provide limited functionality and usually do not allow third-party code to run on its processor. Untrusted software running on the main processor can only access the HSM via a secure interface that prevents unintended behavior. An HSM, for example, may provide an interface to create and use cryptographic keys (e.g., to sign certificates), but should prevent that cryptographic keys can be

exported from the HSM in plaintext.

Second, security measures are taken to prevent hardware attacks against the HSM. While software attacks are often the easiest attacks to execute – and thus usually the preferable option for attackers – there may not be any exploitable vulnerability in the software of the HSM. In such situations a determined attacker may target the HSM’s hardware directly. Hardware attacks can be divided in two categories. In invasive attacks the hardware chip is directly physically accessed. An attacker may, for example, ground signals preventing correct execution of instructions. Invasive attacks do not always actively modify the behavior of the chip. In passive attacks of this category data buses may be probed to intercept sensitive information that pass over them. A variety of countermeasures exist to defend against invasive attacks, ranging from covering hardware components in epoxy making them harder to access to continuous monitoring the integrity of a protective mesh over the chip.

Non-invasive attacks on the other hand, preserve the chip’s physical integrity. Passive attacks in this category only monitor information that can be observed externally such as timing differences, power consumption or electromagnetic radiation. When this information can be correlated with the internal state of the chip, sensitive information may leak to an attacker. An attacker may however also actively modify the chip’s physical environment. Providing spikes in the

power supply, for example, may cause unintended behavior of the chip and (indirectly) leak sensitive information. Sensors onboard the chip may mitigate

such attacks.

To boost security of commodity computing devices, most modern desktop and laptops are also equipped with an HSM, called the Trusted Platform Module (TPM). While this chip is very resource constrained and operates at very low speeds, it has a number of interesting security primitives. We briefly discuss some of these primitives we will use throughout the text but refer to other work for a more elaborate discussion [49, 76, 95].

Platform Configuration Registers. One of the key components of the TPM

chip are its Platform Configuration Registers (PCRs). PCRs are a set of registers that can be used to securely collect the state of the platform. To ensure that malicious software cannot tamper with the contents of PCR registers, they cannot be set to a specific value. A PCRi can only be extended with

measurement m by hashing its current content appended with m: PCRnew_i ← SHA-1(PCRold

i ||m)

There are two types of PCR registers. Static PCRs are initialized to 0 at boot time and cannot be reset afterwards. Dynamic PCRs, in contrast, are set to −1 at boot time and can be reset to 0 after the system booted. The different initial values enable a third party to distinguish between reboots and PCR resets. To collect the state of the platform, every component in the boot process first computes the hash of the next boot component, extends a PCR register with the result and only then hands over control. Modification of one of these components, for example to provide a persistent backdoor to an attacker, will result in a different PCR value. Hence, when PCR content remains unchanged, the system has booted to a pristine state.

Attestation. In a number of use cases it is desirable that a user can prove

certain properties to a third party. Employees connecting to a company network, for example, may need to prove that their operating system was not compromised and runs the latest software updates. Or users of a public network may need to prove that they run an up-to-date anti-virus scanner. The TPM chip can be used to provide such attestations; the TPM chip can sign the contents of one or more PCR registers that can be presented to the third party. As the used private key cannot be extracted from the TPM chip and PCR contents cannot be set to a specific value by an attacker, this attests the state of the platform.

WHY SOFTWARE SECURITY IS STILL A MESS 11

Sealed Storage. Sensitive data can also be tied to a specific state of the

platform. Software can provide sensitive data to the TPM chip and request that it is sealed to the contents of one or more PCR registers. The resulting ciphertext can be stored at an untrusted location. Only when the systems enters a state where PCR content matches the specified value at the time of sealing, will the TPM decrypt the ciphertext.

NVRAM. Sensitive data can also be stored in TPM NVRAM based on PCR

contents. Unfortunately TPM NVRAM has significant drawbacks. Most TPM implementations only provide 1,280 bytes of non-volatile memory and support only 100,000 write operations. Accessing TPM NVRAM every second would wear it out in less than 28 hours.

Monotonic Counters. Finally, TPM chips are also shipped with at least 4

monotonic counters; these are counters that can be incremented but never decremented. Unfortunately, the TPMv1.2 specification [132] only requires these counters to be incrementable at least once every 5 seconds. TPM vendors may provide increments at higher speeds but counters must not wear out within 7 years of operation.