![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
mjg59One of the benefits of the Shim approach of bridging trust between the Microsoft key and our own keys is that we can define whatever trust policy we want. Some of the feedback we've received has indicated that people really do want the ability to disable signature validation without having to go through the firmware. The problem is in ensuring that this can't be done either accidentally or via trivial social engineering.
We've come up with one possible solution for this. A tool run at the OS level generates a random password and hashes it. This hash is appended to the desired secure boot state and stored in an EFI variable. On reboot, Shim notices that this variable is set and drops to a menu. The user then selects "Change signature enforcement" and types the same password again. The system is then rebooted and Shim now skips the signature validation.
This approach avoids automated attacks - if malware sets this variable, the user will have no idea which password is required. Any social engineering attack would involve a roughly equivalent number of steps to disabling Secure Boot in the firmware UI, so it's not really any more attractive than just doing that. We're fairly confident that this meets everyone's expectations of security, but also guarantees that people who want to run arbitrary kernels and bootloaders can do so.
We've come up with one possible solution for this. A tool run at the OS level generates a random password and hashes it. This hash is appended to the desired secure boot state and stored in an EFI variable. On reboot, Shim notices that this variable is set and drops to a menu. The user then selects "Change signature enforcement" and types the same password again. The system is then rebooted and Shim now skips the signature validation.
This approach avoids automated attacks - if malware sets this variable, the user will have no idea which password is required. Any social engineering attack would involve a roughly equivalent number of steps to disabling Secure Boot in the firmware UI, so it's not really any more attractive than just doing that. We're fairly confident that this meets everyone's expectations of security, but also guarantees that people who want to run arbitrary kernels and bootloaders can do so.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
How do they know the password
Date: 2012-10-17 10:27 pm (UTC)Re: How do they know the password
Date: 2012-10-17 10:37 pm (UTC)Re: How do they know the password
Date: 2012-10-17 10:37 pm (UTC)Re: How do they know the password
Date: 2012-10-17 10:53 pm (UTC)Re: How do they know the password
Date: 2012-10-18 01:27 am (UTC)Re: How do they know the password
Date: 2012-10-18 01:49 am (UTC)Re: How do they know the password
Date: 2012-10-18 01:54 am (UTC)Could malware convince users to do that? Yes. Could malware convince users to just do the same through their firmware menus? Yes. If the option exists (as Microsoft require it to on x86) there will always be some people who can be convinced to change it without knowing what they're doing. There's no way of keeping those people safe.
Re: How do they know the password
Date: 2012-10-18 12:00 pm (UTC)At the very least, a zero-length password should definitely be prohibited.
Re: How do they know the password
Date: 2012-10-18 04:06 pm (UTC)Re: How do they know the password
Date: 2012-10-18 05:32 pm (UTC)no subject
Date: 2012-10-18 01:52 am (UTC)If you can define any trust policy you want, then so can anyone, including your local (or remote, be it as it may) malware author. Explain how the Shim approach benefits the end user if this is the case?
no subject
Date: 2012-10-18 01:56 am (UTC)no subject
Date: 2012-10-18 08:24 am (UTC)(Or is it simply a laughable idea that a signature on a bootloader certifies anything other than that somebody with halfway plausible credentials gave a lot of money to the signing authority?)
no subject
Date: 2012-10-18 04:05 pm (UTC)Anonymity
Date: 2012-10-20 11:01 am (UTC)"Hi Microsoft! Sell me a Secure Boot certificate but please also make sure you will never be able to find me again."
Impossible? No. Very difficult? Yes, likely to be. Less malware (in numbers) is more security.
no subject
Date: 2012-10-18 03:21 pm (UTC)And why do we need to "trust" Microsoft in order to compete with them. That's like Apple having to "trust" Microsoft just to create the iPhone 6.
no subject
Date: 2012-10-18 06:02 pm (UTC)no subject
Date: 2012-10-18 06:09 pm (UTC)Apple keyboards?
Date: 2012-10-19 03:25 am (UTC)Re: Apple keyboards?
Date: 2012-10-19 03:44 am (UTC)Approach eases social engineering attacks
Date: 2012-10-19 02:58 pm (UTC)I thought firmware UIs are so diverse that it is unreasonable/impossible to guide users to the secure boot options. Luckily, this makes it very hard to attack masses of users with single social engineering attacks.
Now the Shim provides a uniform mechanism that can be exploited by a single social engineering attack? ("There is a problem with the signature validation process of your computer. To fix this problem, please reboot and enter 09sifd5b when asked for a password." CLICK-HERE-TO-REBOOT)
Am I something wrong? For me it looks like you're increasing the attractiveness for these kinds of attacks a lot.
Re: Approach eases social engineering attacks
Date: 2012-10-19 03:49 pm (UTC)Re: Approach eases social engineering attacks
Date: 2012-10-19 03:49 pm (UTC)Re: Approach eases social engineering attacks
Date: 2012-10-20 01:09 pm (UTC)While I'm impressed by Matthew's work, I never understood this (fundamental!) argument of his.
1. There are NOT that many BIOS vendors and there are NOT that many different BIOS interfaces.
2. People need to mess with their BIOS ANYWAY to boot from a CD or USB stick!
PS: I know and like and use GRUB4DOS but it's much less newbie friendly than all the above.
Re: Approach eases social engineering attacks
Date: 2012-10-20 03:48 pm (UTC)It's different for pretty much every laptop vendor, and often within different ranges from the same vendor.
"People need to mess with their BIOS ANYWAY to boot from a CD or USB stick!"
This is typically untrue (there's a separate interface for choosing a one-off boot device), and entirely untrue with UEFI.
Re: Approach eases social engineering attacks
Date: 2012-10-21 09:41 pm (UTC)Not my experience. Maybe I don't see the subtle differences any more. Or I've just been lucky.
"there's a separate interface for choosing a one-off boot device"
Only on not too old PCs but you're right it really makes things easier. It's still not the pinnacle of user friendliness though.
"..., and entirely untrue with UEFI."
Sorry if I missed one of your previous blog but... what are you referring to here? I've installed Linux on a number of (non-secure) EFI laptops already and it was not any different from any pre-EFI laptop. What did I miss?
(In fact, for most of these laptops it was actually hard to notice they were using EFI at all)
Re: Approach eases social engineering attacks
Date: 2012-10-23 02:02 am (UTC)Re: Approach eases social engineering attacks
Date: 2012-10-23 11:29 pm (UTC)Re: Approach eases social engineering attacks
Date: 2012-10-23 11:42 pm (UTC)Re: Approach eases social engineering attacks
Date: 2012-10-24 05:31 pm (UTC)Re: Approach eases social engineering attacks
Date: 2012-10-24 05:36 pm (UTC)Re: Approach eases social engineering attacks
Date: 2012-10-24 06:21 pm (UTC)no subject
Date: 2012-10-28 10:37 pm (UTC)