Communications - June 2012

that provides TPM-like answers without providing TPM security guarantees. Since the adversary has physical possession of his own TPMM, he can extract its private keys and credentials and include them with the malware. Thus provisioned, the malware on the local machine can emulate TPMM, even without network access.

The right way to prevent a cuckoo attack is to introduce a secure channel to the local TPM, instantiated through either a physically hardwired channel allowing users to connect directly to the TPM on the local machine, or a mechanism to allow the user to learn authentic cryptographic information about the local TPM, and hence establish a cryptographic secure channel.

Both the formal model and a usability assessment were used to analyze a dozen instantiations of these approaches, 20, 21 including adding a special-purpose port or button to the computer, reusing existing interfaces (such as USB and Fire Wire), using soft-ware-only attestation, and encoding cryptographic material as a 2D barcode or serial number printed on the computer. Each involves advantages and disadvantages. In the short term, placing an alphanumeric hash of the TPM’s public key on the exterior of the computer seems to offer the best trade-off among security, usability, and deploy-ability. In the long term, the strongest security would come from a special-purpose hardware interface wired directly to the machine’s secure hardware (such as the TPM), designed so the user is unable to inadvertently connect the verifying device to another interface. This solution removes almost any opportunity for user error and does not require preservation of secrets.

How can secure code execution coexist with the untrustworthy mountain of buggy yet feature-rich software common on modern computers? For example, how can a user’s keystrokes be kept private if the operating system, the most privileged software on the computer, cannot be trusted to be free of vulnerabilities? This coexistence is even more challenging due to the need to preserve the system’s existing functionality and performance.

Previous work sought to deal with
the problem by running a persistent se-
curity layer, dubbed a security kernel,
VMM, or hypervisor, in the computer’s
most privileged mode. 8, 11, 12, 26 The secu-
rity layer was responsible for creating
isolation domains for ordinary, un-
trusted code and for security-sensitive
code. Unfortunately, the approach
also involves several drawbacks; for
example, the security layer’s need to in-
terpose on hardware accesses leads to
performance degradation for ordinary
code and often requires eliminating ac-
cess to devices too complicated to emu-
late (such as 3D graphics cards). 4 More-
over, the need to run both untrusted
and trusted code simultaneously can
lead to security vulnerabilities (such as
side-channel attacks), as well as code
bloat in the security layer; for example,
the initial implementation of the Xen
VMM in 2003 required 42,000 lines of
code4 but almost doubled to 83,000
lines within a few years. 13

figure 1. Cuckoo attack.

in one implementation (a), malware on a user’s local machine sends messages intended for the local tPM (tPMl) to a remote attacker who feeds the messages to a tPM (tPMM) inside a machine controlled (physically) by the attacker. given physical control of tPMM, the attacker is able to violate its security guarantees via hardware attacks. At a logical level (b), the attacker controls all communication between verifier and local tPM while also having access to an oracle that provides all the answers of a normal tPM without providing the security properties expected of a tPM.