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
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).
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.
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.
executing Code securely