Keyfile Support for GRUBs LUKS

Keyfile Support for GRUBs LUKS

[Ralf Ramsauer]

Hi,

yesterday I realised, that GRUB is already supporting LUKS and even
simple DSA signature checking.

I was thinking about the following setup:
  - fully encrypted harddisk (LUKS) (incl. rootfs).
  - no bootloader on harddisk
  - kernel + initrd inside encrypted partition
  - optionally: signatures of the kernel + initrd

For "trusted" booting, I thought about an USB stick, that just includes
GRUB, a public key for verification and a keyfile for LUKS.
Using that setup, no password input would be required during boot. The
USB stick can be considered as "trusted environment".

Unfortunately, GRUB doesn't support keyfile for Luks up to now. As I'm
quite familiar with dm-crypt and LUKS I tried to implement the keyfile
feature to GRUB.
After spending several hours trying to get a deeper insight into the
GRUB internas I finally resigned, as I was missing documentation on
several things...

I was very confused about the way how GRUB2 is handling its modules and
about the strategies how functions are exactly called.
The aim is to implement three additional options to cryptodisk.c resp.
luks.c:
 -k keyfile [e.g. (hd2,msdos3)/mysecretkey]
 -o keyfile offset [optional, default: 0]
 -s keyfile size [optional, default: keyfilesize]

Using LUKS, a keyfile can simply be treated like a passphrase, which
basically is already implemented.

I would appreciate, if perhaps someone of you could help me with this issue.

Thanks in advance!
  Ralf

-- 
Ralf Ramsauer

PGP: 0x8F10049B

Re: Keyfile Support for GRUBs LUKS

[Glenn Washburn]

On Wed, 20 Nov 2013 00:43:37 +0100
Ralf Ramsauer <ralf+grub@ramses-pyramidenbau.de> wrote:

> Hi,
> 
> yesterday I realised, that GRUB is already supporting LUKS and even
> simple DSA signature checking.
> 
> I was thinking about the following setup:
>   - fully encrypted harddisk (LUKS) (incl. rootfs).
>   - no bootloader on harddisk
>   - kernel + initrd inside encrypted partition
>   - optionally: signatures of the kernel + initrd

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.

> For "trusted" booting, I thought about an USB stick, that just
> includes GRUB, a public key for verification and a keyfile for LUKS.
> Using that setup, no password input would be required during boot. The
> USB stick can be considered as "trusted environment".

Can you give more details on what you'd use the public key to verify?
The initrd + kernel?  I'm not sure it'll buy you much unless you're
using it in combo with hardware/firmware.

> Unfortunately, GRUB doesn't support keyfile for Luks up to now. As I'm
> quite familiar with dm-crypt and LUKS I tried to implement the keyfile
> feature to GRUB.
> After spending several hours trying to get a deeper insight into the
> GRUB internas I finally resigned, as I was missing documentation on
> several things...
> 
> I was very confused about the way how GRUB2 is handling its modules
> and about the strategies how functions are exactly called.
> The aim is to implement three additional options to cryptodisk.c resp.
> luks.c:
>  -k keyfile [e.g. (hd2,msdos3)/mysecretkey]
>  -o keyfile offset [optional, default: 0]
>  -s keyfile size [optional, default: keyfilesize]
> 
> Using LUKS, a keyfile can simply be treated like a passphrase, which
> basically is already implemented.

To open and read from a file, use grub_file_open and grub_file_read.
Look at the implementation of ./grub-core/commands/cat.c for
inspiration.  Read in the key data into global memory in
grub_cmd_cryptomount from ./grub-core/disk/cryptodisk.c.  Then in
luks_recover_key from grub-core/disk/luks.c use the keydata instead of
asking for the password if keydata exists.

This seems like one way to do it, but I'm not a grub developer, so it
might not be a method they would except patches for.  While you're at
it, it would be nice to have support for detachable luks headers. :)

Glenn

