This page permanently redirects to gemini://gemini.techrights.org/2013/04/07/multimedia-drm-like-uefi/.
Posted in Antitrust, GNU/Linux, Microsoft, Security at 2:30 pm by Dr. Roy Schestowitz
As much about security as multimedia DRM
Summary: Antitrust offences with UEFI restricted boot can no longer be defended as an act of enhancing security because keys are leaking
A Fedora developer was the first to embrace Microsoft’s restricted boot, so Fedora was usually ahead of the curve when it comes to it and it shows.
=> Fedora developer | ↺ it shows
Torvalds criticised Red Hat for complicity with Microsoft [1, 2] after he had slammed restricted boot as something that would not improve security. He was right. Keys were inevitably leaked, leaving UEFI restricted boot (which former Novell/SUSE developers too helped promote) in a position where it is only an antitrust issue and nothing to do with computer security, just protectionism. As one new article puts it, the “Linux Lawsuit Shines Uncomfortable Light on UEFI Standard” and a Restricted Boot proponent leads with this news about UEFI signing keys getting leaked:
=> 1 | 2 | something that would not improve security | ↺ UEFI restricted boot | ↺ Novell | too helped promote | an antitrust issue | ↺ new article puts it | ↺ this news about UEFI signing keys getting leaked
A hardware vendor apparently had a copy of an AMI private key on a public FTP site. This is concerning, but it’s not immediately obvious how dangerous this is for a few reasons. The first is that this is apparently the firmware signing key, not any of the Secure Boot keys. That means it can’t be used to sign a UEFI executable or bootloader, so can’t be used to sidestep Secure Boot directly. The second is that it’s AMI’s key, not a board vendor – we don’t (yet) know if this key is used to sign any actual shipping firmware images, or whether it’s effectively a reference key. And, thirdly, the code apparently dates from early 2012 – even if it was an actual signing key, it may have been replaced before any firmware based on this code shipped.But there’s still the worst case scenario that this key is used to sign most (or all) AMI-based vendor firmware. Can this be used to subvert Secure Boot? Plausibly. The attack would involve producing a new, signed firmware image with Secure Boot either disabled or with an additional key installed, and then to reflash that firmware. Firmware images are very board-specific, so unless you’re engaging in a very targeted attack you either need a large repository of firmware for every board you want to attack, or you need to perform in-place modification.
Now we know that UEFI restrictions had nothing to do with security and eventually became just a competition barrier. Rather than cracking we are seeing leaking as the end of UEFI restricted boot’s (or ‘secure’ boot’s) reputation. █
Share in other sites/networks: These icons link to social bookmarking sites where readers can share and discover new web pages.
Permalink Send this to a friend
=> Permalink | ↺ Send this to a friend
=> Techrights
➮ Sharing is caring. Content is available under CC-BY-SA.
text/gemini;lang=en-GBThis content has been proxied by September (ba2dc).