Marcin Jahn | Dev Notebook
  • Home
  • Programming
  • Technologies
  • Projects
  • About
  • Home
  • Programming
  • Technologies
  • Projects
  • About
  • An icon of the Networking section Networking
    • HTTP Protocol
    • OSI Model
    • TCP Procol
    • UDP Protocol
    • WebSocket
    • HSTS
    • DNS
    • Server Name Indication
    • gRPC
  • An icon of the Security section Security
    • OAuth2
      • Sender Constraint
    • Cryptography
      • Cryptography Basics
    • TPM
      • Overiew
      • TPM Entities
      • TPM Operations
  • An icon of the Linux section Linux
    • Gist of Linux Tooling
    • Unknown
    • SELinux
    • Containers
    • Bash Scripting
    • Linux From Scratch
    • Networking
  • An icon of the Kubernetes section Kubernetes
    • Meaning and Purpose
    • Cluster
    • Dev Environment
    • Kubernetes API
    • Objects
    • Pods
    • Scaling
    • Events
    • Storage
    • Configuration
    • Organizing Objects
    • Services
    • Ingress
    • Helm
  • An icon of the Observability section Observability
    • Tracing
  • An icon of the Databases section Databases
    • ACID
    • Glossary
    • Index
    • B-Tree and B+Tree
    • Partitioning and Sharding
    • Concurrency
    • Database Tips
  • An icon of the SQL Server section SQL Server
    • Overview
    • T-SQL
  • An icon of the MongoDB section MongoDB
    • NoSQL Overview
    • MongoDB Overview
    • CRUD
    • Free Text Search
  • An icon of the Elasticsearch section Elasticsearch
    • Overview
  • An icon of the Git section Git
    • Git
  • An icon of the Ansible section Ansible
    • Ansible
  • An icon of the Azure section Azure
    • Table Storage
    • Microsoft Identity
  • An icon of the Google Cloud section Google Cloud
    • Overview
  • An icon of the Blockchain section Blockchain
    • Overview
    • Smart Contracts
    • Solidity
    • Dapps
  • Home Assistant
    • Home Assistant Tips
  • An icon of the Networking section Networking
    • HTTP Protocol
    • OSI Model
    • TCP Procol
    • UDP Protocol
    • WebSocket
    • HSTS
    • DNS
    • Server Name Indication
    • gRPC
  • An icon of the Security section Security
    • OAuth2
      • Sender Constraint
    • Cryptography
      • Cryptography Basics
    • TPM
      • Overiew
      • TPM Entities
      • TPM Operations
  • An icon of the Linux section Linux
    • Gist of Linux Tooling
    • Unknown
    • SELinux
    • Containers
    • Bash Scripting
    • Linux From Scratch
    • Networking
  • An icon of the Kubernetes section Kubernetes
    • Meaning and Purpose
    • Cluster
    • Dev Environment
    • Kubernetes API
    • Objects
    • Pods
    • Scaling
    • Events
    • Storage
    • Configuration
    • Organizing Objects
    • Services
    • Ingress
    • Helm
  • An icon of the Observability section Observability
    • Tracing
  • An icon of the Databases section Databases
    • ACID
    • Glossary
    • Index
    • B-Tree and B+Tree
    • Partitioning and Sharding
    • Concurrency
    • Database Tips
  • An icon of the SQL Server section SQL Server
    • Overview
    • T-SQL
  • An icon of the MongoDB section MongoDB
    • NoSQL Overview
    • MongoDB Overview
    • CRUD
    • Free Text Search
  • An icon of the Elasticsearch section Elasticsearch
    • Overview
  • An icon of the Git section Git
    • Git
  • An icon of the Ansible section Ansible
    • Ansible
  • An icon of the Azure section Azure
    • Table Storage
    • Microsoft Identity
  • An icon of the Google Cloud section Google Cloud
    • Overview
  • An icon of the Blockchain section Blockchain
    • Overview
    • Smart Contracts
    • Solidity
    • Dapps
  • Home Assistant
    • Home Assistant Tips

TPM Operations

Generating Random Numbers

The TPM2_CC_GetRandom command generates random bytes (max 48 per call).

Generating Keys

Each hierarchy can have a primary key, which acts as a parent for all the child keys. The children are wrapped (encrypted by the parent).

Enrollment Primary Key is certified by the manufacturer of the TPM. It means that the key has an accompanying certificate signed by the trusted CA. This certificate is stored in the TPM’s NVDATA. It can be read and verified any time. The NV indices for the certs are reserved.

If EK is trusted, all keys under it can be trusted as well (chain of trust).

The Primary Key may be recreated multiple times, it will always be the same, as long as the provided parameters (such as key type) are the same. The EK has predefined templates, which can be used anytime we need that key. One is for RSA, the other for ECC.

Keys may be stored persistently, but TPM has limited space for it.

Attributes

Other than algorithm information, it is also required to provide attributes of the new key (object). Example:

CreatePrimary(
TPM2_RH_OWNER,
TPM2_ALG_RSA,
/*restricted=*/ 1,
/*decrypt=*/ 1,
/*sign=*/ 0,
/*unique=*/ "hello"
);

