Wednesday, January 23, 2013

UEFI SECURE BOOT WIN 8! !!!!!!!?

BUILDWindows/FlickrA new security measure introduced with Windows 8 requiring so-called secure boot keys could make it more difficult for consumers to load other operating systems including Linux on OEM Microsoft-certified machines pre-loaded with the software.Depending on whom you talk to, this is a massive violation of consumer freedom that might (or should) draw anti-trust scrutiny from authorities such as the EU — or it is a desirable defense against malware that just so happens to coincidentally inconvenience a small, if vocal, group of power users.The issue was flagged this week by a blogger and Red Hat Linux developer, Matthew Garrett, who laid out the problem and suggested that the jury was still out on whether this constitutes bad behavior, but urged the software community to at least pay attention."It's probably not worth panicking yet. But it is worth being concerned," he wrote on Tuesday.Microsoft has tried for years to lock down Windows to prevent unauthorized changes to its security keys that would allow untrusted software from working on a machine, for example, through its controversial work with the Trusted Computing Group and Next-Generation Secure Computing Base initiatives. At issue in this week's debate is the Unified Extensible Firmware Interface (UEFI) for secure boot, a protocol that requires users to provide a cryptographic key in order to install and run any software on a machine. This key is held by the manufacturer, which could prevent malicious software from infecting a computer; but it could at the same time prevent consumers who buy locked devices from voluntarily changing the manufacturer-installed OS or choosing to run untrusted software of any kind."Because there's no central certification authority for UEFI signing keys," Garrett said in another post on his blog after the debate gained steam. "Microsoft can require that hardware vendors include their keys. Their competition can't. A system that ships with Microsoft's signing keys and no others will be unable to perform secure boot of any operating system other than Microsoft's. No other vendor has the same position of power over the hardware vendors."Garrett accused the software giant of effectively forcing users to use Windows 8 on pre-installed boxes, which would leave them "no longer in control of their PC." Machines operating with certified Windows 8 would be unable able to run other operating systems, such as Linux, install additional OS's, or replace Windows all together and boot securely, Garrett said on Tuesday.This would be a problem that would only affect those who want to run multiple operating systems on the Windows 8, including previous versions of Windows. For the vast majority of users that simply want to start Windows 8 securely, this change should have little affect.Even still, din on the blogosphere about the changes climbed to such a volume that Microsoft's Windows President Steven Sinofsky responded with a post on the Windows 8 developer's blog on Thursday.The impetus behind the secure boot change, according to Microsoft, is nothing more than security. Without the right certification key, malware will be unable to disable security policies in the firmware."There have been some comments about how Microsoft implemented secure boot," he said, "and unfortunately these seemed to synthesize scenarios that are not the case."Tony Mangefeste of the Microsoft Ecosystem team added later in the post: "Microsoft supports OEMs having the flexibility to decide who manages security certificates and how to allow customers to import and manage those certificates, and manage secure boot. We believe it is important to support this flexibility to the OEMs and to allow our customers to decide how they want to manage their systems."However, Garrett contends this affects both hardware and software makers because unless their products are signed in with the key included in the system firmware, they'll be useless. For example, if you install a new graphics card that has unsigned drivers or drivers with a key not in the firmware, the card won't be supported in Windows 8.Sinofsky somewhat implied this would be the case in the comments section when a reader asked if Windows 8 without secure boot."Of course," he said, but then added, "How secure boot works with any other operating systems is obviously a question for those OS products," complete with emoticon smiley face.Reactions to the controversy among the Linux community were mixed, with some crying foul over what they perceive as a clear an unwarranted intrusion on their freedom to tinker. But others took a more measured stance."Remember Palladium? Then NGSCB and Trusted Computing? Microsoft has been trying to solve this 'problem' for many years," wrote one anonymous poster on Garrett's blog. "Through TPMs and Intel's TXT, it is finally becoming a reality for them. That it makes loading Linux difficult is just a beneficial side effect for them
UEFI secure booting

Sep. 20th, 2011 02:01 pmmjg59Since there are probably going to be some questions about this in the near future:The UEFI secure boot protocol is part of recent UEFI specification releases. It permits one or more signing keys to be installed into a system firmware. Once enabled, secure boot prevents executables or drivers from being loaded unless they're signed by one of these keys. Another set of keys (Pkek) permits communication between an OS and the firmware. An OS with a Pkek matching that installed in the firmware may add additional keys to the whitelist. Alternatively, it may add keys to a blacklist. Binaries signed with a blacklisted key will not load.There is no centralised signing authority for these UEFI keys. If a vendor key is installed on a machine, the only way to get code signed with that key is to get the vendor to perform the signing. A machine may have several keys installed, but if you are unable to get any of them to sign your binary then it won't be installable.This impacts both software and hardware vendors. An OS vendor cannot boot their software on a system unless it's signed with a key that's included in the system firmware. A hardware vendor cannot run their hardware inside the EFI environment unless their drivers are signed with a key that's included in the system firmware. If you install a new graphics card that either has unsigned drivers, or drivers that are signed with a key that's not in your system firmware, you'll get no graphics support in the firmware.Microsoft requires that machines conforming to the Windows 8 logo program and running a client version of Windows 8 ship with secure boot enabled. The two alternatives here are for Windows to be signed with a Microsoft key and for the public part of that key to be included with all systems, or alternatively for each OEM to include their own key and sign the pre-installed versions of Windows. The second approach would make it impossible to run boxed copies of Windows on Windows logo hardware, and also impossible to install new versions of Windows unless your OEM provided a new signed copy. The former seems more likely.A system that ships with only OEM and Microsoft keys will not boot a generic copy of Linux.Now, obviously, we could provide signed versions of Linux. This poses several problems. Firstly, we'd need a non-GPL bootloader. Grub 2 is released under the GPLv3, which explicitly requires that we provide the signing keys. Grub is under GPLv2 which lacks the explicit requirement for keys, but it could be argued that the requirement for the scripts used to control compilation includes that. It's a grey area, and exploiting it would be a pretty good show of bad faith. Secondly, in the near future the design of the kernel will mean that the kernel itself is part of the bootloader. This means that kernels will also have to be signed. Making it impossible for users or developers to build their own kernels is not practical. Finally, if we self-sign, it's still necessary to get our keys included by ever OEM.There's no indication that Microsoft will prevent vendors from providing firmware support for disabling this feature and running unsigned code. However, experience indicates that many firmware vendors and OEMs are interested in providing only the minimum of firmware functionality required for their market. It's almost certainly the case that some systems will ship with the option of disabling this. Equally, it's almost certainly the case that some systems won't.It's probably not worth panicking yet. But it is worth being concerned


There is a lot of misunderstanding of the GPLv3 requirement for signing keys. The requirement that you provide "installation information" (which includes signing keys) applies to object code distributed for a "User Product" that is distributed AS PART OF a transaction in which the right of possession of the "User Product" changes hands.A "User Product" is a tangible person property or goods designed for installation in a dwelling.The gist of what GPLv3 is saying is that if you sell someone some hardware that includes GPLv3 firmware, you have to give them the keys to install new firmware of their choice.Since Red Hat sells their software for use on other people's hardware, rather than selling their software bundled with hardware as part of the sale of that hardware, Red Hat can ship signed GPLv3 code without being obligated to provide the keys.Link Reply Thread Expand




No comments:

Post a Comment