As I’ve mentioned in previous posts, a notable area of recent security innovation is the Trusted Platform Module, or TPM, which is a tamper-resistant security chip that has been built into many PC motherboards for the past several years. Importantly, TPM capabilities are being integrated into firmware in system-on-a-chip architectures (such as the latest wave of tablets). Soon we’ll be seeing TPMs in mobile phones.
Of the scenarios enabled by the TPM, two of my favorites are secure boot and remote attestation. Here’s how it starts: at boot time, the BIOS computes a cryptographic hash of the operating system boot loader and boot drivers. This is critical for blocking malware such as rootkits, which load early in the boot cycle in order to effectively become invisible to antivirus software which loads much later.
Once the cryptographic loader and driver hashes have been computed, and the system is booted, a report consisting of a list of those hashes can be generated. This is where things get interesting. The hash of the boot loader is protected by the TPM itself. Further, the TPM can be provisioned with a cryptographic key which can be used to sign a measured boot log file. Thus, if you trust the TPM key, and you trust that a user can’t muck with the TPM itself (generally considered to be very hard, but not impossible), then you can establish a hardware-rooted trust chain for all of the drivers listed in that report.
This approach to secure boot has limitations. For one thing, it only protects early-boot drivers. For software higher in the stack, including most device drivers and anything loaded in user mode (e.g. browser plug-ins), you’re trusting your antivirus software to protect you. Second, the measurement part of secure boot only happens at boot time. After that, until the next reboot, you’re trusting your antivirus software to do its job.
Remote attestation is just a fancy, albeit descriptive name for the process of taking the signed report described above and sending it off-box for verification. The ramifications of that ability may not be immediately obvious, but they’re significant, since the main weak point of authentication schemes today is, “How do we really know that the client PC is acting on behalf of the user?”
In current authentication schemes, a server has no way of knowing whether a rootkit has been installed on a remote client. Why should it care? Compromised client computers are more likely to be used in fraudulent transactions. With remote attestation, a trusted TPM, and a trusted antimalware solution in place, the server can with higher assurance authorize the user to perform high-value transactions (transfer money, get a driver’s license, etc).
No Comments »
Permalink
