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"? 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 _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
