config TCG_TPM2_HMAC
    bool "Use HMAC and encrypted transactions on the TPM bus"
    default n
    select CRYPTO_ECDH
    select CRYPTO_LIB_AESCFB
    select CRYPTO_LIB_SHA256
    select CRYPTO_LIB_UTILS
    help
      Setting this causes us to deploy a scheme which uses request
      and response HMACs in addition to encryption for
      communicating with the TPM to prevent or detect bus snooping
      and interposer attacks (see tpm-security.rst).  Saying Y
      here adds some encryption overhead to all kernel to TPM
      transactions.

Last year, I came agross a Linux kernel feature called TCG_TPM2_HMAC. It claims to detect or prevent active and passive interposer attackers. That’s one of my sleeper agent activation phrases, so I dug in.

TCG_TPM2_HMAC lives primarily in drivers/char/tpm/sessions.c and is discussed at further length in Documentation/security/tpm/tpm-security.rst.

It all sounds really great. We should care about interposer adversaries. It’s great to use the TPM features that were invented to help us with these problems. Let’s draw a little picture of what’s being attempted here.

In this threat model, there is an adversary who can access the untrusted bus on which all the TPM traffic is sent during the boot. This can be done using hardware hacking or by hijacking another device that controls the TPM bus (e.g., a BMC).

TCG_TPM2_HMAC is a kernel feature, and the kernel boots after the platform firmware and the boot loader, so it can’t do anything about interposer adversaries tampering with firmware and boot loader measurements. Let’s assume for now that the firmware and boot loader are just implicitly trusted to have booted “correct” code and successfully made honest measurements of all the boot stages up to and including the kernel. We also implicitly trust the TPM to behave correctly, here. Or if you have a newer TPM, don’t!

Someone familiar with the STRIDE model can easily observe the following threats just on the big red wire in our picture above:

The attacker may or may not necessarily get anything out of manipulating the TPM traffic itself (unless they are some kind of degenerate that just likes to talk to TPMs for fun). But folks who are familiar with TPM-based measured boot and attestation should be able to immediately see the value to the attacker of “modifying measurements” or “obtaining unsealed secrets”.

Let’s take a second to distinguish the two types of attackers here:

• Passive Interposers aka snoopers can only read from the bus but not modify the data.
• Active Interposers can read and write to the bus.

The very best thing a passive interposer can do here is Information Disclosure: read data from the bus. Since measurements should typically not be secret, the (legitimate) measurements sent to the TPM are not very interesting. Unsealed secrets (that were sealed to the measurements in the TPM) might very much be! That’s why security/keys/trusted-keys/trusted_tpm2.c uses an encrypt session using the helper tpm_buf_append_hmac_session which is unfortunately a little bit entangled with the TCG_TPM2_HMAC feature (but that’s how software development goes). All that really needs to be done here for this case is to use an encrypt session key established using the EK as discussed widely by many others but also myself.

The remainder of this blog post discusses the active interposer case.

An active interposer generally wants to do one of two things in this scenario:

1. (Tampering, Denial of Service) Tamper with TPM measurements made by the kernel, to falsely attest or unseal as the “intended” code or state, from “unintended” code or state.
2. (Spoofing, Information Disclosure) Interpose the TPM connection and defeat the encrypt session solution for unsealing secrets.

The TCG_TPM2_HMAC feature will establish an auth session salted (key-encapsulated) to the EK every time the kernel extends a PCR or gets randomness. You might say to yourself, “self, that’s a lot of overhead (asymmetric crypto in the TPM) for common, fast operations (PCR extensions, randomness generation)” and you’d be right. Wow, this feature is expensive! Good thing it’s solving a real problem, right?

Every time a session is needed (e.g., every time the kernel needs to extend a PCR), the TCG_TPM2_HMAC feature key-encapsulates a new session key with something called the “Null Primary Key” which is a P256 ECDH key derived from the Null hierarchy (which means it changes on every boot). It uses this session key to protect the TPM command by encrypting the inputs and outputs and adding an HMAC to detect tampering. Great.

One problem: how does the kernel know what the Null Primary Key should be? Read this thread to not find out.

The kernel takes the Null Primary Key at face value and stashes the Name (hash) of it at /sys/class/tpm/tpm0/null_name and trusts that userspace will attest the key later using the EK.

This inverts the chain of trust for measured boot: the kernel is responsible for measuring userspace, so that “bad” or “malicious” or “unintended” userspace cannot impersonate “good” or “well-behaved” or “intended” userspace.

