I thought twice about responding to this.

I worked on Palladium from very early days in 2002 through renaming to NGSCB and the eventual shutdown/transition of the project to ship BitLocker in Vista

The team never saw DRM as being an interesting use case. Remember that the Darknet paper [1] was written by the Palladium architects and product manager. The team fully understood that DRM wasn't an effective use of a secure computing environment.

The scenarios that we were interested in were more like credential management, or being able to run remote sessions from a trusted space within an otherwise untrusted machine, etc.

Interesting; I stand corrected. Thank you for responding!

oops forgot the reference...

[1] http://www.bearcave.com/misl/misl_tech/msdrm/darknet.htm

> That's the official story. Anybody familiar with Microsoft's history knows they have been trying to lock down the wintel platform for a long time. Creating a "Trusted Computing" environment specifically for DRM purposes has been a goal since "Palladium".

Are you implying Microsoft encouraged Lenovo to disable the firmware toggle for Secure Boot? Even though it's only defective on one model of one manufacturer's computer, and literally any other computer (including the Surface x86 line) can toggle it?

I don't see why they would maliciously introduce Secure Boot and only sabotage it on a very small number of computers.

Microsoft seems to have used a phased-in strategy: first it was all optional, then it should be there by default but ALSO with a mandatory option to disable to get the Windows logo (and probably goes with big OEM deals) then IIRC with Windows 10 MS dropped the mandatory removable part (but it is still ok to have it) on x86, and on non-x86 this is probably already mandatory to NOT be able to remove it. I guess in a few years they will render it mandatory to NOT be able to remove it also on x86, for new computers to be eligible to Windows compat logo/OEM deals.

Given implementations are huge and full of bugs, the stated intent is also complete bullshit: it is actually far more dangerous to have a platform with that kind of "security" measures, because once a hole is found malware can hide in there more efficiently and be extremely difficult to remove.

How does Secure Boot enable malware to "hide in there more efficiently"? With or without Secure Boot, a compromised bootloader is in a privileged position, but not any more so with Secure Boot, from what I can tell.

Because there is in general nothing to authenticate the hardware owner in contrast with the usual OS users/admins - that the model consider corrupted, and because it is designed to msot of the time prevent modification by even admins (allowing only modifications signed by the hardware manufacturer), if a security hole is discovered and exploited it is not very easy to revert the system in a good state; it can even become completely impossible if the malware patches the security hole after having exploited it. So it can then sit there, unremovable, and with ultra-privileges. The situation is similar to infected android: because of the security model it is not supposed to happen (most of the time, there are often "bugs" even in the informal model), but because software are full of security holes once one is exploited it is less easy to remove the infection than it can be on a PC.

This is for this reason that the security community consider the Intel Management Engine a huge security risk, and the situation is only marginally better with x86 firmware using such "security" features.

Microsoft is in an impossible position here. Signed kernels are the only way to prevent rootkits. If they don't move in this direction people will complain about insecurity. If they do we get complaints about locking down the platform.

How about letting the owner uploading keys combined with a hardware switch to enable that?

Yeah, seems like there ought to be some way to do it securely if you have access to the hardware.