Re:Microsoft proves backdoor keys are a bad idea
by sp332 on Wednesday August 10, 2016 @01:27PM
(#12263411)
You need admin rights, but not physical access.
Re:Microsoft proves backdoor keys are a bad idea
by bradford on Wednesday August 10, 2016 @02:16PM
(#12263752)
requiring admin rights for an exploit is certainly a lower barrier to entry than is requiring physical access, but I think my point still stands: if someone has those rights, you're already screwed.
Re:Microsoft proves backdoor keys are a bad idea
by stable-point on Wednesday August 10, 2016 @05:31PM
(#12264879)
> if someone has those rights, you're already screwed.
I think that this was once true, but Secure Boot was an attempt to improve the situation. My understanding is that Microsoft's Virtualization Based Security (which Device Guard/Credential Guard are built upon) rely on the assumption that the boot process is secure. If an attacker could have their root kit load before the OS/Hyper-V, then they render those mitigations useless.
Re:Microsoft proves backdoor keys are a bad idea
by bradford on Wednesday August 10, 2016 @01:24PM
(#12263386)
>> Isn't a secure boot policy that can be bypassed with physical access more secure than none?
>Of course it isn't.
Really?
Suppose that you are choosing a new device. You can choose one that let's a remote hacker install a rootkit via a malicious website, or you can choose one that let's a hacker install a rootkit only when they have physical access to your device.
Which one do you choose, and why is it the latter?
Of course it isn't. Impossibility of bypassing is the only reason for secure boot technologies to exist. They are invented so that you are NOT automatically screwed if an attacker has physical access to your device. Secure boot technology is fine in principle, it's just stupid position the manufacturers hold. They ignore recent history. At their own peril, I'd say. https://en.wikipedia.org/wiki/Clipper_chip
And I'm not even sure physical access factor is strictly necessary for adversarial bypassing.
(I'm not a security expert, too.)