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

Embassy Trust Architecture

Embassy Root Non-Repudiation Agent Application Developer Services CA ADS #m Applet Certification Agent CA Authorization Agent CA Embassy Manufacturer CA Embassy Device Server CA Trust Assurance Network CA(s) ACA #m AA #m PS #m DS #m Embassy Device #1 Embassy Device #x Embassy Device #y Embassy Device #n

Persistent Storage of Applets Applet Storage Embassy Client Architecture Ability for user to inspect and manage device functionality Embassy Manager PC Client interface for applet and server interaction Embassy Host API Device Driver Transparent device driver for device communications Device Driver Embassy Device Transparent device driver for host communications Trusted programmable hardware for applet execution Back Office component for registration, authentication, and permissioning Embassy Device Server

3 RD Party Application Server Multiple Application Framework 3 RD Party WAF Applications Applications (Wave Desktop) 3 RD Party Application (or Non-WAF) Embassy Manager Wave Application Framework (WAF) Applet Storage Embassy Host API Device Driver Device Driver Embassy Device WaveNet Server Embassy Device Server

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

Applet Header ACA’s Signature Encrypted Object Code By Code Key ACA’s Signature

• • • 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

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

Applet Life Cycle

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

Applet Header ACA’s Signature Encrypted Object Code By Code Key ACA’s Signature

ASP distributes applet to consumer ASP securely sends code key to Authorized Embassy Servers .

Consumers Application Service Provider (ASP) Applet Certifying Agent (ACA) Application Service Provider (ASP) Embassy Servers (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

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

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) SHA Key Operations •Keygen •Des/3DES •Memory •RSA •RNG Management •Interprocessor Communication FLASH Programming RTC Service Page load/unload other

Embassy Device Software Block Diagram Host-Side Device Driver Host Hardware Host - Device Boundary Applet - 1 Toolkit Components Applet - n Static Libraries User/Unprivileged Space Device Internal Trust Boundary Kernel/Privileged Space Kernel Applet Manager Subsystem Kernel VM Subsystem System Call Interface Kernel Local Volatile Storage Kernel Dispatcher Device Drivers Hardware Abstraction Layer (HAL) Hardware Kernel Libraries

Messaging Memory Management Flash File System ISO7816 RNG SHA DES/3DES RSA PKCS#1 PKCS#7 Keyboard/Keypad ASN (DER) Secure Input Secure Output Timer/RTC OS Enumeration KeyGen ECC PKCS#10 PKCS#11 Secure Bulk Storage Inter-Applet Communication X509v3 Certificate Processing EMV

OS (V1.0 )

X X X X X X X X X X X X X X X X Libraries

Static (V1.0)

X

OS (V2.0)

X X X X X

Static (V2.0) Dynamic (V2.0)

X X 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 Master Interface LPC Slave / RS-232 Interface USB Interface ISO 7816 Controller ISO 7816 Controller Keyboard / Keypad I/F Controllerc Controller Pointing Device I/F Microprocessor Secure Memory Micro Support Cache / MMU Real Time Clock Crypto Controller Symmetric (DES, 3DES) External RAM Encryptor Flash Memory General Purpose I/F External RAM I/F Battery Wireless Transceiver Bio Sensor RAM Flash

Persistent Device Storage (Flash) Layout

BOOT OS LOADER CONFIG INFO CONTEX TABLE (80 B per applet) APPLET PDS FILES (512B per applet) ACL AS Rand AS Rand Index Applet Dependant Storage 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

An Implementation Example