The Secure Boot Journey¶
Speaker: | Matthew Garrett |
---|---|
Date: | 2013-02-23 |
The Past¶
- UEFI is cross-vendor ($3000/year to contrib)
- 2006: UEFI 2.0 - describes method for signing drivers
- 2008: UEFI 2.2 - describes method for image validation
- 2011: Windows 8 client hardware must default ot enforcing UEFI Secure Boot.
- WTF MSFT?!
- Will this mean that ONLY Windows 8 can run?
UEFI Secure Boot¶
- Hash a binary
- Sign it with private key
- On bot, check hash
- Check sig was made w/ trusted key
- Refuse to boot if checks fail
But why?¶
- If you hijack the bootloader, you get total control.
- Perfectly designed malware could be virtually impossible to detect
- Command & control == Profit
- Therefore: Anti-terrorism (Obviously)
What are our options?¶
- Drink
- No, really. Drink.
- Break RSA, taking down SSL with it.
- Ok, back to drinking.
Cause Trouble¶
- Sept 2011: Matthew blogs about the Win8 requirements (aka WTF MSFT?!)
- PANIC
- It’s easy to cause trouble:
- Just tell people Microsoft is trying to take Linux away from you.
- 2 days later, MSFT responds:
- “Secure Boot is a UEFI standard, not a Windows 8 feature.”
- Translation: Blame the system vendors (yeah, right)
- Bullets are also “standards”
- Aren’t you glad you’re being shot at with a standard?
Now What?¶
- Don’t just run around: Run around and scream.
- Try to convince vendors to ship a Linux key?
- Who would control it?
- Whould get access to it?
- What baout licensing implications of shipping objects signed with it?
- What if there was a Red Hat key?
- What about the PR issues?
- What about Debian, Ubuntu, etc...
- Can we get aaccess to MSFT key? (Heh.)
Other options¶
- Can we avoid pre-instaled keys entirely?
- What about installing a new signing key when you install the OS?
- Give up this Linux thing, take up goat farming.
December 2012¶
- Vendors must provide a mechanism to disable Secure Boot
- Vendors must provide a mechanism for users to install their own keys
Did we win?¶
- No standard way of key mgmt
- No standard way of disabling Secure Boot
- No way of remote deployments
- Complexity & documentation nightmare - how do you get end-users to do this themselves?
Mcirosft Plays Ball
- Commtited to provide open access ot the UEFI signing service
- Sigs are contingent upon not being used to attack Windows (Derp)
- Potential revocatoin of existing sigs (e.g. Red Hat key exploited to attack)
Licenese¶
- “Everyone knows” GPLv3 requires you to release signing keys
- GPLv3 material must be configurable by the end-user.
- (Everyone is wrong)
Two Getouts¶
- If it’s possible to replace it, you don’t need to ship the keys
- If it’s not a User Product, you don’t need to ship the keys
- (Software isn’t a User Product, e.g. a physical object)
User Control¶
- User freedom is essential
- Users need key mgmt
- Machine Operator Key
- variables can be limited ot pre-boot
- keys stored in them can’t nbe modified by the OS
- key install can be limited to physically presetn users
- code written and contributed by Suse
Secure Boot Support
- Ubuntu 12.10 and 12.04.2
- Fedora 18
- A few smaller distros.
Pre-signed Shim¶
- Signed binary w/ no intrinsic trust
- Insall distro key as first step of install process
- NO MST!!
- No risk of revocation
Now what?¶
- Linux can be installed w/out disabling Secure Boot or changing firmware settings
- Users can install and manage their own keys