Some of the parameters:

  • Decrypt (TPMA_OBJECT_DECRYPT) - Specifies an encryption key.
  • Sign (TPMA_OBJECT_SIGN_ENCRYPT) - Specifies a signing key.
  • Restricted (TPMA_OBJECT_RESTRICTED) - Restricts the key to signing/encrypting only internal TPM data.

Non primary keys are created with the TPM2_CC_Create command. The command requires a handle to the parent key.

Using Keys

Keys generated by TPM might be used to sign, verify, encrypt, decrypt data.

Ownership

Endorsement Hierarchy keys are protected by the EK (which is certified and can be trusted). The Owner Hierarchy cannot be trusted in the same way, it’s not certified by the TPM manufacturer. It’s the owner’a responsibility to provision and certify the primary key of the owner hierarchy. The primary key of the owner hierarchy is the Storage Root Key (SRK) (like in TPM 1.2?). It’s a restricted encryption key.

Having a trusted, restricted signing key is useful for remote system attestation. It’s, therefore, recommended to create and certify a restricted signing key during provisioning time. This trusted signing key is also called Attestation Identity Key (AIK).

Taking Ownership

  1. Read and validate the EK certificate. Proceed only if you trust the vendor.
  2. Clear the owner hierarchy with TPM2_CC_Clear.
  3. Create a primary, restricted asymmetric encryption key on the owner hierarchy (TPM2_CC_CreatePrimary). Call this the SRK.
  4. Certify the SRK with your enterprise CA: create a CSR with SRK public part, and ask your internal, trusted CA to sign it. Store the certificate in NV data (TPM2_CC_NV_DefineSpace, TPM2_CC_NV_Write). Alternatively, you can store the SRK public key in a remote database. Use this database to verify the SRK’s authenticity in the future.
  5. Make the SRK persistent by evicting it to NVDATA (TPM2_CC_EvitControl).
  6. Create a restricted asymmetric signing key under the SRK (TPM2_CC_Create, TPM2_CC_Load). Call this the AIK.
  7. Certify the AIK with your enterprise CA: create a CSR with AIK public part, and ask your internal, trusted CA to sign it. Store the certificate in NV data (TPM2_CC_NV_DefineSpace, TPM2_CC_NV_Write). Alternatively, you can store the AIK public key in a remote database. Use this database to verify the AIK’s authenticity in the future. It’s possible to use the SRK certificate as root of trust for the AIK, however, having an AIK certificate can simplify some workflows.
  8. Make the AIK persistent by evicting it to NVDATA (TPM2_CC_EvitControl).

These keys should be set as fixed (non-duplicable): use TPMA_OBJECT_FIXEDTPM and TPMA_OBJECT_FIXEDPARENT in the objectAttributes field in their templates. At this point we have two trusted keys we can use: one for storage (protecting other TPM keys) (SRK?) and one for signing TPM statements (AIK).

A common practice is to set the owner hierarchy’s auth value to a random string during provisioning. It protects keys on this hierarchy against unwanted use.

Measured Boot

It’s a standardized technology supported by modern firmware. Before executing an element in the boot sequence, it’s measured to make sure that it is the expected executable. If the result is unexpected, it’s not executed.

Each element is measured by its predecessor in the sequence. Each measurement is stored in a different PCR.

Measuring the Firmware

We assume that the first element (firmware) is trusted. It measures itself into PCR0. Vendors publish the expected measurements of their firmware.

Another approach is to use CRTM. There’s an immutable code component called Core Root of Trust for Measurement (CRTM). It is the first piece of code that executes on the main processor during the boot process. It measures the firmware blob before passing execution to it.

Event Log

There is a log that gives some details about measurements sent to TPM. It’s maintained by the firmware, bootloader and the OS. Users can read the log to see what was measured.

Log example:

Fimware blob "firmware.bin", PCR8, digest=0x11223344.
Boot app "/EFI/Windows/Bootloader.efi", PCR8, digest=0x55667788.
Kernel image "c:\Windows\ntoskrnl.exe", PCR8, digest=0x99AABBCC.

Thanks to Measured Boot a Remote Attestation may be done. It checks the integrity of a system.

Authorization

TPM may be used only with the right authorization. Authorization policies are used. Many authorization schemes are supported (e.g. a password scheme). Autorization value may be set for the entire hierarchy or on individual keys.

An example of authorizing before calling a command:

app.SetAuthPassword("secret-password");
var key = app.Create(
primary.handle,
TPM2_ALG_RSA,
/*restricted=*/ 1,
/*decrypt=*/ 1,
/*sign=*/ 0
);

When more than three attempts of authorization fail, TPM enters locked-out mode. It protects against a dictionary attack. It will not accept any command for the target object in that state.

Session Authorization

Session is an internal TPM object that encodes an authorization value. A session has a digest of PCRs. When creating a data/key in TPM, we can specify what is the expected PCR digest. If the session’s digest matches the one expected by the data/key it is accessible.

←  TPM Entities
© 2023 Marcin Jahn | Dev Notebook | All Rights Reserved. | Built with Astro.