Transcript Peer-to-Peer Access Control Architecture Using Trusted

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 participation
from academia or larger
research 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
Adapted from TCG presentation
Trusted Platform Module
(TPM)
• Specified by TCPA/TCG
• “Smartcard” on board
TPM is connected to
the motherboard
CPU
RAM
MCH
AGP
TPM
LPC
ICH
BIOS
Network
Port
From TCG presentation
TPM
• Key Hierarchy
– Non-Migratable Keys :Permanently bound specific TPM, i.e.,
platform
– Migratable Keys: Can be migrated to other platforms
Protected by the TPM
Endorsement Key
Storage Root Key
(SRK)
Protected by the RTS
Migratable
Storage Key
Migratable
Storage Key
Migratable
Signing Key
Non-Migratable
Storage Key
Migratable
Signing Key
Non-Migratable
Storage Key
Migratable Signing
or Storage Key
Attestation ID
Keys
Non-Migratable
Signing Key
Migratable Signing
or Storage Key
From Intel presentation
Attestation
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, mobilepayment)
Architecture
• Platform with trusted reference monitor (TRM)
• Assumptions:
– Tamper resistent hardware
– A homogeneous environment
• Each platform is equipped uniformly with necessary TC hardware.
protected runtime
environment
Application2
Application1
OS User Space
OS Kernel Space
Hardware
Secure
Channel
Sealed
Storag
e
Trusted
Reference
Monitor
Trusted
Reference
Monitor
Application
OS User Space
Secure Kernel
OS Kernel Space
Domain Manager
Secure Kernel
Trusted
Hardware
TPM
Hardware
LaGrande
Technology
TPM
PCR 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
Sealed
Storage
APP
Access Request
Trusted
Reference
Monitor
Trusted
Reference
Monitor
Attest Challenge
Attest Response
Policy & Secrets
OS User Space
OS User Space
OS Kernel Space
Trusted
Hardware
Hardware
OS Kernel Space
Secure Kernel
TPM
Hardware
Alice's Platform
1
Secure Kernel
Trusted
Hardware
TPM
Bob's Platform
Request: {OBJ_ID | H(APPB)} |}SK_{TPM_B.AIK}
Verify H(APPB)
2
3



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
4
Seal k_OBJ
and 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.
Sealed
Storage
APPB
APPB
Trusted
Reference
Monitor
OS User Space
OS Kernel Space
Hardware
Secure Kernel
Trusted Hardware
Bob's Platform
APPB
1
2
3
4
View request: {OBJ}k_OBJ
TRM
Attest challenge
Attest response: {H(APPB) | PK_APPB}SK_{TPM.AIK}


Verify attestation
Generate session key k_s
{k_s }PK_APPB, {OBJ}k_s

Update object attribute:
viewTimes=viewTimes-1
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:
Identity CA
Role Server
{PK_u}SK.CA, H(UA),
{PK_UA}SK_TPM.AIK } }SK.UA
{PK_u, H(UA),
{PK_UA}SK_TPM.AIK } }SK.UA
{PK_u}SK.CA
{{PK_u}SK.ICA, Role}SK.RS
User
Agent
Trusted
Reference
Monitor
OS User Space
OS Kernel Space
Hardware
Secure Kernel
Trusted
Hardware
TPM
Support User Attribute
• Binding of identity and role certificates
– tightly-coupled binding: by signature
– loosely-coupled binding: by other components
Identity
Certificate
Role
Certificate
Binder Info
name, email, SSN
Identity
Public Key
Other Info
Public Key Info
Attribute Info
key, algorithm, length
Role name,
Group, Title
Identify Info
Other Info
serial no, issuer,
valid period,
ICA's Signature
Other Info
serial no, issuer,
valid period,
Role Server's Signature
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)
User Credential
Migration
User
Agent
Trusted
Reference
Monitor
OS User Space
OS User Space
OS Kernel Space
Hardware
Secure Kernel
Trusted
Hardware
TPM
OS Kernel Space
Hardware
Platform 1
Secure Kernel
Trusted
Hardware
TPM
Platform 2
Attest challenge
1
Attest response: {H(UA2), PK_UA2}SK_TPM2.AIK
2


Trusted
Reference
Monitor
User
Agent
Verify attestation
Unwrap SK_u
3
{SK_u}PK_UA2
Wrap 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
VoIP client
application
User
Agent
1
5
2
7
Trusted
Reference
Monitor
7
4
3
Driver
Sound
Card
6
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
A
s
s
u
r
a
n
c
e
What?
Information Sharing,
VoIP, etc
•
•
•
•
Objectives
Model
Architecture
Mechanism
Future work
This paper
focuses here
TPM, LT, PKI
How?