Re: Keyfile Support for GRUBs LUKS

[Elliott Mitchell]

On Tue, Nov 19, 2013 at 11:43:12PM -0600, Glenn Washburn wrote:
> 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"?

Some of the portions at the start of the kernel are fixed.  If I have
knowledge of the architecture the kernel is for, I'll be able to recover
parts of the cryptographic stream by XORing the known parts.  The rest of
the stream is harder to recover, but I could try changing individual
bytes to all 256 values and observing which values cause the processor to
halt where.  From this I could come up with a map of what the byte in the
kernel is and what the byte of the cryptographic stream is.  The process
would be slow, but it is entirely doable if someone is willing to spend
the resources.

Heck, even the known bytes may allow someone to inject enough code to
break into the kernel at a later stage.  Look for information on "single
byte buffer overflows" for how systems have been successfully broken into
merely by initially controlling 1 byte.

> 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?

I'm unsure of what threats you're worried about, so you may in fact not
need the signatures.  I was mostly noting you were suggesting encrypting
the kernel and initrd images would be enough to protect them.  This is a
major no-no in the general case (yours might not be the general case).

> 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.

I'm unsure what kind of threat you think the "evil maid" is.  If the USB
is trusted, why bother even encrypting it?  For that matter, depending on
your case, you may well have the keys on the USB stick itself, at which
point those could be recovered.

> 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".

If one really wants to be absolutely 100% secure, yes you need firmware
to verify everything.  As such, this may well be outside the threat model
you're concerned with.  In the general case though merely encrypting is
not enough.


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         address@hidden  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445