Re: Keyfile Support for GRUBs LUKS

[Glenn Washburn]

On Tue, 19 Nov 2013 22:42:27 -0800
Elliott Mitchell <address@hidden> wrote:

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

How do you know what block on disk the kernel is on?  Without that you
can't know that you have recovered the actual cipher stream.  Also
what you're suggesting assumes you can actually boot the device, which
assumes you have access to the "trusted" USB stick _and_ you have a way
to already decrypt the LUKS container to get the kernel.  This means
you already have access to the LUKS master key, but we assume that's
what you're trying to get in the first place.  So this doesn't work.

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

I was suggesting that signatures don't buy you much assuming you have a
"trusted" USB _and_ kernel+initrd on the LUKS container.  What's a
scenario where this would matter.  The one above is circular, so
doesn't work.

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

The "evil maid" attack is one where an attacker has physical access
to your computer.  It could include physical access to the USB stick in
this scenario, however the OP clearly stated "the USB stick can be
considered as "trusted environment"".  Thus we would limit are
discussion to physical access to the full disk encrypted computer.

No one as said anything about encrypting the USB.  Where do you see
that being discussed?  Since the USB is "trusted", I take that to mean
that it is not modifiable by an attacker, but in this case it makes
sense to assume that its not readable either.  So I assume only I have
access to my USB stick.

The scenario is a USB stick which boot to Grub.  Grub then reads the
kernel+initrd from the LUKS partition after obtaining key material
(password or keyfile).

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

Firmware doesn't even give you 100%.  Firmware can be flashed and there
is known malware which actually embeds malicious code in firmware that
it flashes.  Even hardware isn't 100%.  How do we know that an entity
with enough power and interest hasn't made some backdoor in the Trusted
Computing environment?  But yes, it takes the game to a whole new level
and much harder to pull off.