Now the setup with knowledge of strong passphrase can be replaced with ownership of hardware token and weaker PIN knowledge. How about the setup with ownership of hardware token only?
Is it possible in theory? Is public API of the Librem key available? How strong is Librem key to resist brute force PIN attacks?
Like most such devices, I would guess you will get a very limited number of attempts (3?) and then it will lock itself against all further PIN entries until it is unlocked with an admin PIN.
If you want a full security analysis of the Librem Key maybe someone else can jump in.
See also: https://puri.sm/faq/ in the section on the Librem Key under the question How secure are my keys on Librem Key?.
I think that may be anti-recommended. What happens if your hardware token is lost, damaged or stolen? What happens if you need to unlock the encrypted file system in a situation where you donât have your hardware token with you?
Of course the essence of Purism is that you own your device and so you are free to make your own decisions.
I think @NineX is saying: why would anyone object to a PIN that can be 128 alphanumeric characters? Noone could brute force that in the lifetime of the universe (claim not verified ) and that (about 762 bits of entropy) must surely be as strong as your âstrong passphraseâ.
I think you can probably set it up so that the smartcard does not unlock the LUKS drive even if the PIN is used to unlock the smartcard.
PIN is intended to be shorter than passphrase in disk-decrypt use case. If PIN is long, it has no benefit to passphrase in disk-decrypt use case.
Also use case with PIN opens doors to new attack vectors and has different brute force resistance compared to use case with passphrase. That is why I asked how strong is Librem key to resist brute force PIN attacks.
It looks like Librem key can not store arbitrary data (ex. to hold encrypted passphrase), so /boot partition or another USB drive must be used to implement unlock without PIN. The package modifies /boot too. It seems to me the problem is that to be able to do anything useful with Librem key, user must provide PIN, which prevents use cases such as âUnlock LUKS encrypted drive without PINâ. I am not sure about it so I asked if there is Librem key public API available.
I want to unlock LUKS encrypted drive without entering PIN - fully automatic boot.
It does not matter how specifically that would work (security of access token / usb device / Librem key itself is less important topic). Now it looks like the package/library with Librem key can not support this use case.
Well, itâs open source. So it can do anything that you are capable of imagining and implementing.
Iâm struggling to see how this is useful. If decrypting the drive relies on something you know (a passphrase that you enter) or something you have (a Librem Key) then it makes sense to use encryption. If it will decrypt the drive fully automatically then what is the benefit of encryption?
The typical use case for disk encryption is that if the disk (or the containing computer) is lost or stolen then a person who is in possession of the disk cannot access the plaintext content without having the âsomething you knowâ or the âsomething you haveâ.
At least as a thought experiment, let say that you dispense entirely with the Librem Key and change the code on the unencrypted /boot partition to supply the passphrase without asking. That should achieve fully automated boot, while still using an encrypted root partition, but it doesnât exactly achieve what most people want to achieve out of disk encryption.
Well, itâs open source. So it can do anything that you are capable of imagining and implementing.
The default Librem key firmware requires unblocking with PIN, so it is much work to modify it and do not break the current functionality.
If it will decrypt the drive fully automatically then what is the benefit of encryption?
Just like a car with key. Laptop can be encrypted and only used when the key is inserted during the boot. Optionally, laptop will shut down automatically when the key is unplugged. Also it should be possible to just unlock with passphrase without the key (fallback).
At least as a thought experiment, let say that you dispense entirely with the Librem Key and change the code on the unencrypted /boot partition to supply the passphrase without asking. That should achieve fully automated boot, while still using an encrypted root partition, but it doesnât exactly achieve what most people want to achieve out of disk encryption.
Yes, this is straightforward and doable in theory because the Librem key can not store arbitrary data. One change is that the passphrase to unlock the disk must be encrypted (not in polaintext) on /boot partition. So the Librem key should somehow decrypt the passphrase and then unlock the disk with the passphrase.
However such setup requires that the Librem key is resistant to malware trying to decrypt the passphrase when OS is booted - so again PIN is required! Or the Librem key must be disconnected before booting OS. Some other scheme can be possible with combination of TPM + Librem Key + passphrase + hash of passphrase.
I donât think it quite works like that. I think the content of the disk is encrypted using a master key and the master key is encrypted in the LUKS metadata, in one (or more) separate places (key-slots).
In one place the master key could be encrypted using an encryption key that is derived from a passphrase (using PBKDF2 i.e. computationally intensive hash i.e. one-way, or perhaps other choices). So if you donât know the relevant passphrase you canât derive the encryption key for that place (key-slot), so you canât have the kernel get the master key and unlock the disk.
In theory you can have multiple key-slots using different passphrases. That might have applicability if two different people have a need to boot the system, and they donât know each otherâs passphrases - and then if one person leaves the organisation, you can revoke that personâs passphrase (remove the key-slot), while still allowing the other person to boot the system.
In another place (key-slot) the master key may be encrypted via some other mechanism e.g. using OpenPGP (e.g. with a Librem Key).
As long as at least one key-slot is valid and intact, you can potentially unlock the disk.
I donât think any disk encryption technology protects your confidentiality if your computer has malware, worse still if the malware is operating at a kernel level.
Once you have unlocked access to an encrypted file system, the content is available to the malware, potentially the same as the content is available to you, or worse.
Technically there is no practical way for malware to âdecryptâ the passphrase. Malware can of course intercept the passphrase when you enter it. Malware can of course get the master key from kernel memory (if the malware is operating at the kernel level). There is no practical way to reverse engineer the passphrase if it was not intercepted at the time of entry.
This all means that you must ensure that you donât have malware in the /boot partition, which is a related function of the Librem Key and a function that is not available with LUKS in and of itself.
If you supply the PIN to open the Librem Key so that it can be used to unlock the disk then you should be able then to close the Librem Key. So the normal resistance to multiple incorrect PINs would apply. However that wonât help you if the malware is operating at the kernel level (since, for example, it might intercept the PIN).
It is not important how it works internally because cryptsetup utility accepts passphrase. CoreBoot already handles passphrases, possibly with the cryptsetup utility. So no need to handle master key because it could be compromised by bugs.
My point was that in that theoretical setup, a connected USB device is vulnerable to brute force attacks of PIN which could steal a secret and later use it before OS boot. The same with no PIN.
This all means that you must ensure that you donât have malware in the /boot partition, which is a related function of the Librem Key and a function that is not available with LUKS in and of itself.
/boot is verified with PureBoot and PureBoot software is trusted / build from verified source.
Not really. Like, for example, a SIM, after, say, 3 bad PINs, it will lock âpermanentlyâ and there is no way to supply the PIN - right or wrong - to unlock the device. Instead, you have to supply the (typically somewhat longer) admin PIN in order to unlock the device - and then you can try, say, 3 more bad PINs.
It is a fair question as to whether the admin PIN is vulnerable to brute forcing. I donât know.
However it was suggested above that the PIN can be 128 alphanumerics (about 762 bits of entropy) and I think most people would take that as being invulnerable to brute forcing (in 2022) even without additional security measures.
To be honest, after 15 posts I am still none the wiser as to what you really want, what you are trying to protect against, what you are trying to achieve, how it makes sense.
Not that Iâm OP, but what I gather is in the same way one cat set automatic login on an unencrypted installation, OP wants the same thing for a LUKS encrypted installation, but is not picky about how one would achieve that.
The OP is yet to explain under what threat model that (encryption) is useful. If something decrypts fully automatically, there is a risk that it will decrypt fully automatically for the person who is the threat. Conversely, why is fully automatic boot considered desirable? Laziness? Remote location? Another reason?
We should be clear that if a computer using LUKS is booted - no matter whether fully automatically or by the userâs providing a passphrase at boot time or by the Librem Key providing decryption at boot time and then the Librem Key is removed (and the computer is not configured to lock when the Librem Key is removed) - and then left unattended then LUKS is vulnerable to a Cold Boot Attack against the master key. That makes the entire contents of the disk available to the attacker in plaintext even though the attacker does not and will not ever know the passphrase / does not have the Librem Key.
Car/PC owner is responsible for protection of physical device holding start/boot key
Car/PC owner must have a key to start/boot
Car/PC is protected when owner is not in physical distance
Key is just alternative method for strong passphrase to boot PC
However this is not doable with Librem key and the current firmware/software because it requires to type PIN before other operations which defies the purpose.
) and that (about 762 bits of entropy) must surely be as strong as your âstrong passphraseâ.