When I received my Librem 13 I followed the initial setup after switching it the first time on.
After setting everything up (including a password for the disk encryption) I started to look around and accustom myself to the new enviroment. After these steps I had the impression I’d have a savely encrypted notebook.
I will try to explain why I had to change my mind about this feeling, how I resolved the issue on my Librem 13 and what could be done to improve the situation - if I didn’t get thinks wrong and all of it is only my misunderstanding.
I bought a Librem 13 because I very much like the philosophy behind the products of Purism, but I generally do not trust anyone.
Remembering that with luks and cryptsetup one can store more then one password I read a bit into luks and cryptsetup and found on my Librem 13 that there are two passwords set for the encryption of my /root device. Searching for an explenation I found the discussion here Hidden luks password automatically enabled in default PureOS? .
After reading through it I became interested in how the same data could be decrypted with several different passwords.
I found this explanation: https://crypto.stackexchange.com/questions/24022/luks-multiple-key-slots-whats-the-intuition . It describes that the data on the disk is encrypted with one masterkey. For each password used on the device this masterkey is encrypted with the passphrase and stored in one of the key slots of the header of the encrypted device.
When decrypting the device the given password is tried agains each of the used key slots and if it can decrypt the masterkey in one of the key slots the device can be decrypted using the masterkey.
Thinking some more about it I realized that the time I had to wait for the gnome-initial-setup after I first switched on my new Librem 13 wouldn’t have been long enough to encrypt the whole volume of ~450GB with a new masterkey and I suspected that the volume had already been encrypted when I received the device and I only set the passphrase to encrypt the same masterkey that had been generated on the notebook at Purism when PureOS had been put on the disk.
I looked at the source of gnome-initial-setup and found the place where the password I entered is used to setup encryption: https://source.puri.sm/pureos/core/gnome-initial-setup/blob/master/debian/patches/04_new-luks-page.patch#L132 . gnome-initial-setup calls the method SetInitialDiskPassword via dbus.
In package pureos-init-disk-crypto I found that the dbus call in the end calls _set_initial_disk_password which then sets the password to encrypt the existing masterkey (https://source.puri.sm/pureos/core/pureos-init-disk-crypto/blob/master/daemon/crypto_setup.py#L142).
From this I assumed that I was right and the masterkey the data I’d put onto my Librem 13 would be encrypted with had already been on the Librem 13 since Purism put the software onto its disk. Since I didn’t need any further information like an initial setup password provided by Purism to start the initial setup the masterkey for encryption and all information to read (and if necessary to decrypt it) had been on the disk during processing and delivery.
If this would be true all people who handled my notebook at Purism, while shipping, at customs and in my company before I put my hands on it could have copied my masterkey for disk encryption without my knowledge.
Wouldn’t be to bad one might think, because the only information on the disk had been the bare operating system PureOS. And in the end I entered my individual password to protect the disk.
But remember: My individual password is only used to finally encrypt that masterkey used to protect my disk - exactly that masterkey that sat unencrypted or together with all information to decrypt it on my disk on its way from Purism to my desk.
So after setting an encryption password on my possibly already compromised disk encryption masterkey I’d have put my data I wished to protect on the disk and the person who had her/his hands on my disk encryption masterkey even before my notebook reached my desk could any time in the future use this information to decrypt my disk or a copy of my disk.
I wrote to the original thread to get a confirmation of this problem or to get information where I assumed something wrong and waited for an answer.
Meanwhile I read a bit more about luks and cryptsetup found found cryptsetup-reencrypt https://manpages.debian.org/testing/cryptsetup-bin/cryptsetup-reencrypt.8.en.html which is able to change the masterkey of the disks encryption while the disk is not being used/mounted.
Since I didn’t have data to loose I used it successfully after booting a rescue system from an usb stick.
Finally I chatted via matrix https://matrix.to/#/!bGtSETqkYFOebMtlfH:talk.puri.sm?via=talk.puri.sm&via=matrix.org&via=librem.one with Jeremiah Foster and Kyle Rankin who confirmed my thoughts.
I asked about the way they put the initial PureOS installation onto the disk of the Librems - whether they do it individually or from an image. As they do claimed to do it individually I assume that each Librems disk has its own unique masterkey.
If the disks would be created from an image (like I did it several times for mass installations of unencrypted systems using PXE and a small script to automate the process) the initial masterkey for disk encryption would be the same on multiple devices.
One way to check this would be to publish the hash of the masterkey of several devices. If these hashes would be the same for different devices each owner of one of those devices with the same masterkey could probably decrypt the disk of any other device without knowing the encryption password the owner of that device set.
If I didn’t get thinks wrong (I’d love an explanation how I came to a wrong conclusion) I suggest
- that information about the risk of using the factory set disk encryption masterkey is explained to the user during initial setup to give the user the oportunity to take further measure (like a new installation or re-encryption of the disk)
- that latest when online reencryption (cryptsetup 2.2.0 as Jonas wrote on the chat) is available in PureOS the process of reencryption with a newly created masterkey is automated as part of the initial setup