This means that all the active-interposer attacker has to do to defeat TCG_TPM2_HMAC is:

1. Replace or hijack the userspace component responsible for checking the Null Primary Key. Call this “Component X”.
2. Interpose HMAC session establishment by creating a fake Null Primary Key themselves (e.g., in software) and pretend to be the TPM responding to requests.
3. Intercept TPM2_PCR_Extend commands, replacing the measurements as desired (e.g., replace “hash of malicious Component X” with “hash of good Component X”).
4. Malicious component X ignores the “wrong” Null Primary Key name at /sys/class/tpm/tpm0/null_name.

You can solve this problem by threat model gerrymandering: simply declare that the active interposer adversary is not able to tamper with userspace, which is stored on physical media less than 12 inches away from the TPM in most cases. Note that full disk encryption using the TPM cannot save you here, because if the booting system can fetch the key, so can the physical adversary. If you still think you have a tamper-proof userspace at this point, ask yourself why you need the kernel to measure it anymore.

Adding remote attestation also does not help here, because while a remote system can spot-attest a “Null Primary Key”, it has no way of knowing which key the kernel used when making its measurements.

TPM2_TCG_HMAC was disabled by default again in August 2025 starting with version 6.18.

What lessons can we learn from all this?

1. Applied cryptography cannot solve a security problem. It can only convert a security problem into a key-management problem.

   Corollary: If you aren’t actually solving the key-management problem, your cryptography is strictly decorative. This is not only not helpful, it is actively harmful, because it gives users a false sense of security, leading them to skip other precautions they would have otherwise taken.

2. Chains of trust are directional. Do not invert them.

   Corollary:

   

   You know what the chain of trust is? It's the chain I go get and beat you with 'til ya understand who's trustin' who here.

3. Unexplainable security features are just marketing materials.

   Corollary: While attestation protocols can be quite byzantine, they should always boil down to 1 or more of “X checks Y against Z” and it should always be possible to explain why X, Y, and Z are each trusted. The explanations may lead to more X, Y, Z tuples, and this is fine, but don’t give up if your questions aren’t being answered.

   Corollary 2: When someone comes along with detailed questions about something you’re responsible for, don’t take it personally. Instead, build trust by engaging in a good-faith discussion. You’ll either be right, and your answers appreciated, or you’ll learn about a gap in your system you can improve.

Active physical interposer adversaries are a very real part of legitimate threat models. You need an integrated root-of-trust in your CPU in order to solve these. Check out Caliptra, which provides TCG DICE APIs from within the SoC itself as an integrated root-of-trust. This can be used on its own, or in conjunction with a discrete TPM.

Opinions expressed here are my own and do not represent the official positions of any employer(s) of mine, past or present

Murphy’s Law says: Anything that can go wrong will go wrong. Unfortunately, TPMs fall into the category of “anything.”

You can usually tell embedded security people apart from not-embedded security people, because the not-embedded security people will say things like “this is secure because the hardware does it for us” and the embedded security people will adopt this vacant, dead expression in their eyes when the not-embedded security people say things like that. Don’t get me wrong: the isolation of “doing it in hardware” is great, but it doesn’t change the fact that a person had to implement it in the hardware, and people occasionally make mistakes (just like they do when they implement things in software). Hardware security vendors work very very hard to avoid these mistakes, but “don’t ever make any mistakes” is not a very good strategy for the same reason that people buy fire alarms even though they typically don’t plan on burning down their houses.

Attestation is the continual process of fixing mistakes wherever they are found, and then checking your work. This is the superpower of a complex system with a hardware root-of-trust (such as a TPM)! Measure whatever you booted into the root-of-trust (e.g., TPM PCRs) before you boot it, and then get the root-of-trust to provide proof of those measurements (e.g., TPM PCR quotes). When you roll out an update to part of your system, the updated software’s measurements will be evident in the proof that you got from the root-of-trust.

What can’t be attested? The Trusted Computing Base (TCB) itself. Elements of the TCB (i.e., the Roots of Trust) must be implicitly trusted because they are not measured (what else would measure them?) This is because of the definition of the Trusted Computing Base:

Trusted Computing Base (TCB): The set of components of a system that must be assumed to be trustworthy because there is no way to check them. ¹

There’s about 60K lines of code in the TPM Reference Implementation. On top of this, TPM implementations have several subsystems that all contribute to the trustworthiness of a TPM, for example:

• Clock
• NV (non-volatile memory)
• Cryptographic key generation and operations
• Vendor-specific functionality

