Trusted System Elements and Examples

1. Trusted System Elements and Examples CS461/ECE422 Spring 2012

2. Reading Material • Chapter 10 in the text. Sections 3, 4, and 5 • Intel Architectures Software Developer Manuals • http://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html • TCG Specification Architecture Overview Specification • http://www.trustedcomputinggroup.org/resources/tcg_architecture_overview_version_14 • More details on TPM

3. What is a Trusted Computer System? • A system that employs sufficient hardware and software assurance mechanisms to allow its use for simultaneous processing of a range of sensitive or classified information. • Implements strong security mechanisms • Effective • Expressible • High assurance implementation • Proof that the system works as advertised.

4. Reference Monitor • Regulates access of subjects to objects • Access policy in Security Kernel Database • Must provide: • Complete mediation • Isolation – no unauthorized modification • Verifiability – prove correctness of implementation

5. Reference Monitor Audit File Subject Reference Monitor Subject Object Subject Object Object Security kernel db Subject: security clearance Object: security classification

6. Trusted Computing Base (TCB) • TCB contains elements of hardware and software that enforce security • Reference Monitor • Software/hardware primitives that reference monitor relies on • TCB must be tamperproof • TCB cannot be circumvented

7. Trojan Horse example • Thompson Turing award lecture compile(source) { if (match(source, “check_password”)) { insert(source, A) } if (match(source, “compile”)) { insert(source, B); } ... }

8. Memory Protection Rings • Originally in Multics • In Intel arch since x386

9. Privilege Levels • CPU enforces constraints on memory access and changes of control between different privilege levels • Similar in spirit to Bell-LaPadula access control restrictions • Hardware enforcement of division between user mode and kernel mode in operating systems • Simple malicious code cannot jump into kernel space

10. Data Access Rules • Access allowed if • CPL <= DPL and RPL <= DPL

11. Data Access Rules • Three players • Code segment has a current privilege level CPL • Operand segment selector has a requested privilege level RPL • Data Segment Descriptor for each memory includes a data privilege level DPL • Segment is loaded if CPL <= DPL and RPL <= DPL • i.e. both CPL and RPL are from more privileged rings

12. Data Access Examples

13. Calling Through Gates DLP

14. Call Gate Access Rules • For Call • CPL <= CG DPL • RPL <= CG DPL • Dst CS DPL <= CPL • Same for JMP but • Dst CS DPL == CPL

15. Call Gate Examples

16. Stack Switching • Automatically performed when calling more privileged code • Prevents less privileged code from passing in short stack and crashing more privileged code • Each task has a stack defined for each privilege level

17. Hardware Rings • Only most basic features generally used • 2 rings • Installed base • Time to adoption • Must wait for widespread system code, e.g. Windows NT

18. Limiting Memory Access Type • The Pentium architecture supports making pages read/only versus read/write • A more recent development is the Execute Disable Bit (XD-bit) • Added in 2001 • Supported by Windows XP SP2 • Similar functionality in AMD Altheon 64 • Called No Execute bit (NX-bit)

19. Trusted Computing Group • Consortium developing standards for computer architectures using secure co-processors • Called the Trusted Platform Module (TPM) • http://trustedcomputinggroup.org • Numerous computers (particularly laptops) already ship with TPM’s • Windows 7 uses TPM for bitlocker. Secure booting? • Many vendors targeting specific enterprises like Health Care that are particularly concerned with privacy (due to HIPAA)

20. TPM Basics • TPM stores a number of key pairs • Private Endorsement Key (EK) encoded at time of manufacturing • Manufacturer signs Endorsement certificate. • TPM has some protected storage • Platform Configuration Registers (PCRs) • TPM can be used to boot strap security locally • TPM can respond to remote requests for system data • E.g. what version of libraries is the system running

21. TPM Layout

22. Root of Trust for Storage (RTS)

23. TPM Protected Message Exchanges • Binding – Encrypting using public key • If using non-migratable key value is bound to TPM • Signing – Using the private key • Some keys are indicated as signing only keys • Sealing – Binding a message with set of platform metrics (expressed in PCRs) • So can only unseal values when the platform metrics match • Sealed-signing – Have a signature also be contingent on PCR values

24. TPM Supported Disk Encryption • Used by Bitlocker in Windows 7 • http://windows.microsoft.com/en-US/windows-vista/BitLocker-Drive-Encryption-Overview • TPM creates a symmetric key • Seals key • Will only unseal key if the specified system components match the values sealed with the key • Moving disk to another system will fail • Key can only be decrypted by TPM on original system

25. TPM Architecture Overview

26. Attestation in Booting • TPM leverages trusted building blocks (as shown in bold in previous diagram) • CRTM == Core root of trust for measurement • TPM signs system state using an Attestation Identity Key (AIK) • CRTM verifies integrity of next level boot code before proceeding • Inductively each level verifies the next higher level

27. Transitive Trust

28. Certification Services • Measurement values • Representation of data or program code • Can be stored anywhere • Measurement digests • Hash of the measurement values • Stored in the TPM • Fixed number of Platform Configuration Registers (PCRs)

29. Integrity Reporting • Two purposes • Expose shielded locations for storage of integrity measurements • Means to manipulate PCR’s • Attest to the authenticity of stored values based on trusted platform identities • Integrity reports signed by Attestation Identity Keys (AIK) • AIK is associated with particular TPM

30. Example Reporting Protocol

31. Usage Scenarios • Store root secrets in secure co-processor • In an enterprise, IT group is responsible for machine admin • They set up the TPM • End user cannot muck with TPM even if they are root on the machine • Ensure platform is in particular configuration • Verify the digest values of SML of configurations of interest

32. Digital Rights Management (DRM) • One scenario concerns protecting data from the user for the vendor • Alice buys a song from Recording Company • License agreement says that Alice buys song for personal use • Trivial for Alice to share song with 10,000 of her closest friends • Hard for Recording Company to track • Want to protect their assets • Can use specialized players, as in Sony’s recent rootkit problems

33. Using TPM for DRM • Alice registers with Record Company for the ability to play their songs • Record Company sends her certificate to store on in her TPM and a player to install • On boot, TPM verifies that player has not been changed • Alice buys a song from Record Company • Song is sealed to the “correct” player configuration on Alice’s computer • To play song • Player passes sealed blob to TPM • TPM detects that it is invoked from legal player • TPM decrypts if sealed PCR values match • Player plays it • No unauthorized program can decrypt song

34. Limitations of TPM for DRM • Even if no other program can spoof player in TPM interactions • Root user can use program debugger to access decrypted program in memory • Then may copy unencrypted copy for use outside player • Could use more stringent OS mechanisms • May still be circumvented, esp. with physical access

35. Summary • Trusted System a kind of fuzzy concept • Some common mechanisms • High assurance • Reference Monitor • Multilevel System • Hardware support • Memory protection rings • TPM