Trusted System Elements and Examples CS461/ECE422 Fall 2011.

Slides:



Advertisements
Similar presentations
Operating System Security
Advertisements

1 cs691 chow C. Edward Chow Confidentiality Policy CS691 – Chapter 5 of Matt Bishop.
TCSEC: The Orange Book. TCSEC Trusted Computer System Evaluation Criteria.
Chapter 3 Multics. Chapter Overview Multics contribution to technology Multics History Multics System – Fundamentals – Security Fundamentals – Protection.
Trusted Ring: A Security Enhancing Software Architecture Michael DiRossi, Inventor The Johns Hopkins University Applied Physics Laboratory.
CSE331: Introduction to Networks and Security Lecture 34 Fall 2002.
Chapter 6 Security Kernels.
Title of Selected Paper: Design and Implementation of Secure Embedded Systems Based on Trustzone Authors: Yan-ling Xu, Wei Pan, Xin-guo Zhang Presented.
DDBMS Security - Bakul Gada.
—On War, Carl Von Clausewitz
Chapter 11 Firewalls.
CMSC 414 Computer and Network Security Lecture 13 Jonathan Katz.
CSE331: Introduction to Networks and Security Lecture 28 Fall 2002.
Chapter 1 Introduction. Chapter Overview Overview of Operating Systems Secure Operating Systems Basic Concepts in Information Security Design of a Secure.
1 Building with Assurance CSSE 490 Computer Security Mark Ardis, Rose-Hulman Institute May 10, 2004.
Chapter 2 Access Control Fundamentals. Chapter Overview Protection Systems Mandatory Protection Systems Reference Monitors Definition of a Secure Operating.
Chapter 4 Access Control Manage Principals operations in system.
IS 4420 Database Fundamentals Chapter 12: Data and Database Administration Leon Chen.
Information Systems Security Security Architecture Domain #5.
OS Organization. OS Requirements Provide resource abstractions –Process abstraction of CPU/memory use Address space Concurrency Thread abstraction of.
Slide 3-1 Copyright © 2004 Pearson Education, Inc. Operating Systems: A Modern Perspective, Chapter 3.
Chapter 20 Firewalls.
Systems Security & Audit Operating Systems security.
ISA 562 Internet Security Theory & Practice
3/16/2004Biba Model1 Biba Integrity Model Presented by: Nathan Balon Ishraq Thabet.
G53SEC 1 Reference Monitors Enforcement of Access Control.
Chapter 5 – Designing Trusted Operating Systems  What makes an operating system “secure”? Or “trustworthy?  How are trusted systems designed, and which.
Three fundamental concepts in computer security: Reference Monitors: An access control concept that refers to an abstract machine that mediates all accesses.
Trusted Computing Or How I Learned to Stop Worrying and Love the MPAA.
Session 2 - Security Models and Architecture. 2 Overview Basic concepts The Models –Bell-LaPadula (BLP) –Biba –Clark-Wilson –Chinese Wall Systems Evaluation.
Security Architecture and Design Chapter 4 Part 3 Pages 357 to 377.
CSCE 201 Introduction to Information Security Fall 2010 Access Control.
Chapter 5 Network Security
Security Overview  System protection requirements areas  Types of information protection  Information Architecture dimensions  Public Key Infrastructure.
Slide 3-1 Copyright © 2004 Pearson Education, Inc. Operating Systems: A Modern Perspective, Chapter 3.
Chapter 7 Securing Commercial Operating Systems. Chapter Overview Retrofitting Security into a Commercial OS History of Retrofitting Commercial OS's Commercial.
G53SEC 1 Reference Monitors Enforcement of Access Control.
ECE Prof. John A. Copeland fax Office: GCATT Bldg.
UNIX System Protection. Unix History Developed by Dennis Ritchie and Ken Thompson at AT&T Bell Labs Adapted some ideas from the Multics project in 1969.
Access Control in Practice CS461/ECE422 Fall 2010.
Improving Xen Security through Disaggregation Derek MurrayGrzegorz MilosSteven Hand.
Multics CysecLab Graduate School of Information Security KAIST.
Operating Systems Security
Chapter 5 – Designing Trusted Operating Systems
CSCE 201 Introduction to Information Security Fall 2010 Access Control Models.
Design Principles and Common Security Related Programming Problems
Archictecture for MultiLevel Database Systems Jeevandeep Samanta.
Chapter 19: Building Systems with Assurance Dr. Wayne Summers Department of Computer Science Columbus State University
Protection & Security Greg Bilodeau CS 5204 October 13, 2009.
Dr. Jeff Teo Class 4 July 2, Deliverables Lecture on Trusted Computing: Evolution and Direction Review of students’ blogs and assignments Summarize.
Chapter 21: Evaluating Systems Dr. Wayne Summers Department of Computer Science Columbus State University
PREPARED BY: MS. ANGELA R.ICO & MS. AILEEN E. QUITNO (MSE-COE) COURSE TITLE: OPERATING SYSTEM PROF. GISELA MAY A. ALBANO PREPARED BY: MS. ANGELA R.ICO.
Information Security Principles and Practices by Mark Merkow and Jim Breithaupt Chapter 5: Security Architecture and Models.
1 Security Architecture and Designs  Security Architecture Description and benefits  Definition of Trusted Computing Base (TCB)  System level and Enterprise.
Chapter 29: Program Security Dr. Wayne Summers Department of Computer Science Columbus State University
Information Security Principles and Practices
TCSEC: The Orange Book.
Access Control CSE 465 – Information Assurance Fall 2017 Adam Doupé
Security Models and Designing a Trusted Operating System
Computer Data Security & Privacy
Official levels of Computer Security
Chapter 19: Building Systems with Assurance
UNIX System Protection
Chapter 27 Security Engineering
Chapter 29: Program Security
Operating Systems: A Modern Perspective, Chapter 3
Sai Krishna Deepak Maram, CS 6410
SCONE: Secure Linux Containers Environments with Intel SGX
Access Control What’s New?
Presentation transcript:

Trusted System Elements and Examples CS461/ECE422 Fall 2011

Reading Material Chapter 10 in the text. Sections 3, 4, and 5 Intel Architectures Software Developer Manuals – s/architectures-software-developer-manuals.html s/architectures-software-developer-manuals.html TCG Specification Architecture Overview Specification – g_architecture_overview_version_14 g_architecture_overview_version_14 – More details on TPM

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.

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

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

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

Trojan Horse example

Memory Protection Rings Originally in Multics In Intel arch since x386

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

Data Access Rules Access allowed if – CPL <= DPL and RPL <= DPL

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

Data Access Examples

Calling Through Gates DLP

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

Call Gate Examples

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

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

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)

Trusted Computing Group Consortium developing standards for computer architectures using secure co-processors – Called the Trusted Platform Module (TPM) – Numerous computers (particularly laptops) already ship with TPMs – 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)

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

TPM Layout

Root of Trust for Storage (RTS)

TPM Protected Message Exchanges Binding – Encrypting using public key – If using non-migratable key value is bound to TPM Signing – Encrypt with 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

TPM Supported Disk Encryption Used by Bitlocker in Windows 7 – vista/BitLocker-Drive-Encryption-Overview 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

TPM Architecture Overview

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

Transitive Trust

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)

Integrity Reporting Two purposes – Expose shielded locations for storage of integrity measurements Means to manipulate PCRs – 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

Example Reporting Protocol

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

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 Sonys recent rootkit problems

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 Alices 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

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 – But if I own system, I can bypass most any OS mechanism

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