Trust Infrastructures for MultiParty Transactions

1
Trust Infrastructures for Multi-Party
Transactions

• Wave Systems Corp
• 11.27.01
• Len Veil

2
Multi-Party Trust Infrastructure

• (For a specific threat model) An environment
  whereby one or more parties may be certain of the
  authenticity and integrity of electronic
  transactions, or computations, involving one or
  more distributed computing environments
• Commonly applied to client/server computing
• Appropriate to server-to-server or peer-to-peer
  computing

3
Servers

• General focus in research and product development
  on securing server and its associated
  environment
• Secure facilities
• Administration procedures
• Multi-factor administrator authentication
• Administration procedures
• Audit Logs
• Authenticated Applications
• Web-page verification
• Cryptographic Co-Processors
• Most server environments are backed by reputable
  organizations and brand names
• Significant motivation by service provider to
  ensure proper operation of application
  environment

4
Clients

• Substantially less resource expended on ensuring
  integrity of client and its associated
  environment
• virus protection
• cookie control
• Code authentication
• Client environment faces different challenges
  than servers
• Consumer price point
• Ease-of-Use requirements
• Dominant OS vendor(s)
• Any client device attached to public network has
  multiple users
• cookies are service providers proxy user

5
Clients

• Clients should offer
• Tamper Resistant Hidden Execution
• RNG
• Asymmetric and Symmetric Cryptographic Processing
• Hashing
• Non-Volatile Secure Storage
• GUID
• Strong Authentication
• Secure input
• Secure output
• Smart Card and/or biometrics
• Application Personalization
• Clone Detection
• User Anonymity
• Cryptographic Application Sealing Unsealing

6
Root of Trust

• Ultimate Authority for permissioning entities
  into the trust infrastructure
• Must be recognized, via some mechanism, to all
  parties involved in transaction
• The more diverse a platform, the greater the
  requirements in order that all the potential
  service providers subscribe to the role and rules
  of the root

7
Trust Considerations

• Managed Client Life-Cycle
• Ease-of-use
• Respected by multiple service providers
• Support for multiple client platforms
• Well-defined validation metrics and
  ease/economics of validation
• Privacy/anonymity of user
• Strong authentication capabilities for user
• Renewability

8
Embassy Overview
9
What is Embassy?

• Embassy Embedded Application Security System
• Client/Server Architecture for integration,
  installation, and execution of programmable
  security functions in client platforms
• Architecture is platform independent, capable of
  being hosted in PCs, STBs, PDAs, SmartPhones, and
  other IAs
• Capable of loading, executing, and unloading
  secure client services through the use of
  authenticated applets
• Provides application based data binding
  cryptographic seal and unseal operations
• Server component for registering and
  authenticating devices, as well as permissioning
  control
• Toolkit for development of third-party services
  and applications
• Client-side embedded processor independent
  architecture,
• Capable of hosting 3rd party applications

10
Applets

• Applets are the secure portion of a client/server
  application which execute in the Embassy trusted
  client environment
• Applets are loaded from the persistent storage
  device of the PC (or other Internet Appliance)
• Before applets are executed, they are
  cryptographically verified and permissions are
  validated
• When an application has completed usage of the
  applet, the applet is unloaded from the Embassy
  device freeing those resources for use by other
  applications (applets)
• Application dependent secure information can be
  contained in an applet and re-encrypted on
  unloading of the applet

11
Embassy Trust Architecture
Embassy
Non-Repudiation
Root
Agent
Trust Assurance Network CA(s)
Embassy
Authorization
Application
Embassy
Applet
Device Server
Agent
Developer
Manufacturer
Certification
CA
CA
Services CA
CA
Agent CA
ADS m
ACA m
AA m
PS m
DS m
Embassy
Embassy
Embassy
Embassy
Device 1
Device x
Device y
Device n
12
Embassy Client Architecture
Ability for user to inspect and manage device
functionality
Embassy Manager
Persistent Storage of Applets
Back Office component for registration,
authentication, and permissioning
PC Client interface for applet and
server interaction
Applet Storage
Embassy Device Server
Embassy Host API
Transparent device driver for device
communications
Device Driver
Transparent device driver for host
communications
Device Driver
Trusted programmable hardware for applet
execution
Embassy Device
13
Multiple Application Framework
Wave Application Framework (WAF)
WaveNet Server
Embassy Manager
Applet Storage
Embassy Device Server
Embassy Host API
Device Driver
Device Driver
Embassy Device
14
Applets

• Embassy applets are developed using an Embassy
  Applet SDK
• Each applet is compiled for execution on the
  Embassy target hardware device (native code)
• Future applet support will provide for hardware
  independent execution (JAVA J2ME/CLDC)
• Applet resource requirements are explicitly
  stated in the toolkit and instantiated in the
  applet code
• Applets are authorized to be used in the Embassy
  environment by a Certifying Agent
• Applet developers are responsible for
  import/export by appropriate government agencies
• Applets may be individually personalized at
  installation time

15
Embassy Applet Construction

