Trusted Platform Module Dries Schellekens COSIC, KU Leuven - - PowerPoint PPT Presentation

trusted platform module
SMART_READER_LITE
LIVE PREVIEW

Trusted Platform Module Dries Schellekens COSIC, KU Leuven - - PowerPoint PPT Presentation

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


slide-1
SLIDE 1

Trusted Platform Module

Dries Schellekens COSIC, KU Leuven

slide-2
SLIDE 2

Nomenclature

Trusted versus trustworthy

slide-3
SLIDE 3

Trusted Platform Module, Dries Schellekens, COSIC Slide 3

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

  • perator 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.

slide-4
SLIDE 4

Trusted Platform Module, Dries Schellekens, COSIC Slide 4

Alternative definitions

  • NSA definition
  • Trusted: System or component whose failure can break

the security policy. (TCB = Trusted Computing Base)

  • Trustworthy: System or component that will not fail with

respect to the security policy.

  • TCG definition
  • “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
  • Trustworthy Computing or maybe Trustable Computing

could be a better title, but it is too late to change.

slide-5
SLIDE 5

Motivation

Establish trustworthiness in distributed IT systems

slide-6
SLIDE 6

Trusted Platform Module, Dries Schellekens, COSIC Slide 6

Classic attacks on online banking

  • Attack on network communication
  • Impersonation attack

transfer €50 to Pela transfer €10000 to Criminal transfer €10000 to Criminal

slide-7
SLIDE 7

Trusted Platform Module, Dries Schellekens, COSIC Slide 7

Modern attacks on online banking

  • Phishing attack
  • Man-in-the-browser attack

transfer €50 to Bob transfer €1000 to Criminal transfer €50 to Bob transfer €1000 to Criminal

slide-8
SLIDE 8

Trusted Platform Module, Dries Schellekens, COSIC Slide 8

Trusted Computing to the rescue

  • Trusted computing platforms support
  • Verification of software executing on remote platform
  • Binding of data to specific platform state
  • Applications
  • Online banking
  • Multiplayer game
  • Remote access to

corporate network

  • Digital/Enterprise

rights management

slide-9
SLIDE 9

Trusted Platform Module, Dries Schellekens, COSIC Slide 9

Milestones of Trusted Computing

1999 Trusted Computing Platform Alliance (TCPA) founded by

  • Feb. 2002

Trusted Platform Module (TPM) 1.1b specification published April 2003 (TCG) formed as successor for TCPA

  • Oct. 2003

TPM 1.2 specification published

  • 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 March 2013 TPM 2.0 library specification published

  • Oct. 2012

Improved TPM support in 2006 20+ million TPMs sold 2011 500+ million TPMs sold

slide-10
SLIDE 10

Technical overview

slide-11
SLIDE 11

Trusted Platform Module, Dries Schellekens, COSIC Slide 11

TCG components

  • Core Root of Trust for Measurement (CRTM)
  • Immutable software component that executes upon a

host platform reset

  • Platform dependent: BIOS for PC and EFI for Server
  • Trusted Platform Module (TPM)
  • Hardware component that provides a set of fixed

cryptographic and security functions

  • (Originally) intended to be platform agnostic
  • Trusted Software Stack (TSS)
  • Issues low-level TPM commands and receives low-level

TPM responses on behalf of high-level applications

slide-12
SLIDE 12

Trusted Platform Module, Dries Schellekens, COSIC Slide 12

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
  • CRTM = BIOS boot block
  • Rest of BIOS is measured in authenticated boot process
  • CRTM = Entire BIOS
  • BIOS Flash memory must be protected against unauthorized

reprogramming

  • TCG has specifications for
  • Conventional BIOS
  • EFI (Extensible Firmware Interface) BIOS
slide-13
SLIDE 13

Trusted Platform Module, Dries Schellekens, COSIC Slide 13

Trusted Platform Module

  • Design goals:
  • Simple, thus cheap (< $1) and hopefully free of bugs
  • Low performance (no crypto accelerator)
  • Smartcard like cryptographic coprocessor
  • Small set of cryptographic functions
  • Key generation, signing, encryption (RSA), hashing (SHA-1), HMAC
  • Hardware random number generator (RNG)
  • Additional features
  • Authenticated boot (integrity measurement)
  • Remote attestation (integrity reporting)
  • Sealed storage
  • Securely bound to the rest of the platform
  • 500+ million TPMs (mainly 1.2) sold today
