slide 1

Adapted from V. Shmatikov

Trusted Computing

slide 2

Why Are Systems Insecure?

Commodity OS are too complex to build secure applications upon

Commodity OS poorly isolate applications Only weak mechanisms for authentication,

making secure distributed applications difficult

No trusted path between users and programs

slide 3

Idea: Trusted Computing

Minimal trusted computing base• Implemented in a tamper-resistent hardware chip

Provides basic security capabilities• Sealed storage• Attestation• Curtained memory• Secure input and output

“Bootstrap” security from kernel to applications• Prevent malicious code from running in the kernel• Remotely “attest” that you are running a particular

software stack (from OS to applications)

slide 4

Business Objectives

Prevent use of unlicensed software Digital rights management (DRM)

• Prevent execution of unlicensed applications• Idea: before a streaming service releases music

for your computer, you must prove that there is no ripping software running in your execution environment

– “Remote attestation”

Law enforcement and intelligence “The mother(board) of all Big Brothers”

- Lucky Green

slide 5

Trusted Computing Group

Founded in 1999, evolved since then Core members

• AMD, HP, IBM, Intel, Microsoft, Sun

Who’s Who of product vendors• ARM, Dell, Phoenix, VeriSign, RSA, Texas

Instruments, Maxtor, Seagate, National Semi, Toshiba, France Telecom, Fujitsu, Adaptec, Philips, Ricoh, Nvidia

http://www.trustedcomputinggroup.org

slide 6

High-Level View [LaMacchia]

Challenge: how to preserve security when pluggable kernel components control the machine?• While keeping flexibility and extensibility of modern OS• No “closed-box” solutions

App

OS

User

Kernel

slide 7

Idea: Use Hardware

“Trusted Platform Module” (TPM)• “Smartcard soldered to motherboard”• Cheap, fixed-function, tamper-proof hardware device

– Contains at least an AES key and an RSA key pair– Registers to store the hash of the currently running OS and

maybe applications (“platform configuration register”)

Must be close to the chipset• Involved in OS initialization; can’t be a real smartcard

Contains other security capabilities• Pseudo-random generator, other crypto ops, tamper-

proof key storage

slide 8

TPM Internals

Endorsement key• Unique RSA key generated at time of manufacture

– Signed by manufacturer’s key, proves that the TPM is genuine

Tamper-resistant store for keys and hash values• Includes one or more user RSA keys

– Certified by “Privacy CA” when TPM is activated, identifies user

Cryptographic operations• Hashing (SHA-1, HMAC), pseudo-random generation,

asymmetric key generation, encryption and decryption (2048-bit RSA), symmetric encryption and decryption (3DES, AES)

slide 9

What Does This Provide?

Separate protected execution environment for applications that need higher security• Hardware-based memory isolation

Privileged cryptographic services for these apps

Applications can be standalone or provide services to other applications

Big idea: “project trust” into the main OS

slide 10

Core Features

Strong process isolation Root key for persistent secret protection Secure path to and from the user

• These protect against malicious code

Interesting feature: remote attestation • Facts about services, machines, software

running on these machines can be proved to (and believed by) remote entities

slide 11

Code Identity

In the trusted computing model, the host always knows what code is running on it• Can assign access rights to code identities

Booting kernel causes its hash to be computed and stored in a read-only, tamper-proof register• “Platform configuration register” (PCR)

Kernel recursively provides similar features for “notarized” applications executing on the system• Can think of code hash as its identity

slide 12

Bootstrapping Trust Chain

Secret key is embedded in hardware, signed (certified) by hardware vendor

Hardware certifies firmware Firmware certifies boot loader Boot loader certifies OS OS certifies applications, virtual machines,

etc.

slide 13

Certification

A component wanting to be certified… … generates public/private key … makes ENDORSE API call to lower level

component Lower level component generates and

signs a certificate containing:• SHA-1 hash of attestable parts of higher

component• Higher component’s public key and application

data

slide 14

TPM

Pre-OS Boot Process [slide stolen from

Lucky Green]

BIOS boot block

BIOS Store hash

OptionROMs

Store hash

DRM boot

loaderStore hash

DRM kernel Store hash

slide 15

OS Boot Process [slide stolen from Lucky Green]

Phase II: inside TPM

TPM

OS Store hash

RSA decrypt

OS binary key

AES decrypt

OS binary

Load OS

Approved Hardware List (HCL),

Serial Number

Revocation List (SRL)

OS is running

slide 16

OS Initial State and Tasks

Approved BIOS Approved PCI cards No unapproved access to operating RAM Initial OS tasks

• Start secure time counter– Can’t rollback system clock

• Synchronize system time with authenticated online time servers

• Obtain HCL and SRL updates over the Internet

slide 17

Secure Loading

Protection Mode Mandatory VoluntaryOS hashes application, stores hash in TPM

YES YES

OS loads approved applications not listed on an SRL

YES YES

OS loads application on SRL NO NO

OS loads non-approved application

NO YES. TCP applications receive SIGCOMP, zero-out their operating RAM, and shut down.

slide 18

Application Tasks [slide stolen from Lucky

Green]

Application is loaded

Verify hashes in TPM

Verify platform ID

Verify license

duration

Obtain fresh SRL

Verify mandatory applications are running

Obtain fresh

Document Revocation List (DRL)

SRL Server

DRL Server

s

DRL Server

s

Application is

ready for user

slide 19

Sealed Storage

Allows software to keep long-lived secrets safe from other software running on the host• OS can keep secrets from other OSes• Applications can use this to keep their own secrets

The hash value stored in the PCR can tag encrypted secrets with the identity of the code that owns them• Owners of secrets can also designate alternate

recipients (necessary for update and migration)

slide 20

Attestation

Goal: prove your local state to remote entities• Local state: operating system, applications

Remote entity (e.g., digital content provider) can request attestation of state via the Internet

What can be proved?• Platform is in an approved configuration

– Owner of machine doesn’t have privileged access to CPU

• OS and applications fully licensed with maintenance fees paid

• OS and applications have not been modified• Only approved applications are loaded

slide 21

Attestation Example

Remote server verifies…• Hardware vendor’s certificate• All hashes in the certificate chain are in

remote server’s list of authorized software• Hash of virtual machine’s attested storage is

on list of authorized applications – For example, check that valid version of Quicken is

running

slide 22

Document Revocation

Application may query Document Revocation List servers for the latest DRLs

Why may a document end up on a DRL?• Created by a compromised or unpaid copy of

the application• Mandated by court order: Official Secrets Act,

copyrighted material, danger to Homeland Security

• Locally illegal content• Many other reasons

slide 23

Secure Input and Output

Isolation, sealed storage and attestation aren’t enough to keep secrets safe

Users can be fooled into thinking they’re talking to a trusted system when they’re not

I/O channels must be protected from sniffing• Keyboard, frame buffer, etc.

Protected path between user and application

slide 24

Privacy Issues

Each trusted machine has sets of unique AES and RSA hardware keys• Unique identifiers, may be used to track user

behavior

Basic approach: opt-in• User designates what software can access the

sealed storage and authentication functions that use the keys

Authentication key disclosure strictly controlled• Access to the RSA public key components is

restricted• Only one export of the RSA public key per power

cycle

slide 25

Pseudo-Identities

If every party I communicate with needs my hardware RSA public key to encrypt some info for me, the key becomes a platform ID

Solution: pseudo-identity• Generate a temporary RSA key pair• Use hardware key once to certify the pseudo-

identity key, then just use the pseudo-identity keys

Need a third-party certification authority (“Privacy CA”) for certifying temporary keys