Transcript 16-0 Trusted Computing

Trusted Computing
Adapted from V. Shmatikov
slide 1
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 2
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 3
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 4
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 5
High-Level View
[LaMacchia]
App
User
Kernel
OS
 Challenge: how to preserve security when pluggable
kernel components control the machine?
• While keeping flexibility and extensibility of modern OS
• No “closed-box” solutions
slide 6
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, tamperproof key storage
slide 7
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 8
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 9
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 10
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 11
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 12
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 13
Pre-OS Boot Process
BIOS boot block
[slide stolen from Lucky Green]
TPM
BIOS
Store hash
Option
ROMs
Store hash
DRM
boot
loader
Store hash
DRM kernel
Store hash
slide 14
OS Boot Process
[slide stolen from Lucky Green]
TPM
OS
Approved
Hardware
List (HCL),
Serial
Number
Revocation
List (SRL)
Load OS
OS is running
Store hash
AES
decrypt
OS binary
RSA
decrypt OS
binary key
Phase II:
inside TPM
slide 15
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 16
Secure Loading
Protection Mode
Mandatory
Voluntary
OS 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 17
Application Tasks
Application
is loaded
Verify
hashes in
TPM
Verify
platform
ID
[slide stolen from Lucky Green]
Verify
license
duration
DRL
Servers
DRL
Servers
SRL
Server
Obtain
fresh SRL
Verify
mandatory
applications are
running
Obtain fresh
Document
Revocation
List (DRL)
Application
is ready
for user
slide 18
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 19
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 20
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 21
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 22
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 23
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 24
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
slide 25