TPM vendors usually get it right, but occasionally, mistakes get made ^{2 3 4}. When a bug is identified inside the TCB, it should be fixed ⁵. Since the TCB has to be assumed to be trustworthy, you have to ask it nicely to update itself and hope it’s not trying to trick you. When your TCB is a Root of Trust inside a lot of remote machines (e.g., a datacenter), it’s hard to have this hope. One attacker on one of the machines might intercept your request, respond with “OK” (perhaps asserting the identity of the root-of-trust, using secrets it exflitrated out of it), and then… not update the Root of Trust. As represented in the drawing at the top of this post, both a buggy and fixed TPM have a valid EK cert. How do we check?

So, we decided to shrink the TCB of the TPM down to just its boot loader:

The job of the TPM’s boot loader is to validate, measure, and start up the TPM’s application firmware. The job of the TPM’s application firmware is to do all the things you ask your TPM to do after that.

Note that there is no requirement that a TPM be organized in this particular way. It might have a big monolithic firmware, or several small firmware bits; the boot loader may be one stage or several. The key idea here is that the TCB of the TPM should be as small as possible, and be the minimal set of TPM implementation parts that allow verifying and launching the rest of the TPM.

The latest version of the TPM 2.0 specification, 1.83, introduces a feature called “Firmware-Limited Objects” that allows us to shrink the TCB of the TPM in this way.

A TPM implementing Firmware-Limited Objects offers some new hierarchies for use with TPM2_CreatePrimary. If you create an EK using TPM_RH_ENDORSEMENT you will get the same EK regardless of TPM firmware version. This is why updating your TPM doesn’t destroy your EK cert. However, now (on TPMs that implement Firmware-Limited Objects!) you can create a key based on the new TPM_RH_FW_ENDORSEMENT, which will change if the TPM’s firmware changes (but otherwise stay the same if you don’t change the TPM’s firmware). If the TPM provides a Firmware Endorsement Key certificate, it can include the firmware version in the cert, and the whole (cert + key) will change between different firmware versions. With the Firmware EK cert, you can attest the TPM after you update it by simply challenging the EK associated with the firmware version you rolled out. If this all sounds kind of familiar, it’s because it’s just DICE (although the TPM spec does not require the TPM to use DICE per se to implement the firmware-limited hierarchy feature).

If you’re not familiar with DICE, that means the TPM will do something like this:

The TPM’s boot loader measures the to-be-launched TPM application firmware (e.g., by hash), then mixes that hash with a secret that it keeps (BL Secret) that the application firmware never gets access to. The resulting derived secret is called the FW Secret, and it is mixed into Primary Keys generated in TPM_RH_FW_* hierarchies. This gives us the following nice properties:

• Each firmware version on a given TPM gets a fresh FW Secret that no other firmware on that TPM (or any other TPM) has
• Each firmware’s FM Secret is stable if the firmware is not changed

This shrinks the TPM’s TCB to effectively just the TPM’s boot loader and the hardware itself: the rest of the TPM’s firmware is measured and can be attested by using firmware-limited keys. Therefore, on such a TPM, we can recover (remotely and at scale) from ~any conceivable bug in the TPM’s application firmware.

What if you want to seal data to the TPM’s firmware, and unseal your data later (potentially from an even newer firmware)? Check out the TPM_RH_SVN_* hierarchies in 1.83.

Disclaimer: I work on TPM at Trusted Computing Group. As always, the views expressed in this blog are my own.

Every year or so, we see another version ^{2 3 4 5 6} of a paper called “I Hacked BitLocker in 25 Seconds With This Soldering Iron and the Power of Friendship”.

And every year, I assume a conversation like this occurs in Redmond:

“Should we fix BitLocker to deal with this issue?”

“No, we (picked our threat model 20 years ago|are too afraid of the code|sacked the people responsible for that so the execs could get bigger bonuses last year).”

Invariably, the telephone game that is tech journalism and social media pollutes the conversation, and people end up asking “why does the TPM suck so much?” (Answer: It’s not the TPM that sucks in this situation).

Security is about solving threat models, not extra credit. People (e.g., I) have asked the BitLocker team to update their threat model in the past. They haven’t so far. They probably won’t this year, or next time this topic hits my feed. So I am going to assume that BitLocker will never change. But here is how a full-disk encryption system like BitLocker could use the TPM properly. If Microsoft wants to hire an intern to finally fix BitLocker’s threat model some summer, that would be cool too.

The Problem

See the diagram at the top of the post.

