Entities
Permanent
Non-volatile indexes
Objects
Non-persistent entities
Persistent entities
Entity names
Permanent
It is defined by the specification.
Cannot be created nor deleted.
Persistent hierarchies
Ephemeral hierarchies
Dictionary attack lockout reset
PCRs
Password authorization session
Platform NV enable
Permanent Entities
Persistent hierarchies
Their elements persist across power-off.
Each one has an authorization and a policy.
Platform
Storage
Endorsement
Ephemeral hierarchies
Their elements disappear across power-offs. But the hierarchies do not.
Have an authorization and a policy.
NULL hierarchy.
Dictionary attack lockout reset
A mechanism designed to overrule lockout states entered upon an excessive number of authentication failures.
Has an authorization and a policy.
PCRs
Arrays of registers
Accessed by index.
Organized in banks by algorithm.
Each has an authorization and a policy
For updating only.
Reading is always allowed.
Password authorization session
Sessions help to organize several commands under a common authorization policy.
Password authorization sessions are special.
They only last for a command.
Thus, they are implicit (thus, permanent).
Platform NV enable
The access to non-volatile (NV) platform data is controlled by this control.
Platform NV data belongs to the platform hierarchy.
TPM non-volatile (NV) indexes
A kind of pointer (or handle) to NV storage. With a structure unknown to the TPM.
Have more attributes than objects. Which have a structure known by the TPM.
Each one has an authorization value and a policy.
Authorizations can be changed by the index owner.
Policies cannot be changed.
They belong to a hierarchy.
And are cleared when the hierarchy is cleared.
TPM NV index types
Ordinary
Can contain any value, of arbitrary length.
Counter
Can contain an increment-only 64-bit value.
Initialized to the largest value that any counter has ever had in the TPM.
Bit field
64-bit array.
Initialized at zero, bits can only be set (never reset).
Extend
Similar to a PCR.
Objects
Key or data.
Each one has authorization data and a policy.
Authorizations can be changed by the object owner.
Policies cannot be changed.
They belong to a hierarchy.
And are cleared when the hierarchy is cleared.
Their use requires a TPM non-persistent entity: the session.
Non-persistent entities
They disappear on power-on.
Reset (upon reboot).
They can be saved out of the TPM.
But not reloaded after a power cycle.
Are preserved across restarts and resumes.
These operations send a different order to the TPM.
Authorization sessions.
Persistent entities
An object that the owner of a hierarchy sets to persist across power cycles.
Usually, keys, and just a few, since the TPM has a small persistent memory.
Names
Names prevent the reuse of handles
They are given to entities that can reuse handles.
They are unique entity identifiers.
Permanent entities have no name
Their handle is constant.
Other entities have a name that is a hash of their public data.
Hierarchies
A hierarchy is a collection of related entities.
Managed as a group.
Can be enabled or disabled.
They include:
Permanent entities
Hierarchy handles
A private, random cryptographic root
Seed
Key trees
Starting on a primary key
NV indexes
A private proof value
To check whether a value was produced by the TPM
Platform hierarchy
Intended to be in control of the platform manufacturer.
It is always configured by the manufacturer's firmware upon a boot.
Which can also enable or disable it.
Storage hierarchy
Intended to be in control of the platform owner.
Company
End user
Intended for non-privacy-sensitive operations
All its contents can be cleared by the owner
Useful when changing owners.
Endorsement hierarchy
Intended to be in control of the platform user.
The TPM chip generates its seed when first powered on.
Endorsement primary seed.
Several primary keys are derived from the seed.
And certified by the TPM manufacturer.
Certification attests they belong to a genuine TPM.
Usually, these are encryption/decryption keys.
And not signing keys.
Last updated