Comments
Description
Transcript
Document 1359342
9/28/15 6. Trustworthy Compu0ng ENEE 757 | CMSC 818V Prof. Tudor Dumitraș Assistant Professor, ECE University of Maryland, College Park http://ter.ps/757 https://www.facebook.com/SDSAtUMD Today’s Lecture • Where we’ve been – Crypto basics – OS protecHon mechanisms – Network security • Where we’re going today – Trusted compuHng • Where we’re going next – Guest lecture: Ksenia Dmitrieva, Cigital – Password storage – Next week: Password security 2 1 9/28/15 A Note on Cri0que Submissions • Pay aQenHon to assignment numbers – 10 + number of criHque .bib files so far • <PATH>/submit 2015 fall <COLLEGE> <COURSE> 0101 11 os_protection_mechanisms.bib • <PATH>/submit 2015 fall <COLLEGE> <COURSE> 0101 12 network_security_basics.bib • <PATH>/submit 2015 fall <COLLEGE> <COURSE> 0101 13 trustworthy_computing.bib • <PATH>/submit 2015 fall <COLLEGE> <COURSE> 0101 14 passwords.bib • Use course-‐specific submit (instead of the general GRACE submit) – /afs/glue.umd.edu/class/fall2015/enee/757/0101/bin/submit <PATH> – Parses your submission and leaves a copy in your home dir 3 Who Can You Trust? ApplicaHon I wonder what Tudor’s SSN is … Request O/S WorkstaHon Keyboard/display channel NFS Server O/S Network channel Server • Where is the request “from”? – The user? The workstaHon? The applicaHon? The network channel? All of the above? – Which of these actors do you trust? 4 2 9/28/15 Trusted Compu0ng Base (TCB) • TCB = the collecHon of hardware and soeware that security depends on – Thus, TCB should be as small as possible • Must be carefully tested, analyzed and protected – “Trust” is something that is bad and must be avoided when possible • Trusted components may operate alongside untrusted components – Example: you cannot trust every host connected to the Internet • A trustworthy system or component is one that will not fail – “Fail secure” or “fail safe”: abort operaHon when uncertain where the request or inputs com from – “Trusted compuHng” really means “trustworthy compuHng” 5 Trusted Compu0ng Group (TCG) • Historically, PC manufacturers have chosen flexibility over security – User can modify the PC in any way she likes – PC does not have hardware protecHon for boot procedure, does not validate O/S before loading it, does not validate other programs • Today this is changing with efforts like the Trusted CompuHng Group (TCG) – www.trustedcomputinggroup.org – Alliance formed in Jan 1999 by Compaq, HP, IBM, Intel & Microsoe – More than 150 companies by 2002 – Developing a standard for a “trusted plaYorm” (TP) – Scope of specs is at hardware, O/S and BIOS levels • Main spec released in Aug 2000 (v1.0) and Feb 2001 (v1.1) • PC-‐specific spec released in Sep 2001 6 3 9/28/15 Trusted PlaYorms • Some goals of TP – Enable local and remote users to obtain reliable informaHon about the soeware running on the planorm – Provide a basis for secure key storage – Enable condiHonal release of secret informaHon to the TP based on the soeware running • TP enabled by a “trusted processing module” (TPM) – A hardware processing component that is isolated from soeware aQacks and at least parHally resistant to hardware tampering • Each TPM is equipped with a different private key K-‐1TPM – And a cerHficate signed by the manufacturer (more on this later) 7 TCG “Roots of Trust” The standard specifies two logical “roots of trust” • Root of trust for measurement (RTM): A planorm-‐dependent component that starts measurement of soeware running – Measurements are hashes of the planorm state (e.g. applicaHons started & configuraHon files used) – In pracHce, this means that the RTM must run first (or everything that is run before it is trusted) • e.g., BIOS boot block, called the “core root of trust for measurement” (CRTM) • Root of trust for repor0ng (RTR): A planorm-‐independent component that stores measurements as they happen, in such a way that measurements cannot be undone – RTR is implemented by the TPM 8 4 9/28/15 TPM PlaYorm Configura0on Registers • TPM (version 1.1) contains sixteen 20-‐byte plaYorm configura0on registers (PCRs) – 20 bytes in order to store a SHA-‐1 hash value • Each PCR records the last in a chain of hashes of the soeware that has been loaded and executed software 001011 101101 load software 001011 101101 • PCR is updated before newly loaded soeware gets control – This is called extending the PCR h( ) PCR h( ) • PCR cannot be erased except by reboot (or SKINIT / GETSEC[SENTER] instrucHon in v1.2 TPMs) • In this way, PCR contains record of soeware running 9 TCG Authen0cated Boot BIOS boot block (CRTM) BIOS 001011 101101 h( ) h( ) PCR 0 PCR 1 ROMS 001011 101101 OS loader 001011 101101 OS components OS 001011 101101 h( ) h( ) h( ) PCR 2 PCR 3 PCR 4 001011 001011 101101 101101 h( ) 10 5 9/28/15 TCG Secure Boot • Non-‐volaHle “data integrity registers” (DIRs) are loaded with expected PCR values – DIRs are contained within TPM and require owner authorizaHon to write • If a PCR value, when computed, doesn’t match corresponding DIR value, then boot is canceled 11 TCG Integrity Challenge and Response • Remote machine can query TPM for contents of PCRs • TPM responds with signed PCR values – Signed with AQestaHon IdenHficaHon Key (AIK) K-‐1AIK – The AIK pair is generated by the TPM • The AIK is endorsed by a cerHficaHon authority • TP addiHonally responds with records (hints) of what is “summarized” in the PCR values – Records could contain soeware itself, but more likely contains name, supplier, version, and URL for soeware – Enables remote machine to reconstruct and check PCR values – Records not trusted and so are stored outside TPM • This is called remote abesta0on 12 6 9/28/15 TPM Sealed Storage • Data encrypted with RSA key stored in the TPM – Slow public-‐key crypto • TPM seal: bind data to current soeware state – Content of PCRs is encrypted along with the data • TPM unseal: decrypt the sealed data – TPM will decrypt the data only if the PCRs contain the same values – Ensures that encrypted data can be trusted • ApplicaHons: – Full Disk EncrypHon (FDE) – Digital Rights Management (DRM) 13 Full Disk Encryp0on: BitLocker Architecture • Sta0c root of trust: measurements of early boot components PreOS Static OS All Boot Blobs unlocked Volume Blob of Target OS unlocked TPM Init BIOS MBR BootSector BootBlock BootManager OS Loader Start OS 14 7 9/28/15 Disk Layout and Key Storage Opera0ng System Volume Where’s the Encryp0on Key? Contains 1. SRK (Storage Root Key) contained in TPM • Encrypted OS 2. SRK encrypts the VMK (Volume Master Key) • Encrypted page file 3. VMK encrypts FVEK (Full Volume EncrypHon Key) – used for the actual data encrypHon • Encrypted temp files • Encrypted data 4. FVEK and VMK are stored encrypted on the Opera0ng System Volume • Encrypted hibernaHon file Operating System 4 Volume 2 3 1 System • • • 15 Abacks Against Sogware FDE [Halderman et al., 2008] • Cold boot aQack on secrets in memory • DRAM does not immediately lose its value upon power-‐off • This can be used to extract BitLocker keys if done skillfully 16 8 9/28/15 Ager 5 seconds Source: Lest We Remember: Cold Boot Attacks on Encryption Keys. J. 17 Alex Halderman et al. 2008 USENIX Security Symposium Ager 30 seconds 18 9 9/28/15 Ager 60 seconds 19 Ager 5 minutes 20 10 9/28/15 Late Launch (TPM v. 1.2) • Sta0c root of trust: must reboot to restart measurement • Dynamic root of trust (late launch): properHes similar to reboot – Without a reboot! – Removes many things from TCB • BIOS, boot loader, DMA-‐enabled devices, … • Long-‐running OS and Apps if done right • Modern CPUs provide special instrucHons that interact with TPM chip – AMD SVM: SKINIT instrucHon – Intel TXT: GETSEC[SENTER] instrucHon • IniHal intent: virtualizaHon support – Virtual machine monitor (VMM) can be measured (MVMM) – Integrity of loaded code can be aQested – Untrusted legacy OS can coexist with trusted soeware 21 Mo0va0ng Example: OPM Data Breach • Ongoing remote aQack against Office of Personnel Management (OPM) detected in April 2015 – Data of 4.2 million Federal government employees stolen – Including security clearance invesHgaHons – Hackers gained valid credenHals to the OPM systems => full disk encrypHon would not have prevented the data breach • What if… – A compromised OS cannot learn the sensiHve data – Only essenHal code can access the data • Decrypt stored data • Update it • Encrypt it back • Report result of operaHon – Can remotely verify this is so 22 11 9/28/15 Flicker Discussion 23 Is Flicker Enough? Social networking service I wonder who are Tudor’s friends … ApplicaHon O/S Web framework AQestaHon WorkstaHon Web server Network driver • Many components manipulate user data – Want to reason about security properHes based on all these components • Web applicaHons evolve – Cannot expect clients to know the most recent hash • Logical aQestaHon (Nexus) – Uses authorizaHon logic (more on this later) 24 12 9/28/15 Review: Security Principles [J. Saltzer & M. Schroeder, SOSP 1973] • Economy of mechanism: Keep the protec0on mechanism as simple and small as possible • Fail-‐safe defaults: Base access decisions on permission rather than exclusion • Complete media0on: Check every access to every object • Open design: Do not keep the design secret • Separa0on of privilege: Require two keys to unlock, not one • Least privilege: Grant every program/user the least set of privileges necessary to complete the job • Least common mechanism: Minimize the amount of mechanism common to more than one user and depended on by all users – This principle talks about confinement • Psychological acceptability: Design interfaces for ease of use • Work factor: Increase the cost of circumvenHng the protecHon mechanism, compared to the aQacker’s resources • Compromise recording: reliably detect that a compromise has occurred 25 Review of Lecture • What did we learn? – Trusted Planorm Module (TPM) – Remote aQestaHon – Sealed storage • Sources – Mike Reiter, Jonathan McCune • What’s next? – Guest lecture: Ksenia Dmitrieva, Cigital • Deadline reminders – Pilot project reports due in one week 26 13 9/28/15 27 Backup slides 28 14 9/28/15 Soeware Engineering & Programming Languages: Bootstrapping Trust: What F will this machine compute? Does program P compute F? Is F what the programmer intended? Bootstrapping Trust What F will this machine compute? XOther YOther F XAlice YAlice 29 Bootstrapping Trust is Hard! Challenges: • Hardware assurance • Ephemeral soeware • User InteracHon App App App App App App 2 3 1 4 5 N Module 1 Module 3 OS Safe? Yes! S15 ) ) 1( ( 2 3 4 5 6 7 8 9 10 11 12 13 14 Module Module 2 4 ^ H( ) 30 15 9/28/15 Bootstrapping Trust is Hard! Challenges: • Hardware assurance • Ephemeral soeware • User InteracHon Evil App Safe? Evil OS Yes! 31 Establish Trust in Sogware • Soeware is ephemeral • We care about the soeware currently in control • Many properHes maQer: – Proper control flow – Type safety – Correct informaHon flow App 1 … App N OS … Which property maQers most? 32 16 9/28/15 A Simple Thought Experiment • Imagine a perfect algorithm for analyzing control flow – Guarantees a program always follows intended control flow • Does this suffice to bootstrap trust? No! Respects Type Safe control flow We want code iden0ty P 33 What is Code Iden0ty? • An aQempt to capture the behavior of a program • Current state of the art is the collecHon of: – Program binary FuncHon f – Program libraries – Program configuraHon files Inputs to f – IniHal inputs • Oeen condensed into a hash of the above 34 • AQempt to capture the f computed by a program • Current state of the art is the collecHon of: – Program binary – Program libraries – Program configuraHon files 17 9/28/15 Code Iden0ty as Trust Founda0on • From code idenHty, one may be able to infer: – Proper control flow – Type safety – Correct informaHon flow … • Reverse is not true! 35 What Can Code Iden0ty Do For You? • Research applicaHons • Secure the boot process • Count-‐limit objects • Improve security of network protocols • Commercial applicaHons • Thwart insider aQacks • Protect passwords • Create a Trusted Third Party • Secure disk encrypHon (e.g., Bitlocker) • Improve network access control • Secure boot on mobile phones • Validate cloud compuHng planorms 36 18 9/28/15 Establishing Code Iden0ty [Gasser et al. ‘89], [Arbaugh et al. ‘97], [Sailer et al. ‘04], [Marchesini et al. ‘04],… YOther XOther F XAlice YAlice 37 Establishing Code Iden0ty [Gasser et al. ‘89], [Arbaugh et al. ‘97], [Sailer et al. ‘04], [Marchesini et al. ‘04],… YOther XOther f1 XAlice f2 … fN YAlice 38 19 9/28/15 Establishing Code Iden0ty [Gasser et al. ‘89], [Arbaugh et al. ‘97], [Sailer et al. ‘04], [Marchesini et al. ‘04],… Chain of Trust Root of Trust ? Soeware 1 . . . Soeware N-‐1 Soeware N 39 Secure Boo0ng Based on Code Iden0ty [Gasser et al. ‘89], [Arbaugh et al. ’97], … Root of Trust Soeware 1 . . . Soeware N-‐1 Soeware N 40 20 9/28/15 Secure Boo0ng Based on Code Iden0ty [Gasser et al. ‘89], [Arbaugh et al. ’97], … Root of Trust Kpub Soeware 1 . . . Soeware N-‐1 ✓ ✓ ✓ SW 1 SW 2 Sign K ( priv Root of Trust SW N-‐1 SW 1 Soeware Evil N Halt SW Evil . . . SW N ) 41 Local Access Control (“Sealing”) Soeware 1 SW 1 Data SW SW SW SW 1 2 N-‐1 N . . . SW 2 Soeware N-‐1 SW N-‐1 Soeware Evil N Data? SW Evil N Seal No! Data 42 21 9/28/15 Authen0cated Boot: Recording Code Iden0ty Root of [Gasser et al. ’89], [England et al. ‘03], [Sailer et al. ‘04],… Trust Soeware 1 . . . SW 2 SW 1 Soeware N-‐1 SW N-‐1 Soeware N SW N 43 Abesta0on: Conveying Records to an External En0ty [Gasser et al. ‘89], [Arbaugh et al. ‘97], [England et al. ‘03], [Sailer et al. ’04]… Soeware Soeware N-‐1 1 random # . . . Sign K ( SW priv SW 2 1 SW SW SW SW 1 2 N-‐1 N random # SW Soeware N ) N-‐1 SW N Controls Kpriv 44 22 9/28/15 Interpre0ng Code Iden0ty App 1…N Drivers 1…N TradiHonal [Gasser et al. ‘89], [Sailer et al. ‘04] Policy Enforcement [Marchesini et al. ‘04], [Jaeger et al. ’06] OS Bootloader OpHon ROMs BIOS 45 Interpre0ng Code Iden0ty TradiHonal [Gasser et al. ‘89], [Sailer et al. ‘04] Virtual Machine Policy Enforcement [Marchesini et al. ‘04], [Jaeger et al. ’06] VirtualizaHon [England et al. ‘03], [Garfinkel et al. ‘03] Virtual Machine Monitor Bootloader OpHon ROMs BIOS 46 23 9/28/15 Interpre0ng Code Iden0ty TradiHonal [Gasser et al. ‘89], [Sailer et al. ‘04] VMM Policy Enforcement Virtual Machine [Marchesini et al. ‘04], [Jaeger et al. ’06] OS Virtual Machine Monitor VirtualizaHon [England et al. ‘03], [Garfinkel et al. ‘03] Late Launch [Kauer et al. ‘07], [Grawrock ‘08] Bootloader OpHon ROMs BIOS 47 Interpre0ng Code Iden0ty TradiHonal [Gasser et al. ‘89], [Sailer et al. ‘04] Flicker Policy Enforcement [Marchesini et al. ‘04], [Jaeger et al. ’06] OS S Flicker VirtualizaHon [England et al. ‘03], [Garfinkel et al. ‘03] Late Launch [Kauer et al. ‘07], [Grawrock ‘08] Targeted Late Launch [McCune et al. ‘07] 48 24 9/28/15 Interpre0ng Code Iden0ty App 1…N Drivers 1…N OS S Flicker Bootloader OpHon ROMs BIOS 49 Load-‐Time vs. Run-‐Time Proper0es • Code idenHty provides load-‐Hme guarantees • What about run Hme? • Approach #1: StaHc transformaHon [Erlingsson et al. ‘06] Run-‐Time Policy Code Compiler Integrity Checked Code’ 50 25 9/28/15 Load-‐Time vs. Run-‐Time Proper0es • Code idenHty provides load-‐Hme guarantees • What about run Hme? • Approach #1: StaHc transformaHon [Erlingsson et al. ‘06] • Approach #2: Run-‐Time Enforcement layer Open QuesHon: How can we get complete r[Haldar un-‐Hme p[roperHes? et al. ‘04], Kil et al. ‘09] Integrity Checked Run Time Code Load Time Enforcer 51 Roots of Trust Cheaper 0 0 4 2 • General purpose • General • Special • Timing-‐based purpose purpose aQestaHon Open QuesHon: • Tamper • No physical • Require What funcHonality d o w e n eed i n h ardware? responding defenses detailed HW knowledge [Weingart ‘87] [White et al. ‘91] [Yee ‘94] [Smith et al. ‘99] … [ARM TrustZone ‘04] [TCG ‘04] [Zhuang et al. ‘04] … [Chun et al. ‘07] [Levin et al. ‘09] [Spinellis et al. ‘00] [Seshadri et al. ‘05] … 52 26 Open QuesHon: What does Alice do with a failed aQestaHon? Open QuesHon: How can Alice trust her device? 9/28/15 Human Factors SW SW SW SW 1 2 N-‐1 N Open QuesHons: How should be communicated to Alice? What does Alice do with a failed aQestaHon? How can Alice trust her device? SW SW SW SW 1 2 N-‐1 N 53 State Con0nuity • Sealed state may be bound to soeware idenHty • What happens when that state changes? – Old state will sHll decrypt and verify – (It was created by the intended soeware) • State must include version informaHon – Secure counter – Hash chain • Crash Resilience – Data may become permanently unusable • More on this on Wednesday 54 27 9/28/15 2nd-‐Genera0on Trusted Compu0ng • First generaHon of Trusted CompuHng was all about measurement and cryptographic key storage – (And Remote AQestaHon; Adrian will get into this tomorrow) • What do we learn from measuring millions of lines of code? – Axiom sHll holds: at least one more flaw! – Can we somehow measure less code? – Can we somehow reduce the TCB? 55 2nd-‐Genera0on Trusted Compu0ng • AMD: Secure Virtual Machine (SVM) • Intel: Trusted eXecuHon Technology (TXT) – Formerly LaGrande Technology (LT) • Common to both: – Late launch of a measured block of code – Hardware support for virtualizaHon • Differences: – AMD provides measured environment only – Intel adds authenHcated code capabiliHes • The system’s chipset contains a public key to verify signed code • That code executes “on die” directly out of cache 56 28 9/28/15 Hardware Support for Trusted Compu0ng • Trusted CompuHng Group (TCG) proposed Trusted Planorm Module (TPM) chip – Already included in many planorms (200M+) – Cost per chip less than $1 today • 2nd GeneraHon: “Dynamic root of Trust” – CPU and chipset support in addiHon to TPM – Modern microprocessors provide special instrucHons that interact with TPM chip – AMD SVM: SKINIT instrucHon – Intel TXT: GETSEC[SENTER] instrucHon 57 LPC bus TCG Trusted PlaYorm Module (TPM) Platform Non-Volatile Configuration Storage Registers (PCR) (EK, SRK) I/O Random Secure Number Hash Generator SHA-1 Key Crypto Generation RSA DIP Packaging or integrated into SuperIO 58 29 9/28/15 Trusted Compu0ng in the Real World • Commercial products using these ideas • Two main areas – Full Disk EncrypHon (FDE) – Rollback protecHon • We will get into TC research starHng tomorrow 59 Microsog Bitlocker* “Some of the largest and medium-sized U.S. airports report close to 637,000 laptops lost each year, according to the Ponemon Institute survey released Monday.” —PC World June 2008 “More than 100 USB memory sticks, some containing secret information, have been lost or stolen from the Ministry of Defense since 2004, it has emerged.” —BBC News July 2008 60 * Slides from Troy Funk, Microsoft PM, WinHEC 2008 30 9/28/15 61 Challenge: Reducing the Trusted Computing Base • Today’s OSes have too much power • Total access to applicaHon data App (ring 3) OS Kernel (ring 0) App 1 … OS Device Device Device Driver Driver Driver 1 2 m App n Kernel Kernel Kernel Module Module Module 1 2 l • TCB: Set of all HW & SW that must Hardware be trusted for an applica0on to do its job • Trusted compuHng base for App 1 includes majority of: OS, drivers, and privileged applicaHons!!! 62 31 9/28/15 BitLocker™ in Windows Vista and Windows Server 2008 Unlock Methods Drive Type Operating System Drives TPM TPM+PIN TPM+Startup key TPM+PIN+ Startup Key* Startup key Recovery Methods Recovery password Recovery key Active Directory backup of recovery password Management Group policy controlled options presented to users Other requirements Use of the BitLocker Drive Preparation Tool to create a system partition where boot files are located System partition size: 1.5GB System partition assigned a drive letter NTFS file system Fixed Data Drives Automatic unlocking Same as OS drive No policies Operating System drive must be encrypted NTFS file system * USB storage device 63 • AQestaHon: can be checked by external enHty • Secure counter • Hash chain • Late launch 64 32 9/28/15 A Note on Paper Reviews • Make your contribuHon statements more summarizing than descripHve – Remembering "introduced a methodology" isn't as useful to you later on as "the key idea is XYZ” – Most of you wrote precise statements for weaknesses – do the same for contribuHons! 65 33