5 ms·

I thought this was initially FUD, but this in particular sounds bad. TPMs really do enhance security since it massively increases the security for even weak pas

by slaymaker1907 5y ago

I thought this was initially FUD, but this in particular sounds bad. TPMs really do enhance security since it massively increases the security for even weak passwords (which 90-95% of them are). However, any security feature should be zero cost such that if you don't use it/want it, it doesn't restrict what you can do. Secure Boot at least can be disabled most of the time and that is one of the most locked down features. Random tangent: I really wish we had a better way to customize code signing and verification. For very sensitive environments, you should be able to only trust certain certs/roots for particular binaries. I'd like to enforce that for some particular python script, it has been signed by one of *my* CI servers. Obviously this is possible, but I think you would need to roll your own code.

salawat 5y ago
Secure boot can only be disabled on x86/_64 systems. It is decreed that ARM systems not be user deactivatable.
- oneplane 5y ago
  Let's make that a bit more specific: Microsoft wants OEMs that manufacture Windows on ARM devices to not allow a user to disable secure boot and not allow a user to add CAs or trust individual certificates. In essence, they want secure boot to not be subvertible. This is both good and bad: for the generic end-user, not being able to 'accidentally' disable root-of-trust via secure boot and not being able to have 'tech savvy nephews' try to 'help' them (and not overseeing the long term consequences) is a net win. It's going to be pretty hard to rootkit a system that has a secured root-of-trust. On the other hand, the device is now worthless the second the OEM, ODM or Microsoft decides they don't want to support it. They also completely control all features, so even if it would be hardware-capable of doing something you simply aren't going to be able to do it. There is a third aspect and that is that it is very hard to inspect the device as a researcher. Knowing that closed chassis debugging is a point of vulnerability, it would be great if it was still possible to boot a research OS and check the device. At this point, you can only do that with reverse-engineered drivers and a shim loader and hoping the CA in the firmware is up-to-date enough to contain a trust relation for the intermediate CA used to sign the shim certificate...
  - R0b0t1 5y ago
    > On the other hand, the device is now worthless the second the OEM, ODM or Microsoft decides they don't want to support it. Heh, no, it's useless from the factory assuming you don't want to run windows.
- my123 5y ago
  This only applies to the (dead) Windows RT and Windows Phone/10 Mobile platforms. Windows on Arm64 devices are regular Windows desktop devices, just running on a different CPU architecture. As such, they share the same security policies. You can disable UEFI Secure Boot just fine on a Surface Pro X, and use custom keys there too. This also applies for devices from other OEMs.
  - Nursie 5y ago
    This is useful info - I didn't know that they'd eased up now, and assumed they were still playing the locked-down game with at least their own arm devices. So ... theoretically I could put a linux distro or android build on a Surface Pro X?
    - djur 5y ago
      Linux can boot on it, but it's lacking hardware support: https://github.com/Sonicadvance1/linux/issues/27 https://github.com/Sonicadvance1/linux/issues/27
      - Nursie 5y ago
        Cool. I'm not exactly interested in getting one, there are enough devices in my life at the moment, but it's definitely an improvement that microsoft are allowing this on their own devices, let alone mandating the entire eco-system follow them, as they previously attempted.
- kaladin-jasnah 5y ago
  > It is decreed that ARM systems not be user deactivatable. There are certain consumer Android ARM tablets/phones that for whatever reason, do not have secure boot enabled (which are not devkits from Aliexpress). So not all of them. But they are indeed quite rare, and is one of the reasons why you can't just replace the Android bootloader with something else (you need the appropriate signing keys to do so). On Qualcomm devices, secure boot, once enabled, blows an irreversible hardware fuse. You then need the appropriate signing keys and software to sign images and you can, I believe, continue to blow fuses to overwrite old signing keys should you want to invalidate them. Thanks to the fuses, you can never deactivate secure boot (without, like, replacing the SoC with a miraculous solder job, or whatever). It's really irreversible.
  - octoberfranklin 5y ago
    > continue to blow fuses to overwrite old signing keys That is definitely wrong. By their very nature efuses can be programmed only once. You can never overwrite the old values with arbitrary new values. In theory you can flip more zeroes to ones, since the fusing operation is only performed on the ones (or only on the zeroes -- the polarity choice is arbitrary but it is made at manufacturing time). But this is not really helpful; you can't feasibly generate your own signing key under the constraint that certain bits must be one... the cost of doing this grows exponentially with the number of constrained bits. In practice I have never ever seen an efuse array that didn't also have a "permanent write-protect" fuse. If that fuse exists, the programming software will certainly activate it after verifying that the key was programmed correctly.
    - kaladin-jasnah 5y ago
      > By their very nature efuses can be programmed only once. You can never overwrite the old values with arbitrary new values. My understanding is this: you cannot overwrite the old values, but you can blow an additional fuse. If you have five fuses, then you blow the first fuse for the first key, then the second fuse for the second key. When you blow the second fuse, the system will only look at the second fuse, then the third, etc.

