Trust Infrastructures for Multi-Party Transactions

Wave Systems Corp

11.27.01

Len Veil

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

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

Clients

• Substantially less resource expended on ensuring integrity of client and it’s 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

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

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

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

Embassy Overview

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

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

EmbassyRoot

EmbassyDevice #1

EmbassyDevice ServerCA

AuthorizationAgentCA

ApplicationDeveloperServices CA

EmbassyDevice #x

EmbassyDevice #y

EmbassyDevice #n

EmbassyManufacturerCA

AppletCertificationAgent CA

ADS #m ACA #m AA #m PS #m DS #m

Non-RepudiationAgent

Embassy Trust Architecture

Trust Assurance Network CA(s)

Embassy Client Architecture

AppletStorage Embassy Host

API

DeviceDriver

DeviceDriver

EmbassyDevice

EmbassyDeviceServer

Embassy Manager

Persistent Storage of Applets

Ability for user toinspect and managedevice functionality

PC Client interfacefor applet and serverinteraction

Back Office componentfor registration, authentication, and permissioning

Trusted programmable hardware for applet execution

Transparent device driver for host communications

Transparent device driver for device communications

Multiple Application Framework

AppletStorage Embassy Host

API

DeviceDriver

DeviceDriver

EmbassyDevice

3RD PartyWAF

Applications

3RD PartyApplication

(or Non-WAF)

Applications(Wave Desktop)

WaveApplicationFramework

(WAF)

WaveNetServer

EmbassyDeviceServer

3RD PartyApplication

Server Embassy Manager

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

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

Applet HeaderACA’s

SignatureEncrypted Object Code

By Code KeyACA’s

Signature

Applet Life Cycle

• Development

• Certified

• Published

• Installed

• Loaded

• Executing

• Swapped

• Unloaded

• UnInstalled

• Revoked

Applet Publishing

• 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 HeaderACA’s

SignatureEncrypted Object Code

By Code KeyACA’s

Signature

ApplicationService Provider

(ASP)

AppletCertifying Agent

(ACA)

ApplicationService Provider

(ASP)

ConsumersEmbassyServers

(ES)

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

Pre-Personalization

• 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

Process of placing the Device ID with the Embassy Device

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

Embassy OS (abstract)

X509ISO7816

USB

other

Secure

Output

Secure UserInput

RTC

SHA

ServicePageload/unload

FLASH Programming

Key Operations•Keygen•Des/3DES

•RSA•RNG•Memory

Management•Interprocessor Communication

Embassy Device Software Block Diagram

Host-Side Device Driver

Host Hardware

Applet - 1 Applet - n

Toolkit Components Static Libraries

System Call Interface

KernelApplet

ManagerSubsystem

Kernel VMSubsystem

Kernel LocalVolatileStorage

KernelDispatcher

DeviceDrivers

KernelLibraries

Hardware Abstraction Layer (HAL)

Hardware

Host - Device Boundary

User/Unprivileged Space

Device Internal Trust Boundary

Kernel/Privileged Space

Em

bassyH

ost-Device

Messaging

Em

bassy Appl et s

Em

bassy OS

LibrariesOS

(V1.0 )Static(V1.0)

OS(V2.0)

Static(V2.0)

Dynamic(V2.0)

Messaging XMemory Management XFlash File System XISO7816 XRNG XSHA XDES/3DES XRSA XPKCS#1 XPKCS#7 XKeyboard/Keypad XASN (DER) XSecure Input XSecure Output XTimer/RTC XOS Enumeration XKeyGen XECC XPKCS#10 XPKCS#11 XSecure Bulk Storage XInter-Applet Communication XX509v3 XCertificate Processing XEMV X

Embassy Devices :

Physical Interfaces

Basic “Embassy”

Core

uP

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

Embassy 2100

LPC Slave / RS-232 Interface

USB Interface

ISO 7816 Controller

ISO 7816 Controller

Keyboard / Keypad I/F

ControllercontrollerDisplay Controller

Pointing Device I/F

Microprocessor

Symmetric (DES, 3DES)

Crypto Controller

Real Time Clock

Flash MemoryCache / MMU

Secure Memory

Micro Support Bio Sensor

RAM

Flash

Wireless Transceiver

Battery

General Purpose I/F

External RAM I/F

LPC Master Interface

External RAM Encryptor

BOOT OS LOADER

CONFIG INFO

CONTEX TABLE(80 B per applet)

Persistent Device Storage (Flash) Layout

APPLET PDS FILES(512B per applet)

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

ACL

AS Rand

AS Rand Index

Applet Dependant Storage

An Implementation Example