Hey everyone, I found a security issue while playing around with my new Librem 5: The encryption key (not passphrase) for your librem 5 is the same as for mine (if the same PureOS version was flashed onto it originally). The reason is:
PureOS is (re-)installed to the librem by flashing a system image onto the internal storage. This system image is encrypted with the passphrase 123456. You can download the system image from purism, and if you download the same version of the image, you’ll end up with the exact same image as I.
I can now change my passphrase to 4321. Which means now my phone has a different passphrase than yours. But with LUKS/dm-crypt the passphrase is only used to encrypt/decrypt an internal key (a number) that does not change at all when I change the passphrase.
In other words, I can decrypt your librem 5 if you give it to me, because my librem 5 has the same internal LUKS key, even if the passphrases differ.
To solve this issue I did the following:
I booted into jumpdrive, backed up all the files from the root filesystem and recreated the dm-crypt. Now my librem 5 has a different key AND a different passphrase. Of course I had to change the UUID of the new dm-crypt to the same UUID as the old one.
I also migrated the root filesystem from ext4 to btrfs, which allows me to mirror my internal storage to my SD card (raid1) in case I break the phone but can recover the SD card. To not have my phone slowed down by the slower SD card, I only sync periodically.
This switch was as easy as changing the UUID of the new btrfs partition to the same id as the old ext4 partition.
Oh, good to know. Especially since I did not know about cryptsetup-reencrypt which can solve this master key issue without recreating the partition. You’d still need to boot into jumpdrive though, because cryptsetup-reencrypt only works when the disk is not mounted. I’ll not try this though, because recreating is easier and I need my btrfs root anyways.
For anyone else reading this
the first link you sent describes the procedure for Librem Laptops, and for those the most secure way is to simply reinstall the whole system and create the partitioning from scratch. It describes the usage of cryptsetup-reencrypt however and that’s very useful.
the second link you sent is just a tutorial for flashing the Librem 5, it does not deal with the issue of the LUKS master key.
In any case, above was just a trial for now. I’ll reflash my librem 5 soon, to get rid of any possible tampering, and then I’ll just recreate the btrfs root partition with the method I described above.
Sorry, it was a quick search. Somewhere in the bowls of ancient forum lore there are even older threads about this on L5, if memory serves. I’m actually surprised that this procedure isn’t in the wiki Tips & Tricks section. Write a good how-to and ad it there…?
Wow. Did you do a search for it? If so, can you tell me the keywords used. I’m still trying to do searches, but most opt out for a search engine to search for forums/puri.sm - I know, crazy, but it gets better hits.
Thank you very much for chiming in with the ink. Bookmarked it.
This is a known issue with using a disk image but my understanding is that it has already been fixed. This should result in a significant delay on first boot while it reencrypts with a new (presumably randomly-generated) disk encryption master key.
What I actually do is … after downloading the disk image and before reflashing the disk image, I can do the reencrypt on the host computer (much faster) - and potentially fine-tune some other LUKS parameters e.g. change default passphrase. (The original goal of this is then that if I have to reflash, those changes have already been done as a one-off.)
Edit: Remove the following paragraph. See further discussion below.
(Of course, now that PureOS has addressed this gap, reencryption on the host computer is likely pointless and likely the reencrypt will get done twice, and only the second one will be effective. In some respects I would prefer PureOS to suppress the reencrypt on first boot if the master key is already different from the factory default.)
Edit: One other comment:
If you only have one Librem 5 phone, this is a good approach. If you have two Librem 5 phones then this is less than ideal but not diabolical. If you had a whole fleet of Librem 5 phones then you absolutely should not simply reencrypt on the host computer as I am doing. (For the case where you have more than one phone, the procedure could be enhanced to reencrypt automatically on the host.)
LOL. That explains why I’ve never actually observed the reencrypt happening at first boot and hence can’t tell anyone what message appears on the screen while it is happening.
I will update my previous post so that it does not confuse or mislead anyone.
This may have changed but my Librem 5 came with a printed copy of the Quickstart Guide as a booklet.
To be clear, the Quickstart Guide that is linked above is suggesting that it is wise to change two separate and unrelated things:
the disk encryption unlock password (passphrase)
your user login (/ screen unlock) password (passphrase / PIN)
(and neither of those is changing a third thing that the OP was concerned about but which is taken care of for you automatically at first boot these days).
I knew where to look because I helped write the content, so my process is a bit biased. In general, however, it is wise to start at https://docs.puri.sm and try navigating the documentation using the sidebar. In this case, searching for “passphrase” would have led you there, but IMHO the raw search functionality is suboptimal; at the time I write this, the correct resource is 6 links down, and searching “passphrase quickstart” yields no results.
Synonyms (passcode, password, passphrase) should normally be handled via meta tags, which are supported in ReStructured Text and Sphinx (what docs.puri.sm is built upon), but I haven’t got it working properly yet and haven’t had spare time to do a deep-dive to fix it. The goal, of course, is for a novice to discover relevant content reasonably easily without speaking precise jargon. Maybe meta tags work in newer versions of Sphinx, maybe I’m invoking them improperly, maybe there’s something wrong in the custom theme, I’m not sure. I’m open to anyone’s suggestions or merge requests.
Is there any documentation on that automatic reencryption on first boot?
It would be nice to be able to verify that by having a location with the image’s master key hash, so that one could compare it with ones own hash.
Is there a message on bootup that says: “regenerating encryption keys”? I failed to notice.
In any case, this does not change my strategy to reinstall from the official image and then recreate the partition (including the encryption) because in that way I can mitigate any possible tampering on the level of the filesystem/encryption, and I’ll have my btrfs root partition.
