> For the complete documentation index, see [llms.txt](https://davidjosearaujo.gitbook.io/notes-mcs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://davidjosearaujo.gitbook.io/notes-mcs/secure-execution-environments/tpm-trusted-platform-module/entities.md).

# 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&#x20;
* 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.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://davidjosearaujo.gitbook.io/notes-mcs/secure-execution-environments/tpm-trusted-platform-module/entities.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
