> The second part is the key management. Clevis currently expects
that the key
> hierarchies are not password protected. This is because asking the user for a
> password would defeat the purpose of automatically unlocking the LUKS volume.
Why bother encrypting anything if it's going to be automatically
unlocked just by booting? If the login window is a sufficient barrier
to exfiltrating and modifying user files on an unlocked volume, then
it's a sufficient barrier for an unencrypted volume because it is in
effect a plaintext volume, automatically without a passphrase, merely
when powered on.
The encryption is tied to the device, if the storage is removed from
the device it fails to be useful. It could also be tied into a network
service like tang [1]. For a end user laptop I agree this doesn't
always make much sense but for something like IoT where the device is
often not directly interacted with by users but have data encrypted at
rest is critical it provides a means of doing it without requiring
user interaction, like most security components there's always trade
offs.
[1]
https://github.com/latchset/tang