still a few glitches in the system... [LWN.net]

still a few glitches in the system...

Posted Nov 20, 2012 15:34 UTC (Tue) by davidescott (guest, #58580)
In reply to: still a few glitches in the system... by mjw
Parent article: Bottomley: Adventures in Microsoft UEFI Signing

The bigger issue in my mind is:
YTF is this process automated? Is Microsoft anticipating such a great need for custom bootloader's that they can't just have someone check a email mailbox? Who is going to want to have their own signed bootloaders and be willing to pay the fee to get one... A half-dozen linux distributors, a few dozen government agencies, X many development teams of major corporations. Everyone else is just going to disable secure boot. Unless X is really large this seems like a relatively minor part-time task for a single developer.

Putting the whole process on some website just opens you up to attacks on that website. An enterprising cracker might find a way to inject code into the signing program website and freely generate as many shims with new keys as he wants and permanently topple the house of cards that is secure boot.

The cynic in me says MSFT recognizes that there is money to be made in selling secure boot keys to malware authors and then revoking them a month later, and they want to automate the process so they can maximize the revenue stream.

still a few glitches in the system...

Posted Nov 20, 2012 16:11 UTC (Tue) by cesarb (subscriber, #6266) [Link] (1 responses)

> The bigger issue in my mind is: YTF is this process automated?

Probably because they do not want anyone to have direct access to the machine with the private signing key. With an automated process, they can enforce that all signatures pass through a well-defined process, with built-in audit trails in case anything goes wrong, and that nothing is signed with that key outside of that process.

Of course, that is the theory. As shown by the number of glitches this time, it seems that the process is not that well-defined in practice.

still a few glitches in the system...

Posted Nov 20, 2012 16:26 UTC (Tue) by davidescott (guest, #58580) [Link]

Matt Garrett already gave the answer. But I wasn't suggesting that the process not be automated internally, but rather that the automation shouldn't be connected to an outward facing website.

still a few glitches in the system...

Posted Nov 20, 2012 22:08 UTC (Tue) by redden0t8 (guest, #72783) [Link] (3 responses)

Forget enterprising crackers... too bad he didn't distribute the Microsoft-signed shim before he was told not too. Once it's out on the internet, you can't ever take it back.

Once keys start getting revoked, I bet an irrevocable shim will look pretty sweet.

still a few glitches in the system...

Posted Nov 20, 2012 22:42 UTC (Tue) by khim (subscriber, #9252) [Link] (2 responses)

Forget enterprising crackers... too bad he didn't distribute the Microsoft-signed shim before he was told not too. Once it's out on the internet, you can't ever take it back.

You can't ever take the [private] key back, but you most certainly can blacklist the shim thus is the end such childish behavior will just lead to troubles.

still a few glitches in the system...

Posted Nov 21, 2012 15:12 UTC (Wed) by redden0t8 (guest, #72783) [Link] (1 responses)

You can't blacklist the shim, only the key it was signed with. If Microsoft accidentally signed it with (one of) their own key(s), blacklisting it would have the side-effect of also disabling everything else signed with the same key.

What else has Microsoft signed with that key? Could they practically push out updates for those components re-signed with a different key, so as to ensure that blacklisting the original key wouldn't break any Windows 8 systems? What would happen to an end-user's system if the blacklist got updated before those components?

I suppose you could see it as "childish", but I see it as not covering for Microsoft's mistakes on their behalf. They made this mess, I don't feel bad for them if they have to deal with it.

still a few glitches in the system...

Posted Nov 21, 2012 15:26 UTC (Wed) by jake (editor, #205) [Link]

> You can't blacklist the shim, only the key it was signed with.

As I understand it, you *can* blacklist the shim. The blacklist can either have keys *or* hashes. Put the hash of the shim in the blacklist and MS can still use their key, but that shim no longer boots.

jake

still a few glitches in the system...

Posted Nov 21, 2012 9:28 UTC (Wed) by jejb (subscriber, #6654) [Link]

> The cynic in me says MSFT recognizes that there is money to be made in selling secure boot keys to malware authors and then revoking them a month later, and they want to automate the process so they can maximize the revenue stream.

Microsoft doesn't get any money from this. The cash we paid was to Verisign (now Symantec) so that they would certify to Microsoft that we were who we said we were and give us a Verisign certified certificate to prove it.

This is the Linux Foundation's actual certificate subject and issuer:

Issuer: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=Terms of use at https://www.verisign.com/rpa (c)10, CN=VeriSign Class 3 Code Signing 2010 CA
Subject: C=US, ST=California, L=San Francisco, O=The Linux Foundation, OU=Digital ID Class 3 - Microsoft Software Validation v2, CN=The Linux Foundation