Offline Micropayments without Trusted Hardware

1
Offline Micropayments without Trusted Hardware

• Presented By Daniel Wiegand
• Date Monday, April 21, 2003

2
Original Authors January 6, 2001

• Matt Blaze
• ATT Labs Research
• John Ioannidis
• ATT Labs Research
• Angelos D. Keromytis
• University of Pennsylvania

3
Existing Technology

• Credit Cards over SSL
• Most Popular
• Requires hidden credit check in the background,
  costing around 10 (US) cents.
• NetBill
• Requires communication with NetBill server for
  each transaction

4
Existing Technology Cont.

• Digital Cash
• Provides anonymity and offline transactions
• Does not address double spending
• IBMs MiniPay
• Used primarily via a web browser
• Performs an online check with a billing server

5
Existing Technology Cont.

• Person to Person Payment Systems
  (e.g. PayPal)
• Providers server is needed to be contacted to
  initiate the transfer

6
Problems To Be Addressed

• Current electronic payment systems are not well
  matched to occasional, low-valued transactions.
• A single compromise or failure should not have
  catastrophic consequences
• No double spending
• Client should have unlimited liability for
  unauthorized transactions

7
Problems To Be Addressed Cont.

• Protocols require online transactions
• Trusted hardware is needed for either the payer
  (e.g smartcard) or payee (e.g. server)
• Current protocols work on prevention
• Often too expensive for low-valued transactions

8
Solution

• An approach that focuses on Risk Management
• Relax many of the expensive requirements of
  traditional payment systems
• Keep fraud / uncollectible transactions to an
  acceptable level
• Use certified code that can authorize offline
  transactions

9
Traditional Transaction Processing

• Payer has an account with some spending limit
• Provides account info to payee who authorizes the
  transaction with provider

10
Traditional Settlement Clearing

• Payee sends a batch of transactions to the
  provider
• Provider bills the payor, and sends the
  appropriate funds to the payee

11
Traditional Transactions

• Clearing is done offline and in batches
• Authorization Request is Needed
• Ensure available funds from payor
• Assures account is in good standing
• Prevents fraud

12
Proposed Mechanism

• Certified user information is included with
  account
• Describes conditions under which transactions can
  be authorized offline
• Used for transactions where fraud is unlikely
• Targets small value transactions where online
  authorizations are cost prohibitive

13
Proposed Mechanism Cont.

• Authorization data is managed by a small,
  portable device with some computational power and
  communication mechanism

14
System Components

• Merchants Sell items and collect payments
• Payers Buy items and pay for them
• Provisioning Agent Provides the service
• Merchant Payment Processor Channel where
  Merchants and Payers interact
• Clearing and Settlement Center Reconciles
  Transactions
• May be part of the Provisioning Agent

15
Design Details and Assumptions

• Communication with the Provisioning Agent is
  relatively expensive
• No communication during a transaction
• Transactions are handled between Payer and
  Merchant directly
• Public key crypto system
• Payers and Merchants must have a Provisioning
  Agent in Common

16
Design Details Cont.

• Payer must prove to the Merchant it is authorized
  for a transaction
• Provides signed messages that the Merchant uses
  to clear payment
• Loss of devices is not catastrophic
• Use of User Credentials previously discussed

17
Trust Management

• Provides standard general purpose mechanisms for
  specifying application security policies and
  credentials
• Credentials bind keys directly to the
  authorization to perform tasks

18
Trust Management Cont.

• Five Components for a Trust Management System
• Language for describing actions operations that
  are controlled by the system
• Identifying principals Entities authorized to
  perform actions
• Language to specify policies Govern the actions
  that principals can perform

19
Trust Management Cont.

• Five Components Cont.
• Language to specify credentials Allow
  principals to delegate authorization to other
  principals
• Compliance checker Determines how an action
  should be handled when provided a policy and set
  of credentials

20
Action Language

• Item Purchased
• Price / Quantity
• History of previous purchases with the same
  Merchant
• Misc Other information
• Time of day
• Location

21
Merchant Policy

• Contains public keys of provisioning agents
• Payers must use one of those agents
• Contains User Requirements for Making a Purchase
• Age
• Drivers License

22
User Credentials

• Limiting risk
• Have a limited lifetime and are refreshed with
  the issuer on a specified interval
• Transaction Limits
• Specific items
• Quantities / Prices
• Characteristics of user (e.g. age)

23
User Credentials Cont.

• Example Fields
• The Users Public Key
• Conditions
• App_domain deli
• Currency USD
• Amount
• Date
• Num of Transactions

24
Bootstrapping the System

• Payers / Merchants have a device capable of
  handling transactions
• Payers / Merchants have a public / private key
• Public key is used as identification
• Payer / Merchant has signed up with a
  Provisioning Agent to issue credentials
• Credentials are short lived

25
Bootstrapping the System Cont.
26
Completing a transaction

• Payer / Merchant exchange Credentials
• Merchant verifies Payers capabilities to
  complete the transaction and pay for goods /
  services
• Optional Payer verifies that the Merchant is
  known
• The Payer issues a Microcheck to the Merchant
• Authorizes a one time charge to the Payers
  account and credit to the Merchants account

27
Completing a Transaction Cont.

• The Merchant validates the transaction with its
  Compliance Checker
• The Payer receives the goods or services
  purchased

28
Completing a Transaction Cont.
29
Post Transaction Activity

• On a certain interval, the Merchant will send its
  Microchecks to the Clearing and Settlement Center
• Payers account is charged
• Merchants account is credited
• Provisioning Agent is contacted to indicate
  status of the accounts for when new credentials
  are issued

30
Post Transaction Activity Cont.
31
Security Analysis

• Provisioning the Device
• Device Dependant
• Decrypting private keys is of limited use
• Same effects as stealing device
• Short lived credentials for making low cost
  purchases
• Clearing Center can detect fraudulent use
• Verifying purchasing limits not exceeded
• Geography

32
Prototype

• Payer hardware Palm PDA
• Already owned by a large number of people in the
  current environment
• Merchant Soda Vending Machine
• Removed traditional payment mechanism and
  replaced it with infrared sensor
• Dispenses 8 kinds of different drinks
• Equipped with display to provide information

33
Prototype Cont.

• Provisioning Agent Unix workstation with a Palm
  Cradle.
• How users got initial credential
• Updated via electronic mail
• Also serves as the Clearing Agent
• Provisioning the PDA
• Short term certificate
• Keys and certificate are compiled to an
  executable and loaded on the PDA

34
Prototype Cont.

• Buying a Drink
• User makes a selection
• Display informs the user to point their PDA at
  the sensor
• User is asked to complete the transaction
• A Microcheck is built and sent to the Merchant
  along with the user credentials
• Merchant verifies the credentials and dispenses
  the drink

35
Prototype Cont.

• Palm Screen Shots

36
Conclusions / Discussion

• Interesting application, but is it really useful?
• Capable device ownership is rapidly increasing
• Very tough to gain widespread acceptance
• Limited target (low-valued transactions)
• High overhead to remove checks with a central
  server