Re: Keyfile Support for GRUBs LUKS

[Glenn Washburn]

On Tue, 19 Nov 2013 17:55:40 -0800
Elliott Mitchell <address@hidden> wrote:

> On Tue, Nov 19, 2013 at 07:31:35PM -0600, Glenn Washburn wrote:
> > I've had this setup ever since grub had LUKS support, except for the
> > signature checking.  I don't really see the point of checking
> > signatures if the kernel and initrd are encrypted.
> 
> You're setting yourself up for a *lot* of pain then.  In places where
> security is important, *always* check signatures.  Utilizing
> encryption without checking signatures leaves you *wide-open* to
> attacks!  In a case like this, by observing whether the system
> continues or halts the attacker will be able to figuring out how the
> incoming stream was handled.  While this may not allow them to figure
> out what the keys are, it will allow them to easily break in.
> 
> Not checking signatures has repeatedly killed zillions of security
> products.  If you worry about security, signatures are non-optional!

I'm not exactly following you.  Checking signatures is a way to verify
that certain data is what you expect it to be.  Can you provide an
example of what you mean by "observing whether the system
continues or halts the attacker will be able to figuring out how the
incoming stream was handled"?

I'm not saying that signatures aren't useful for security.  They are an
essential part of trusted computing.  Would you care to elaborate how
in this specific instance signatures would make the system more secure?

Let me be clear, my comment was based on the assumption (as stated by
the OP) that the USB stick was "trusted" and the threat model is of an
"evil maid" attack. Since the USB is trusted it needs no verification.
What other data do we have then?  A LUKS encrypted device.  Assuming
that the attacker does not have a way to unlock the drive, she can only
do cipher text modification or mess with the LUKS header.  Assuming no
bugs in the LUKS header parsing of the grub on the USB, modifying the
header will only potentially cause the unlocking of the device to fail
(nothing signatures would prevent). Modifying the cipher text just
manifests as random data corruption of the plain text device, again not
a security issue and nothing that signatures would prevent.

I assumed by signatures, the OP was referring to signatures for the
kernel and initrd, which residing inside the encrypted volume would
make signatures pointless (for this threat model).

Now verifying signatures of the code on the USB would certainly be
worthwhile if you didn't trust it.  But again, they won't prevent a
determined attacker if the signature verification code is unencrypted
on the USB.  Obviously untrusted code can't verify the trustworthiness
of other code/data.  Thus, I previously stated "I'm not sure it'll buy
you much unless you're using it in combo with hardware/firmware".

Looking forward to your response,
Glenn