> I would appreciate, if perhaps someone of you could help me with this
> issue.
> 
> Thanks in advance!
>   Ralf
> 

Re: Keyfile Support for GRUBs LUKS

[Elliott Mitchell]

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!


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

Re: Keyfile Support for GRUBs LUKS

[Glenn Washburn]

On Tue, 19 Nov 2013 17:55:40 -0800
Elliott Mitchell <ehem+grub@m5p.com> 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

Re: Keyfile Support for GRUBs LUKS

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 594 bytes --]

On 20.11.2013 06:43, Glenn Washburn wrote:
> 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.
It's a security threat. Imagine you have somewhere a routine which
verifies SSH-key when connecting by network. Replace it with random
data. With some significant probability this decodes to valid opcodes
but which do no check. Now everyone can use your SSH.
encryption provides secrecy. Signatures provide verification. Using one
to achieve the other will always fail.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 291 bytes --]

Re: Keyfile Support for GRUBs LUKS

[Glenn Washburn]

[-- Attachment #1: Type: text/plain, Size: 2122 bytes --]

On Wed, 20 Nov 2013 06:48:40 +0100
Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com> wrote:

> On 20.11.2013 06:43, Glenn Washburn wrote:
> > 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.
> It's a security threat. Imagine you have somewhere a routine which
> verifies SSH-key when connecting by network. Replace it with random
> data. With some significant probability this decodes to valid opcodes
> but which do no check. Now everyone can use your SSH.
> encryption provides secrecy. Signatures provide verification. Using
> one to achieve the other will always fail.
> 

Let me see if I understand you.  Suppose an attacker can modify the LUKS
containers cipher text and happens to know the exact block which
contains the routine for verifying the ssh key.  The attacker then
writes some data to that block, which will then manifest as random
bytes once unencrypted.

You're claiming that there's a more than insignificant probability that
this could cause the verification to not happen?  And thus for anyone
to be able to log into the system via ssh?  I hope you're not
suggesting that because it would be ludicrously improbable (try
executing data from /dev/random and see how far you get). If you'd like
more of an analysis I can provide reasons why, but I think its fairly
obvious. If I've misunderstood you (highly probable), could you explain
in more detail.

In the above scenario, signatures must cover those specific bytes in
order to verify that you're running the correct ssh key verification
code.  Then, to extrapolate, you need to have signatures for all code
and some data on your system.  While I would agree that signatures for
everything is ideal, all other things being equal, I don't think that's
what the OP had in mind.

Also, if this kind of threat were worth considering, why doesn't LUKS
address this?  It would seem fairly easy (add some HMACs in the blocks).
Did they just fail to address some huge security concern?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: Keyfile Support for GRUBs LUKS

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 2205 bytes --]

On 20.11.2013 08:02, Glenn Washburn wrote:
> On Wed, 20 Nov 2013 06:48:40 +0100
> Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com> wrote:
> 
>> On 20.11.2013 06:43, Glenn Washburn wrote:
>>> 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.
>> It's a security threat. Imagine you have somewhere a routine which
>> verifies SSH-key when connecting by network. Replace it with random
>> data. With some significant probability this decodes to valid opcodes
>> but which do no check. Now everyone can use your SSH.
>> encryption provides secrecy. Signatures provide verification. Using
>> one to achieve the other will always fail.
>>
> 
> Let me see if I understand you.  Suppose an attacker can modify the LUKS
> containers cipher text and happens to know the exact block which
> contains the routine for verifying the ssh key.
This is determenistic.
>  The attacker then
> writes some data to that block, which will then manifest as random
> bytes once unencrypted.
> 
> You're claiming that there's a more than insignificant probability that
> this could cause the verification to not happen?  And thus for anyone
> to be able to log into the system via ssh?  I hope you're not
> suggesting that because it would be ludicrously improbable (try
> executing data from /dev/random and see how far you get).
It's not as low as you claim. You change only 16 bytes. And you don't
need the resulting code to be doing anything useful, just not crash.
In CBC modes this attack is even somewhat easier.
Read http://www.cs.berkeley.edu/~daw/teaching/cs261-f12/misc/if.html
> Also, if this kind of threat were worth considering, why doesn't LUKS
> address this?  It would seem fairly easy (add some HMACs in the blocks).
It's not that easy. Trouble is that you need to also prevent
inconsistent rollback and for this you need to have a hash tree. Then
since power failure is a possibility you need this tree to be consistent
at every moment. Those issues are a bit easier to handle on FS level.
ZFS supports HMACs. BtrFS perhaps will one day.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 291 bytes --]

