Microsoft gave a sneak peek at some of the cool upcoming security features of Windows 8 at the recent BUILD conference. One of the notable areas of innovation is building on 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 (or, more recently, integrated as firmware into system-on-a-chip architectures).
Of the TPM-related features, one of my favorites is “measured boot”. It’s introduced in this video from BUILD, Building hardware-based security with a TPM.
If you install the Win 8 developer preview build on a TPM-capable machine (for example, I’m using a 64-bit HP ProBook 6360b), the measured boot feature is on by default. You’ll need a third party tool to view the data, or you can build your own from an SDK sample Microsoft has provided. Back to that in a second, though.
What does measured boot do? In short, it 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 log file which lists 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 in the log file.
Measured boot has limitations. For one thing, it only protects early-boot drivers (including an optional Early-Load Anti-Malware, ELAM, driver which is expected to be provided by antivirus vendors – see the “Secured boot architecture” slide in the above presentation). 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 measured boot only happens at boot time (see the “TPM basics” slide in the above presentation). After that, until the next reboot, you’re trusting your antivirus software to do its job.
The ELAM/anti-malware opportunity is cool, but where measured boot really shines is in the context of remote attestation, another TPM-based feature discussed at BUILD. Remote attestation is just a fancy, albeit descriptive name for the process of taking the signed log file 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/ELAM 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).
So much for the fine print; let’s see measured boot in action. The easiest way to do so is to download and build the Platform Crypto Provider sample from MSDN. It builds pcptool.exe, which offers a command-line interface for interacting not only with measured boot, but also with other TPM-related features discussed in the BUILD presentation. Unfortunately, building pcptool.exe seems to require the full Developer Preview version of Visual Studio 11, rather than just the Express version.
Once pcptool.exe is built, you can retrieve the binary version of the measured boot log data as follows:
>PCPTool.exe GetLog c:\temp\bootlog.out
Then, to convert the binary into XML:
>PCPTool.exe DecodeLog c:\temp\bootlog.out > c:\temp\bootlog-decoded.txt
Finally, it’s instructive to examine the contents of the XML log file.
<LoadedModule_Aggregation Size=”435″>
<FilePath Size=”60″>\Windows\system32\winload.exe</FilePath>
<ImageSize Size=”8″>1286144<!– 0x000000000013a000 –></ImageSize>
<HashAlgorithmId Size=”4″>SHA-256</HashAlgorithmId>
<AuthenticodeHash Size=”32″>
9cb15db889bb78400e4cc6831d04616c013bf904b097cedb503e5136e5750b16
</AuthenticodeHash>
… <AuthoritySHA1Thumbprint Size=”20″>
cc9008d2d4e80eb924e3ad29cb08600f58570cdc
<!– …………….XW.. –>
</AuthoritySHA1Thumbprint>
</LoadedModule_Aggregation>
The above log entry shows the hash and signer information for the Windows boot loader. Again, combined with remote attestation, this information can be evaluated by a remote server to establish cryptographically that early system boot components have not been modified.
Measured boot is a powerful security feature of Windows 8, and we’re looking forward to integrating it into customer protocols and applications.
5 Comments »
Permalink
