information security – theory vs. reality 0368-4474-01, winter 2013-2014 lecture 11: trusted...

27
1 Information Security – Theory vs. Reality 0368-4474-01, Winter 2013-2014 Lecture 11: Trusted computing architecture Eran Tromer Slides credit: Dan Boneh, Stanford

Upload: lilah

Post on 26-Feb-2016

38 views

Category:

Documents


0 download

DESCRIPTION

Information Security – Theory vs. Reality 0368-4474-01, Winter 2013-2014 Lecture 11: Trusted computing architecture. Eran Tromer Slides credit: Dan Boneh , Stanford. Fully homomorphic encryption: discussion. Assumptions Mathematical Adversarial model Applicability - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Information Security – Theory vs. Reality  0368-4474-01, Winter 2013-2014 Lecture 11: Trusted computing architecture

1

Information Security – Theory vs. Reality

0368-4474-01, Winter 2013-2014

Lecture 11:Trusted computing architecture

Eran TromerSlides credit: Dan Boneh, Stanford

Page 2: Information Security – Theory vs. Reality  0368-4474-01, Winter 2013-2014 Lecture 11: Trusted computing architecture

2

Fully homomorphic encryption: discussion

• Assumptions– Mathematical– Adversarial model

• Applicability– Who dies decryption? Does it leak? Where are keys stored?

• Intreraction– FHE addresses the non-interactive case– If we allow interaction, secure multiparty computation offers additional

primitives, constructions and (in some cases) much better performance

• What about integrity?– (later…)

2

Page 3: Information Security – Theory vs. Reality  0368-4474-01, Winter 2013-2014 Lecture 11: Trusted computing architecture

3

Motivation

Virtual machine confinement:a blessing or a curse?

Page 4: Information Security – Theory vs. Reality  0368-4474-01, Winter 2013-2014 Lecture 11: Trusted computing architecture

4

Subvirt [King Chen Wang Verbowski Wang Lortch 2006]

• Virus idea:• Once on the victim machine, install a malicious

VMM• Virus hides in VMM• Invisible to virus detector running inside VM

HW OS

HW

OS VMM and virus

Anti-virus

Anti-virus

Page 5: Information Security – Theory vs. Reality  0368-4474-01, Winter 2013-2014 Lecture 11: Trusted computing architecture

5

The MATRIX

Page 6: Information Security – Theory vs. Reality  0368-4474-01, Winter 2013-2014 Lecture 11: Trusted computing architecture

6

Page 7: Information Security – Theory vs. Reality  0368-4474-01, Winter 2013-2014 Lecture 11: Trusted computing architecture

7

VM Based Malware (blue pill virus) [Rutkowska 2006]

• A virus that installs a malicious VMM (hypervisor) on-the-fly under running OS

• Use SVM/VT-x to create VM• Microsoft Security Bulletin: (Oct, 2006) :

Suggests disabling hardware virtualization features by default for client-side systemshttp://www.microsoft.com/whdc/system/platform/virtual/CPUVirtExt.mspx

• VMBRs are easy to defeat• A guest OS can detect that it is running on top

of VMM

Page 8: Information Security – Theory vs. Reality  0368-4474-01, Winter 2013-2014 Lecture 11: Trusted computing architecture

8

VMM Detection• Can an OS detect it is running on top of a VMM?• Applications:

• Virus detector can detect VMBR• Normal virus (non-VMBR) can detect VMM

• refuse to run to avoid reverse engineering• Software that binds to hardware (e.g. MS Windows)

can refuse to run on top of VMM

• DRM systems may refuse to run on top of VMM

Page 9: Information Security – Theory vs. Reality  0368-4474-01, Winter 2013-2014 Lecture 11: Trusted computing architecture

9

VMM detection (red pill techniques)

1. VM platforms often emulate simple hardware• VMWare emulates an ancient i440bx chipset

… but report 8GB RAM, dual Opteron CPUs, etc.

2. VMM introduces time latency variances• Memory cache behavior differs in presence of

VMM• Results in relative latency in time variations

for any two operations3. VMM shares the TLB with GuestOS

• GuestOS can detect reduced TLB size4. Deduplication (VMM saves single copies of identical

pags)

… and many more methods [GAWF’07]

