I have observed something with the PureBoot boot process which I cannot explain and let me very puzzled.
Hardware: Librem 15/v4
Firmware: Pureboot 30
USB Security device: Librem Key
Explanation: Normally, the boot sequence first runs coreboot and then enters the payload HEADS in order to check that the HOTP secret released by the TPM matches the one on the LK. It will first check that the LK is inserted and after that validate HOTP, thus proving untampered firmware. The key will at this point flash green and display HOTP verification success on the screen. If you let the boot process continue automatically, it will wait 5 seconds and if there is no keyboard event, proceed with signature verification before kexec into the target OS.
Observed behaviour: I usually let all this go uninterrupted and proceed with default boot automatically - BUT the other day I inadvertently unplugged the LK just after HOTP verification while still in the 5 seconds delay. I thought I would get an alert, since I had removed the LK much too early, before the /boot partition validation; and to my great surprise, the process continued without the key inserted and completed the boot as usual…
This really puzzled me, so I replicated the sequence several times, confirming this odd behaviour that in fact the LK does not need to be there in order to verify signatures and binaries/files inside the /boot partition. This is very strange and unexplainable: the signature, hashes and anti-rollback data can only be verified if the gpg smartcard is accessible, right? How could any gpg operation succeed if there is no smartcard plugged in? Or are the required gpg keys stored in memory at this point (which would be disastrous)?
I can only conclude - having no other logical explanation - that no verification really occurs and that all the text being displayed might only be spoof to reassure cautious user.
I hope someone will prove me wrong and explain why…
Yes, although they were already verified when you decided to remove your Librem Key during the five second keypress window.
See above.
No, but since the TPM does not have a clock, the TOTP secret must be temporarily stored in RAM in order to produce the OTP code that is verified against the Librem Key.
See also:
If what you say is correct, then I find this very misleading: if all verifications were already made before the timeout, why then display all subsequent (but in reality former and already done) steps live as if they were actually happening?
After verification, there are no subsequent steps other than the five second keypress window, which is an optional prompt to access the PureBoot Boot Menu.
You didn’t understand what I meant: after the 5 seconds window and if there was no keyboard event, Pureboot goes on to display all its verification steps as if they were happening right then, live - although what you say is that these were already processed long ago before the 5 s. pause. This doesn’t make sense to me: why not just kexec and give control to the target OS without further output, then!
After the five second keypress window, there are no additional verification steps displayed other than potentially verified kexec boot parameters and hashes from a default boot previously signed with your OpenPGP public key using the currently running firmware, otherwise all live verification happen before the five second keypress window.