[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Keyfile Support for GRUBs LUKS
From: |
Vladimir 'φ-coder/phcoder' Serbinenko |
Subject: |
Re: Keyfile Support for GRUBs LUKS |
Date: |
Wed, 20 Nov 2013 07:52:01 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131005 Icedove/17.0.9 |
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 <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.
You assume here stream cipher or block cipher in CTR mode. Disks are
encrypted in XTS mode (usually) or some CBC-variant.
signature.asc
Description: OpenPGP digital signature
- Keyfile Support for GRUBs LUKS, Ralf Ramsauer, 2013/11/19
- Re: Keyfile Support for GRUBs LUKS, Glenn Washburn, 2013/11/19
- Re: Keyfile Support for GRUBs LUKS, Elliott Mitchell, 2013/11/19
- Re: Keyfile Support for GRUBs LUKS, Glenn Washburn, 2013/11/20
- Re: Keyfile Support for GRUBs LUKS, Vladimir 'φ-coder/phcoder' Serbinenko, 2013/11/20
- Re: Keyfile Support for GRUBs LUKS, Glenn Washburn, 2013/11/20
- Re: Keyfile Support for GRUBs LUKS, Vladimir 'φ-coder/phcoder' Serbinenko, 2013/11/20
- Re: Keyfile Support for GRUBs LUKS, Glenn Washburn, 2013/11/21
- Re: Keyfile Support for GRUBs LUKS, Darren J Moffat, 2013/11/25
- Re: Keyfile Support for GRUBs LUKS, Elliott Mitchell, 2013/11/20
- Re: Keyfile Support for GRUBs LUKS,
Vladimir 'φ-coder/phcoder' Serbinenko <=
- Re: Keyfile Support for GRUBs LUKS, Glenn Washburn, 2013/11/20
Re: Keyfile Support for GRUBs LUKS, Vladimir 'phcoder' Serbinenko, 2013/11/21