![[personal profile]](https://web.archive.org/web/20170703045045im_/http://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
mjg59(Update January 18th 2012 - you probably want to read this for details on why the technical details described below are not the difficult bit of the problem)
An obvious question is why Linux doesn't support UEFI secure booting. Let's ignore the issues of key distribution and the GPL and all of those things, and instead just focus on what would be required. There's two components - the signed binary and the authenticated variables.
The UEFI 2.3.1 spec describes the modification to the binary format required to produce a signed binary. It's not especially difficult - you add an extra entry to the image directory, generate a hash of the entire binary other than the checksum, the certificate directory entry and the signatures themselves, encrypt that hash with your key and embed the encrypted hash in the binary. The problem has been that there was a disagreement between Microsoft and Intel over whether this signature was supposed to include the PKCS header or not, and until earlier this week the only widely available developer firmware (Intel's) was incompatible with the only widely available signed OS (Microsoft's). There's further hilarity in that the specification lists six supported hash algorithms, but the implementations will only accept two. So pretty normal, really. Developing towards a poorly defined target is a pain. Now that there's more clarity we'll probably have a signing tool before too long.
Authenticated variables are the other part of the puzzle. If a variable requires authentication, the operating system's attempt to write it will fail unless the new data is appropriately signed. The key databases (white and blacklists) are examples of authenticated variables. The signing actually takes place in userspace, and the handoff between the kernel and firmware is identical for both this case and the unauthenticated case. The only problem in Linux's support here is that our EFI variable support was written to a pre-1.0 version of the EFI specification which stated that variables had a maximum size of 1024 bytes, and this limitation ended up exposed to userspace. So all we really need to do there is add a new interface to let arbitrary sized variables be written.
Summary: We don't really support secure boot right now, but that's ok because you can't buy any hardware that supports it yet. Adding support is probably about a week's worth of effort at most.
An obvious question is why Linux doesn't support UEFI secure booting. Let's ignore the issues of key distribution and the GPL and all of those things, and instead just focus on what would be required. There's two components - the signed binary and the authenticated variables.
The UEFI 2.3.1 spec describes the modification to the binary format required to produce a signed binary. It's not especially difficult - you add an extra entry to the image directory, generate a hash of the entire binary other than the checksum, the certificate directory entry and the signatures themselves, encrypt that hash with your key and embed the encrypted hash in the binary. The problem has been that there was a disagreement between Microsoft and Intel over whether this signature was supposed to include the PKCS header or not, and until earlier this week the only widely available developer firmware (Intel's) was incompatible with the only widely available signed OS (Microsoft's). There's further hilarity in that the specification lists six supported hash algorithms, but the implementations will only accept two. So pretty normal, really. Developing towards a poorly defined target is a pain. Now that there's more clarity we'll probably have a signing tool before too long.
Authenticated variables are the other part of the puzzle. If a variable requires authentication, the operating system's attempt to write it will fail unless the new data is appropriately signed. The key databases (white and blacklists) are examples of authenticated variables. The signing actually takes place in userspace, and the handoff between the kernel and firmware is identical for both this case and the unauthenticated case. The only problem in Linux's support here is that our EFI variable support was written to a pre-1.0 version of the EFI specification which stated that variables had a maximum size of 1024 bytes, and this limitation ended up exposed to userspace. So all we really need to do there is add a new interface to let arbitrary sized variables be written.
Summary: We don't really support secure boot right now, but that's ok because you can't buy any hardware that supports it yet. Adding support is probably about a week's worth of effort at most.
![[identity profile]](https://web.archive.org/web/20170703045045im_/http://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
Is there any way for the end-user to load their own keys?
Date: 2011-09-24 12:44 am (UTC)Re: Is there any way for the end-user to load their own keys?
Date: 2011-09-24 02:10 am (UTC)Re: Is there any way for the end-user to load their own keys?
Date: 2011-09-24 03:56 am (UTC)Re: Is there any way for the end-user to load their own keys?
Date: 2011-09-24 05:08 am (UTC)Re: Is there any way for the end-user to load their own keys?
Date: 2011-09-24 01:59 pm (UTC)Re: Is there any way for the end-user to load their own keys?
Date: 2011-09-24 08:23 pm (UTC)Re: Is there any way for the end-user to load their own keys?
Date: 2011-09-24 10:45 pm (UTC)Re: Is there any way for the end-user to load their own keys?
Date: 2011-09-25 12:16 am (UTC)And seeing as Microsoft keys are the only ones guaranteed to be present on all systems, third parties will likely prefer this over any program set up by individual or coalition of OEMs.
Re: Is there any way for the end-user to load their own keys?
Date: 2011-09-25 10:25 am (UTC)If you want the issuance of countersigned keys to be viable in practice, there needs to be provision in the spec for the signed key update request to be limited in scope - say to a particular motherboard serial number and/or date range.
why is this needed?
Date: 2011-09-26 02:54 pm (UTC)Re: why is this needed?
Date: 2011-09-26 02:59 pm (UTC)Re: why is this needed?
Date: 2011-10-24 04:24 pm (UTC)Re: why is this needed?
Date: 2012-01-02 04:32 pm (UTC)The whole purpose of secure boot is to stop you from copying DRM'd media. It doesn't work because the pirates won't use secure boot, and then everybody uses those pirate copies even on systems with secure boot, IE it's completely f***ing useless, except that Linux won't always run with it and Microsoft of course likes that.
If we're not careful politicians will make this insidious crap a mandatory requirement.
Re: why is this needed?
Date: 2012-01-02 04:43 pm (UTC)seem a tramp, here lasted on sun 24 sep 2011
Date: 2011-09-24 07:13 am (UTC)http://blogs.msdn.com/b/b8/archive/2011/
umm seems a tramp..
no subject
Date: 2011-09-25 11:52 am (UTC)Look for the mobile coverage outage news in the Net. And for the blackout in Chile.
Thees were hardware Trojans, NOT software viruses.
This is the only beginning. The USA President Barack Obama is the terrorist Number One in the world, but this is not clear to everyone
Masha Lukyanova
Please be serious
Date: 2011-09-26 08:44 am (UTC)@ Matthew: how does Coreboot enter in this picture?
Re: Please be serious
Date: 2011-09-26 11:35 am (UTC)DMCA. Unjail your PC, jail yourself.
Date: 2011-10-20 12:45 am (UTC)They could say it allows overriding DRM or even put a poem in the firmware to force it to be considered a DMCA violation because access to a copyrighted work has been obtained by circumvention.
5 years in prison and being a felon (look at the Perl guy who was banned from Canada for life) is enough to scare almost everyone off of Linux. Not to mention the reality of how physically brutalized the average geek would be in prison - 5 hours would be enough to destroy him.
In all honesty
Date: 2011-09-26 02:15 am (UTC)With security, we've been running reactively for a very long time and I do not really see the issue. In fact, reactive is how humans are. When we get sick, we respond appropriately. Look up projects like ABACUS, where computers could potentially heal themselves on detection of 'misuse'. We also run retroactively. We have the best of both worlds. Preventing boot-ups because the system detected 'misuse'? That would NEVER fly with me and NEVER would fly with anyone else. What is Microsoft trying to do here? INCREASE downtime? Microsoft has costed the world over 100 billion USD in security problems. When are they going to give that back?
And also, let's just imagine that we had keys and all nice things worked out (as some people seem to state here). So now I have to find some 'authority' who can give me the keys to do WHAT I WANT to with MY (potentially custom built) machine? That is absolute nonsense! Any of you are suggesting that there be 'Linux keys', or 'Ubuntu keys' (yuck) means that you do not see an underlying problem. Sure, today for some odd reason we trust CA's like VeriSign to secure our websites (honestly I still find this a strange deal). Why? Why should we trust anyone other than ourselves in this regard? Who made them king?
In a hacker sense: if a motherboard has this functionality, hack it to death and REMOVE IT ENTIRELY. Do not even have a bit of this. It's absolute nonsense!
In another sense: I should NEVER have to do anything like just mentioned just to do get the OS I want running, nor should I have to do any key fiddling.
The fight will go on. In fact, I hope UEFI+secure boot turn out to be a disaster and the security problems for Windows users go UP instead of down. Go on malware writers! Keep doing what you do until Microsoft is bankrupt!
Things the way they are just fine if you ask me, if you NEVER use Windows. Linux (almost any distro) and Mac OS X are 2 fine operating systems that don't need this crap.
Re: In all honesty
Date: 2011-09-26 06:22 pm (UTC)Re: In all honesty
Date: 2011-09-27 05:58 am (UTC)Interesting.
Re: In all honesty
Date: 2011-09-28 05:50 pm (UTC)Re: In all honesty
Date: 2011-10-02 02:05 pm (UTC)They load the clip in omnicolour
Said they pack the 9, they fire it at prime time
Sleeping gas, every home was like Alcatraz
And motherfuckers lost their minds
No escape from the mass mind rape
Play it again jack and then rewind the tape
And then play it again and again and again
Until your mind is locked in
Believin' all the lies that they're tellin' you
Buyin' all the products that they're sellin' you
They say jump and you say how high
You're brain-dead
You've gotta fuckin' bullet in your head
Just victims of the in-house drive-by
They say jump, you say how high
Just victims of the in-house drive-by
They say jump, you say how high
Uggh! Yeah! Yea!
(You're) Standin' in line
Believin' the lies
(You're) bowin' down to the flag
You got a bullet in your head
Lyrics here: http://www.sing365.com/music/lyric.nsf/
Video clip (Warn' FLASH): http://www.youtube.com/watch?v=
Rather Upside Down Reasoning
Date: 2011-10-24 04:40 pm (UTC)This doesn't stop tampering from going on. It just stops your machine from running after it's been tampered with. In theory, this gives you the opportunity to reverse the tampering. In practice, we'll see.
I don't generally trust firmware/hardware based encryption. Without the ability for the user to modify the key database himself it takes away more control of the machine, and in no way is it guaranteed to be unhackable (though it may afterward be unfixable). Give the user the ability to control the key database, and then I might trust it a bit more.
Re: In all honesty
Date: 2012-01-02 04:42 pm (UTC)So as an analogy, secureboot hands your keys over to a bunch of strangers and you then have to trust them with your house.... stupid idea - I trust me, not some bunch of corporations whose main aim is to make money, my security is way down their list of priorities.
And what makes you think trojans won't run quite happily within the secureboot environment - they're trojans, they'll simply masquerade as something else. Secureboot != anti-virus.
Re: In all honesty
Date: 2012-01-02 04:44 pm (UTC)Re: In all honesty
Date: 2012-02-27 11:08 pm (UTC)no subject
Date: 2011-09-27 08:03 pm (UTC)Moving to Windows 8 is a hard choice for most users - new investment, brand new pc and not able to upgrade to Windows 9 or a better OS - is a curse.
What I expect is - this feature will have an option to disable it, if it does not, then we will see it in court.
So, in short, its pretty much useless and back to the 80s BIOS stuff. I also suspect this will be enabled by default by major manufacturers and ignored by 99% of computer users, until Win 9 comes out/switching OS/PC needs rescue they realized they need the D F Manuals.
Windows OEM manufacturer will get blamed and users at a losing side, OEM manuf is playing with fire.
Lets watch in 2 years time
http://www.google.com.my/search?hl=en&q;=disabling+EUFI
Current: 444,000 results
Early problem winner goes to-
http://forums.lenovo.com/t5/W-Series-
no subject
Date: 2011-09-27 08:19 pm (UTC)no subject
Date: 2011-09-28 05:57 pm (UTC)So far everyone is discussing a problem, but I think what most people would love to hear is potential solutions to this.
What would you point as a potential solution for this mess ?
All the best,
NM
Screw Microscum
Date: 2011-09-29 07:26 am (UTC)6 Years on Linux and 0 malware infections and I go where I want on the net and no Winblows users can say that so epicfail to Microscum and their crappy business model/products.
LOL Linux doesn't even have antivirus because their are NONE - Yet MS claims they are secure LOL I feel sorry for the sheeple!
Re: Screw Microscum
Date: 2011-10-08 04:33 pm (UTC)death to MS find new enemy
Date: 2011-09-29 01:05 pm (UTC)Matthew described a solution in a previous post
Date: 2011-10-02 11:41 am (UTC)Spread the word...
Date: 2011-10-14 04:53 pm (UTC)http://software.intel.com/en-us/forums/
This is really about losing the ability to modify both the hardware and the software -- in other words, you cannot use your own PC in a way you want. People who say "there will be Linux/Ubuntu keys" forget that they most likely won't be able to compile their own bootloader and/or kernel and sign them.
Instead of punishing those who abuse PCs for cyber crime they want to make sure that it is impossible to commit it. If they used the same principles in real life, firing a weapon would require a signed key for every bullet.
What happens if one of the supported keys gets leaked/discovered?
Date: 2011-10-20 02:18 pm (UTC)I guess the problem revolves around the signing key which is unlikely to make its way into the public. What if it does? Also, what happens when the certificates expire? Surely I'm either insane for asking these questions or they have already been addressed (or both)..
Re: What happens if one of the supported keys gets leaked/discovered?
Date: 2011-10-20 02:32 pm (UTC)UEFI and Linux
Date: 2011-10-27 08:18 am (UTC)solution ?
Date: 2011-12-30 12:36 am (UTC)So, if you want to install Windows 8, it will install the extension, but it can also be uninstalled ?