Re: Bitlocker-tripping hardware change with 5.2.0?

[Stefan Berger]

On 12/17/20 10:54 AM, Marc-André Lureau wrote:

Hi On Wed, Dec 16, 2020 at 11:45 PM Michael Weiser ...                                                                                                                                                                                     

Could it be as easy as booting a recovery linux distro and comparing the
outputs of dmidecode or somesuch?

I am afraid it's not so easy.  We should probably consider new tests to ensure version machines get the same PCR measurement from bios/uefi. That's what OS usually rely on, but they may probe more hardware related details themself too.

I created now this wiki page for swtpm: https://github.com/stefanberger/swtpm/wiki/Sealing-to-PCR-0-7-Values-when-using-QEMU

The whole purpose of measured/trusted boot is to reflect some known measurement values of a known BIOS in the TPM PCRs. Unfortunately this bites with sealing to those values and the rather fast development of QEMU. Updates of QEMU on the host platform then become a recovery event inside the VM, which is unfortunate, but this is when measured/trusted boot actually 'does its job'.

For giggles I did enter the recovery key of the testing VM when
prompted. It did boot up and showed Bitlocker enabled. After rebooting
it prompted for the recovery key again. I entered it again, it booted
again and I turned off Bitlocker (decrypted the disk). After re-enabling
Bitlocker (re-encrypting the disk) and rebooting again it now does not
prompt for the recovery key again.

Does Bitlocker not allow you to accept a configuration change (= PCR value change) and it internally (presumably) then seals the secreted against those new values so upon the next reboot it works again? Do you really need to go through the whole re-encryption process? It sounds like unattractive even for a physical machine firmware update...

       Stefan