Trusted Platform Module
Dries Schellekens
COSIC, KU Leuven
Nomenclature
Trusted versus trustworthy
RFC 4949 (Internet Security Glossary)
• Trust: A feeling of certainty (sometimes based on
inconclusive evidence) either (a) that the system will not
fail or (b) that the system meets its specifications (i.e., that
system does what it claims to do and does not perform
unwanted functions).
• Trusted system: A system that operates as expected
according to design and policy, doing what is required –
despite environmental disruption, human user and
operator errors, and attacks by hostile parties – and not
doing other things.
• Trustworthy system: A system that not only is trusted, but
also warrants that trust because the system’s behavior can
be validated in some convincing way, such as through
formal analysis or code review.
Trusted Platform Module, Dries Schellekens, COSIC
Slide 3
Alternative definitions
• NSA definition
Trusted: System or component whose failure can break
the security policy. (TCB = Trusted Computing Base)
o Trustworthy: System or component that will not fail with
respect to the security policy.
• TCG definition
o “An entity can be trusted if it always behaves in the
expected manner for the intended purpose.”
• Some people now regret the name Trusted Computing
o Trustworthy Computing or maybe Trustable Computing
could be a better title, but it is too late to change.
o
Trusted Platform Module, Dries Schellekens, COSIC
Slide 4
Motivation
Establish trustworthiness in
distributed IT systems
Classic attacks on online banking
• Attack on network communication
transfer €50
to Pela
transfer €10000
to Criminal
• Impersonation attack
transfer €10000
to Criminal
Trusted Platform Module, Dries Schellekens, COSIC
Slide 6
Modern attacks on online banking
• Phishing attack
transfer €50
to Bob
transfer €1000
to Criminal
• Man-in-the-browser attack
transfer €50
to Bob
Trusted Platform Module, Dries Schellekens, COSIC
transfer €1000
to Criminal
Slide 7
Trusted Computing to the rescue
• Trusted computing platforms support
o
o
Verification of software executing on remote platform
Binding of data to specific platform state
• Applications
o
o
o
o
o
Online banking
Multiplayer game
Remote access to
corporate network
Digital/Enterprise
rights management
…
Trusted Platform Module, Dries Schellekens, COSIC
Slide 8
Milestones of Trusted Computing
1999
Feb. 2002
April 2003
Oct. 2003
2006
Trusted Computing Platform Alliance (TCPA) founded by
Trusted Platform Module (TPM) 1.1b specification published
(TCG) formed as successor for TCPA
TPM 1.2 specification published
20+ million TPMs sold
Jan. 2007
TPM supported by BitLocker drive encryption in
June 2007
Mobile Trusted Module (MTM) 1.0 specification published
May 2009
TPM 1.2 specification adopted as ISO/IEC 11889 standard
2011
Oct. 2012
March 2013
500+ million TPMs sold
Improved TPM support in
TPM 2.0 library specification published
Trusted Platform Module, Dries Schellekens, COSIC
Slide 9
Technical overview
TCG components
• Core Root of Trust for Measurement (CRTM)
Immutable software component that executes upon a
host platform reset
o Platform dependent: BIOS for PC and EFI for Server
• Trusted Platform Module (TPM)
o Hardware component that provides a set of fixed
cryptographic and security functions
o (Originally) intended to be platform agnostic
• Trusted Software Stack (TSS)
o Issues low-level TPM commands and receives low-level
TPM responses on behalf of high-level applications
o
Trusted Platform Module, Dries Schellekens, COSIC
Slide 11
Core Root of Trust for Measurement
• Immutable portion of the host platform’s initialization code
that is executed upon a host platform reset
• Trust in measurement of platform configuration is based on
the integrity of the CRTM
• On PC platform
o CRTM = BIOS boot block
• Rest of BIOS is measured in authenticated boot process
o
CRTM = Entire BIOS
• BIOS Flash memory must be protected against unauthorized
reprogramming
• TCG has specifications for
o
o
Conventional BIOS
EFI (Extensible Firmware Interface) BIOS
Trusted Platform Module, Dries Schellekens, COSIC
Slide 12
Trusted Platform Module
• Design goals:
Simple, thus cheap (< $1) and hopefully free of bugs
o Low performance (no crypto accelerator)
• Smartcard like cryptographic coprocessor
o Small set of cryptographic functions
o
• Key generation, signing, encryption (RSA), hashing (SHA-1), HMAC
Hardware random number generator (RNG)
• Additional features
o Authenticated boot (integrity measurement)
o Remote attestation (integrity reporting)
o Sealed storage
• Securely bound to the rest of the platform
• 500+ million TPMs (mainly 1.2) sold today
o
Trusted Platform Module, Dries Schellekens, COSIC
Slide 13
TPM hardware architecture
EEPROM
SRAM
µC
ROM
RSA
Chip layout of Infineon TPM 1.2  Christopher Tarnovsky (Black Hat 2010)
Trusted Platform Module, Dries Schellekens, COSIC
Slide 14
TPM hardware architecture
• Microcontroller (µC) with RSA coprocessor and RNG
• ROM: Firmware for microcontroller
SHA-1 and HMAC typically in software
SRAM: Volatile memory
o Key slots: load external keys
o Platform Configuration Registers (PCR): store integrity
measurements (24 x 160 bit)
EEPROM: Non-volatile memory
o Endorsement Key (EK) uniquely identifies TPM
o Storage Root Key (SRK) encrypts other keys maintained by TPM
o Owner’s authorization data (password)
o Monotonic counters (4 x 32 bit)
o NVRAM: small amount of freely programmable memory
I/O interface
o PC Client: Low-Pin Count (LPC) bus
o Embedded: I2C or System Management Bus (SMBus)
o
•
•
•
Trusted Platform Module, Dries Schellekens, COSIC
Slide 15
TPM
BIOS Flash
Trusted Platform Module, Dries Schellekens, COSIC
Expansion
Cards
Super I/O
I/O
Controller
Hub
(ICH)
USB
Devices
LPC
Network
Interface
Hard Disk
Parallel Port
Serial Port
PS/2
Floppy
Integration of TPM into PC platform
Graphics
Controller
Graphics
Memory
Controller
Hub
(GMCH)
FSB
Central
Processing
Unit
(CPU)
System
Memory
LPC = Low Pin Count
FSB = Front Side Bus
Slide 16
TCG functionality
• Authenticated boot
Logging of boot sequence
Remote attestation
o Report boot sequence to third party
User management
o Balance the interest of different parties (user, owner, …)
Key management
o Maintain cryptographic keys and control usage/access
o Sealed storage: restrict access based on specific boot
sequence
Other features
o RNG, clock, monotonic counter, …
o
•
•
•
•
Trusted Platform Module, Dries Schellekens, COSIC
Slide 17
Authenticated boot
• Synonym: measured boot or trusted boot
• Transitive chain of trust
CRTM
3
1
BIOS
4
Boot
Loader
Operating
System
Application
2
TPM
SML
PCR
12
65
0
49
98
MBIOS
MBL
MOS
MApp
1. “Measure” integrity of next component
MX = Hash(X)
2. Store measurement value MX in SML
3. Extend measurement value MX in PCR
PCRnew = Hash(PCRold, MX)
4. Execute/pass control to next component
PCR = Platform Configuration Register
SML = Stored Measurement Log
Trusted Platform Module, Dries Schellekens, COSIC
Slide 18
Difference with secure boot
• Secure boot
Boot process is halted when untrusted software is loaded
o Only execute code that is signed by the device manufacturer
or a certified software vendor
o Examples: game consoles, smart phones, TV settop box
• Authenticated boot
o TPM is passive and only records the boot process
o Platform can still load arbitrary software, like with a traditional
open platform (e.g., PC)
o Enforcement of “good” configurations has to be done
separately
o
• Remote attestation is used to grant/deny access to network service
• Sealed storage is used to grant/deny access to locally stored secret
• Warning: UEFI Secure Boot is coming to PC with Windows 8
Trusted Platform Module, Dries Schellekens, COSIC
Slide 19
Remote attestation
• Remote attestation: challenge-response protocol
nonce
certAIK, SignAIK(nonce, PCR), SML
Verifier
• TPM identities
o
o
Endorsement Key (EK): uniquely identifies TPM
Attestation Identity Key (AIK): pseudonym
CertEK, AIK
EncEK(certAIK)
Privacy CA
Trusted Platform Module, Dries Schellekens, COSIC
Slide 20
Direct anonymous attestation (DAA)
• TPM may have multiple AIKs
Best case: different AIK for every service provider
• Practical issues with Privacy CA
o Trusted third party is hard to find and expensive to maintain
o Evidence: no commercial privacy CA at the moment
o Privacy CA can link pseudonyms
• TPM 1.2 defines alternative solution to certify AIKs
o Direct Anonymous Attestation: zero knowledge protocol
o
• Unlinkability of TPM transactions
• No privacy CA needed
o
TPMs can only be recognized if
• Their internal DAA secrets are exposed
• They try to identify too often in a short period
Trusted Platform Module, Dries Schellekens, COSIC
Slide 21
Key management
• Non-volatile memory of TPM is limited in size
• TPM only stores two permanent cryptographic keys
o
Endorsement Key (EK): unique RSA en-/decryption key
•
•
•
•
o
Private key never leaves TPM
Public key is privacy sensitive (identifies a TPM)
Generated during manufacturing process of TPM
Some TPM manufacturers (Infineon, STM) provide endorsement
certificate on the EK
Storage Root Key (SRK): RSA en-/decryption key
•
•
•
•
Root of key hierarchy maintained by TPM
Private key never leaves TPM
Generated by TPM when ownership is taken
Deleted when TPM owner is deleted
Trusted Platform Module, Dries Schellekens, COSIC
Slide 22
TPM key hierarchy
TPM
EK
• Unlimited amount of keys
SRK
External storage
AIK
SignK
AIK
StorK
BindK
StorK
SignK
BindK
SymK
File
SymK
File
File
can be stored externally
• Storage keys (StorK) protect
other key types
• Attestation ID keys (AIK)
• Binding keys (BindK)
• Signing keys (SignK)
• Symmetric keys (SymK)
• All keys and data (i.e., files)
indirectly protected by SRK
• External TPM keys must be loaded in a key slot by the
TSS before they can be used
Trusted Platform Module, Dries Schellekens, COSIC
Slide 23
Key types and attributes
• Most important key types
o
Attestation identity keys: used for remote attestation
• Pseudonyms for EK
o
o
o
Binding keys: encrypt secret data (e.g., symmetric key)
Signing key: sign arbitrary data
Storage keys: protect other keys outside of TPM
• Inner nodes of key hierarchy
• Key attributes
o
o
o
Password protected
Migratable, non-migratable, or certified
Bound to specific PCR value (known as sealed storage)
Trusted Platform Module, Dries Schellekens, COSIC
Slide 24
User management
• Access to certain operations/keys requires authentication
• Two ways to authenticate to the TPM
o
o
Asserting Physical Presence: Proof that one has physical
access to the platform through BIOS setting or hardware
switch
Using Authentication Protocols: Proof that one knows an
authentication secret (= hash of passphrase)
• Mitigation techniques to prevent online dictionary attacks
• Distinction between user and owner of platform
Corporate setting: IT department owns the platform
o Home environment: user and owner are the same entity
• TPM only becomes fully functional after “take ownership”
command
o Owner sets owner authentication secret (encrypted with EK)
o This command clears the TPM and generates new SRK
o
Trusted Platform Module, Dries Schellekens, COSIC
Slide 25
Beyond TPMs
Problem statement
transfer €50
to Bob
transfer €1000
to Criminal
• Applications
Online banking: honest user, but malware present
o Multiplayer game: dishonest user
o Remote access to corporate network
o Digital rights management: dishonest user
o Enterprise rights management
• Does TC enable to remotely detect man-in-the-browser?
o Yes, but …
o
Trusted Platform Module, Dries Schellekens, COSIC
Slide 27
Shortcomings of TCG attestation
• Criticism on TCG attestation
Privacy issue: verifier gets too detailed information
o Risk for discrimination of certain platforms (e.g., Linux)
Attestation of individual programs is challenging
o What should be measured? Executable image, shared libraries,
sensitive arguments, configuration files, …
Scalability issues
o Measurement log can become very long
o
•
•
• Windows loads 200+ drivers from known set of 4+ million
• IMA records 3000+ measurements on default Linux desktop
Verifier must maintain large database of possible configurations
Time-of-Check Time-of-Use problem
o Runtime compromise using security vulnerability after integrity
measurement
Trustworthiness of platform must be improved with other security
mechanisms; e.g., malware detection, microkernel, virtualization, safe
programming language, trusted execution environment, ….
o
•
•
Trusted Platform Module, Dries Schellekens, COSIC
Slide 28
Concept of trusted virtualization layer
• In a nutshell
o
Hypervisor/virtual machine monitor isolates multiple virtual
machines (VM)
• VM for untrustworthy legacy OS, where
• VM with stripped-down secure OS that host the critical application
(e.g., DRM client, game, email client, …)
Remote attestation is used to verify the hypervisor
o Hypervisor reports security policy and/or integrity of secure
VM
• More scalable because the image of secure VM does not
depend on the underlying hardware
• Performance overhead is limited on processors with
virtualization extensions
• Proof-of-concept implementation by OpenTC project
o
Trusted Platform Module, Dries Schellekens, COSIC
Slide 29
Dynamic Root of Trust for Measurement
• Hardware virtualization support was added to x86 architecture
• Intel TXT and AMD SVM provide late launch functionality
Ability to start hypervisor after legacy operating system has
booted
o Integrity of hypervisor can be measured and recorded in the
TPM using a special processor instruction (SENTER/SKINIT)
o This special instruction can reset certain PCRs with special
LPC bus cycles
• In theory: legacy components such as BIOS, bootloader, …
must no longer be trusted, hence reducing the TCB
considerably
• In practice: DRTM has been attacked with System Management
Mode (SMM) code
o
Trusted Platform Module, Dries Schellekens, COSIC
Slide 30
Executive summary
• TCG introduced the concept of authenticated boot and remote
attestation as alternative for traditional, code signing-based
secure boot
• TPM is the hardware component in a trusted computing
platform, but software support (CRTM + TSS) is needed as well
• TC is only an enabling technology, but without a trustworthy
operating system it is rather useless
o The addition of a TPM does not automagically make a
platform more secure
• Practical deployment of TC technology is more challenging than
expected
o 500+ million TPMs have been sold, but most are rarely used
o Best known TPM application: Microsoft Bitlocker disk
encryption
o Windows 8 has much more extensive TPM support (including
authenticated boot process) than previous versions
Trusted Platform Module, Dries Schellekens, COSIC
Slide 31
Main changes in TPM 2.0
• More flexible command set
TPM 1.2 specification was focused on PC(-like) platform.
o Dedicated MTM specification was needed for mobile phone,
making mandatory TPM 1.2 features optional.
o TPM 2.0 is “library specification” that will be used as the
basis for the creation of platform-specific TPM specifications.
• Algorithm agility
o TPM 1.x: only RSA and SHA-1
o TPM 2.0: addition of elliptic curve-based crypto, AES, SHA-2,
Whirlpool
• A bit more from everything: multiple banks of PCRs, multiple
EKs and SRKs, more flexible/fine-grained authorization
• Reference implementation in C available
o
Trusted Platform Module, Dries Schellekens, COSIC
Slide 32
Additional reading material
• http://www.trustedcomputinggroup.org
• Books
Trusted Platform Module, Dries Schellekens, COSIC
Slide 33