Peer-to-Peer Access Control Architecture Using Trusted Computing Technology

Ravi Sandhu and Xinwen Zhang

George Mason University

SACMAT05, June 1--3, 2005, Stockholm, Sweden

With thanks to our Intel colleagues Kumar Ranganathan, Carlos Rozas and Michael Covington

What is trust?

• Trust– “An entity can be trusted if it always behaves in the expected

manner for the intended purpose.”– Trusted Computing Group (TCG)

• Previously called Trusted Computing Platform Alliance (TCPA)• Includes Intel, Microsoft, IBM, HP

• Entity– A platform, or an application or service running on a platform.

• personal computer, personal digital assistant (PDA), smart phone, etc.

– A client is a computing platform that can initiate communication with other clients to transfer or share data and resources

Need Trust on the Client

• Traditional Client/Server Architecture– Trust is on the server side.– Trust is obtained with multi-layer protection mechanisms.

• Access control• Firewall• Intrusion detection and intrusion prevention systems

– There is little trust on client side.• Clients are generally lightly protected.• Ubiquitous connectivity in clients• Attacks outpacing today’s protection models• Attack tools readily available

• Information resident on the client becomes susceptible to software-based attacks.– Mismatch between security and high value of data in client

platforms.

Trusted Computing Technology• Basic premise

– software alone cannot provide an adequate foundation for trust on the client

• Old style TC– Multics system– Capability-based computers

• Intel 432– Trust with security kernel based on military-style security labels

• Orange Book, eliminate trust from applications• What’s new

– Hardware and crypto-based root of trust• Ubiquitous availability

– Trust within a platform– Trust across platforms– Trust in applications

• No Trojan Horses, ergo no covert channels

Little participationfrom academia or largerresearch community

Trusted Computing

• Recent TC activities:– TCG Specifications of TPM (Trusted Platform Module)

• TPM is hardware root of trust• Needs to be ubiquitous

– cheap, cheap, cheap– therefore a performance bottleneck

– Additional Hardware• Intel’s LaGrande Technology (LT)• ARM TrustZone

– OS/Software• Microsoft Palladium -> NGSCB -> ??• Linux, SE Linux, Trusted BSD

– Mostly NSA funded

– Supporting PKI

Trusted Platform Module(TPM)

• Specified by TCPA/TCG

• “Smartcard” on board

MCH

ICH

AGP

NetworkPort

LPC

TPM

CPU

RAM

BIOS

TPM is connected to the motherboard

Adapted from TCG presentation

TPM• Key Hierarchy

– Non-Migratable Keys :Permanently bound specific TPM, i.e., platform

– Migratable Keys: Can be migrated to other platforms

Storage Root Key(SRK)

Non-Migratable

Storage Key

Migratable Storage

Key

Endorsement Key

Migratable Storage

Key

Migratable Signing

Key

Migratable Signing

Key

Non-Migratable

Storage Key

Non-Migratable Signing Key

Migratable Signing or Storage Key

Attestation ID Keys

Migratable Signing or

Storage Key

Protected by the RTS

Protected by the TPM

From TCG presentation

AttestationFrom Intel presentation

Intel’s LaGrande Technology (LT)• LT includes:

– Chipset• Protected graphics and memory management

– Extended CPU: • Enable domain separation• Enforce policy for protected memory

– Currently DMA bypasses memory protection– Sleep mode on laptops looses memory protection guarantee

– Protected I/O:• Trusted channel between keyboard/mouse and trusted software

– TCG TPM v1.2• Protect keys• Provide platform authentication and attestation

– Ultra privileged ring -1• Existing ring 0 has too much stuff in it (principally device drivers)• Rings 1 and 2 unused, everything outside OS kernel runs in ring 3• New ring -1 privileged beyond OS kernel

Contributions of this paper

• Integrate user attributes into TC architecture

• Support a user's ability to roam between platforms by migrating user identities and attribute certificates

• Consider specific applications

Motivating Applications

