View
214
Download
0
Embed Size (px)
Citation preview
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