3 ms·

The security reasoning is that the device must boot intended operating system, and not just any system that conveniently lies around on drive. This is to preven

The security reasoning is that the device must boot intended operating system, and not just any system that conveniently lies around on drive. This is to prevent attack of switching operating system with look-a-like and stealing sensitive information from unsuspecting user. Also to prevent attacker from booting into another OS and reading disk content.

koolba 10y ago
> The security reasoning is that the device must boot intended operating system, and not just any system that conveniently lies around on drive. This is to prevent attack of switching operating system with look-a-like and stealing sensitive information from unsuspecting user. I'm not saying being able to have signed OS's is a bad idea. What I'm wondering is why isn't this something that the user can enable/disable? Say secured with a long BIOS password. I'd wager 99.999% of people don't have to worry about evil maid attacks and those that do aren't going to defer to Microsoft's defaults as counter measures. > Also to prevent attacker from booting into another OS and reading disk content. Bullshit. If they really want that they can rip out the hard disk. If you don't want people reading your plaintext then don't store it as plaintext. Encrypted disks unlocked at boot is a solved problem. Having the device default to not booting other OS's unless you go into an unsecured BIOS and flip a bit would cover the majority of cases. All you need is a secure boot path into the BIOS that malware presumably wouldn't be able to replicate from a booted OS.
- contextfree 10y ago
  "What I'm wondering is why isn't this something that the user can enable/disable? " It is on x86
- marcosdumay 10y ago
  Secure boot does not protect against evil maid attacks. (I'm not sure anything really does.) With physical presence, you can still grab the data and run it in a VM managed by your malicious code. Secure boot protects against BIOS level root kits and similar low-leve but remote exploitation. No argument it's a bad idea to use MS's key, instead of the computer's owner. The only explanation for why MS made it this way was for DRM - once again weakening end user security to enforce MS's secure against us.

koolba 10y ago

> The security reasoning is that the device must boot intended operating system, and not just any system that conveniently lies around on drive. This is to prevent attack of switching operating system with look-a-like and stealing sensitive information from unsuspecting user. I'm not saying being able to have signed OS's is a bad idea. What I'm wondering is why isn't this something that the user can enable/disable? Say secured with a long BIOS password. I'd wager 99.999% of people don't have to worry about evil maid attacks and those that do aren't going to defer to Microsoft's defaults as counter measures. > Also to prevent attacker from booting into another OS and reading disk content. Bullshit. If they really want that they can rip out the hard disk. If you don't want people reading your plaintext then don't store it as plaintext. Encrypted disks unlocked at boot is a solved problem. Having the device default to not booting other OS's unless you go into an unsecured BIOS and flip a bit would cover the majority of cases. All you need is a secure boot path into the BIOS that malware presumably wouldn't be able to replicate from a booted OS.

contextfree 10y ago
"What I'm wondering is why isn't this something that the user can enable/disable? " It is on x86
marcosdumay 10y ago
Secure boot does not protect against evil maid attacks. (I'm not sure anything really does.) With physical presence, you can still grab the data and run it in a VM managed by your malicious code. Secure boot protects against BIOS level root kits and similar low-leve but remote exploitation. No argument it's a bad idea to use MS's key, instead of the computer's owner. The only explanation for why MS made it this way was for DRM - once again weakening end user security to enforce MS's secure against us.