Librem V4, Qubes, Heads and Librem Key


#1

Greetings all!

I have done a bit of research and as best that I can see the Librem Key currently does not work with Qubes. Is that correct? I recently received my Purism 13 inch (v4) and installed Qubes immediately (with LUKS encrypted hard drive).

I have the Librem key, but outside of the GPG Key storage it does not seem to have a huge use for my preferred set up at the moment . Is that correct, or (hopefully) am I wrong and I can upgrade the BIOS to use Heads (away from the default version it ships with) and then maximise the use of the Librem Key with the device’s inbuilt security settings and Qubes OS?

I have researched it, and it seems that this may not work.

Thanks in advance, anyone and everyone :slight_smile:


#2

As an update, I have managed to upgrade the BIOS and it is running Heads, with PureOS. However, I am confused as it seems I can probably simply install a new OS (eg Qubes) and it will not change the BIOS and therefore get the security of the Librem Key to test the BIOS and then Qubes for other / additional security features.

Has anyone tested out this set up at all; or have any input?


#3

As for the steup with the Librem key, Qubes and Heads, I doubht it will work. At least a few weeks ago I was in contact with Mladen about it and at that point, they were still working on an adapted version of Heads to work with the Librem keys.
But I don’t see what would stop you from using HEADS with Qubes.


#4

I’m confused by what you are asking. Changing the OS has no effect on the system firmware

Our Pureboot firmware has worked with the Librem keys since around the beginning of the year, I’m not sure what you or Mladen was referring to. Pureboot + LK + Qubes (or any other distro) works perfectly well


#5

I’m talking about HEADS with LK instead of a smartphone as second factor (which requires an adapted version of HEADS). I had the impression, they were not quite done adapting HEADS to it and I couldn’t find any documentation how it would be set up if it was possible. Maybe I just misinterpreted it and he was only talking about some Pure OS integration (say for updates).

If I get you correctly and it is already possible to set up HEADS with an LK as second factor (for whatever OS), would you please provide a pointer to some documentation (if existent) how this can be done?


#6

and I’m saying we’ve had this available for 6+ months now

https://docs.puri.sm/PureBoot.html

easiest way to install is via the coreboot update/utility script: https://puri.sm/coreboot/


#7

I just received my 15v4 with Librem Key. Successfully configured the Key, flashed Heads, added my GPG pubkey to Heads, installed Qubes4.0.2rc1, and then set up the TPM module (in that order). I can see why you would think the Librem Key doesn’t work, due to the Purism Heads-beta-installation-instructions, under the Requirements section.

I think it’s just saying that you can’t flash the BIOS from within QubesOS like you can from within PureOS. However, you could probably still run the script from a Debian VM, save to USB, and then flash the BIOS from within Coreboot.


#8

I just installed the required utils in my debian template vm and ran the script in a vm using that template. I generated the (backup) rom file for coreboot and the one for coreboot-heads, so I guess I just have to flash this file using the latest version of flashrom (say using a debian live system (which I can authentically get along with the newest flashrom package), so no internet access required and it won’t break the security model) to the BIOS.

The other steps should work on Qubes OS just as well as on Debian (or Pure OS for that purpose).

But of cause this is not an acceptable method, seeing that the script is essentially just downloading an unverified binary file from the internet (in my case from https://source.puri.sm/coreboot/releases/raw/cce6af46b69a9e441772e941041fb1f9ce05c03e/librem_15v4/coreboot-heads-l15v4.rom.gz).
Then, I am supposed to just trust and flash this file.
But as long as there are no integrity checks in the process, there is also no way for me to trust the retrieved rom file. Using it would trade the risk of getting compromised in a physical attack against the risk of downloading and flashing a compromised rom file in this procedure. Not sure whether that’s really a good trade-off.

If however, the developers could cryptographically sign the file and allow people to verify its integrity, this issue could easily be avoided…


#9

you’re downloading a precompiled binary from Purism’s site, and the script validates the hash of the downloaded file. All of this is public/viewable from our site. Adding a cryptographic signature doesn’t add much to that, but is on the to-do list.


#10

Yes, but that still won’t help as long as I can’t trust the script (which is also just unauthentically downloaded from the internet). So, I would still need a cryptographic signature of the script for this to be really useful.


#11

And the part of being public/viewable doesn’t change it either. All it really takes is to compromise the website or control a certificate authority and perform a mitm attack.


#12

Oh wait, sorry it does actually help.

The website source code is hosted via gitlab and the developers use signed commits, so I can verify the source code of the website including the script, which then includes hashes verifying the authenticity of the binary files.

So this way we can actually get the desired root of trust.


#13

Can somebody please verify the authenticity of one of the following keys (which all certify the validity of the (first) key, I need to trust the script and hence the roms):

pub rsa4096 2018-07-05 [SC]
8D60 66CF 922E 5279 6F18 7ABE 2BBB 776A 35B9 78FD
uid [ unknown] Matt DeVillier matt.devillier@puri.sm
sub rsa4096 2018-07-05 [E]

pub rsa3072 2019-02-21 [SC]
A1A9 6A3C 988A 185D 3C20 4AD0 E921 1E0A C4A6 B8DB
uid [ unknown] Scott Booth scott.booth@puri.sm
sub rsa3072 2019-02-21 [E]

pub rsa2048 2019-01-25 [SC] [expires: 2020-01-25]
08E6 5C7D 1B8D 2B4A 6A86 F52E 49D1 2436 F39A 5633
uid [ unknown] Scott Booth scott.booth@puri.sm
sub rsa2048 2019-01-25 [E] [expires: 2020-01-25]

Thanks.


#14

They are authentic.,


#15

kV1x_2xx Thanks for being thorough!