Fedora to use Microsoft-signed bootloader on EFI Secure Boot enabled hardware

[Hungry Man]

Sure. SecureBoot prevents untrusted code from running before the operating system. This is a direct response to rootkits starting before the operating system to avoid detection/ other security methods and it allows them to dig really deep into the OS.

SecureBoot would stop this.

edit:
https://insanitybit.wordpress.com/20...ut-secureboot/

There. That's a more balanced post.

[funkydude]

FYI, Microsoft has nothing to do with it, other than the fact that their certificates are being used. It's VeriSign that's in charge of the whole process and VeriSign that takes the $99.

http://arstechnica.com/information-t...h-secure-boot/

[Hungry Man]

I'm aware that VeriSign is who gets paid. More than that, Microsoft actually subsidizes the price.

Microsoft is actually subsidizing VeriSign keys so that they’re only 99 dollars (SSL certs can be 200-300 dollars and only last 1-3 years) so that’s pretty nice I guess…

Microsoft has plenty to do with it though considering that it's their actions that have forced the hand of distro owners to incorporate this software.

Microsoft is actually subsidizing VeriSign keys so that they’re only 99 dollars (SSL certs can be 200-300 dollars and only last 1-3 years) so that’s pretty nice I guess…

Sometimes I think that Microsoft is too good with hostile people.

[Hungry Man]

lol... yeah, they're saints.

[funkydude]

Originally Posted by Hungry Man

lol... yeah, they're saints.

Lol, I guess they all have their good and bad days.

Originally Posted by Hungry Man

Microsoft has plenty to do with it though considering that it's their actions that have forced the hand of distro owners to incorporate this software.

One could argue that the actions of crackers that lead to these actions of Microsoft that lead to these actions of the distro owners.... and so on, back and forth.

[Hungry Man]

And if they developed it in an open way it could have been truly an amazing feature.

Think about SSL for a second and how insanely broken the whole thing is. Why? Because it was developed behind closed doors and, by admission of the guy at Netscape who basically made the damn system, the whole CA thing was thrown in at the end and they just assumed they'd deal with it later.

Microsoft is creating a system right now int he same exact way - the parallels are obvious as it's about a system of trust handled by Certificate Authorities. If it had been opened up and if it had come about naturally in such a process we would have probably seen really great ideas come up. If this had been done with SSL we'd probably have had Convergence 10 years ago.

Open ways? Isn't the point of SecureBoot and CAs to restrict things?

[Hungry Man]

That's like saying that AppArmor isn't open because it's used to restrict software.

You could open source the secureboot code it wouldn't make it any less effective. What opening it would have done (among other things) is allow the open source community to work on it and discuss proper implementation in such a way that would:
1) probably have ended up being more secure
2) wouldn't have caused such issues

edit: You just linked to something that's pretty much irrelevant.

BTW, SecureBoot was discussed with a big community. See: http://en.wikipedia.org/wiki/Unified_EFI_Forum

AMD, American Megatrends, Apple, Dell, HP, IBM, Insyde Software, Intel, Lenovo, Microsoft, and Phoenix Technologies.

http://www.uefi.org/home/

More software companies can join it: http://www.uefi.org/join/

[Hungry Man]

See above:

edit: You just linked to something that's pretty much irrelevant.

Well no. The link shows that the specification and its features/implementations are open to interested companies that join the UEFI Forum.

[Hungry Man]

This really doesn't have to do with EFI at all.

It shoudl be simple to realize why. The issue here is not EFI or what it's capable of it's how these capabilities were implemented by Microsoft, a company with more than just controlling market share.

No again. This feature is being implemented with extensive collaboration from the UEFI Forum.

See:
http://www.uefi.org/learning_center/
http://www.uefi.org/learning_center/...st_May2012.pdf

[Hungry Man]

I... don't think you're understanding...

It really is irrelevant. I'm just too lazy to write a long post explaining something that should be self evident.

Did you check this? http://www.uefi.org/learning_center/...st_May2012.pdf

It sums up what is Secure Boot.

Also - OEM is Responsible for Initializing Secure Boot.

[Hungry Man]

Again, entirely irrelevant. I'm well aware what secureboot is and that EFI booting trusted code is something related to the hardware, just like a TPM card holds keys, jus tlike a hard drive holds information, just like a CPU processes information and a GPU deals with textures.

The issue here is not with the hardware, which supports secureboot. The issue is that secureboot as implemented by Microsoft could have been opened up.

Just as the hardware supports Microsoft's implementation so would it have supported any other implementation. The hardware does not care if the CA is handled through Microsoft, VeriSign, Notaries, or the User. The hardware and its specifications, open or closed, is almost entirely unrelated to the conversation as pertaining to Microsoft's implementation, which obviously makes use of the hardware.

Well, other partners (OEM and OS) can have their "implementations" (keys?) too.

Who “Owns” The System
Security Keys?

• PK – Key pair is created by Platform Manufacturer

Typically one PK pair used for a model or model Line

• KEK – Key supplied by OS Partner,
Optional: Include 2nd key created by OEM

• db – OS Partner supplies Key,
CA Partner supplies Key,
Optional: OEM App Signing Key

Signature Tests using db Keys Block Rogue S/W!

UEFI Plugfest – May 2012

www.uefi.org

[Hungry Man]

Yes, you just linked to that.

There is nothing special here. Microsoft is simply following OEMs:

"With the Benefits of Secure Boot come new responsibilities for OEMs in management of security database." ~www.uefi.org

[Hungry Man]

Again, you're just not getting this. SecureBoot is a function of the hardware developed by various organizations. The certificate system they are implementing is a function of SecureBoot, which Microsoft chose and in their choice forced on the vast number of computers sold.

Again, had this been implemented in an open way it would:
1) likely be easier and more secure instead of directly mirroring a system that everyone knows is broken
2) be much easier for Linux to have implemented it because they would have been included from the get go

There is nothing that needs to be changed about the hardware or about EFI. It is open, it works, and it would support multiple systems built on it.

What exactly could be opened by Microsoft? From what I understood, Microsoft as an OS partner simply holds its KEK key.

[Hungry Man]

The certificate system they are implementing is a function of SecureBoot, which Microsoft chose and in their choice forced on the vast number of computers sold.

This bit here. The system that they've now implemented on the vast majority of systems that will be sold come Win8 release time.

Originally Posted by Hungry Man

This bit here. The system that they've now implemented on the vast majority of systems that will be sold come Win8 release time.

That was a choice made by the UEFI Forum.

"Call to Action: System OEMs and their partners need to carefully plan the switch to UEFI 2.3.1 Secure Boot"

http://www.uefi.org/