The naive implementation of a system that uses the TPM to unseal a disk encryption key causes the disk encryption key to appear in-the-clear on the TPM bus (typically, LPC or SPI). It’s not hard to read the 1s and 0s on these wires and convert them back into data. And nobody assumed that it would be. The TPM may as well be shouting the BitLocker key back to the CPU.

So, all these papers about breaking BitLocker are really about parsing LPC or SPI framed TPM commands. There isn’t, like, cryptography or anything happening here.

The Solution

So, how can a full-disk encryption product protect itself from sophisticated attackers with access to a Raspberry Pi?

In terms of applied crypto toolboxes and the threat model, we would say that we want the host and the TPM to perform some sort of key establishment and then use that key to protect the secrets that have to traverse the bus.

Since this particular threat model includes a passive interposer who can read the bus but not modify/drop commands/responses, any type of key establishment would help here. Let’s say that we use Key Encapsulation as our key-agreement mechanism.

TPM supports TPM-specific RSA and ECC KEMs, designed to allow use of a restricted decryption key for this use-case, though without using the term “KEM” as that wasn’t popular until NIST’s PQC competition despite being apparently coined in 2001.

The Work

1. Create a restricted ECDH decrypt key in the TPM during boot (do not use RSA unless you aren’t in a hurry to boot).
2. Perform the encapsulation to create an additional encrypt session for the unseal command.
3. Decrypt the encrypted response parameter using the key you encapsulated in (2).

The Future

Interested in active interposers? Now you’re thinking with interposers. You need some way for the host and the TPM to mutually authenticate. Check out what my colleagues and I are working on: https://www.osfc.io/2022/talks/protecting-tpm-commands-from-active-interposers/

I’d like to propose a simple test for any definition of security success: the Brick Test.

As Security Team people, we tend to evaluate our own work in terms of prevention. Under a certain threat model: the secrets are prevented from being exfiltrated; the messages are prevented against being forged; the company property is prevented against being misused.

If we’re being good engineers about it, we usually try to agree on a definition of success before we start: otherwise it’s not clear when we’re done or if we’ve done anything at all. Knowing what success looks like can also help us avoid starting unrealistic projects.

What should be considered in the definition of success? Certainly all the things we want to prevent (and the threat models under which they should be prevented), as discussed above. But what else?

The Brick Test asks just one question:

could a standard brick (i.e., a bit of masonry, any color, heavy enough to break glass when propelled) satisfy your definition of success?

If success is “the user’s disk can’t be decrypted by an attacker,” then a brick could achieve success more more permanently and completely than a whole team of very smart engineers. Bricks are also considered post-quantum.

If a brick can achieve success, it’s probably cheaper than you are. In this case, re-think your definition of success! (Or, shut down the project, job’s done!)

Corollary: any system that uses machine learning to satisfy criteria that fail the Brick Test is called “BrickGPT.”

As I mentioned last week, your TCB is important and without a good one, your capabilities are quite limited when it comes to attestation.

So, all right, we now live in a world where we know bugs like TPM Carte Blanche exist, and we can never go back to the world where it doesn’t. (Actually, we’ve been living in that world since 2014.) So what do we do now?

The best thing to do is probably to find a hardware Root of Trust for Measurement. Your CPU vendor may have some ideas, but a non-exhaustive list probably doesn’t leave out Boot Guard or Platform Secure Boot.

What about the millions of devices out there in the world today that don’t have a hardware RTM? Well, it turns out TPM 2.0 has some uncommonly-used features that can come in handy here.

TPM 2.0 has a feature called audit sessions, which you can read about in Part 1 of the TPM 2.0 specification. Audit sessions serve two purposes:

• An audit session with a session key (set up by “salting” or “binding” the session) causes the TPM to use that key to calculate an HMAC over its response.
• An audit session digest can be explicitly attested by an Attestation Key for consumption by remote verifiers, using a command called TPM2_GetSessionAuditDigest.

When you set up an audit session, it gets initialized with an “empty digest” (a buffer of all 0x00 bytes the size of the session hash algorithm like a PCR). Each time you send a command in the audit session, the session is extended:

where \(commandCode\) is the command code constant associated with the command, \(names\) is the concatenation of all authorized TPM Names (TPM object unique identifiers; hash of public area or primary seed handle value) used in the command, and \(commandParams\) is the concatenation of all the command parameters.

where \(responseCode\) is a TPM_RC value and \(responseParams\) is the concatenation of all the response parameters.