Page 10: Information Security – Theory vs. Reality  0368-4474-01, Winter 2013-2014 Lecture 11: Trusted computing architecture

10

VMM DetectionBottom line: The perfect VMM does not exist

• VMMs today (e.g. VMWare) focus on:Compatibility: ensure off the shelf software

worksPerformance: minimize virtualization

overhead

• VMMs do not provide transparency• Anomalies reveal existence of VMM

Page 11: Information Security – Theory vs. Reality  0368-4474-01, Winter 2013-2014 Lecture 11: Trusted computing architecture

11

Trusted Computing Architecture

Page 12: Information Security – Theory vs. Reality  0368-4474-01, Winter 2013-2014 Lecture 11: Trusted computing architecture

12

BackgroundTCG consortium. Founded in 1999 as TCPA. Main players (promotors): (>200

members) AMD, HP, IBM, Infineon, Intel, Lenovo, Microsoft, Sun

Goals: Hardware protected (encrypted)

storage: Only “authorized” software can decrypt

data e.g.: protecting key for decrypting file

system Secure boot: method to “authorize”

software Attestation: Prove to remote server what

software is running on my machine.

Page 13: Information Security – Theory vs. Reality  0368-4474-01, Winter 2013-2014 Lecture 11: Trusted computing architecture

13

Secure bootHistory of BIOS/EFI malware:

CIH (1998): CIH virus corrupts system BIOS Heasman (2007):

System Management Mode (SMM) “rootkit” via EFI

Sacco, Ortega (2009): infect BIOS LZH decompressor CoreBOOT: generic BIOS flashing tool

Main point: BIOS runs before any defenses (e.g. antivirus)

Proposed defense: lock system configuration (BIOS + OS)

Today: TCG approach

Page 14: Information Security – Theory vs. Reality  0368-4474-01, Winter 2013-2014 Lecture 11: Trusted computing architecture

14

TCG: changes to PCExtra hardware: TPM Trusted Platform Module (TPM) chip

Single 33MhZ clock. TPM Chip vendors: (~.3$)

Atmel, Infineon, National, STMicro Intel D875GRH motherboard

Software changes: BIOS, EFI (UEFI) OS and Apps

Page 15: Information Security – Theory vs. Reality  0368-4474-01, Winter 2013-2014 Lecture 11: Trusted computing architecture

15

TPMs in the real worldTPMs widely available on laptops, desktops and some servers

Software using TPMs: File/disk encryption: BitLocker, IBM, HP,

Softex Attestation for enterprise login: Cognizance,

Wave Client-side single sign on: IBM, Utimaco, Wave

Page 16: Information Security – Theory vs. Reality  0368-4474-01, Winter 2013-2014 Lecture 11: Trusted computing architecture

TPM Basics

What the TPM does How to use it

16

Page 17: Information Security – Theory vs. Reality  0368-4474-01, Winter 2013-2014 Lecture 11: Trusted computing architecture

17

Components on TPM chip

I/O

Crypto Engine:RSA, SHA-1, HMAC, RNG

Non Volatile Storage

(> 1280 bytes)PCR Registers(16 registers)

OtherJunk

RSA: 1024, 2048 bit modulusSHA-1: Outputs 20 byte digest

LPCbus

API calls

Page 18: Information Security – Theory vs. Reality  0368-4474-01, Winter 2013-2014 Lecture 11: Trusted computing architecture

18

Non-volatile storage1. Endorsement Key (EK) (2048-bit RSA)

Created at manufacturing time. Cannot be changed.

Used for “attestation” (described later)2. Storage Root Key (SRK) (2048-bit RSA)

Used for implementing encrypted storage Created after running

TPM_TakeOwnership( OwnerPassword, … ) Can be cleared later with TPM_ForceClear from

BIOS3. OwnerPassword (160 bits) and persistent

flagsPrivate EK, SRK, and OwnerPwd never leave the

TPM

Page 19: Information Security – Theory vs. Reality  0368-4474-01, Winter 2013-2014 Lecture 11: Trusted computing architecture

19

PCR: the heart of the matter

PCR: Platform Configuration Registers Lots of PCR registers on chip (at least 16) Register contents: 20-byte SHA-1 digest

(+junk)

