Skip to content
This repository has been archived by the owner on Jan 6, 2019. It is now read-only.

Latest commit

 

History

History
87 lines (77 loc) · 4.32 KB

tpm.md

File metadata and controls

87 lines (77 loc) · 4.32 KB

Trusted Platform Module (TPM)

TPM Goals

  • Platform identity
  • Remote attestation: remote verifier can validate platform configuration
  • Sealed storage: secret bound to specific platform configuration
  • Secure counter
  • Is a passive device offering some basic security relevant functionality

TPM Parts

  • Non-volatile Storage
  • RAM
  • Execution Engine
  • RSA Engine
  • Random Number Generator
  • Platform Configuration Registers (PCRs)
    • PCR 0 to PCR 15
    • only reset at system boot
    • each 128 bits
    • Only writeable by extend operation: \(\operatorname{extend}(PCR_i, data) = \operatorname{SHA-1}(PCR_i || \operatorname{SHA-1}(data))\)
    • Used as a hash-chain to store log of events
    • Only final event is checked. Check fails if any intermediate value was incorrect
  • SHA1 Engine
  • Interfaced over memory mapped I/O
    • memory page reserved for TPM
    • reading/writing to it equals a read/write to the corresponding TPM register
    • modern TPMs use «Low Pin Count (LPC)» bus interface

TPM PCRs

  • Primary security requirement for the hashes is integrity, i.e. make sure nothing is altered
  • Store as hash-chain by extend operation: \(\operatorname{extend}(PCR_i, data) = \operatorname{SHA-1}(PCR_i || \operatorname{SHA-1}(data))\)

TPM Misconceptions

  • not a general-purpose processor
  • not tamperproof
  • not part of the processor

TPM Keys

  • TPM 1.2 uses asymmetric crypto
  • each key is for decryption or signing, never both
  • Keys stored in TPM
    • Endorsement Key: certified by TPM vendor, used to establishing the presence and correctness of the TPM
    • Storage Root Key: used for secure storage (e.g. encryption of other keys stored on disk), generated the moment an entity takes ownership of the TPM
    • Attestation Identity Key: certified by third party based on endorsement key, used to sign non-migratable TPM data or keys (e.g. PCR's value). Generated by the TPM, it's not possible to find out the Endorsement Key by knowing the public part of the Attestation Identity Key.
  • Key types
    • Migratable: generated in TPM, transferable between TPMs
    • Non-migratable: generated in TPM, private part never leaves TPM

Primary Usage

  • Secure Boot: operating system boots only if the chain of trust is valid (BIOS, Boot Loader, Operating System)
  • Authenticated Boot: system uses chain of trust to record everything loaded. Operating system boots even if chain results in an invalid value
  • Cryptographic Co-Processor: use TPM to generate keys, encrypt, decrypt and perform hashing
  • Secure Storage: store non-migratable keys
  • Trusted Log: store hash-chain in PCRs
  • Attestation: proof system state to some party by sending and signing the trusted log (i.e. hash-chain). Attestation Identity Key is used to sign.

Attested Boot

  • Also known as: Authenticated Boot, Measured Boot, Verified Boot, Static Root of Trust for Measurement, TCG 1.1 style attestation
  • Measure all executed software and used configuration files to get platform configuration
  • Remote verifier should be able to verify these measurements

Implementation for Linux by IBM

  • Whole system is measured
  • Executables measured on-demand, to measure whole system is too time consuming
  • Measures before execution starts
  • Places as little trust as possible into the measurement system
  • Linux Kernel extended to measure dynamic linker and each executable
  • Extended dynamic linker to measure shared libraries
  • Extended kernel module loader to measure kernel modules
  • Kernel keeps measurements in a cache, files are only measured once unless they were modified
  • Measurements done at load-time and not run-time
    • Time-of-check-time-of-use problem!
    • Can't detect dynamic attacks!
  • No guarantee execution was done

Dynamic Root of Trust

  • Also known as: Dynamic Root of Trust for Measurements (DRTM), Late Launch
  • Processor contains support for an Isolated Execution Environment
  • Expected property: remote verifier gets assurance of code execution and achieves run-time attestation
  • Primitives:
    • Possible to create an Isolated Execution Environment (IEE), its data can only be access within the isolated environment
    • Remote verification/attestation of the IEE
    • Secure channel into IEE
    • Verify output was generated by running specific code on a specific input inside the IEE
  • Allows to run software without trusting its environment
  • Only hardware and the software inside the IEE is part of the TCB