salawat 5y ago

Secure boot can only be disabled on x86/_64 systems. It is decreed that ARM systems not be user deactivatable.

oneplane 5y ago
Let's make that a bit more specific: Microsoft wants OEMs that manufacture Windows on ARM devices to not allow a user to disable secure boot and not allow a user to add CAs or trust individual certificates. In essence, they want secure boot to not be subvertible. This is both good and bad: for the generic end-user, not being able to 'accidentally' disable root-of-trust via secure boot and not being able to have 'tech savvy nephews' try to 'help' them (and not overseeing the long term consequences) is a net win. It's going to be pretty hard to rootkit a system that has a secured root-of-trust. On the other hand, the device is now worthless the second the OEM, ODM or Microsoft decides they don't want to support it. They also completely control all features, so even if it would be hardware-capable of doing something you simply aren't going to be able to do it. There is a third aspect and that is that it is very hard to inspect the device as a researcher. Knowing that closed chassis debugging is a point of vulnerability, it would be great if it was still possible to boot a research OS and check the device. At this point, you can only do that with reverse-engineered drivers and a shim loader and hoping the CA in the firmware is up-to-date enough to contain a trust relation for the intermediate CA used to sign the shim certificate...
- R0b0t1 5y ago
  > On the other hand, the device is now worthless the second the OEM, ODM or Microsoft decides they don't want to support it. Heh, no, it's useless from the factory assuming you don't want to run windows.
my123 5y ago
This only applies to the (dead) Windows RT and Windows Phone/10 Mobile platforms. Windows on Arm64 devices are regular Windows desktop devices, just running on a different CPU architecture. As such, they share the same security policies. You can disable UEFI Secure Boot just fine on a Surface Pro X, and use custom keys there too. This also applies for devices from other OEMs.
- Nursie 5y ago
  This is useful info - I didn't know that they'd eased up now, and assumed they were still playing the locked-down game with at least their own arm devices. So ... theoretically I could put a linux distro or android build on a Surface Pro X?
  - djur 5y ago
    Linux can boot on it, but it's lacking hardware support: https://github.com/Sonicadvance1/linux/issues/27 https://github.com/Sonicadvance1/linux/issues/27
    - Nursie 5y ago
      Cool. I'm not exactly interested in getting one, there are enough devices in my life at the moment, but it's definitely an improvement that microsoft are allowing this on their own devices, let alone mandating the entire eco-system follow them, as they previously attempted.
kaladin-jasnah 5y ago
> It is decreed that ARM systems not be user deactivatable. There are certain consumer Android ARM tablets/phones that for whatever reason, do not have secure boot enabled (which are not devkits from Aliexpress). So not all of them. But they are indeed quite rare, and is one of the reasons why you can't just replace the Android bootloader with something else (you need the appropriate signing keys to do so). On Qualcomm devices, secure boot, once enabled, blows an irreversible hardware fuse. You then need the appropriate signing keys and software to sign images and you can, I believe, continue to blow fuses to overwrite old signing keys should you want to invalidate them. Thanks to the fuses, you can never deactivate secure boot (without, like, replacing the SoC with a miraculous solder job, or whatever). It's really irreversible.
- octoberfranklin 5y ago
  > continue to blow fuses to overwrite old signing keys That is definitely wrong. By their very nature efuses can be programmed only once. You can never overwrite the old values with arbitrary new values. In theory you can flip more zeroes to ones, since the fusing operation is only performed on the ones (or only on the zeroes -- the polarity choice is arbitrary but it is made at manufacturing time). But this is not really helpful; you can't feasibly generate your own signing key under the constraint that certain bits must be one... the cost of doing this grows exponentially with the number of constrained bits. In practice I have never ever seen an efuse array that didn't also have a "permanent write-protect" fuse. If that fuse exists, the programming software will certainly activate it after verifying that the key was programmed correctly.
  - kaladin-jasnah 5y ago
    > By their very nature efuses can be programmed only once. You can never overwrite the old values with arbitrary new values. My understanding is this: you cannot overwrite the old values, but you can blow an additional fuse. If you have five fuses, then you blow the first fuse for the first key, then the second fuse for the second key. When you blow the second fuse, the system will only look at the second fuse, then the third, etc.