I noticed something strange when attempting to change my encryption password on my librem 13, it seems that there are two keyslots which have different passwords enabled. After looking online it seems that this means that there are two separate passwords which will unlock the disk, however I am positive I only set one.
I decided to see if this was due to something that happened to me, if someone had somehow managed to hack me/get physical access or something and enable a separate password, so I downloaded another pureos image and loaded it in a VM. I went through the setup and installation and everything, and once everything was set up I checked the enabled passwords again with cryptsetup luksDump /dev/luksdevice, and found there were again two key slots with passwords enabled. I tried to delete the hidden password, however it was not the same as my password, wasn’t blank, and I was unable to access or delete it.
I’m not sure what could be causing this, it seems like anyone who knew this password could log into the device. If anyone has any ideas or could clear this up I would be very grateful, as it is very concerning.
On installation, PureOS sets up two ways to unlock the disk containing the root filesystem: One password-based and one keyfile based one.
The keyfile is /crypto_keyfile.bin on said disk. All subsequent partitions are unlocked using this keyfile, and all remounts can be done with it as well. The file itself consists of 2048 bytes of random data and is generated on installation time (live setups) or initial setup time (for OEM setups), so nobody except for the owner has access to it, and only if they decrypted the file with their password first.
So, in summary:
Partition mounted as /boot => No encryption (can be verified by TPM)
Partition mounted as / => Encrypted with the user’s password and the randomly generated /crypto_keyfile.bin as secondary key which is on / (hence, to access it you need to decrypt the partition first)
Partition mounted as swap => Reformatted and encrypted with a randomly generated key on every boot
Every other partition that might exist on the system => Decrypted via /crypto_keyfile.bin after the root filesystem has been mounted.
So, the second keyslot you see is very likely the one for the decryption file.
I see that makes sense, thanks for the reply. I do agree it could be useful as a wiki article. With something as sensitive as encryption it seems like it would be helpful have this information easily accessible.
I do have a few more questions about this, some of them I may need to wait and learn more on my own first to grasp a little better.
Considering what this keyfile does, what would happen if I killed it from the key slot? As far as I know, the default PureOS installation has only the boot, /, and swap partitions. Does this mean that the keyfile is only used if I were to manually create more partitions? Lastly, I was wondering if there are any added benefits or risks to this method of having a password+keyfile.
Encryption is an enforcement mechanism for access control. So the question becomes, how hard is it to bypass that access control?
If an attacker temporarily gets root privileges, they can probably find a way to read the actual disk encryption keys out of kernel memory. It’s not trivial even then, but it’s doable. By setting up LUKS to use a keyfile, you’re making it easier to extract the key but they still need root privileges (or the ability to trick root into reading/copying a file for them) to actually do so. It represents a mild downgrade in access control but not a substantive difference.
If you decide to periodically change your encryption password, having a keyfile just means one more thing to remember to change - again, not a substantive difference if you know what you’re doing.
One potential upside: a keyfile could be used to create an emergency recovery thumbdrive in case you forget your password. I doubt PureOS has a script to automate this for you.
Of course, mounting the extra partitions with a keyfile is not actually necessary. You can set up multiple LUKS partitions and mount them all at boot - so long as they have the same password, cryptsetup will only prompt you for that password once and try it on all partitions in crypttab.
Overall, it’s not a big deal either way, but they really should have documented it.
In fact Purism provides and sells the Librem Key which “features a tamper-resistant OpenPGP smart card that can store up to 4096-bit RSA keys and up to 512-bit ECC keys and can even securely generate them directly on the device. Ordinary GPG keys stored on your computer can be copied and used by hackers to decrypt your emails and documents, but once private keys are on the Librem Key, they stay on there and can’t be copied–encryption and decryption happens on the key itself.”
From the article I understand that there is one mastersecret that is encrypted with different passwords/method. Each of the encrypted copies of the same mastersecret exist in one of the eight key slots. The volume can be decrypted if the given password decrypts successfully one of the key slots.
If this is correct I wonder when and how the mastersecret is generated. Did it already exist when I received my Librem and I only changed/setup the password of one keyslot? Or is the mastersecret generated on first boot and the luks encryption setup during initial setup of the Librem?
If the latter is there a part (script, program) of the initial setup routine I could read to understand the process?
This routine seems to check whether the file/device it should change already is a encrypted devices.
If this is true the masterkey (MK) (or as I named it above: mastersecret) which is encrypted with the user given password (and the file containing the secret for further volumes) is created before shipping the devices.
If I do not misunderstand the situation this should be known and clear (big fat warning during setup) to users.
If not already done in other places I didn’t look at the disk could be re-encrypted using cryptsetup-reencrypt. The user could be informed about the risks: Either loosing initial installation of PureOS if re-encryption fails or using an masterkey that could already have been compromised.
As I understand the situation my newly delivered Librem device passed through the hands of many people I do not trust with the encryption key for my disk sitting unproteced on that same disk.
I fear that the encryption key of my disk could have been compromised before my new Librem reached my desk and if correct I criticize that I’ve not been made aware of this possible problem before or during setup.
