Linked by Thom Holwerda on Tue 18th Oct 2011 21:03 UTC, submitted by Dirge
Thread beginning with comment 493410
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[5]: "Secure boot" vs "Restricted boot"
by Lennie on Wed 19th Oct 2011 08:20
in reply to "RE[4]: "Secure boot" vs "Restricted boot""




Member since:
2011-01-28
Lennie,
"That depends on the OEM. If for example the OEM gives you a boot-CD (or some BIOS-option) which can be used to load other keys, in that case you can use it for other OS too."
Everyone should read the UEFI spec, specifically section 27.5. Here is a partial extract.
http://www.uefi.org/specs/agreement/survey_form/process
*** BEGIN ***
27.5.2 Clearing The Platform Key
The platform owner clears the public half of the Platform Key (PKpub) by calling the UEFI Boot Ser-
vice SetVariable() with a variable size of 0 and resetting the platform. If the platform is in
setup mode, then the empty variable does not need to be authenticated. If the platform is in user
mode, then the empty variable (just the monotonic count) must be signed with the current PKpriv.
The name and GUID of the Platform Key variable are specified in chapter 3.2, “Globally Defined
Variables”
*** END ***
The above piece describes a method under the spec to remove the hard coded public manufacturer key, however it requires the the private manufacturer key to do it, so it's useless. Read it carefully, the manufacturer CAN NOT create a secure generic unlock disk using this mechanism. If the manufacturer signs any end user platform keys to enable them to unlock secure boot, then any of those users can then use this signature to install malware keys on any system sharing the same manufacturer platform key.
*** BEGIN2 ***
The platform key may also be cleared using a secure platform-specific method. In this case, the
global variable SetupMode must also be updated to 1.
*** END2 ***
So, the spec leaves the possibility for keys to be reset using unspecified methods. But what are the chances "designed for win8" computers will provide this at all? If it's not supported, bootling alternate operating systems on this hardware could be impossible (say a live cd). If it is supported, the methods to boot alternate operating systems could become platform specific.
It's good to have a security feature to secure the bootloader, it's bad that this feature is under third party control. Third party control is not a necessary function of secure booting. The design of it is actually quite poor and it seems to me that the underlying goal was to secure microsoft windows from end user modification rather than to secure the end user from malware.