3 ms·

It's interesting that there's no attempt to solve the actual problem here - telling the difference between the owner of the device (who should be able to do wha

It's interesting that there's no attempt to solve the actual problem here - telling the difference between the owner of the device (who should be able to do what they like to their stuff) and an attacker (who must be prevented from making changes to the device). Both are presumed to have extended physical access to the device, any requisite knowledge, tools, etc. The normal solution to this is to have a password that only the owner knows. I'm assuming that that hasn't been used in this case because the intention here is actually to lock the owner out and only allow the manufacturer access to change the device. Is that the case?

mjg59 5y ago
Where do you put the password? If you're just protecting the firmware setup, then I can just rewrite the secure boot key database without using the firmware setup. If you're using it for disk encryption, I just buy one myself, dump the disk image after it's decrypted, modify it so it'll boot whatever password you type in, intercept your device while it's being shipped or spend some time alone in a room with it, and drop my backdoored image on there. Please don't get me wrong - I would love a solution to this problem that wasn't isomorphic to a solution that can be used to lock out users. But I've spent the last 8 years or so of my life trying to do so and haven't succeeded yet, because the hardware we have available to us simply doesn't seem to give us that option.
- marcus_holmes 5y ago
  Well, you're comparing hashes to ones online, can't you put the password hash online? (sorry, I am very ignorant of the situation here and am asking stupid simple questions) I mean, surely the same problem exists for any data stored on the device (keys, hashes, whatever)? If there's a way of storing a key chain securely on the device so it can't be modified by an attacker, can't a password be stored there instead? > ... the hardware we have available to us simply doesn't seem to give us that option. Is that because the manufacturers don't give the option, or because technically there isn't a way of giving the option?
  - mjg59 5y ago
    > Well, you're comparing hashes to ones online, can't you put the password hash online? (sorry, I am very ignorant of the situation here and am asking stupid simple questions) If the system is compromised then it can just report the expected password hash. You can't trust a compromised machine to tell the truth. > I mean, surely the same problem exists for any data stored on the device (keys, hashes, whatever)? If there's a way of storing a key chain securely on the device so it can't be modified by an attacker, can't a password be stored there instead? Various bits of TPM functionality can be tied to requiring a password, but it's hard to actually turn that into something that's more freedom preserving while still preserving the verifiability. What you want is the ability to re-seal a secret to new values only as long as you have the password available, and I don't /think/ you can construct a system that does that with the features the spec gives you. > Is that because the manufacturers don't give the option, or because technically there isn't a way of giving the option? Unclear. There's little commercial incentive for people to come up with elegant solutions to this, and I can't immediately think of a model that would be significantly better than the status quo.
    - hnlmorg 5y ago
      > If the system is compromised then it can just report the expected password hash. You can't trust a compromised machine to tell the truth. I think the GP's point is that you assume the system can't tell the truth so you do the validation server side rather than client side. Sure, the system could send a different password hash, but as long as you don't publish the correct hashes it's not going to matter if the client sends alternative hashes since that validation happens server side and thus the client wouldn't know what hashes are valid.
    - marcus_holmes 5y ago
      Thanks for the clear answers and info :) It's an interesting subject!
- juhanima 5y ago
  Is it really that easy just to overwrite the secure boot key database? I set up recently secure boot on a Lenovo laptop according to these instructions https://nwildner.com/posts/2020-07-04-secure-your-boot-process/ https://nwildner.com/posts/2020-07-04-secure-your-boot-proce... ...and deploying the keys involves setting UEFI in the Setup mode, which is protected by the firmware setup password. Granted, I didn't verify where the keys are stored and in which format once deployed. But it would be pretty disappointing if they were just copied to another place without any encryption or signing authorized by the password.
  - mjg59 5y ago
    The UEFI variable store is typically just a region of the flash chip that stores the firmware. It's not impossible that some systems perform some sort of integrity validation, but I haven't seen that in the wild.
    - Harvesterify 5y ago
      Isn't Intel Bios Guard supposed to protect against this very attack ?
moring 5y ago
This distinction is only useful if additional conditions are satisfied: The user must not be asked to enter that password repeatedly to do everyday tasks, otherwise it is easy to trick them into entering the password into a malicious input field. More important, the user must not be expected to routinely waive all protection for required tasks. For example, the user is often expected when installing software on a computer to give administrator privileges to an installer script which comes from an untrusted source. The user is expected to "make sure the source is trusted". This does nothing but put the blame on the user, who cannot do that in a meaningful way at all, yet is expected by other factors to install and use the software. The user must not be forced by other factors to enter the password and take measures which are not just unsafe but are actually known to attack the system, exfiltrate data or similar.
- marcus_holmes 5y ago
  I agree totally. But we haven't come up with any better methods of doing this. Some tasks require making changes to the machine that could be evil, so we have to ask the user for permission to make those changes (to stop evil people making those changes with no permission). The more parts of the device we protect, the more we have to ask for permission, and the more routine the granting of that permission is and the less effective the whole permission-granting mechanism is. Coming up with a decent, workable, solution to this would be great. As you say, in an ideal world the onus would not be on the user to verify that the software they're installing is not malicious (with no way of effectively doing that). hmm, sounds like a problem that could be lucrative to solve...
candiodari 5y ago
> I'm assuming that that hasn't been used in this case because the intention here is actually to lock the owner out and only allow the manufacturer access to change the device. Is that the case? No the intention is to lock out functionality. Either programming code that can't be decrypted without secure boot actually booting security, or access to remote networks. That second one is where the controversy comes in because it means if the owner of the device is Netflix (or FB/Youtube/HBO/...) and the network is owned by Netflix you cannot change anything on the device in your house and still watch Netflix. Because of this locking out functionality it is referred to as "rendering your device useless". It can of course still do everything it can do, at the owner's request, just not with Netflix' data.

