Hi,
On 06-12-18 19:32, Chris Murphy wrote:
On Thu, Dec 6, 2018 at 3:13 AM Javier Martinez Canillas
<javierm(a)redhat.com> wrote:
<snip>
> This is a two part question I think. First is the measurements
and since the
> BitLocker seals against a PCR state when booting with the Windows bootloader
> this means that we can't chain-load Windows from grub2 since the measurements
> would be different and prevent BitLocker to unlock the encrypted disk.
>
> So for this case Windows has to be booted using the EFI firmware and having a
> separate boot entry. This is my understanding at least, I don't have a Windows
> installation to test.
>
> 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.
This is not the same as an unencrypted volume at all, the disk will only
unlock *when booted from the disk*. So you cannot simply mount the disk in
another machine, or boot from external media and still access the disk.
I'm not saying this is 100% safe, but it certainly is a lot safer then
unencrypted data and makes all kind of simple attacks impossible.
Regards,
Hans