Previously, Matthew Garrett and I came up with an
new idea for a method of local attestation. Local attestation here means:
authenticating the computer that the user possesses a valid hardware token
and authenticating to the user that the computer is executing the intended
code, and that said code has not been tampered with. The idea is to use some
NFC-enabled “smart” wearable device, something trivially hideable on (or
inside¹) one’s person in order to authenticate to the TPM, which then
validates that the next stage of code to be executed, e.g. usually the kernel
(ring 0) or the hypervisor (ring “-1”), has verifiable integrity. Matthew has
a great 32c3 talk on
TPM-based local attestation, and even breifly, towards the end of the video,
mentions the NFC ideas.
As an example use case, this would allow journalists² greater safety when
crossing borders. Your laptop got taken away by the TLA at a border? Not
such a problem; it simply doesn’t boot without you present. The TLA took your
laptop into the back room to try to install some malware on it? No worries,
because your laptop will refuse to boot the next time you try to do so (or it
could signal in some other way that the system was compromised… however,
refusing to decrypt the user’s harddrive is probably a bare minimum safety
requirement, and refusing to boot at all is probably the safest).
However, all of this places a great deal of trust in both the TPM device and
its manufacturer…
Despite Joanna Rutkowska’s
concerns over untrusted user input/output,
it would be interesting to see a system, built upon the above local
attestation method, which uses an
Intel SGX enclave
(see the
Intel Instruction Set Extensions Programming Reference
for architectural details) to execute code whose integrity has been previously
verified through two-factor authenticated TPM local attestation. This doesn’t
require user I/O, and it doesn’t require anything to be displayed to the user.
What it would provide, however, is a way for the code whose integrity is
verified by the TPM to remain safely isolated from:
- the BIOS, or tampering thereof,
- System Management Mode (SMM), and,
- (possibly) Intel Active Management Technology (AMT) — modulo Intel’s SGX
implementation (and how much you trust said implementation to protect you from
their AMT backdoor).
This protects against tampering of the BIOS itself, which, otherwise, could
possibly subvert the initialisation of the TPM hardware and cause the
integrity verification checks to falsely pass. Without SGX, SMM (ring “-2”)
would have the capability to emulate and/or forward calls to and from the TPM
device, and as such any SMM-based attack would completely subvert the local attestation.
Additionally, in my and Matthew’s NFC-TPM-based local attestation method, the
cryptographic code for verification would need to be partially executed on the
“smart” device. In
Matthew’s 32c3 talk,
the laptop uses a pre-shared key, stored in the TPM, to generate a
Time-based One-Time Password (TOTP),
which is very simple scheme used for two-factor authentication, and which
essentially does:
TOTP ← HMAC(SharedKey||TimeInterval)
The output then is presented as a QRcode on the screen, which the user scans
into the external device (a smart phone, in this case) which also runs TOTP to
check that the TPM verification was successful.
Smart phones being security nightmares, it’s nice in my opinion to avoid them
altogether. (And certainly to never rely on them in any trusted computing
scheme!) Alternatively, one could also imagine some smart² jewelry³ such as a
necklace or bracelet (cufflinks could also be pretty badass) with an embedded
NFC-capable smartcard. Unfortunately, smartcard means you’re likely running
in a JVM… which — my livid hatred for the Java programming language aside —
hasn’t exactly had the best track record in terms of security. This also
unfortunately
probably restricts us to using
only the set of cryptographic primitives which are PKCS#11 compatible, in
order to facilitate communication between the smartcard and the TSS. One
interesting area for further research would be a way to remove this
requirement, i.e. use something other than a smartcard, and/or devise a scheme
for moving execution (on either side) into an SGX enclave as well.
Moving forward towards more secure computing platforms, the most realistic
candidate I can currently imagine would be comprised by a
hardware-modified Thinkpad
which uses the above local attestation scheme to verify the integrity of
QubesOS’s security-critical code
and the integrity of a Coreboot (the latter of
which could also be verified from within QubesOS, e.g. via
Joanna’s Anti-Evil Maid system,
however only post boot and unsure if this would be capatible with using some
the extra protections against malicious SMM code, like verifying the RAMstage
upon wake from S3, which Coreboot can provide). Providing these integrity
checks pass, and the user possesses a valid hardware-authentication token,
Coreboot can then be executed (without needed to trust SMM) and further
initialise Qube’s Xen hypervisor, which then executes dom0 and so on.
¹ Matthew’s rather grotesque aside was, “Well… you want to limit the number of
parts they have to cut off of you…”
² Well… anyone actually. But everyone likes to pretend journos are
special and the rest of us are second-class citizens, right?
³ Yes, I hate that word too. Shut up and mark your bingo card already.
⁴ I’d just like to take this opportunity to coin the term SmartSchmuck.