tlaurion
commented
1 year ago Put on my todo list to watch conference soon (expect next days).
Present concerns with such idea (just the idea) is the for Heads to be able to support this (bluetooth) would require adding bluetooth kernel support (modules loaded on demand) and also having bluetooth toolstack (runtime) to be able to pair and also communicate with phone. Not only is the toolstack huge (SPI space is really limited), most of Heads users (Qubes users AFAIK) normally remove their bluetooth daughter boards if present and dodge Bluetooth altogether.
Bluetooth added attack surface to Heads is in my opinion (pre-boot level) undesired, but I also understand the convenience it would offer. The trade off would go on the side of convenience. But to have trustable measurements here, it should still be done as early as possible. That would mean, through coreboot as early as possible (where talk is on top of UEFI from presentation description).
But this opened issue relaunched the exploration of extending remote attestation possibilities, DRTM (for DRTM requiring ACM+SINIT for Intel based hardware): read t440p #1282 + #1172). This taking advantage of TPM again, but putting more trust into bootblock measurements (done by ACM blob prior of the bootblock to measure the bootblock itself from outside source into PCR0 which only ACM can write into).
Some ideas if we want to go in the remote attestation path with another device being trusted for attestation:
- We could have that through USB (less convenient: cable needed while limiting the adding much TCB)
- Fobnail is about that: https://fobnail.3mdeb.com/description/
- We could use phone to store not only firmware measurements, but using the phone as a trusted verification (replacing TPM for people deciding to not trust it).
The problem here, unless someone points me to new data, is that nothing exists as of now under coreboot to use such devices in a secure way. The reason why TPM are loved is because they first exist on existing machines, and have simple enough communication protocols to be usable directly from coreboot bootblock to either measure itself, or have itself measured as part of IBB when TXT exists (TXT using the TPM to measure the bootblock from the CPU from Intel ACM +SINIT blobs). That is trusting additional added blobs only existing on Haswell+ to have RoT anchored in CPU.
So here, just like with the idea under #493 is that if USB/Bluetooth is not initialized by coreboot bootblock, then devices made available through those devices would arrive way too late to be usable as a trustable source for remote attestation. Otherwise, I may miss something @kerneis-anssi on the theoritical level and general trustworthiness of such ideas.
Those thoughts here were based on description of the talk only. Wish I was at the presentation, but missed it. Will extend thinking process after having watched it and meditated on it a bit.
kerneis-anssi
DemiMarie
This issue is intended as a discussion to decide whether the following is an idea worth pursuing or not.
Is your feature request related to a problem? Please describe.
It would be nice to be able to have disk decryption gated on remote attestation working: instead of checking a TOTP on your phone, have your phone send a decryption key to the laptop if and only if PCRs match their expected values.
Describe the solution you'd like
A way to make this happen for personal users using their phone is Ultrablue: https://github.com/ANSSI-FR/ultrablue
Describe alternatives you've considered
I've been told VaultBoot does something similar using a server running on a RPi: https://github.com/hardenedvault/vaultboot
I haven't tried to use it myself. The upside of the VaultBoot approach is that you don't need to fit an entire Bluetooth stack in your initramfs (including dbus). A downside is that the user needs to own and setup a RPi rather than a mere smartphone.
Additional context