1 / 28

Trust Infrastructures for Multi-Party Transactions

Trust Infrastructures for Multi-Party Transactions. Wave Systems Corp 11.27.01 Len Veil. Multi-Party Trust Infrastructure.

lassie
Download Presentation

Trust Infrastructures for Multi-Party Transactions

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  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) Application Applet Authorization Embassy Embassy Developer Certification Agent Manufacturer Device Server Services CA Agent CA CA CA 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. 3RD Party WAF Applications Applications (Wave Desktop) 3RD Party Application (or Non-WAF) 3RD Party Application Server 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. 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 Header ACA’s Signature Encrypted Object Code By Code Key ACA’s Signature Embassy Applet Construction

  16. Applet Life Cycle • Development • Certified • Published • Installed • Loaded • Executing • Swapped • Unloaded • UnInstalled • Revoked

  17. 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 Header ACA’s Signature Encrypted Object Code By Code Key ACA’s Signature Applet Publishing Application Service Provider (ASP) 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. 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 Pre-Personalization Process of placing the Device ID with the Embassy Device

  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 - n Applet - 1 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. Physical Interfaces Basic “Embassy” Core uP 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. Wireless Transceiver Bio Sensor RAM Flash Embassy 2100 LPC Master Interface LPC Slave / RS-232 Interface USB Interface Real Time Clock Battery ISO 7816Controller ISO 7816Controller Crypto Controller Keyboard / KeypadI/F Controllercontroller Symmetric (DES, 3DES) Secure Memory DisplayController General Purpose I/F Micro Support PointingDevice 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

More Related