Re: Keyfile Support for GRUBs LUKS

["Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>]

[-- 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 --]