> For reasons, creating keys under the Endorsement hierarchy can be fidgety There are four key hierarchies: - the platform hierarchy, which exists mainly so t

> For reasons, creating keys under the Endorsement hierarchy can be fidgety There are four key hierarchies: - the platform hierarchy, which exists mainly so that OEMs can create keys under it that they certify - the endorsement hierarchy, which exists mainly for the EK, which is certified by the TPM manufacturer - the storage hierarchy, which is meant for the owner of the system - and the null hierarchy, which is meant for really ephemeral keys as the null hierarchy's primary seed is randomly generated each time the TPM starts (rendering all primary keys created on the null hierarchy useless after each reboot) The keys certified by the platform and TPM manufacturers can be used to identify the system, so they are considered privacy-sensitive, which is why then the storage hierarchy exists: the user can change its primary seed at any time and create keys for the user's use. A typical use of the storage hierarchy is to enroll a host using its platform and/or EK certificates, proving possession of their private keys and proving the platform's and/or TPM's legitimacy, then certifying (or whatever) public keys in the storage hierarchy. Once you have done this you can in principle lock the platform and endorsement hierarchies out so that applications cannot identify the user through them. An operating system is free to do just that: set controls on the PH/EH that make it impossible to use them post early boot. This attempt at privacy protection may or may not work for consumers though. Pressure to have attestable systems will mean that the OS vendor will want to enroll consumer devices so as to be able to provide apps with keys they can use. OS vendors will be able to control how much privacy the consumer gets, and maybe they will provide the user with decent privacy protection, and maybe not. Basically, I can see an OS certifying a different key per-{device, app} (under the storage hierarchy) so that apps may use _a_ key for attestation, but that key can be used for identification too, even if it's different for each application, as long as it is reused. So OS vendors will really have to certify new keys for apps frequently. Anyways, the "fidgety" reason that you might want to create keys under the SH rather than the EH is precisely that the OS might not let you have any access to the EH. You might only get to use the SH. You could leave the choice of hierarchy up to the user, but chances are they won't have a clue how to make that choice. Or you could try the EH then the SH if the EH is not available. Depending on what you're up to, it may not matter much. For enterprise systems you can make sure that you have access to the EH, so you might use the EH (though if you ever want to send a system back to a vendor, or sell it, you might want to be able to change the chosen hierarchy's seed, but if you change the EH's seed, then you render the EK certificate useless, which would render that TPM useless to anyone else, but then, you might not ever resell your used equipment). Another reason is that changing the primary seed of the PH or EH should only be done when one has first created useful keys under the SH, otherwise one can never again be able to establish the authenticity of the TPM after changing the EH seed, or the platform after changing the PH seed. But one can change those seeds, and some might in an attempt to add some privacy protection, but then any keys under those hierarchies will no longer be accessible. This mostly shouldn't happen, so it's not much of a reason.