slide-14
SLIDE 14

Trusted Platform Module, Dries Schellekens, COSIC Slide 14

TPM hardware architecture

Chip layout of Infineon TPM 1.2  Christopher Tarnovsky (Black Hat 2010)

SRAM EEPROM ROM µC RSA

slide-15
SLIDE 15

Trusted Platform Module, Dries Schellekens, COSIC Slide 15

TPM hardware architecture

  • Microcontroller (µC) with RSA coprocessor and RNG
  • ROM: Firmware for microcontroller
  • SHA-1 and HMAC typically in software
  • SRAM: Volatile memory
  • Key slots: load external keys
  • Platform Configuration Registers (PCR): store integrity

measurements (24 x 160 bit)

  • EEPROM: Non-volatile memory
  • Endorsement Key (EK) uniquely identifies TPM
  • Storage Root Key (SRK) encrypts other keys maintained by TPM
  • Owner’s authorization data (password)
  • Monotonic counters (4 x 32 bit)
  • NVRAM: small amount of freely programmable memory
  • I/O interface
  • PC Client: Low-Pin Count (LPC) bus
  • Embedded: I2C or System Management Bus (SMBus)
slide-16
SLIDE 16

Trusted Platform Module, Dries Schellekens, COSIC Slide 16

Integration of TPM into PC platform

Central Processing Unit (CPU) Super I/O Graphics Memory Controller Hub (GMCH) I/O Controller Hub (ICH) Graphics Controller System Memory USB Devices Expansion Cards Hard Disk Network Interface Floppy PS/2 Parallel Port BIOS Flash TPM

FSB LPC

Serial Port

LPC = Low Pin Count FSB = Front Side Bus

slide-17
SLIDE 17

Trusted Platform Module, Dries Schellekens, COSIC Slide 17

TCG functionality

  • Authenticated boot
  • Logging of boot sequence
  • Remote attestation
  • Report boot sequence to third party
  • User management
  • Balance the interest of different parties (user, owner, …)
  • Key management
  • Maintain cryptographic keys and control usage/access
  • Sealed storage: restrict access based on specific boot

sequence

  • Other features
  • RNG, clock, monotonic counter, …
slide-18
SLIDE 18

Trusted Platform Module, Dries Schellekens, COSIC Slide 18

Authenticated boot

  • Synonym: measured boot or trusted boot
  • Transitive chain of trust

CRTM BIOS Boot Loader Operating System Application TPM PCR SML 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

1 2 3 4

PCR = Platform Configuration Register SML = Stored Measurement Log 12 65 49 98

slide-19
SLIDE 19

Trusted Platform Module, Dries Schellekens, COSIC Slide 19

Difference with secure boot

  • Secure boot
  • Boot process is halted when untrusted software is loaded
  • Only execute code that is signed by the device manufacturer
  • r a certified software vendor
  • Examples: game consoles, smart phones, TV settop box
  • Authenticated boot
  • TPM is passive and only records the boot process
  • Platform can still load arbitrary software, like with a traditional
  • pen platform (e.g., PC)
  • Enforcement of “good” configurations has to be done

separately

  • 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
slide-20
SLIDE 20

Trusted Platform Module, Dries Schellekens, COSIC Slide 20

Remote attestation

  • Remote attestation: challenge-response protocol
  • TPM identities
  • Endorsement Key (EK): uniquely identifies TPM
  • Attestation Identity Key (AIK): pseudonym

nonce certAIK, SignAIK(nonce, PCR), SML Verifier CertEK, AIK EncEK(certAIK) Privacy CA

slide-21
SLIDE 21

Trusted Platform Module, Dries Schellekens, COSIC Slide 21

Direct anonymous attestation (DAA)

  • TPM may have multiple AIKs
  • Best case: different AIK for every service provider
  • Practical issues with Privacy CA
  • Trusted third party is hard to find and expensive to maintain
  • Evidence: no commercial privacy CA at the moment
  • Privacy CA can link pseudonyms
  • TPM 1.2 defines alternative solution to certify AIKs
  • Direct Anonymous Attestation: zero knowledge protocol
  • Unlinkability of TPM transactions
  • No privacy CA needed
  • TPMs can only be recognized if
  • Their internal DAA secrets are exposed
  • They try to identify too often in a short period
