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+g...@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.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
