Integrate with Ultrablue for remote attestation over Bluetooth/USB

[kerneis-anssi]

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

• FOSDEM presentation about Ultrablue: https://fosdem.org/2023/schedule/event/image_linux_secureboot_ultrablue/
• Precompiled binaries: https://github.com/ANSSI-FR/ultrablue/releases/

[tlaurion]

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.

[tlaurion]

@kerneis-anssi Sorry I had no idea who you were or what you were working on at FOSDEM.

I finally watched your talk, and the idea of UltraBlue is quite amazing to say the least.

Same reasoning applies on my prior concerns, tough : including Bluetooth support inside of Heads alone, on a footprint cost basis, would be a challenge alone.

Then I see that current codebase is in Go.

I haven't tested linuxboot+u-root for a really long while, but it seems that the integration path would be from their side (cross-compile bluettooth needed toolstack for a board, then pack additional go dependencies under u-root) a much easier integration.

[kerneis-anssi]

@tlaurion All of this makes a lot of sense, thank you for the feedback. We'll try and investigate that path. (Of course, bundling in initramfs as we do now is also an option, we're just trying to find projects that would find the approach useful and see how we can integrate.)

[DemiMarie]

Using Linux’s Bluetooth support is an absolutely terrible idea. See Blueborne for just one of many vulnerabilities in Bluetooth stacks. If Bluetooth support is to be implemented at all, it should be entirely in a sandboxed userspace process. This includes both the Bluetooth stack and communication with the Bluetooth device.

[tlaurion]

@kerneis-anssi you might want to read https://matrix.to/#/!POHYKVCNbDBbWjLeSl:matrix.org/$1o6a0ZtbwaZRYZglgSvjUw-BweLVNU1VQ9Kg_HJd5Xo?via=matrix.org&via=invisiblethingslab.com

[tlaurion]

@tlaurion All of this makes a lot of sense, thank you for the feedback. We'll try and investigate that path. (Of course, bundling in initramfs as we do now is also an option

Sorry for the multiple edits.

@kerneis-anssi A lot of questions are getting to Heads to not use TPM as storage for Disk unlock key. Some users would prefer to use a OpenPGP key to use
https://source.puri.sm/pureos/packages/smartcard-key-luks or similar implementation instead. Some would want TPM for disk unlock key unsealing while still having additional inspection capabilities. Some currently uses @hardenedvault's autoboot script which automatically unlocks LUKS container based on PCR measurements alone to boot servers without auth. In all cases, more details given on PCRs details based in policy base (ie: coreboot vboot, measured boot? Others would give a lot of insights of what thet are they about, could even offer tools to extract firmware content to reproduce measurements from another runtime etc) and have more details on current state of OS when prior firmware state is measured and trusted is an interesting idea. Mixing both, not sure still.

In either scenario/use cases/threat models, I reconsider the idea of having Ultrablue as an option for second factor validation system, for diagnosis, for example, from OS initramfs. Yet again, that would be unrelelated to packaging ultrablue under Heads, but having ultrablue doing its stuff in OS booted initramfs, where Heads would just detach sign initramfs as being trusted per user when it changes. But usage should not be suggested against.

If Ultrablue is not used to unlock the Disk unlock key (already unlocked through other means) but used for diganosis under initramfs, where for example Heads or another system in place is responsible to make sure pre-boot environment is safe to type dusk unlock secret, I think ultrablue can be a really powerful tool. I would love to see Ultrablue packaged and testable for QubesOS.

Question here would be: what about having Bluetooth support under initramfs and only there for the sake of ultrablue? Not sure. But that idea deserves some challenging.

@DemiMarie thoughts on that?
What I understand here is that Ultrablue is talking through Bluetooth with stack added in initramfs, right. But depending of how things are done there (still against adding this and hardware enablement in firmware because past arguments) if the firmware is responsible to validate firmware state + signed initramfs, I say it's a nice experiment with possible interesting outcome, where trust and time window can be and should be limited talking only to trusted devices with already established trust and proper auth and encryption, using Bluetooth as transport for data. And there lies the interest for this project, and the states and details given there.

@DemiMarie think of this for Trenchboot?
Not yet into implementing support ubdrt Heads, but in the longer shot, I think those ideas are complimentary and should not be discarded.

[tlaurion]

A reminder linuxboot/heads-wiki#116

[DemiMarie]

