On Thu, Dec 6, 2018 at 9:56 PM Peter Robinson <pbrobinson@xxxxxxxxx> 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 _______________________________________________ desktop mailing list -- desktop@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to desktop-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/desktop@xxxxxxxxxxxxxxxxxxxxxxx
