Re: [PLUG] Fwd: Linux Install & school

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

On Wed, Jan 10, 2024 at 5:30 AM brent saner via plug
<plug@lists.phillylinux.org> wrote:
>
> On Tue, Jan 9, 2024, 15:37 Rich Freeman via plug <plug@lists.phillylinux.org> wrote:
>>
>> On Tue, Jan 9, 2024 at 3:04 PM Aaron Mulder via plug
>> <plug@lists.phillylinux.org> wrote:
>> >
>> >  (even if we selected Windows from the Grub menu, Windows wanted a BitLocker recovery key because it noticed the changes, and we don’t have that for the school machine).
>>
>> Well, Windows didn't notice the change so much as the TPM did.
>
> 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.

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

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.

Another way to think about it - how did Bitlocker know the boot order
was changed?  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.  BitLocker would be useless with TPM-stored keys if it didn't
use measured boot.  Of course you don't need a TPM to just type in a
passphrase when you boot, but that is a less than ideal solution for a
bunch of reasons, and clearly isn't being used here.

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

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

This requires remote attestation to be effective, because how would
your software know it is even talking to the TPM otherwise?

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

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.

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

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