@DemiMarie thoughts on that? What I understand here is that Ultrablue is talking through Bluetooth with stack added in initramfs, right. But depending of how things are done there (still against adding this and hardware enablement in firmware because past arguments) if the firmware is responsible to validate firmware state + signed initramfs, I say it's a nice experiment with possible interesting outcome, where trust and time window can be and should be limited talking only to trusted devices with already established trust and proper auth and encryption, using Bluetooth as transport for data. And there lies the interest for this project, and the states and details given there.

The single most important factor is going to be the Bluetooth stack used. Using the Linux kernel stack, or any other stack written in an unsafe language without formal proof of memory safety, is a terrible idea. On the otherhand, a userspace Bluetooth stack written in safe Rust or SPARK Ada might be okay. However, part of Bluetooth is often implemented in the radio firmware, and that firmware is a proprietary blob written in C. This means that one would need to ensure that the radio is treated as untrusted, which means that the driver must also run in userspace. I also
recommend treating Bluetooth as an insecure transport and using application-layer authenticated encryption. Bluetooth is a very complex protocol and application-layer encryption is much less likely to be bypassible.

@DemiMarie think of this for Trenchboot? Not yet into implementing support ubdrt Heads, but in the longer shot, I think those ideas are complimentary and should not be discarded.

It’s not a bad idea per se, but implementing it securely is going to be incredibly hard. If one uses a userspace stack (perhaps based on Android’s Gabeldorsche) and a userspace driver for the radio device, it could probably be made secure enough.

[kerneis-anssi]

I also recommend treating Bluetooth as an insecure transport and using application-layer authenticated encryption. Bluetooth is a very complex protocol and application-layer encryption is much less likely to be bypassible.

Fully agreed on that front, Ultrablue already does this (AES-GCM encryption, key shared via QR Code from computer to phone).

I don't have enough knowledge of user-space stacks to know what to use unfortunately, but will try and ask some of our Bluetooth experts at work. I'd be happy to try and test any you may have in mind.

[kerneis-anssi]

Also note that Ultrablue's code is structured such that switching to an alternate physical layer should be easy enough but I'm not sure what convenient generally-available protocol would be appropriate. The only one that comes to mind would be USB with a cable from the phone to the computer, and USB stacks are not exactly bulletproof either…

[tlaurion]

Also note that Ultrablue's code is structured such that switching to an alternate physical layer should be easy enough but I'm not sure what convenient generally-available protocol would be appropriate. The only one that comes to mind would be USB with a cable from the phone to the computer, and USB stacks are not exactly bulletproof either…

USB would actually be far more interesting then Bluetooth. On Heads side, with control over the kernel, depending of what would be the USB protocol/kernel module developped/used, we could go to even load and unload the module when needed.

Have you investigated that possibility?
Can you point me to some entry point in code to see where those abstractions could be made?

Heads already uses usb when HOTP is enforced for remote attestation. I dream of a day where my usb security dongle is redundant, and subkeys kept in secure element where something like OpenkeyChain works the other way around and offers HSM properties and opengpg smartcards for other devices, through usb, where the phone is host and the computer the client.

Point here is that nowadays recent computers replaced PS2 with USB, meaning USB controllers need to be initialized and ready, offering usb-hid which is the one we don't like. For others still relying on PS2, usb-hid doest need to be loaded, and nothing from the outside can act like a keyboard. But from there, if we require a single usb module to be loaded only at the time of enrolling/attesting/challenge, I would love to use my phone and replace those usb dongles.

Point is also that way forward under heads is probably to offer tethering through Android as well, on demand, loading needed drivers to be able to download additional/fresher/overlayfs that would be detached signed and trustable on integrity/authenticity and be able to be booted from.

I hear criticisms for all protocols. But USB is still the most reliable we have. And we all have a charging/data cable with us.

Depending of how we go forward, there could also be no cable at all after pairing. The information could maybe even just displayed on screen, encrypted only for the phone to decrypt through a QR code for attestation. And if need be, connect the phone through usb to dig deeper/inspect and make reporting way more user friendly then what can be done through whiptail and console output.

@kerneis-anssi thoughts?

[tlaurion]

@kerneis-anssi any other project integrating Ultrablue?

[kerneis-anssi]

Unfortunately we had to prioritize other projects and didn’t attempt any integration. Feel free to close this issue.