mjg59 5y ago

Where do you put the password? If you're just protecting the firmware setup, then I can just rewrite the secure boot key database without using the firmware setup. If you're using it for disk encryption, I just buy one myself, dump the disk image after it's decrypted, modify it so it'll boot whatever password you type in, intercept your device while it's being shipped or spend some time alone in a room with it, and drop my backdoored image on there. Please don't get me wrong - I would love a solution to this problem that wasn't isomorphic to a solution that can be used to lock out users. But I've spent the last 8 years or so of my life trying to do so and haven't succeeded yet, because the hardware we have available to us simply doesn't seem to give us that option.

marcus_holmes 5y ago
Well, you're comparing hashes to ones online, can't you put the password hash online? (sorry, I am very ignorant of the situation here and am asking stupid simple questions) I mean, surely the same problem exists for any data stored on the device (keys, hashes, whatever)? If there's a way of storing a key chain securely on the device so it can't be modified by an attacker, can't a password be stored there instead? > ... the hardware we have available to us simply doesn't seem to give us that option. Is that because the manufacturers don't give the option, or because technically there isn't a way of giving the option?
- mjg59 5y ago
  > Well, you're comparing hashes to ones online, can't you put the password hash online? (sorry, I am very ignorant of the situation here and am asking stupid simple questions) If the system is compromised then it can just report the expected password hash. You can't trust a compromised machine to tell the truth. > I mean, surely the same problem exists for any data stored on the device (keys, hashes, whatever)? If there's a way of storing a key chain securely on the device so it can't be modified by an attacker, can't a password be stored there instead? Various bits of TPM functionality can be tied to requiring a password, but it's hard to actually turn that into something that's more freedom preserving while still preserving the verifiability. What you want is the ability to re-seal a secret to new values only as long as you have the password available, and I don't /think/ you can construct a system that does that with the features the spec gives you. > Is that because the manufacturers don't give the option, or because technically there isn't a way of giving the option? Unclear. There's little commercial incentive for people to come up with elegant solutions to this, and I can't immediately think of a model that would be significantly better than the status quo.
  - hnlmorg 5y ago
    > If the system is compromised then it can just report the expected password hash. You can't trust a compromised machine to tell the truth. I think the GP's point is that you assume the system can't tell the truth so you do the validation server side rather than client side. Sure, the system could send a different password hash, but as long as you don't publish the correct hashes it's not going to matter if the client sends alternative hashes since that validation happens server side and thus the client wouldn't know what hashes are valid.
  - marcus_holmes 5y ago
    Thanks for the clear answers and info :) It's an interesting subject!
juhanima 5y ago
Is it really that easy just to overwrite the secure boot key database? I set up recently secure boot on a Lenovo laptop according to these instructions https://nwildner.com/posts/2020-07-04-secure-your-boot-process/ https://nwildner.com/posts/2020-07-04-secure-your-boot-proce... ...and deploying the keys involves setting UEFI in the Setup mode, which is protected by the firmware setup password. Granted, I didn't verify where the keys are stored and in which format once deployed. But it would be pretty disappointing if they were just copied to another place without any encryption or signing authorized by the password.
- mjg59 5y ago
  The UEFI variable store is typically just a region of the flash chip that stores the firmware. It's not impossible that some systems perform some sort of integrity validation, but I haven't seen that in the wild.
  - Harvesterify 5y ago
    Isn't Intel Bios Guard supposed to protect against this very attack ?

moring 5y ago

This distinction is only useful if additional conditions are satisfied: The user must not be asked to enter that password repeatedly to do everyday tasks, otherwise it is easy to trick them into entering the password into a malicious input field. More important, the user must not be expected to routinely waive all protection for required tasks. For example, the user is often expected when installing software on a computer to give administrator privileges to an installer script which comes from an untrusted source. The user is expected to "make sure the source is trusted". This does nothing but put the blame on the user, who cannot do that in a meaningful way at all, yet is expected by other factors to install and use the software. The user must not be forced by other factors to enter the password and take measures which are not just unsafe but are actually known to attack the system, exfiltrate data or similar.

marcus_holmes 5y ago
I agree totally. But we haven't come up with any better methods of doing this. Some tasks require making changes to the machine that could be evil, so we have to ask the user for permission to make those changes (to stop evil people making those changes with no permission). The more parts of the device we protect, the more we have to ask for permission, and the more routine the granting of that permission is and the less effective the whole permission-granting mechanism is. Coming up with a decent, workable, solution to this would be great. As you say, in an ideal world the onus would not be on the user to verify that the software they're installing is not malicious (with no way of effectively doing that). hmm, sounds like a problem that could be lucrative to solve...

candiodari 5y ago

> I'm assuming that that hasn't been used in this case because the intention here is actually to lock the owner out and only allow the manufacturer access to change the device. Is that the case? No the intention is to lock out functionality. Either programming code that can't be decrypted without secure boot actually booting security, or access to remote networks. That second one is where the controversy comes in because it means if the owner of the device is Netflix (or FB/Youtube/HBO/...) and the network is owned by Netflix you cannot change anything on the device in your house and still watch Netflix. Because of this locking out functionality it is referred to as "rendering your device useless". It can of course still do everything it can do, at the owner's request, just not with Netflix' data.