Embassy - Carnegie Mellon University

Report
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
ACA #m
Authorization
Agent
CA
AA #m
Embassy
Manufacturer
CA
PS #m
Embassy
Device #1
Embassy
Device Server
CA
Trust
Assurance
Network
CA(s)
DS #m
Embassy
Device #x
Embassy
Device #y
Embassy
Device #n
Embassy Client Architecture
Ability for user to
inspect and manage
device functionality
Persistent Storage
of Applets
Embassy
Manager
PC Client interface
for applet and server
interaction
Applet
Storage
Embassy
Device
Server
Embassy Host
API
Device
Driver
Device
Driver
Embassy
Device
Back Office component
for registration,
authentication, and
permissioning
Transparent device
driver for device
communications
Transparent device
driver for host
communications
Trusted programmable
hardware for applet
execution
Multiple Application Framework
3RD Party
WAF
Applications
3RD Party
Application
Server
3RD Party
Application
(or Non-WAF)
Applet
Storage
Embassy
Manager
Embassy Host
API
Device
Driver
Device
Driver
Embassy
Device
Applications
(Wave Desktop)
Wave
Application
Framework
(WAF)
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
•
Encrypted Object Code
By Code Key
ACA’s
Signature
Header contains necessary bookkeeping information
–
–
–
–
–
–
•
ACA’s
Signature
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 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
Applet Header
•
•
ACA’s
Signature
Encrypted Object Code
By Code Key
ASP distributes applet to consumer
ASP securely sends code key to Authorized
Embassy Servers.
Application
Service Provider
(ASP)
Applet
Certifying Agent
(ACA)
Application
Service Provider
(ASP)
ACA’s
Signature
Consumers
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)
Key Operations
•Keygen
•Des/3DES
•RSA
•Memory
•RNG
Management
•Interprocessor
Communication
SHA
FLASH Programming
Service
Page
load/unload
other
RTC
Embassy Device Software Block Diagram
Host-Side Device Driver
Host Hardware
Host - Device Boundary
Applet - n
Applet - 1
Static Libraries
Toolkit Components
Embassy
Host-Device
Messaging
User/Unprivileged Space
Device Internal Trust Boundary
Kernel/Privileged Space
Kernel
Applet
Manager
Subsystem
Kernel VM
Subsystem
Kernel Local
Volatile
Storage
Kernel
Dispatcher
Device
Drivers
Hardware Abstraction Layer (HAL)
Hardware
Kernel
Libraries
Embassy OS
System Call Interface
Libraries
OS
(V1.0 )
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
Static
(V1.0)
OS
(V2.0)
Static
(V2.0)
Dynamic
(V2.0)
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
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
Real Time
Clock
Battery
ISO 7816
Controller
ISO 7816
Controller
Crypto
Controller
Keyboard /
Keypad I/F
Symmetric
(DES, 3DES)
Controllerc
ontroller
Display
Secure
Memory
General
Purpose I/F
Controller
Bio Sensor
Micro Support
Pointing
Device I/F
Wireless
Transceiver
External RAM
Encryptor
External RAM
I/F
RAM
Microprocessor
Cache / MMU
Flash Memory
Flash
Persistent Device Storage (Flash) Layout
BOOT OS LOADER
CONFIG INFO
Root Key Hash
Auth Token
CONTEX TABLE
(80 B per applet)
Registration Keys
Unique ID
Device Keys
APPLET PDS FILES
(512B per applet)
Last Checkpoint
Time Offset and
Drift
Last Sync Period
ACL
CRL period
AS Rand
Last CRL process
Time
AS Rand Index
Applet Dependant
Storage
An Implementation Example

similar documents