Re: Keyfile Support for GRUBs LUKS

[Glenn Washburn]

[-- Attachment #1: Type: text/plain, Size: 3034 bytes --]

On Wed, 20 Nov 2013 08:36:40 +0100
Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com> wrote:

> On 20.11.2013 08:02, Glenn Washburn wrote:
> > On Wed, 20 Nov 2013 06:48:40 +0100
> > Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com> wrote:
> > 
> >> On 20.11.2013 06:43, Glenn Washburn wrote:
> >>> 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.
> >> It's a security threat. Imagine you have somewhere a routine which
> >> verifies SSH-key when connecting by network. Replace it with random
> >> data. With some significant probability this decodes to valid
> >> opcodes but which do no check. Now everyone can use your SSH.
> >> encryption provides secrecy. Signatures provide verification. Using
> >> one to achieve the other will always fail.
> >>
> > 
> > Let me see if I understand you.  Suppose an attacker can modify the
> > LUKS containers cipher text and happens to know the exact block
> > which contains the routine for verifying the ssh key.
> This is determenistic.

Are you suggesting that given a LUKS partition and no key material, it
is a deterministic process to determine where the kernel is?  Say you
steal my laptop.  Remember you can't actually read the kernel to boot
because you can't decrypt the LUKS device.

> >  The attacker then
> > writes some data to that block, which will then manifest as random
> > bytes once unencrypted.
> > 
> > You're claiming that there's a more than insignificant probability
> > that this could cause the verification to not happen?  And thus for
> > anyone to be able to log into the system via ssh?  I hope you're not
> > suggesting that because it would be ludicrously improbable (try
> > executing data from /dev/random and see how far you get).
> It's not as low as you claim. You change only 16 bytes. And you don't
> need the resulting code to be doing anything useful, just not crash.
> In CBC modes this attack is even somewhat easier.
> Read http://www.cs.berkeley.edu/~daw/teaching/cs261-f12/misc/if.html

Very interesting reference.  However, luckily, we don't have that
situation.  It would be highly improbable that an attacker can do
cipher text modification and then see the results of that (even more
improbable that it would be repeatable).

> > Also, if this kind of threat were worth considering, why doesn't
> > LUKS address this?  It would seem fairly easy (add some HMACs in
> > the blocks).
> It's not that easy. Trouble is that you need to also prevent
> inconsistent rollback and for this you need to have a hash tree. Then
> since power failure is a possibility you need this tree to be
> consistent at every moment. Those issues are a bit easier to handle
> on FS level. ZFS supports HMACs. BtrFS perhaps will one day.
> 

Why do you need rollbacks?  That would seem to imply versioned block
data.

Thanks for the insightful response.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: Keyfile Support for GRUBs LUKS

[Darren J Moffat]

On 11/20/13 07:36, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> It's not that easy. Trouble is that you need to also prevent
> inconsistent rollback and for this you need to have a hash tree. Then
> since power failure is a possibility you need this tree to be consistent
> at every moment. Those issues are a bit easier to handle on FS level.
> ZFS supports HMACs. BtrFS perhaps will one day.

Minor terminology nit: ZFS has a MAC not an HMAC. HMAC implies a hash 
based MAC such as HMAC-SHA256.

ZFS uses AES-CCM or AES-GCM modes which are AEAD modes that produce an 
Auth/MAC tag. You could do an equivalent thing with AES-CBC or AES-XTS 
plus HMAC-SHA256 (the original ZFS crypto prototype was AES-CBC with 
HMAC-SHA256 but I switched to AES-CCM/GCM).

-- 
Darren J Moffat

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 <ehem+grub@m5p.com> 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 (    |         EHeM+sigmsg@m5p.com  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Re: Keyfile Support for GRUBs LUKS

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 2469 bytes --]

On 20.11.2013 07:42, Elliott Mitchell 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 <ehem+grub@m5p.com> 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.
You assume here stream cipher or block cipher in CTR mode. Disks are
encrypted in XTS mode (usually) or some CBC-variant.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 291 bytes --]