slide-22
SLIDE 22

Trusted Platform Module, Dries Schellekens, COSIC Slide 22

Key management

  • Non-volatile memory of TPM is limited in size
  • TPM only stores two permanent cryptographic keys
  • Endorsement Key (EK): unique RSA en-/decryption key
  • 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
slide-23
SLIDE 23

Trusted Platform Module, Dries Schellekens, COSIC Slide 23

TPM key hierarchy

  • External TPM keys must be loaded in a key slot by the

TSS before they can be used

EK SRK StorK BindK TPM External storage SignK AIK AIK StorK SignK BindK SymK SymK File File File

  • Unlimited amount of keys

can be stored externally

  • Storage keys (StorK) protect
  • ther 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

slide-24
SLIDE 24

Trusted Platform Module, Dries Schellekens, COSIC Slide 24

Key types and attributes

  • Most important key types
  • Attestation identity keys: used for remote attestation
  • Pseudonyms for EK
  • 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
  • Password protected
  • Migratable, non-migratable, or certified
  • Bound to specific PCR value (known as sealed storage)
slide-25
SLIDE 25

Trusted Platform Module, Dries Schellekens, COSIC Slide 25

User management

  • Access to certain operations/keys requires authentication
  • Two ways to authenticate to the TPM
  • 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
  • Home environment: user and owner are the same entity
  • TPM only becomes fully functional after “take ownership”

command

  • Owner sets owner authentication secret (encrypted with EK)
  • This command clears the TPM and generates new SRK
slide-26
SLIDE 26

Beyond TPMs

slide-27
SLIDE 27

Trusted Platform Module, Dries Schellekens, COSIC Slide 27

Problem statement

  • Applications
  • Online banking: honest user, but malware present
  • Multiplayer game: dishonest user
  • Remote access to corporate network
  • Digital rights management: dishonest user
  • Enterprise rights management
  • Does TC enable to remotely detect man-in-the-browser?
  • Yes, but …

transfer €50 to Bob transfer €1000 to Criminal

slide-28
SLIDE 28

Trusted Platform Module, Dries Schellekens, COSIC Slide 28

Shortcomings of TCG attestation

  • Criticism on TCG attestation
  • Privacy issue: verifier gets too detailed information
  • Risk for discrimination of certain platforms (e.g., Linux)
  • Attestation of individual programs is challenging
  • What should be measured? Executable image, shared libraries,

sensitive arguments, configuration files, …

  • Scalability issues
  • Measurement log can become very long
  • 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
  • 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, ….

slide-29
SLIDE 29

Trusted Platform Module, Dries Schellekens, COSIC Slide 29

Concept of trusted virtualization layer

  • In a nutshell
  • 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
  • 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
slide-30
SLIDE 30

Trusted Platform Module, Dries Schellekens, COSIC Slide 30

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

  • Integrity of hypervisor can be measured and recorded in the

TPM using a special processor instruction (SENTER/SKINIT)

  • 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

slide-31
SLIDE 31

Trusted Platform Module, Dries Schellekens, COSIC Slide 31

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
  • perating system it is rather useless
  • The addition of a TPM does not automagically make a

platform more secure

  • Practical deployment of TC technology is more challenging than

expected

  • 500+ million TPMs have been sold, but most are rarely used
  • Best known TPM application: Microsoft Bitlocker disk

encryption

  • Windows 8 has much more extensive TPM support (including

authenticated boot process) than previous versions

slide-32
SLIDE 32

Trusted Platform Module, Dries Schellekens, COSIC Slide 32

Main changes in TPM 2.0

  • More flexible command set
  • TPM 1.2 specification was focused on PC(-like) platform.
  • Dedicated MTM specification was needed for mobile phone,

making mandatory TPM 1.2 features optional.

  • TPM 2.0 is “library specification” that will be used as the

basis for the creation of platform-specific TPM specifications.

  • Algorithm agility
  • TPM 1.x: only RSA and SHA-1
  • 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
slide-33
SLIDE 33

Trusted Platform Module, Dries Schellekens, COSIC Slide 33

Additional reading material

  • http://www.trustedcomputinggroup.org
  • Books