It's not the usage of the mechanism itself, but how the mechanism is used that mandates specific types of policy. It's a matter of where the trust is anchored:
> publicly posted hashes
The method you used to retrieve the hash and ...
> package managers
The method you used to obtain the initial install and ...
> GPG
The web of trust (how you came to associate a given key with an identity) and ...
> TLS
As commonly used, the CAs. Which we're presently having a problem with, because the list is too damn fixed. In the case of TLS applied to other protocols (eg openvpn), then the trust lies in how the keys are distributed. And ...
The "..." is of course the integrity of your machine. Which, unless you always keep it in your sight, is a big if. A large part of this is what boot image verification is aiming to solve. But to do this, one needs to choose somewhere else to anchor the trust. "Secure Boot" specifies that this trust should be anchored in manufacturer-designated entities using public key signatures. On x64 this this would raise antitrust hackles, so Microsoft mandates (for now) that its primary security property be destroyed, leaving the anchor back to possession/integrity of the machine.
What I'm advocating is that this trust anchor could also be something non-trapdoored like a proof of work (or simple waiting time, since we're dealing with trusted hardware). For example, imagine if the specification mandated that all conforming implementations allow changing the keys after waiting in an offline "key provision mode" for a week. The trust root would then be "possession of the hardware for a week" (defeating an evil maid), rather than a fixed set of manufacturer-designated signers.
You could root your trust in a TPM or other hardware security modules. You still have to trust the manufacturer of the HSM chip but that's their entire business model, unlike Microsoft's.
You can't really "root" your trust in an HSM. Yes, the HSM is trusted in that if it is broken, then the security of the system is as well. But the "trust root" is what the HSM uses as a specification for what to trust. This still boils down to a public key, physical possession, proof of work, immutable hash, etc.
>Secure Boot" specifies that this trust should be anchored in manufacturer-designated entities using public key signatures.
No, it doesn't. It doesn't specify how the keys should be dealt with at all. The implementation currently has manufacturers controlling that aspect, which the author views as flawed.
As long as the trust root consist of public keys and not physical possession of the device, then the manufacturer inherently controls those public keys.
> publicly posted hashes
The method you used to retrieve the hash and ...
> package managers
The method you used to obtain the initial install and ...
> GPG
The web of trust (how you came to associate a given key with an identity) and ...
> TLS
As commonly used, the CAs. Which we're presently having a problem with, because the list is too damn fixed. In the case of TLS applied to other protocols (eg openvpn), then the trust lies in how the keys are distributed. And ...
The "..." is of course the integrity of your machine. Which, unless you always keep it in your sight, is a big if. A large part of this is what boot image verification is aiming to solve. But to do this, one needs to choose somewhere else to anchor the trust. "Secure Boot" specifies that this trust should be anchored in manufacturer-designated entities using public key signatures. On x64 this this would raise antitrust hackles, so Microsoft mandates (for now) that its primary security property be destroyed, leaving the anchor back to possession/integrity of the machine.
What I'm advocating is that this trust anchor could also be something non-trapdoored like a proof of work (or simple waiting time, since we're dealing with trusted hardware). For example, imagine if the specification mandated that all conforming implementations allow changing the keys after waiting in an offline "key provision mode" for a week. The trust root would then be "possession of the hardware for a week" (defeating an evil maid), rather than a fixed set of manufacturer-designated signers.