Re: [PLUG] Fwd: Linux Install & school

[Rich Freeman via plug <plug@lists.phillylinux.org>]

On Wed, Jan 10, 2024 at 8:44 AM brent saner via plug
<plug@lists.phillylinux.org> wrote:
>
> 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.
>
>
> 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.

Nothing in that document says that it bypasses TPM checks.  It DOES
say that changing the boot order will cause Bitlocker to fail and go
into recovery mode, which makes perfect sense if it is using measured
boot.  If you change the boot order, measured boot will fail.

I don't know whether Bitlocker directly checks the EFI boot order, or
if it just attempts to read the data from the TPM and fails, but
either way it wouldn't be able to read the key data from the TPM so it
would have to go into recovery.

>
>>
>> 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.

Yup, I read all of that, and nothing I said contradicts it.  Changing
the UEFI boot order will cause measured boot to record a different
hash, since the EFI program it runs is part of the hash.

>> 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*.

That is true, but without reverse engineering it or more documentation
we have no idea what is happening.

You're proposing the pseudo-code for this is:
1. Check UEFI boot order.
1a. If UEFI boot order has been changed go into recovery and do not proceed.
2. Attempt to load the keys from the TPM.
2a. If keys cannot be loaded go into recovery and do not proceed.
3. Continue with decrypting the disk using the keys...

I suggested that the pseudo-code basically skips step 1 entirely, and
fails on step 2.  Either of us could be right, but the end result is
the same.

>
>> 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.

You don't know that is how they're doing it, but let's assume this is the case.

>
>> 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?

Simple - install a hypervisor that when you attempt to read the EFI
vars you instead return the original boot order.  If you attempt to
check for a hypervisor or install your own, then emulate this
succeeding.  This is the sort of thing measured boot is designed to
prevent.

> 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.

So, this goes back to step 1 in the pseudo-code above.  Sure, it is
possible they're doing a sanity check first, and there is no harm in
that, but either way the result is that if you change the boot order
you can't access the data in the TPM.  If you bypassed this check
reading the data from the TPM would still fail.


>
>> > (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*.

Of course it is.  That's the whole point of recovery.  It bypasses the
TPM.  The recovery data includes the key needed to decrypt the hard
drive.  If you use it then Bitlocker can just decrypt the drive
without needing to access the TPM, and then it can just reset the TPM
and store the key again, and now it will work as long as you don't
change the EFI program you use to boot again.

However, I wasn't talking about Bitlocker recovery.  I was just saying
that if you restore the original boot order then you probably won't
even need recovery mode, because now measured boot will succeed,
unless it actually does go looking for other EFI changes as you
suggest.

>> 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:

So, again, that webpage doesn't seem to have anything to do with
Bitlocker.  It is describing a completely different set of APIs for
accessing measured boot info, and isn't necessary to use Bitlocker
with measured boot.

>
> 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?

So, you're conflating remote attestation and measured boot.  They're
two separate things.

Measured boot takes place through the boot process, and of course has
to happen before userspace runs.

Remote attestation is an OS process that is accessed by userspace.  It
could be started at any time, perhaps on demand by a system call, and
really the only thing that matters is that it is launched by the
trusted OS code.

>
> 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."?

Yes, because that is how TPM key storage with measured boot works.  It
has nothing to do with remote attestation.0

>
> 2.a. The above is Microsoft's provided recommendation for measured boot in Windows 10 (and 11).

No, that is their recommendation of how it should be used with
userspace programs.  It is not a description of how measured boot
itself works, and it is not a description of how Bitlocker TPM key
storage works.

If you buy a modern laptop, stick a brand new empty hard drive in it,
then wipe it and install Arch on it, then it is STILL doing measured
boot, because that is a function of the TPM, CPU, and firmware.  Now,
if Arch doesn't support it the measured boot hashes will end with the
loading of grub or whatever you're using to boot it, but those hashes
are recorded in write-once memory on the TPM.

> 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.)

None of the above.  That webpage isn't intended to describe the
operation of Bitlocker.  It has no need to read the measured boot data
anyway.  It just needs to ask the TPM for the keys, and the TPM will
read that data.

> 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.

Nothing in that documentation says the TPM isn't involved.  It is a
guide intended to help sysadmins.  If they screw up their boot order,
the solution is to fix their boot order.  They don't even need to know
that a TPM detected the change, or that the reason the boot order
matters is due to measured boot.

> 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.

That's possible - the whole pesudo-code bit above.  Honestly, it
doesn't really matter.  It is an internal implementation detail.  Fail
on step 1, or fail on step 2 - the result appears the same to the end
user.


> (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.
> )

So, I've never used that, but this just sounds like an additional
layer of protection.  Now you need a PIN in addition to a clean
measured boot, and the PIN can be provided over the LAN.  The result
is that the laptop won't boot if you tamper with it, and it also won't
boot if you remove it from the LAN.

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

Measured boot is just the storage of hashes in the TPM PCR during the
boot process.  It is the same whether you use Windows or not, though
what MS adds to the PCR and when would be specific to their OS.  If
you use measured boot with Linux it obviously won't be storing the
same things since from the point where Grub/etc is run the
architecture and layers are different.  Up to that point the PCR would
be same on a particular bit of hardware no matter what OS it is
running, unless you change the firmware.

The issue is that you're mixing up:
1. A MS document on how to use measured boot, as a software developer,
which has nothing to do with how they implemented Bitlocker.
2. Bitlocker docs designed for a sysadmin, which are more about what
you need to know and not how it works.
3. Technical descriptions of Bitlocker which are intended to describe
the security measures it employs, but not describe the actual
code-level implementation of those features.

RE #3 I agree that I can't be sure whether MS checks the UEFI boot
order before querying the TPM.  They could do that, but it is a bit
moot, since the visible results of either approach would be the same,
and there is no way to bypass it with either design.  The TPM and
measured boot is what is ultimately securing the keys.

> 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.

Sure, but you can't use TPM-backed key storage with Bitlocker without
a TPM.  It then is vulnerable to the sorts of things that can happen
when malicious code is inserted prior to your encryption software
running, like intercepting the keys and so on.

If they weren't using a TPM then the solution here is to just patch
Bitlocker to not check the UEFI boot order, which would be exactly
what a nefarious actor would do, which is why this is a poor way to
implement things.

-- 
Rich
___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug