Maybe it's evil in consumer devices, but secure boot is very effective when you don't want people to tamper with your hardware, e.g., preventing counterfeit commercial-grade routers from entering the market. Cisco for example is facing a HUGE problem with counterfeits and is looking at secure boot as a potential solution. I'm not affiliated with Cisco, but I did attend a talk by one of their researchers at Georgia Tech.
Secure boot solves the opposite problem from counterfeit hardware. If you make the hardware, you can insert whatever signing key you'd like - including Cisco's.
This argument demonstrates why architecture is so insidious. Yes, "Secure Boot" solves real problems. As I said, these problems can be solved through similar functionality that does not anchor the trust root to private keys. But now that Microsoft (et al) have promulgated their naive fully-trusted-publisher implementations, we're left having to dispel the primacy of "keys" in the first place.
I don't understand your point. You cannot "insert" Cisco's signing key into your own hardware because 1) the device does not possess it, and 2) only Cisco (ideally) has access to its signing key.
If you instead mean that you can build your own custom hardware that mimics the functionality of Cisco's TPM and uses another key pair for signing boot code, then I give you a pat on the back for the accomplishment.
Sorry, by "signing key" I meant "public part of the signing key", which is what is used for verification. Counterfeit hardware can also just ignore signatures on binaries.
Presumably Cisco is really talking about using trusted hardware to preserve secrecy of their binaries (as the march of software eats their custom hardware, too). Which as I said, is possible to do without privileging specific signing keys.
