Re: [PLUG] Fwd: Linux Install & school

On Wed, Jan 10, 2024, 06:31 Rich Freeman <r-plug@thefreemanclan.net> wrote:

> Nope. bcfg and BitLocker lock for many reasons. This sounds more like a Bitlocker *recovery*, which doesn't involve TPM at all.[0]

Bitlocker recovery doesn't involve the TPM of course, since how could
it? The whole point of the recovery process is to bypass the keys in
the TPM since they are inaccessible.

That is *one of* the recovery conditions, yes. If you read the Microsoft documentation I provided, you will note that *another* condition that will trigger Bitlocker *recovery* is *if the Windows ESP is not the first boot*. It still bypasses TPM checks entirely but is based on UEFI boot order configuration.

It can be triggered by the inability to read the keys from the TPM.
The webpage you linked isn't a technical description of how Bitlocker
works. Yes, changing boot order can cause Bitlocker to go into
recovery. However, TPM measured boot is the reason WHY it goes into
recovery.

You can find more details here:
https://learn.microsoft.com/en-us/windows/security/operating-system-security/data-protection/bitlocker/countermeasures

With emphasis:

"Because BitLocker is designed to protect computers from numerous attacks, there are numerous reasons why BitLocker could start in recovery mode. ...

Changing the BIOS boot order to boot another drive in advance of the hard drive ...

The *TPM isn't involved in any recovery scenarios*, so recovery is still possible if the TPM fails boot component validation, malfunctions, or is removed."

No, Bitlocker *recovery* does not use TPM. The condition is (can be, but I suspect "is" in this case) triggered via UEFI vars configuration.

You'll find a bunch of references to the PCR here, but it is summed up
in: "By default, BitLocker provides integrity protection for Secure
Boot by utilizing the TPM PCR[7] measurement. An unauthorized EFI
firmware, EFI boot application, or bootloader can't run and acquire
the BitLocker key."

Secure Boot is a bit of a red herring here IMO, because ultimately it
is the boot measurement process and not control over the bootloader
that is securing the key. If you run some other EFI bootloader, then
its hash ends up in the PCR, and then when Bitlocker goes to read the
keys it can't do so because the hash doesn't match what was used to
store it.

It would not be reading the key if a recovery condition were triggered *before* a TPM check/validation/key request for *disk en(de)cryption*.

Another way to think about it - how did Bitlocker know the boot order
was changed?

EFI vars. They're *quite* readable from the hardware. Certain vars (bootorder, current) do not require TPM to, at the least, read.

And if the answer isn't measured boot, then how would it
protect itself against a rootkit that just intercepts all the API
calls and gives responses that indicates that the boot order wasn't
changed.

Because EFI vars are just that; variables. They don't execute code. They are stored values. How would you exploit this?

The EFI bootorder var, specifically, is a series of UINT16s from recollection.

(The current boot entry is stored as a separate read-only EFI var and is populated by the board once a boot entry is initiated.)

Could the boot entries be modified by intermediate malicious software that specifies that BCD's ID matches current boot? Sure! Which is why it's not *the only* BCD validation, but is *a* validation. An early one. There's no sense completing boot further if a configuration doesn't match up.

