Hacker News Reader

Comment by methodin | Hacker News Reader

What are the actual problems Microsoft is ostensibly trying to fix with a secured bootloader? Something related to viruses/hacks or something else entirely?

View on HN

I also wonder at the utility of this for end user machines. On end user machines, the valuable and secret data is owned by the user, is volatile (not protectable at the OS level with current OS's which have no idea when/how user owned data should be changing), and furthermore is accessed and modified using processes owned by the user. Confused deputy process which are owned by the user seem much more likely to me to do real damage on a home machine.

Which is not to say that this technology is useless, boot-level attacks are important to defend against even if they aren't common now. But one has to wonder whether the costs are worth the benefit, on end user machines?

Botnets often cause little to no perceptible harm to the users of the zombies machines. I've heard of cases where the viruses actually attempted to improve the computers security to keep other viruses out and gain exclusive access to it. But still most agree that fighting botnets is important.

Note that I'm not saying that Secure Boot is significant in the battle against bots, but rather that security is important even if there is not immediate benefits to the users of that particular machine.

I don't think the concern is for the user's data at all. It's to prevent the computer from becoming an uncleanable botnet zombie.

Do you mean publicly acknowledged problems? Viruses, especially boot viruses, BIOS viruses, and rootkits.

Or do you mean mustache-twirling evil conspiracy "plausibly deniable" motives? I'm sure it's easy to ascribe malice to Microsoft's actions here.

Users installing their preferred OS, clearly.

I'm fairly flummoxed as to why this hasn't received antitrust review, frankly.

"Secure Boot is designed to address the potential for malware to insert itself between the firmware and the operating system on your computer. It accomplishes this by enforcing that only “approved” software is able to boot in your computer by way of a key that recognises pre-approved and signed software."

That's from the linked canonical article on the issue: http://blog.canonical.com/2011/10/28/white-paper-secure-boot...

Undetectable root kits. Which is a pretty serious problem, admittedly. It's an open question whether or not secured boot is a good or effective way to go about solving it.

I'm not sure that you can call pre-kernel malware a "serious problem" yet. It exists, but is rare. Stuxnet and Flame seem to have the current crowns for "best malware" and did their deeds without it, after all.

It's also important to point out that the secure code chain is also held up (albeit often incorrectly) as an important criteria for a working DRM implementation. The content providers like that story, and like to hear about efforts to prevent rogue code from running. Certainly this has a lot to do with the Intel/Microsoft rush to secure boot.

It's a serious problem when it happens, but it's not at all widespread. Though there's a good argument to be made that we shouldn't wait for problems to become widespread before fixing them, especially when they are as potentially damaging as rootkits. Imagine if we'd spent the 70s and 80s taking buffer overflow issues very seriously, for example. We'd live in a much different and arguably better world.

The point still stands on whether or not this is actually the best or most effective way to go about tackling the problem. And as you point out the "unintended" of securing the DRM chain and of increasing vendor OS lock-in are not to be ignored and probably just as much a factor behind adoption as the purported security issues.

The notion of "Secure Boot" only loading a verified bootloader protects against Evil Maid [1] attacks and helps you start the chain of trust from the boot sequence, rather than from your bootloader (which you can't trust necessarily). http://www.schneier.com/blog/archives/2009/10/evil_maid_atta...

For instance today if you install Fedora and select encryption for the drives, /boot is still not encrypted (what would decrypt /?). Your data is secure from offline analysis, but anybody can walk up and replace /boot to record your password (not to mention more complicated hacks) the next time you use it.

So verifying the bootloader with EUFI is a great thing that must happen. It could be completely transparent to most users -- their system works the same, it's just more secure. The problem is that Microsoft has engineered it so in practice only their key can be on the system to unlock it. Once this scheme gets established they might even be able to maintain a 'windows tax' just to unlock the hardware even if you don't even use their OS. That's really the only negative about EUFI.

Errr, if they let anyone else generate keys, it would defeat the whole purpose in the real world of many legit and illegit organizations and anti-trust laws that would make it impossible to draw reliable boundaries between the two (e.g. you have to tune the system for false negatives (false determinations that an org is illegit); see the recent SSL certificate mess).

I don't follow that argument. Say the EUFI boot used the last key you booted with... Windows PCs would boot just the same, securely using the Microsoft key.

But when you pressed Esc or F1 or whatever for a boot menu, instead of choosing what partition to boot from you choose which key. ie the list is

1) Microsoft, Inc. Operating System

2) Red Hat, Inc. Operating System

3) ...

So even if somebody hacked Red Hat and stole their key and signed something malicious, the user would still have to select that key on boot in order for it to run. Maybe the boot menu would only list keys that verified an actual installed OS.

In any case, just because you have a bunch of keys in the BIOS doesn't mean you have to automatically boot anything they sign.

Reply on news.ycombinator.com