• Trust on client needed in emerging applications– Information Sharing (sometimes called Dissemination

Control or DCON)• Health records of a patient may be transmitted from a primary physician to a

consultant who can access them for some limited period of time and cannot transmit them to anyone else

– P2P VOIP application• Realtime protection of audio data in a platform

– conversation is not eavesdropped or illegally recorded.

• Forward control of audio object (e.g., voice mail)– control the platform and user to forward

– M-commerce• electronic currency between peer platforms• payment systems for p2p e-commerce (e.g., micropayment, mobile-

payment)

Architecture• Platform with trusted reference monitor (TRM)• Assumptions:

– Tamper resistent hardware– A homogeneous environment

• Each platform is equipped uniformly with necessary TC hardware.

Hardware

OS Kernel Space

OS User Space

Application2

SecureChannelApplication1

TrustedReference

Monitor

Secure Kernel

TrustedHardware

protected runtimeenvironment

SealedStorag

e

TPM Hardware

OS Kernel Space

OS User Space

ApplicationTrusted

ReferenceMonitor

Secure Kernel

Domain Manager

LaGrandeTechnology PCR

TPM

PCR PCR PCR

Available Credentials

• TPM AIK pair (PKTPM.AIK, SKTPM.AIK)– private key is protected by a TPM with SRK.– Public key is certified by a privacy CA.

• TRM key pair (PKTRM,SKTRM)– The private key is protected by the TPM.– The public key is certified by AIK.

• Application key pair (PKAPP,SKAPP)– Similar to TRM key pair

• TPM storage key(s) – Either the SRK of a TPM, or a key protected by the SRK– Protect TRM's credential – Protect secrets and policies

Functions of TRM

• TRM.Seal(H(TRM),x):– seals data x by TRM with integrity measurement of H(TRM).– x can only be unsealed under this TRM when the corresponding

PCR value is H(TRM).– In practical a set of PCRs may be included.

• TRM.GenerateKey(k)– generates a secret key k

• TRM.Attest(H(TRM), PKTRM)

– Return {H(TRM) || PKTRM} SK_TPM.AIK

– Attestation response signed by AIK of TPM

Architecture• Policy and Secret Distribution:

– Each object has a policy.

– Object is encrypted with secret key before distribution.

– Policy specifies what platform and application can access this object• migratable or non-migratable policy

Hardware

OS Kernel Space

OS User Space

TrustedReference

Monitor

Secure Kernel

Hardware

OS Kernel Space

OS User Space

TrustedReference

Monitor

Secure Kernel

Attest Challenge

APP

Alice's Platform

Attest Response

Policy & Secrets

SealedStorage

TrustedHardware

TPMTrusted

HardwareTPM

Access Request

Bob's Platform

Request: {OBJ_ID | H(APPB)} |}SK_{TPM_B.AIK}

Attest challenge

Attest response: {H(B.TRM) | PK_B.TRM}}SK_{TPM_B.AIK}

Verify attestation Generate object encryption key k_OBJ Seal k_OBJ

{k_OBJ | policy }PK_B.TRM

1

2

3

4

Verify H(APPB)

Seal k_OBJand policy

Architecture• Policy Enforcement in a client platform

– Only valid TRM can unseal the policy info and secret.

– This valid TRM (specified by integrity measurement) can enforce the policy.

View request: {OBJ}k_OBJ

Attest challenge

Attest response: {H(APPB) | PK_APPB}SK_{TPM.AIK}

Verify attestation Generate session key k_s

APPB TRM

1

2

3

4{k_s }PK_APPB, {OBJ}k_s

Update object attribute:viewTimes=viewTimes-1

Bob's Platform

APPB

Hardware

OS Kernel Space

OS User Space

TrustedReference

Monitor

Secure Kernel

Trusted Hardware

APPBSealedStorage

Revocation

• Revocation because of – Trust revocation of a requesting application– Trust revocation of a TRM– Trust revocation of a platform

• Two approaches: – Push: Object owner sends updated policy to client

