> The mere fact alone that this could have mitigated the stealthiness and harm of Flame makes it easy for me to include that it can enhance security for individuals.
Did either Flame or Stuxnet (or Duqu or any other worm) override the boot process? I remember reading that Stuxnet used a kernel driver signed by a bona-fide certificate issued to some asian hardware maker, and I assumed Flame did the same (and also used some other MD5 code signing hack, that exploited trust farther away in the chain).
How would have Secure Boot mitigated the stealthiness? You seem to be knowledgeable, so I assume you are right in that Flame did use a boot-level exploit -- but what did it give Flame that a Stuxnet like (bona fide) signed kernel driver couldn't?
I (feel like I) understand the basics of how Secure Boot is supposed to work at least, heh. My knowledge of Flame and it affecting the boot loader came from something I read either in a comment here (and trusted) or read in an article posted here. I can look for it. (I'll be completely honest, a quick Google doesn't seem to support this notion, so take the Flame side of things at your own volition.)
Additionally, my understanding is that the keys in UEFI's Secure Boot storage can also be applied against signed drivers, so assuming the keys are better than the MD5 collided Microsoft certificates, it would also help secure against malicious drivers. (Note, this post is more speculative, I don't know if Windows will use this driver-related feature or if I'm explaining it entirely accurately).
(And not to be repetitive, I apologize, but this would still help prevent evil maid attacks on full disk encryption.)
It's all down to implementation faults; e.g., the wii "trucha" signing bug http://wiibrew.org/wiki/Signing_bug would be good if only they used memcmp rather than strcmp.
There's nothing magic about the bootloader check; They have to get it right, which they might -- but it's much harder than one would expect.
> Additionally, my understanding is that the keys in UEFI's Secure Boot storage can also be applied against signed drivers, so assuming the keys are better than the MD5 collided Microsoft certificates, it would also help secure against malicious drivers.
Not really. You just have to get an exploitable driver signed (possibly through official channels of some sort), and you are good to go. Whoever wrote stuxnet had the means to acquire a driver signing certificate; they probably had the means to get a driver certified even if Microsoft had to sign it.
Without a proper revocation setup, you aren't really better off, and a proper setup is much harder than one would expect, because a well-equipped attacker can DOS/DDOS the revocation list response.
> (And not to be repetitive, I apologize, but this would still help prevent evil maid attacks on full disk encryption.)
It would stop a specific class of evil maid attacks on full disk encryption, yes, and would make other attacks harder but not impossible (ASLR, W^X/NX and many other features were supposed to make buffer overflows unusable for attacks; they made them harder, but apparently not much harder and definitely not impossible).
I don't think it is worth the price in freedom that I suspect will be associated (and yes, I know you disagree. My distrust of PC hardware vendors is based on a lot of continuing frustrating experience, but they might surprise me in the end)
Did either Flame or Stuxnet (or Duqu or any other worm) override the boot process? I remember reading that Stuxnet used a kernel driver signed by a bona-fide certificate issued to some asian hardware maker, and I assumed Flame did the same (and also used some other MD5 code signing hack, that exploited trust farther away in the chain).
How would have Secure Boot mitigated the stealthiness? You seem to be knowledgeable, so I assume you are right in that Flame did use a boot-level exploit -- but what did it give Flame that a Stuxnet like (bona fide) signed kernel driver couldn't?