It's much easier to add such a scheme to any platform than removing it when the vendor decided for you that this is what you want. If you want to lock the box down, put the firmware in flash, clip the ~WP pin, pour epoxy on it.
I guess the Raptor Eng folks aren't opposed to adding something more flexible to a later iteration (I'd propose securely measuring the firmware into some trusted external store in the style of TPM1.x and working from there), but for now the project is about helping undo the damage done to the ecosystem by providing an old-style "all open" platform again.
This seems to be an unfortunate relic from the fight against the clipper chip.
Buying hardware that you don't own and control is a big problem, but that doesn't mean all methods of securing the boot process are evil. The important bit is that it's the owner of the hardware that's in control of the keys, and that (s)he can retain sole control of the signing keys if desired.
The Snowden leak claimed that the NSA had special Intel chips, but no one has ever claimed Intel did a special production run. However, if they stole Intel's signing keys and internal documentation, they could just reflash the existing chips and Intel would not need to know a thing about it. Anyone who gets their hands on that information would be able to do the same and there is not a thing you can do about it beside using hardware where that is not possible.
I think we're in agreement then. Intel's system does not meet the criteria I set forth in the post you're replying to (since there is only one key, and it's generated out of the owners control). So that's a bad solution. If there were some way for a physically present user to set a new firmware signing key, that would get the benefit without having to throw out any attempt to secure the boot process.
Of course, intel's microcode is not open for scrutiny, so the point is moot there (what would you sign instead?)
The linked project states that having no way to lock the boot process is a benefit. I disagree that it's a feature to advertise, because it's possible to implement in such a way that the user retains complete control. Pointing out bad implementations is not a good answer to that.
The ME is an embedded device that has its own independent CPU and operating system. Whether Secure Boot is possible is tangential to that. Secure Boot is as relevant to security here as lowering the anchor on the titanic after hitting that iceberg. Whether the measure is in place or not does not actually fix things.
No, it's an ongoing contour. The companies that are interested in creating secure boot chains are uninterested in openly documenting the details. I presume both aspects come from the single-minded business desire of centralized control.
> Buying hardware that you don't own and control is a big problem, but that doesn't mean all methods of securing the boot process are evil.
Hear hear! Why are technology people, who are supposedly intellectual, thoughtful people, so prone to unthinking political knee-jerk?
As much as such technology can suck for individual's interests when turned against them, there is just as much potential for benefit to individual interests if the technology can be aimed 180 degrees the other way.
What if all information corporations possessed about you as an individual were protected through some trusted execution environment, with only publicly vetted code operating on it? What if any individual could meaningfully revoke access to their information when corporations turned out to be evil?
I guess the Raptor Eng folks aren't opposed to adding something more flexible to a later iteration (I'd propose securely measuring the firmware into some trusted external store in the style of TPM1.x and working from there), but for now the project is about helping undo the damage done to the ecosystem by providing an old-style "all open" platform again.