Updating PCR #n : TPM_Extend(n,D): PCR[n] SHA-1 ( PCR[n] || D

) TPM_PcrRead(n): returns value(PCR(n))

PCRs initialized to default value (e.g. 0) at boot time

TPM can be told to restore PCR values in NVRAM via TPM_SaveState and TPM_Startup(ST_STATE)

for system suspend/resume

Page 20: Information Security – Theory vs. Reality  0368-4474-01, Winter 2013-2014 Lecture 11: Trusted computing architecture

20

Using PCRs: the TCG boot process

BIOS boot block executes Calls TPM_Startup (ST_CLEAR) to initialize PCRs

to 0 Calls PCR_Extend( n, <BIOS code> ) Then loads and runs BIOS post boot code

BIOS executes: Calls PCR_Extend( n, <MBR code> ) Then runs MBR (master boot record), e.g.

GRUB.MBR executes: Calls PCR_Extend( n, <OS loader code,

config> ) Then runs OS loader … and so on

Page 21: Information Security – Theory vs. Reality  0368-4474-01, Winter 2013-2014 Lecture 11: Trusted computing architecture

21

In a diagram

BIOS boot block

BIOS OS loader OS Application

TPM

Hardware

Root of trust in integrity measurement

Root of trust in integrity reporting

measuringExtend PCR

• After boot, PCRs contain hash chain of booted software• Collision resistance of SHA-1 ensures commitment

Page 22: Information Security – Theory vs. Reality  0368-4474-01, Winter 2013-2014 Lecture 11: Trusted computing architecture

22

Example: Trusted GRUB (IBM’05)

What PCR # to use and what to measure specified in GRUB config file

Page 23: Information Security – Theory vs. Reality  0368-4474-01, Winter 2013-2014 Lecture 11: Trusted computing architecture

23

Using PCR values after boot

Application 1: encrypted (a.k.a sealed) storage.

Step 1: TPM_TakeOwnership( OwnerPassword, … ) Creates 2048-bit RSA Storage Root Key (SRK) on

TPM Cannot run TPM_TakeOwnership again without

OwnerPwd: Ownership Enabled Flag False

Done once by IT department or laptop owner.

(optional) Step 2: TPM_CreateWrapKey / TPM_LoadKey Create more RSA keys on TPM protected by SRK Each key identified by 32-bit keyhandle

Page 24: Information Security – Theory vs. Reality  0368-4474-01, Winter 2013-2014 Lecture 11: Trusted computing architecture

24

Protected StorageMain Step: Encrypt data using RSA key on TPM TPM_Seal (some) Arguments:

keyhandle: which TPM key to encrypt with KeyAuth: Password for using key

`keyhandle’ PcrValues: PCRs to embed in encrypted blob data block: at most 256 bytes (2048 bits)

Used to encrypt symmetric key (e.g. AES) Returns encrypted blob.

Main point: blob can only be decrypted with TPM_Unseal when PCR-reg-vals = PCR-vals in blob. TPM_Unseal will fail othrwise

Page 25: Information Security – Theory vs. Reality  0368-4474-01, Winter 2013-2014 Lecture 11: Trusted computing architecture

25

Protected Storage

Embedding PCR values in blob ensures that only certain apps can decrypt data. e.g.: Messing with MBR or OS kernel will

change PCR values.

Page 26: Information Security – Theory vs. Reality  0368-4474-01, Winter 2013-2014 Lecture 11: Trusted computing architecture

26

Sealed storage: applications

Lock software on machine: OS and apps sealed with MBR’s PCR. Any changes to MBR (to load other OS) will

prevent locked software from loading. Prevents tampering and reverse engineering

Web server: seal server’s SSL private key Goal: only unmodified Apache can access SSL

key Problem: updates to Apache or Apache config

General problem with software upgrades/patches:Upgrade process must re-seal all blobs with new PCRs

Page 27: Information Security – Theory vs. Reality  0368-4474-01, Winter 2013-2014 Lecture 11: Trusted computing architecture

27

A cloud application

Client seals VM to VMM measurement VM code and data is encrypted Can only be decrypted on valid cloud server Cloud operator cannot easily access data

cloudservers

VMMTPM

VMMTPM

ClientVM

sealedto VMM