Trusted Computing Models
1 / 14

Trusted Computing Models Prof. Ravi Sandhu Executive Director and Endowed Chair - PowerPoint PPT Presentation

  • Uploaded on

Trusted Computing Models Prof. Ravi Sandhu Executive Director and Endowed Chair Institute for Cyber Security University of Texas at San Antonio June 2008 Change Drivers. Stand-alone computers. Internet. Vandals.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Trusted Computing Models Prof. Ravi Sandhu Executive Director and Endowed Chair' - maryam-oneal

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Trusted computing models prof ravi sandhu executive director and endowed chair

Trusted Computing Models

Prof. Ravi Sandhu

Executive Director and Endowed Chair

Institute for Cyber Security

University of Texas at San Antonio

June 2008

Change drivers
Change Drivers

Stand-alone computers



Criminals, Nation states, Terrorists

Mutually suspicious yet mutually dependent security

Enterprise security

Many and new

innovative services

Few standard services

Basic assumptions axioms
Basic Assumptions (Axioms)

  • Information needs to be protected

    • In motion

    • At rest

    • In use

  • Absolute security is impossible and unnecessary

    • Trying to approximate absolute security is a bad strategy

    • “Good enough” security is feasible and meaningful

  • Security is meaningless without application context

    • Cannot know we have “good enough” without this context

  • Models and abstractions are all important

    • Without a conceptual framework it is hard to separate “what needs to be done” from “how we do it”

We are not very good at doing any of this

Access control models
Access Control Models

  • Discretionary Access Control (DAC)

    • Owner controls access but only to the original, not to copies

  • Mandatory Access Control (MAC)

    • Access based on security labels

    • Labels propagate to copies

  • Role-Based Access Control (RBAC)

    • Access based on roles

    • Can be configured to do DAC or MAC

  • Attribute-Based Access Control (ABAC)

    • Access based on attributes, to possibly include roles, security labels and whatever

Usage control model ucon
Usage Control Model (UCON)

  • unified model integrating

    • authorization

    • obligation

    • conditions

  • and incorporating

    • continuity of decisions

    • mutability of attributes

What makes ucon different
What makes UCON different?

  • UCON is an attribute-based authorization model


  • Attributes are mutable, in that the system updates them automatically as a result of usage

    • Allows count-limited, rate-limited, quota-limited policies to be expressed and enforced

    • E.g., can access upto 10 documents per hour

  • Access may require explicit actions by the user attempting access, other users or the system

    • Enables human-in-the-loop just-in-time decisions

    • E.g., access requires confirmation by a superior officer

    • Enables notification of access

    • E.g., access is notified to a designated audit authority

    • Enables clean-up after access is completed

    • E.g., delete cryptographic keys, plaintext content

  • Access can depend on system condition and mode

    • E.g., in emergency mode access is enabled (or disabled)

  • Access mediation can continue while access is in progress

    • E.g., if credentials are revoked access is immediately terminated

    • E.g., if system mode changes from normal to emergency access is terminated

Policy model
Policy Model

  • Access to current documents only (or)

  • Access to current documents and past documents

  • Access can be further restricted with rate and/or usage limits

  • Access can be further restricted on basis of individual user credentials

  • Past member loses access to all documents (or)

  • can access any document created during his membership (or)

  • can access documents he accessed during membership (or)

  • can access all documents created before he left the group (this includes the ones created before his join time)

  • all subject to possible additional rate, usage and user credential restrictions

  • No rejoin of past members is allowed, rejoin with new ID (or)

  • Past members rejoin the group just like any other user who has never been a member

  • The same access policies defined during his prior membership should again be enforced (or)

  • access policies could vary between membership cycles

  • Straight-forward. User has no access to any group documents.


Initial state:

Never been a member

State I

Currently a member

State II

Past member

State III



Policy model1
Policy Model

  • Cannot be re-added.

  • When a document is re-added, it will be treated as a new document that is added into the group.

  • Only current members can access.

  • Past members and current members can access

  • No one can access

  • Any one can access

  • Past members can access

  • Straight-forward. No access to group members.

  • Access allowed only to current group members

  • Access allowed to current and past group members


Initial state:

Never been a group doc

State I

Currently a group doc

State II

Past group doc

State III



Enforcement model
Enforcement Model

Control Center (CC)

  • Two sets of attributes

  • Authoritative: as known to the CC

  • Local: as known on a member’s computer







  • Member enroll and dis-enroll (steps 1-2, 5)

  • Document add and remove (step 6, 7)

  • Read policy enforcement (step 3)

  • Attribute update (step 4)

Joining Member





Ideal Model: steps 3 and 4 are coupled

Approximate Model: steps 3 and 4 are de-coupled

Implementation model
Implementation Model

  • Use TC mechanisms to bind group key + attributes to TRM

Trusted computing technology
Trusted Computing Technology

  • Need crypto and access control

  • Requirements

    • Hide the root keys

    • Authorize use of root keys

      • Wrt software

      • Wrt people

    • Curtained memory

    • Remote attestation

    • Translation of policy

      • E.g., Policy in XACML to policy in SELinux


  • Some very interesting challenges ahead and some very exciting research to be done

  • Requires collaboration between

    • Domain experts

    • Technology experts

    • Security experts