bzt wrote:
You mean by "replace" that an attacker has access to the boot partition? That's an epic fail, no matter SB or not...
It is, but it is the sort of thing SB is supposed to prevent. Using Windows, getting root is possible by just flashing up a message. I once saw an exploited installer program. Like all installers, it would ask for root permission, and then write files into root-only directories. But it would also use the root permission to do its own evil thing. Since getting the UAC prompt is normal for an installer program, the user was none the wiser. And this thing could modify the boot sector.
linguofreak wrote:
It helps if:
1) The code is signed by the end-user, not some industry third-party.
2) The hardware allows the end-user to chose what signing keys will and won't be accepted.
3) The end-user's private key is not accessible to the attacker, and the vector for the attack is not social engineering of the end-user.
I know too many end-users that don't know what a file is to think that is a good idea. The end-user likely has less expertise in what they are signing then industry third-parties. At least those usually contract programmers, and could, in theory, audit what they are signing. There are two possibilities for what you are proposing to play out:
(1) Either the boot loader can be signed from things inside the machine. Then an attacker can use a trojan horse attack as outlined above, even if the OS tries to make access to the private key hard.
(2) Or the boot loader cannot be signed from things inside the machine. Then it will be "too difficult to use" (I can already picture the whining faces of users required to plug in their private key dongle once more)
In both cases, code signing is yet another patch. It doesn't help if the signed code isn't secure. No matter what you do, if the code can be subverted into doing that which it isn't supposed to do, then all your security measures are for naught. And if big companies like Microsoft, Nintendo, and Sony, throwing massive money bags at the problem, cannot manage to produce secure code, then it is unlikely anyone else can, either.
linguofreak wrote:
EDIT: The question, of course, is then "how often are these conditions fulfilled for a machine using secure boot", and the answer is likely "not often".
That too. However, you can't expect anyone to use cryptography effectively if they don't understand it. I'm an OS programmer, and I don't understand secure boot, so how can I reasonably expect anyone else to understand it? My mom was a network admin most of her life, and she doesn't understand it. And my dad double-clicks all links in the web browser. Last time he understood computers was when he was installing DOS from 5 1/4" floppy disks on his 386.
Putting cryptography in the hands of the unlearned is only wise if they know what to do with it. Not necessarily how it all works in the details, just what it is they are doing. And most people don't know what their computer is doing on boot up, or why it should be necessary to sign anything that is running at the time.