These formulas can be combined into higher-layer logic that lets a verifier plug in expected command/response invocations, like in this example:

audit := tpm2.NewAudit(tpm2.TPMAlgSHA256)
getCapCmd := tpm2.GetCapabilityCommand{
	Capability:    tpm2.TPMCapPCRs,
	Property:      0,
	PropertyCount: 1,
}
getCapRsp := tpm2.GetCapabilityResponse{
	MoreData: false,
	CapabilityData: tpm2.TPMSCapabilityData{
		Capability: tpm2.TPMCapPCRs,
		Data: tpm2.TPMUCapabilities{
			AssignedPCR: &quote.Attested.Quote.PCRSelect,
		},
	},
}
if err := audit.Extend(&getCapCmd, &getCapRsp); err != nil {
	return err
}
if !bytes.Equal(auditAttest.Attested.SessionAudit.SessionDigest.Buffer, audit.Digest()) {
	return fmt.Errorf("invalid audit digest")
}

In the above example, a test verifier checks to make sure that the audited session proves that the caller called TPM2_GetCapability(TPM_CAP_PCRS) and got back the same set of PCR banks they quoted with TPM2_Quote (see this part of the same test).

This allows the verifier to establish the following web of trust:

1. The AK is trusted because the caller provided an AK certificate.
2. The two things signed by the AK, the PCR quote and session audit digest, are trusted because the AK is trusted in (1)
3. The TPML_PCR_SELECTION quoted in the PCR quote is trusted because the signed audit log digest trusted in (2) is the digest of the well-known TPM2_GetCapability command with the TPM returning the same PCR selection in response.
4. The preimage PCR values are trusted because the quote is trusted in (2) and we know from (3) that the quote covers all active PCR banks.
5. The boot log is trusted because when replayed it results in the preimage PCR values trusted in (4).

Attesting a PCR quote, along with a reliable signal that there are no other active PCR banks on the system, helps defend against BIOS bugs where some of the PCR banks are left uncapped, by allowing the verifier to either mandate that every event in the boot log is measured into every PCR bank, or (more simply) that the device is configured correctly and only using a single PCR bank (e.g., SHA256). Because there’s not actually a good reason to have some of the software measuring into the SHA1 bank and other software measuring into the SHA256 bank.

This still leaves open other types of BIOS bugs, for instance a bug where the SHA384 PCR bank is just never extended even if it is the only active bank. (BIOS writers: please just use TPM2_PCR_Event to make the TPM do all the hashing and automagically populate every PCR.)

For a more complete example of this type of PCR attestation, please see https://github.com/chrisfenner/tcb-attestation.

For more information, see last week’s blog post about TPM Carte Blanche.

Opinions expressed here are my own and do not represent the official positions of any employer(s) of mine, past or present

I like to tinker with the TPM in my spare time. It’s like a great big box of security legos, or like a dryer, punk-er form of Minecraft. It’s pretty fun.

In 2017 I had the privilege of working on mitigations for an issue called ROCA. From then on, I’ve been fascinated by the idea of the Trusted Computing Base.

I believe that Murphy’s Law applies equally to code as it does to which way buttered toast will fall, or whether two intersecting clues in the New York Times crossword will be unusual names of minor celebrities from the 1970’s. The meaning of the TCB isn’t so much “your system is safe because of this smart stuff in this box” as it is “your system is utterly booched if when we find any important mistakes in this box”.

Also, the amount of mistakes we know about in any given box is a monotonically increasing function of time. Nobody says “good news, we’ve discovered some unexpectedly correct behavior in your kernel.”

I recently came into the possession of a Surface Pro 3, which is a machine that I happen to know shipped with TPMs affected by ROCA. I thought “ah, this is my chance to apply my superficial understanding of finite-field arithmetic to learn some more about this bug and how it was discovered.” So, I installed Linux on it, sshed in, and installed some TPM tools. My go-to “hello world” TPM tool is gotpm and reading the PCRs is a pretty basic TPM activity that lets you know you’re talking to a TPM.

So, when I was greeted with these PCRs, I knew that obviously I had made a mistake, and I was talking to some simulated, shim TPM or something:

