On Thu, Dec 6, 2018 at 9:56 PM Peter Robinson <pbrobinson(a)gmail.com> wrote:
> > 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
Gotcha - thanks. Yes that makes complete sense for the iot, embedded,
kiosk use cases.
--
Chris Murphy