> (Addendum: Bitlocker recovery is like a "soft lock"; it can be removed by simply restoring the flagging condition state, such as by moving the disk's boot order to the first entry again.)

Sure, because all the TPM cares about is what measured programs are
run in what order. The data it stores is reset at reboot. If you fix
the boot order and reboot, then the TPM ends up with the PCR loaded
with the correct set of hashes, and thus the Bitlocker key is
unlocked.

Again, per BITLOCKER FAQ, TPM is ignored in Bitlocker recovery *regardless of the recovery condition*.

>> Most
>> likely it is configured to do a measured boot, so when the firmware
>> booted grub it hashed the grub EFI program and loaded that into the
>> write-once-per-reset TPM memory before executing grub. Then when
>> Bitlocker went to retrieve the key for the hard drive encryption the
>> TPM noted that the boot history had changed and refused to provide the
>> key. The recovery key would provide an alternate means of access -
>> without one or the other there is no way to decrypt the hard drive.
>
> Last I checked, Measured Boot, if enabled for an org in Windows 10
> and up, uses remote attestation and requires third-party client to
> request attestation.[1] It is unlikely this is enabled on a laptop
> issued by an org does not take the basic attention to lock out
> external/removable boot entries. School IT dep'ts are notoriously
> minimum/superficial effort.

So, the document you linked isn't about Bitlocker - it is about
leveraging measured boot in your own userspace software, and not to
just store keys in the TPM.

I quote:

Measured Boot uses the following process:

The PC's UEFI firmware stores in the TPM a hash of the firmware, bootloader, boot drivers, and everything that is loaded before the anti-malware app.
At the end of the startup process, Windows starts the non-Microsoft remote attestation client. The trusted attestation server sends the client a unique key.
The TPM uses the unique key to digitally sign the log recorded by the UEFI.
The client sends the log to the server, possibly with other security information.

So, in review:

1. The attestation occurs *before userspace*; why would you load userspace before successful attestation?

2. Did you or did you not say:

"Most likely it is configured to do a measured boot, ... Then when Bitlocker went to retrieve the key for the hard drive encryption the TPM noted that the boot history had changed and refused to provide the key."?

2.a. The above is Microsoft's provided recommendation for measured boot in Windows 10 (and 11). Were you thinking of something that is *not* measured boot, or were you thinking of Windows 8, which implemented non-remote attestation? Perhaps you and Microsoft disagree on what is considered "measured boot". (Which in fairness to you would not be egregious; Microsoft has plenty of misnomers.)

We agree that a Bitlocker can can be granted from TPM. We agree a recovery key can be used in lieu of a TPM key.

But what is provided per documentation is recovery key generation can trigger *by entirely non-TPM-related conditions*, conditions *far more common* than that outlined, and that Windows 10 and up require third-party remote (or however the third-party implements, but probably remote) attestation.

Bitlocker doesn't require remote attestation because it has no need to

trust that it is talking to the TPM and that its API calls to it
aren't being tampered with. It is effectively the TPM that is
checking that Bitlocker wasn't tampered with, not the other way
around.

Again, in *a* condition, yes. Again, another condition that can absolutely trigger *before Bitlocker TPM interaction* is boot order. This check does not weaken TPM validation. Ideally it oughtn't be the ONLY check, which is why it *isn't*, but it occurs before a Bitlocker key is requested from TPM.

(Sidenote, the following is typically in conjunction with measured boot:

To address these issues, BitLocker Network Unlock can be deployed. Network Unlock allows systems that meet the hardware requirements and have BitLocker enabled with TPM+PIN to boot into Windows without user intervention. It requires direct ethernet connectivity to a Windows Deployment Services (WDS) server.

)

If a rogue program was inserted in the boot chain, then its
hash would be stored in the PCR, and the TPM would only allow access
to keys that were stored when the rogue program was running. Since
the rogue program wasn't running when Bitlocker was set up, there
won't be any accessible keys.

The entirety of which is ignored if an EFI bootorder var validation fails.

Imagine if you stored your disk encryption key in a bank safety
deposit box. When you retrieve the key from the box, how do you know
it wasn't tampered with by the bank? Well, the answer is that you
don't care - if it is tampered with, it won't work, and if it does
work, then it wasn't tampered with. As long as the bank knows that
you are yourself and not an imposter, and the vault is impenetrable,
the key is secure while stored there. So what matters is that the TPM
can tell that the OS wasn't tampered with.

Physical key analogies fall short when discussing asymmetric PKI, but that's largely irrelevant here - I'm saying there are cases you don't get to the bank because you trip and fall in an open manhole on the way. (Look, it's really hard to provide a congruent metaphor for an EFI var validation.)

For another metaphor, I am saying that a Chuck E. Cheese is refusing you access to staff areas because you're wearing a Mickey Mouse costume. Is it a *valid* refusal? Maybe, maybe not, but it's a *simple, common sense* one that can be performed before they even check for an employee badge.

>> . This is a pretty typical
>> secure configuration on laptops - at least the ones that don't run
>> Linux other than ChromeOS.
>
> Typical for orgs that lock down beyond "UEFI menu has password, is gud", sure. Typical for school-issued hardware? Absolutely not.

It is provided by Bitlocker out of the box if the hardware has a TPM,
so it is likely to be used pretty widely.

Again, I suspect what you consider "measured boot" and what Microsoft calls "measured boot" differ.

Lastly, for fun, I should note it's entirely possible to remove the TPM requirement and usage for recent Windows (both desktop and server variants), it's just a single registry key during install. I doubt a school is doing that either, but it's certainly easily found.