Re: Keyfile Support for GRUBs LUKS

[Glenn Washburn]

On Tue, 19 Nov 2013 22:42:27 -0800
Elliott Mitchell <ehem+grub@m5p.com> 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 <ehem+grub@m5p.com> 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.

Re: Keyfile Support for GRUBs LUKS

[Vladimir 'phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 2110 bytes --]

Why do you need offset and size options? keyfile option should be
repeteable. The whole array would be passed down and file would be opened
instead before reading password and concatebated with it unless
--no-password was specified as well. If you have remaining questions feel
free to ask here or on IRC.
On Nov 20, 2013 12:43 AM, "Ralf Ramsauer" <ralf+grub@ramses-pyramidenbau.de>
wrote:

> Hi,
>
> yesterday I realised, that GRUB is already supporting LUKS and even
> simple DSA signature checking.
>
> I was thinking about the following setup:
>   - fully encrypted harddisk (LUKS) (incl. rootfs).
>   - no bootloader on harddisk
>   - kernel + initrd inside encrypted partition
>   - optionally: signatures of the kernel + initrd
>
> For "trusted" booting, I thought about an USB stick, that just includes
> GRUB, a public key for verification and a keyfile for LUKS.
> Using that setup, no password input would be required during boot. The
> USB stick can be considered as "trusted environment".
>
> Unfortunately, GRUB doesn't support keyfile for Luks up to now. As I'm
> quite familiar with dm-crypt and LUKS I tried to implement the keyfile
> feature to GRUB.
> After spending several hours trying to get a deeper insight into the
> GRUB internas I finally resigned, as I was missing documentation on
> several things...
>
> I was very confused about the way how GRUB2 is handling its modules and
> about the strategies how functions are exactly called.
> The aim is to implement three additional options to cryptodisk.c resp.
> luks.c:
>  -k keyfile [e.g. (hd2,msdos3)/mysecretkey]
>  -o keyfile offset [optional, default: 0]
>  -s keyfile size [optional, default: keyfilesize]
>
> Using LUKS, a keyfile can simply be treated like a passphrase, which
> basically is already implemented.
>
> I would appreciate, if perhaps someone of you could help me with this
> issue.
>
> Thanks in advance!
>   Ralf
>
> --
> Ralf Ramsauer
>
> PGP: 0x8F10049B
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>

[-- Attachment #2: Type: text/html, Size: 2666 bytes --]

Re: Keyfile Support for GRUBs LUKS

[Ralf Ramsauer]

[-- Attachment #1: Type: text/plain, Size: 3269 bytes --]

On 11/21/13 16:31, Vladimir 'phcoder' Serbinenko wrote:
>
> Why do you need offset and size options? keyfile option should be
> repeteable. The whole array would be passed down and file would be
> opened instead before reading password and concatebated with it unless
> --no-password was specified as well. If you have remaining questions
> feel free to ask here or on IRC.
>
See man 8 cryptsetup:
 /      --keyfile-offset value//
//              Skip value bytes at the beginning of the key file. 
Works with all commands that accepts key files.//
//
//       --keyfile-size, -l value//
//              Read a maximum of value bytes from the key file. 
Default is to read the whole file up to the compiled-in maximum that can
be queried with --help. Supplying more data than the compiled-in maximum
aborts the operation.//
//
//              This option is useful to cut trailing newlines, for
example. If --keyfile-offset is also given, the size count starts after
the offset.  Works with all commands that accepts key files./


> On Nov 20, 2013 12:43 AM, "Ralf Ramsauer"
> <ralf+grub@ramses-pyramidenbau.de
> <mailto:ralf%2Bgrub@ramses-pyramidenbau.de>> wrote:
>
>     Hi,
>
>     yesterday I realised, that GRUB is already supporting LUKS and even
>     simple DSA signature checking.
>
>     I was thinking about the following setup:
>       - fully encrypted harddisk (LUKS) (incl. rootfs).
>       - no bootloader on harddisk
>       - kernel + initrd inside encrypted partition
>       - optionally: signatures of the kernel + initrd
>
>     For "trusted" booting, I thought about an USB stick, that just
>     includes
>     GRUB, a public key for verification and a keyfile for LUKS.
>     Using that setup, no password input would be required during boot. The
>     USB stick can be considered as "trusted environment".
>
>     Unfortunately, GRUB doesn't support keyfile for Luks up to now. As I'm
>     quite familiar with dm-crypt and LUKS I tried to implement the keyfile
>     feature to GRUB.
>     After spending several hours trying to get a deeper insight into the
>     GRUB internas I finally resigned, as I was missing documentation on
>     several things...
>
>     I was very confused about the way how GRUB2 is handling its
>     modules and
>     about the strategies how functions are exactly called.
>     The aim is to implement three additional options to cryptodisk.c resp.
>     luks.c:
>      -k keyfile [e.g. (hd2,msdos3)/mysecretkey]
>      -o keyfile offset [optional, default: 0]
>      -s keyfile size [optional, default: keyfilesize]
>
>     Using LUKS, a keyfile can simply be treated like a passphrase, which
>     basically is already implemented.
>
>     I would appreciate, if perhaps someone of you could help me with
>     this issue.
>
>     Thanks in advance!
>       Ralf
>
>     --
>     Ralf Ramsauer
>
>     PGP: 0x8F10049B
>
>
>     _______________________________________________
>     Grub-devel mailing list
>     Grub-devel@gnu.org <mailto:Grub-devel@gnu.org>
>     https://lists.gnu.org/mailman/listinfo/grub-devel
>
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel


-- 
Ralf Ramsauer

PGP: 0x8F10049B


[-- Attachment #2: Type: text/html, Size: 5568 bytes --]

Re: Keyfile Support for GRUBs LUKS

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 1415 bytes --]

On 21.11.2013 20:34, Ralf Ramsauer wrote:
> On 11/21/13 16:31, Vladimir 'phcoder' Serbinenko wrote:
>>
>> Why do you need offset and size options? keyfile option should be
>> repeteable. The whole array would be passed down and file would be
>> opened instead before reading password and concatebated with it unless
>> --no-password was specified as well. If you have remaining questions
>> feel free to ask here or on IRC.
>>
> See man 8 cryptsetup:
>  /      --keyfile-offset value//
> //              Skip value bytes at the beginning of the key file. 
> Works with all commands that accepts key files.//
> //
> //       --keyfile-size, -l value//
> //              Read a maximum of value bytes from the key file. 
> Default is to read the whole file up to the compiled-in maximum that can
> be queried with --help. Supplying more data than the compiled-in maximum
> aborts the operation.//
> //
> //              This option is useful to cut trailing newlines, for
> example. If --keyfile-offset is also given, the size count starts after
> the offset.  Works with all commands that accepts key files./
> 
Cutting trailing newlines throuch such options is IMHO inelegant and
would require more scripting than we currently have. Also those options
result in ambiguous syntax if you have multiple keyfiles (like geli). I
think it's better to skip those options, at least for now.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 291 bytes --]