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. > 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+sig...@m5p.com PGP 87145445 | ) / \_CS\ | _____ -O #include <stddisclaimer.h> O- _____ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