0: 0000000000000000000000000000000000000000000000000000000000000000
1: 0000000000000000000000000000000000000000000000000000000000000000
2: 0000000000000000000000000000000000000000000000000000000000000000
3: 0000000000000000000000000000000000000000000000000000000000000000
4: 0000000000000000000000000000000000000000000000000000000000000000
5: 0000000000000000000000000000000000000000000000000000000000000000
6: 0000000000000000000000000000000000000000000000000000000000000000
7: 0000000000000000000000000000000000000000000000000000000000000000
8: 0000000000000000000000000000000000000000000000000000000000000000
9: 0000000000000000000000000000000000000000000000000000000000000000
10: 52dafc83858586083a5b09d80f4c75e77180691ee717d30bc07194713d5884b3
11: 0000000000000000000000000000000000000000000000000000000000000000
12: 0000000000000000000000000000000000000000000000000000000000000000
13: 0000000000000000000000000000000000000000000000000000000000000000
14: 0000000000000000000000000000000000000000000000000000000000000000
15: 0000000000000000000000000000000000000000000000000000000000000000
16: 0000000000000000000000000000000000000000000000000000000000000000
17: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
18: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
19: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
20: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
21: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
22: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
23: 0000000000000000000000000000000000000000000000000000000000000000

Except I wasn’t. This was my real TPM. For a sense of which of these rows of nonsense are supposed to not all be 0’s or f’s, see the SHA1 bank:

0: 3dcaea25dc86554d94b94aa5bc8f735a49212af8
1: b2a83b0ebf2f8374299a5b2bdfc31ea955ad7236
2: b2a83b0ebf2f8374299a5b2bdfc31ea955ad7236
3: b2a83b0ebf2f8374299a5b2bdfc31ea955ad7236
4: 27b2c869333dbe59c520294ffb652964da78b7ce
5: fe1b29141dcded019fe3423df304b5676c6c58d6
6: b2a83b0ebf2f8374299a5b2bdfc31ea955ad7236
7: 03e7b21f363721d4a04a550602c0742291f735b4
8: c7e3ff980c58cd67bc554519847b585de6b9bd33
9: 6167364dca8c424a2f5b1a9b3df5f121ddcfab4b
10: e13d0ffa292ef1e530005679978a0c5aae8967d3
11: 0000000000000000000000000000000000000000
12: 0000000000000000000000000000000000000000
13: 0000000000000000000000000000000000000000
14: 0000000000000000000000000000000000000000
15: 0000000000000000000000000000000000000000
16: 0000000000000000000000000000000000000000
17: ffffffffffffffffffffffffffffffffffffffff
18: ffffffffffffffffffffffffffffffffffffffff
19: ffffffffffffffffffffffffffffffffffffffff
20: ffffffffffffffffffffffffffffffffffffffff
21: ffffffffffffffffffffffffffffffffffffffff
22: ffffffffffffffffffffffffffffffffffffffff
23: 0000000000000000000000000000000000000000

This is pretty bad, because a bank of empty PCRs means an attacker researcher can just boot up a custom OS that doesn’t make any measurements, and use simple tools to extend whatever they want into those PCRs and attest them honestly (from the TPM’s point of view).

So, what prevents this happening normally, on all of the computers all of the time? Well, theoretically your BIOS has a well-behaved, immutable initial boot block that always makes proper measurements into the TPM, and whenever it fails to make proper measurements into the TPM it creates a small wormhole and sucks itself and your BitLocker key into the Negative Zone or, like, North Dakota, or something.

It turns out the code in your initial boot block is more or less like code you might find elsewhere in your computer, and you should not assume it’s better just because it’s more important.

I have three takeaways from working on this project:

1. Building a measured and/or verified aka Secure boot attestation system without considering the TCB is like building an ice sculpture on top of a dumpster full of matches. Like, chock full, to the brim of matches. And it’s in Oklahoma in July. Your plans are neat and also doomed.
2. People who build security frameworks should prefer simplicity over elegance and flexibility. It’s easier not to notice one of the PCR banks hasn’t been capped by the firmware when there are N banks of them (one per hash algorithm) and all the software running on the system can interact with whichever bank suits its delicate, not-crypto-agile preferences. If there were only ever one bank of PCR active at a time, it would be harder to miss a bug like this. (Note I didn’t say it would be impossible.)
3. The best place for TCB is in the immutable ROM of something that’s very hard to probe, swap, or tamper. Code in ROM should measure/verify “mutable” code (and by “mutable” I really mean “your threat model shouldn’t assume your adversary can’t afford one of these”). This step should be as simple as possible, with respect for the fact that if it’s broken you may need to throw away hardware. TCG DICE is an example of up-and-coming new hotness in this area.

Microsoft’s advisory was published on 2021-10-18.

For more information, see the full writeup at google/security-research.

Opinions expressed here are my own and do not represent the official positions of any employer(s) of mine, past or present