• Header contains necessary bookkeeping information
• Version
• Applet ID
• Resource Requirements
• Number of pages
• Security classification
• Command table
• Certifying Agent attest to applet validity by
  signing applet (header plaintext executable)
• Creates a certificate for every applet
• Signature is used to validate applet
  authenticity, cannot validate until code key
  received from Device Server

16
Applet Life Cycle

• Development
• Certified
• Published
• Installed
• Loaded
• Executing
• Swapped
• Unloaded
• UnInstalled
• Revoked

17
Applet Publishing
Application Service Provider (ASP)

• ASP designs and develops applet
• ASP distributes EXE, SRC, HDR, to ES and ACA
• ACA checks applet for validity
• ACA signs EXE and HDR
• ACA transmit signed EXE and HDR to ASP
• ASP Generates Code Key
• ASP encrypts EXE with Code Key
• ASP builds applet
• ASP distributes applet to consumer
• ASP securely sends code key to Authorized Embassy
  Servers.

Applet Certifying Agent (ACA)
Application Service Provider (ASP)
Consumers
Embassy Servers (ES)
18
Embassy Device Life Cycle

• Life Cycle of the Embassy device
• Manufactured (Pre-Personalization)
• Personalized
• Registers with an Embassy Server
• Installs and Executes Applets
• Changes or Modifies Registration

19
Pre-Personalization
Process of placing the Device ID with the Embassy
Device

• Authorization Agent
• Licensing Authority
• Starting point to Non-Repudiation.
• Creates a sequence of permissioned IDs
• Signs the sequence of permissioned IDs with a
  time stamp.
• Sends the signed sequence of permissioned IDs to
  the personalization agent.
• Personalization Station
• Assumes all liability for the validity and
  creation of the Embassy Device ID.
• Secure Kernel
• Verify Input Signatures, Signs Output to Device,
  RSA Key Gen and signing
• Receives the signed permissioned IDs from the
  Authorization Agent.
• Sends back a confirmation upon receipt of the
  signed and permissioned IDs.
• Assembles and installs Device ID onto the Embassy
  Device.
• Device ID Auth.Agent ID, Personalization Station
  ID, Sequence ID

20
Personalization

• Occurs during the device and subassembly
  manufacturing process
• Process of placing unique keying material into
  each Device and to create an audit trail
• Loads onto the Device the
• Embassy Root Key Hash
• Mechanism to validate all Entities in the Embassy
  System
• Unique Identifier
• Concatenation of (AA ID, PS ID, Device ID)
• Registration Keys
• Key pair to be used in the registration process
• Registration Authorization Token
• Unique token to prove validity of personalized
  device

21
Embassy OS (abstract)
ISO7816
X509
Secure User Input
Secure Output

• Key Operations
• Keygen
• Des/3DES
• RSA
• RNG

USB

• Memory
• Management
• Interprocessor
• Communication

RTC
SHA
FLASH Programming
Service Page load/unload
other
22
Embassy Device Software Block Diagram
Host-Side Device Driver
Host Hardware
Host - Device Boundary
Applet - 1
Applet - n
Embassy Applets
Static Libraries
Toolkit Components
User/Unprivileged Space
Embassy Host-Device Messaging
Device Internal Trust Boundary
Kernel/Privileged Space
System Call Interface
Kernel Local Volatile Storage
Kernel Applet Manager Subsystem
Kernel Dispatcher
Embassy OS
Device Drivers
Kernel Libraries
Kernel VM Subsystem
Hardware Abstraction Layer (HAL)
Hardware
23
Libraries
24
Embassy Devices
25
Embassy Security Functionality

• All Embassy device security cores must contain
• MMU
• RNG
• DES/3DES
• DES performance requirement of 2.2 MB/s
• RSA/MME (hardware or firmware)
• performance requirement of 100 ms 1024b sign
• SHA-1 (hardware or firmware)
• performance requirement of 475 KB/s
• Based upon support context for a minimum of 32
  applets
• non-volatile secure storage (for OS and applets)
• OS loader storage of 48K minimum
• User storage of 0.5K minimum per applet
• secure ram, either internal or encrypted external
• OS storage of 96-128K
• User storage of 72K per applet (typical)
• Secure RTC

26
Embassy 2100
LPC Master Interface
LPC Slave / RS-232 Interface
USB Interface
Real Time Clock
Battery
ISO 7816 Controller
ISO 7816 Controller
Crypto Controller
Keyboard / Keypad I/F Controllercontroller
Symmetric (DES, 3DES)
Secure Memory
Display Controller
General Purpose I/F
Micro Support
Pointing Device I/F
External RAM I/F
External RAM Encryptor
Microprocessor
Cache / MMU
Flash Memory
27
Persistent Device Storage (Flash) Layout
BOOT OS LOADER
CONFIG INFO
Root Key Hash Auth Token Registration Keys Unique
ID Device Keys Last Checkpoint Time Offset and
Drift Last Sync Period CRL period Last CRL
process Time
CONTEX TABLE (80 B per applet)
APPLET PDS FILES (512B per applet)
ACL AS Rand AS Rand Index Applet Dependant Storage
28
An Implementation Example