Hacker News Reader

Comment by Arnavion | Hacker News Reader

This is not "attacking" RAM. A UEFI binary (or Linux kernel in the CCC demo which uses a different method to retain the key in memory) already has access to all the extents of physical memory. It just has to search it for the scribble leftover from the bootloader.

See https://github.com/NoInitRD/Memory-Dump-UEFI/blob/db4888dc05... and onwards.

Edit: Ah, I guess you're referring to the fact that the reboot preserves RAM contents? DDR5 doesn't change anything about that AFAIK.

View on HN

Indeed, however it should be noted that this is only a single attempt attack and which will trigger the tamper protection.

Changing the boot order, making changes to the BIOS or booting from an unsigned bootloader would trigger a bitlocker lockout.

This means that if you don’t get the keys on the first attempt you can’t just pass the machine back to the user and try again later since the next time it will boot it would boot into bitlocker recovery.

And even if the attack is successful the user will still be aware that something did happen so you are still better off with other physical attacks if they are still possible.

Why? You're not booting Windows again, and restoring the secure boot state and boot order to the original values will result in the PCR values being what they were before, so what's changing that would force recovery mode?

The TPM tracks the state of the secure boot and the bios, that log is stored in the TPM itself the next time you’ll try to boot into windows it will see that something happened and bitlocker will lock itself out.

Do this experiment.

Boot into any Linux live CD on a machine with bitlocker enabled.

Reboot and see what happens.

I did that last night. It didn't have any issues booting back into Windows after booting to a live USB.

I didn't change any parameters of the Windows boot option or the rest of the system.

It seems that this is a property of TPM 1.2.

> On devices with TPM 1.2, changing the BIOS or firmware boot device order

https://learn.microsoft.com/en-us/windows/security/operating...

Changing it will trigger recovery, changing it back to the original won't

Yeah I seem to recall every time I've done that it seems to auto boot fine when I change it back to what it was before.

And as mentioned it's never had issues if I did a one off choice from the boot menu.

No, the TPM doesn't retain PCR measurements over reboots, and the log (rather than the composite PCR value) is handled by the firmware and the OS and the TPM has no idea it exists.

It seems that this is a property of TPM 1.2.

> On devices with TPM 1.2, changing the BIOS or firmware boot device order

https://learn.microsoft.com/en-us/windows/security/operating...

It doesn't matter if you change the settings back. I don't know how it works, but something non-user configurable is changed that prompts Windows to require a reset of the TPM keys.

Reply on news.ycombinator.com