side– Pull: client side check policy update from object owner– Both may have delayed revocation– Instant revocation needs centralized policy server

Support User Attributes• Each platform has a user agent (UA)

– Controlled by platform administrator

– A key pair (PKUA,SKUA)

• Each user has an identity key pair (PKu, SKu)

– Migratable key

• Identity and role certificates:

UserAgent

Hardware

OS Kernel Space

OS User Space

TrustedReference

Monitor

Secure Kernel

TrustedHardware

TPM

{PK_u, H(UA),{PK_UA}SK_TPM.AIK } }SK.UA

{PK_u}SK.CA

{PK_u}SK.CA, H(UA),{PK_UA}SK_TPM.AIK } }SK.UA

{{PK_u}SK.ICA, Role}SK.RS

Identity CA Role Server

Support User Attribute

• Binding of identity and role certificates– tightly-coupled binding: by signature– loosely-coupled binding: by other components

Identify Infoname, email, SSN

Public Key Infokey, algorithm, length

Other Infoserial no, issuer,

valid period,

ICA's Signature

IdentityCertificate

Binder InfoIdentity

Public KeyOther Info

Attribute InfoRole name,Group, Title

Other Infoserial no, issuer,

valid period,

Role Server's Signature

RoleCertificate

Support User Attribute

• Role-based policy enforcement:– TRM sends attestation challenge message to the UA.– UA responds with attestation information. – If the TRM trusts the running UA, it sends requesting

message for role information of the user.– The UA sends back the role certificate of the user.

• UA may submit the proof-of-possession for the corresponding private key of the identity public key

– Mutual attestation may be needed • UA needs to ensure that TRM does not release role

information. • Role certificate is private information of a user.

Support User Attribute• Migration of User Credentials

– Identity credential and role credential are migratable.• Not bounded to specific platform

• Can be moved or copied between platforms

– Destination platforms determined by identity owner (user)

UserAgent

Hardware

OS Kernel Space

OS User Space

TrustedReference

Monitor

Secure Kernel

TrustedHardware

TPM

UserAgent

Hardware

OS Kernel Space

OS User Space

TrustedReference

Monitor

Secure Kernel

TrustedHardware

TPM

Platform 1 Platform 2

User CredentialMigration

Attest challenge

Attest response: {H(UA2), PK_UA2}SK_TPM2.AIK

Verify attestation Unwrap SK_u

{SK_u}PK_UA2

1

2

3Wrap SK_u

Applications• Secure VOIP:

– Realtime Protection of Conversation• Secure channel between VOIP software and device driver

• Attestation between TRM and VOIP software

• Attestation between TRM and UA

• Attestation between TRM and device driver

– Secure Storage and Forward of Voice Mail• A policy specifying authorized platform and user attribute

• Similar to DCON

TrustedReference

Monitor

VoIP clientapplication

SoundCard

Driver

1

2

34

7

UserAgent

5 6

7

Related Work Includes• Secure Boot:

– Arbaugh et al., Oakland97– Boot only signed and verified software

• Secure coporcessors – IBM 4758 crypto coprocessor – Closed system to run certified and signed software

• Behavior-based attestation– Haldar et al. USENIX04. – Trusted VM

• Trusted operating systems– SELinux, Trusted Solaris, TrustedBSD

• Attestation-based policy enforcement– Sailer et al. CCS04– Controlled access from client to server by attesting client platform

Conclusion• Summary

– Architecture with TC to support peer-to-peer based access control– General architecture for client-side access control – Consider trust of platforms and applications in access control policy– Integrate user attributes in TC

• Future work opportunities include: – Performance

• TPM is highly performance challenged– Access control model with TC

• A new model? • Fit in some component of existing models?

– Consider other applications• P2P and Ad Hoc networks• Grid systems• Ubiquitous and pervasive computing environments• Information sharing• Digital home

OM-AM

• Objectives

• Model

• Architecture

• Mechanism

What?

How?

Assurance

TPM, LT, PKI

Information Sharing, VoIP, etc

This paper focuses here

Future work