4 ms·

I don't think it's fair to group measures that have a valid security justification along with those that do not. Code signing, secure boot (including TPM when

by comex 13y ago

I don't think it's fair to group measures that have a valid security justification along with those that do not. Code signing, secure boot (including TPM when used as a part of that), and patch protection do, and can be disabled. Linux distros really should probably have more rigorous protections along those lines, but manage to avoid it because nobody targets Linux (not because it's that much more secure); Chrome OS has them anyway, despite almost everything being open source, including Chromebook bootloaders, and I like that fact. Meanwhile, proprietary software and closed hardware specifications have nothing to do with security and should be criticized more harshly.

mindslight 13y ago
The idea of secure boot could theoretically be a no-tradeoff security positive, but the implementation would be quite different from what it is currently. For starters, any non-user-hostile solution is going to have something like a usb device header on the motherboard as the highest-privileged interface to the system (with something like mandatory time delays to prevent against evil maid attacks). But to large manufacturers run by business people, the attraction to a hardcoded manufacturer-administered signing certificate for the trust root (which obviously erodes the owner's control) is just too strong for us to see a proper implementation any time soon.
- yuhong 13y ago
  I once proposed handing the keys to an independent standard body, particularly after FSF complained about the process.
  - mindslight 13y ago
    But why forge a centralized ring of power in the first place? Even completely above-reproach independent bodies can still be co-opted by subpoenas and the like. And the mere existence of that possibility for control is blood in the water for governments.
- comex 13y ago
  You realize that with UEFI (ed: on x86... yes, Windows RT devices are different), you can either disable Secure Boot or (at least on some systems) replace the root key with your own, without any hardware modification? On Chromebooks, which I'm a bit more familiar, you cannot, and disabling verification involves a 30 second delay on boot with beep, to prevent against evil maid attacks. However, apparently it's not too hard [1] to flash the ROM on some devices if you can open the thing. [1] http://krblogs.com/post/63809988096/bootloader-unlock-on-samsung-arm-chromebook http://krblogs.com/post/63809988096/bootloader-unlock-on-sam...

by comex 13y ago

mindslight 13y ago

The idea of secure boot could theoretically be a no-tradeoff security positive, but the implementation would be quite different from what it is currently. For starters, any non-user-hostile solution is going to have something like a usb device header on the motherboard as the highest-privileged interface to the system (with something like mandatory time delays to prevent against evil maid attacks). But to large manufacturers run by business people, the attraction to a hardcoded manufacturer-administered signing certificate for the trust root (which obviously erodes the owner's control) is just too strong for us to see a proper implementation any time soon.

yuhong 13y ago
I once proposed handing the keys to an independent standard body, particularly after FSF complained about the process.
- mindslight 13y ago
  But why forge a centralized ring of power in the first place? Even completely above-reproach independent bodies can still be co-opted by subpoenas and the like. And the mere existence of that possibility for control is blood in the water for governments.
comex 13y ago
You realize that with UEFI (ed: on x86... yes, Windows RT devices are different), you can either disable Secure Boot or (at least on some systems) replace the root key with your own, without any hardware modification? On Chromebooks, which I'm a bit more familiar, you cannot, and disabling verification involves a 30 second delay on boot with beep, to prevent against evil maid attacks. However, apparently it's not too hard [1] to flash the ROM on some devices if you can open the thing. [1] http://krblogs.com/post/63809988096/bootloader-unlock-on-samsung-arm-chromebook http://krblogs.com/post/63809988096/bootloader-unlock-on-sam...