Development of an Open and Flexible Payment System

By Gary Howland , August - November 1996.

Abstract

The Internet is in need of a simple, open, flexible and secure payment system. Many payment systems that currently exist are either proprietary, insecure, inflexible or all three. This paper examines the types of payment system in use today, the payment system requirements of Systemics Ltd., an overview of the Systemics Open Transaction (SOX(tm)) payments system that was developed, and a summary of how this system met the requirements.

The SOX payment system is currently in live use for a bond trading system, and a reference implementation will shortly be made available on the Internet.

Table of Contents

Also see the SOX Index. Headings below return to the above table of contents.

Introduction

Systemics required a payment system to support their financial applications. The following attributes were required: As no payment system fulfilled these requirements, Systemics developed one, called SOX. There are three main varieties of payment system: (1) The payment system that Systemics developed turned out to be a hybrid system that could potentially contain the essential components of all three models, depending upon how it was used.

The payment system that was developed turned out to be extremely flexible. The size of the payments could be almost anything, and currently range from sub-cent payments to payments for several hundred dollars or more (used for purchasing $10 electronic bonds on the Systemics market). Given that the security is suitably configured, there is no reason why the payments cannot be for even larger amounts.

Payments do not have to represent currencies, but can instead be used for a wide variety of purposes, such as

It is even envisioned that this payment system could be used to represent tradable luxury items such as bottles of wine or whisky.

A micropayments system [1] can easily be added to SOX, providing more efficient small transactions.

Payment Models

There are two types of party involved in all payment systems, the issuers and the users. An issuer is an entity that operates the payment service. An issuer holds the items that the payments represent (for example, cash held in regular bank accounts). The users of the payment service perform two main functions, that of making payments and that of receiving payments, and as such can be described as a payer or a payee respectively.

The Electronic Coin Model


The objective of electronic coin systems is to emulate physical cash. An issuer attempts to do this by creating digital certificates (usually called coins), which are then purchased (or withdrawn) by the users, who then redeem (deposit) them with the issuer at a later date. In the interim, certificates can be transferred between users in order to trade them for goods or services.

In order that the certificates can take on some of the attributes of physical cash, techniques can be used so that when a certificate is deposited, the issuer cannot determine the original withdrawer of the certificate. This provides the electronic certificates with unconditional untraceability [2].

Electronic coin systems can be hard to implement in practice, due to the overheads of solving the "double spending" problem (that of preventing a user from depositing the same coin twice).

Some advantages of electronic coin systems are:


The Electronic Cheque Model


Electronic cheque systems model real world cheques quite well, and are thus relatively simple to understand and implement. A user writes an electronic cheque, which is an instruction to pay that is signed digitally. This is transferred (in the course of making a purchase) to another user, who then deposits it with the issuer. The issuer will verify the payer's signature on the payment, and transfer the funds from the payer's account to the payee's account.

Some advantages of electronic cheque systems are:

These systems are usually fully traceable, which is an advantage for certain law enforcement, tax collection and marketing purposes, but a disadvantage for those concerned about privacy.

The Electronic Transfer Model


Electronic transfer systems are the simplest of the three payment models. The payer simply creates a payment transfer instruction, signs it digitally, and sends it to the issuer. The issuer then verifies the signature on the request, and performs the transfer.

This type of system requires the payer to be online, but not the payee.

Some advantages of electronic transfer systems are:


The transfer model is not particularly suited for use as an interactive Internet payment system.

Requirements

A set of requirements for a payment system was drawn up, and is listed below.

Security Requirements

The security of the system must be far more stringent than conventional systems, since the Internet is both a low-trust environment as well as a highly efficient communications medium. Hence, any loopholes can be exploited relatively safely, and to excess. Because of this, it was important that an imperfect implementation of the system must not leave itself open to large scale fraud.

Privacy Requirements

It was decided that the payment system should be strictly oriented to providing secure payments, and not reveal extraneous information. Of course in some situations extra information will have to be provided (such as during the purchase of mail-order goods, when a name and address will be required). However, the essential feature is that the payment system itself imposes no weakening on privacy, that being a decision for the users, and that the provision of additional information such as mail addresses becomes a decision for the user (and user application software). It is recognised that traffic analysis, the monitoring of existence of communications, may provide useful information, but this is a problem outside the domain of any payment system.

Implementation Requirements

Other Requirements

Other issues such as ease of use and achieving a customer base are of course very important. These issues are, however, outside the scope of this paper, and more concerned with a particular implementation of the payment scheme, not the payment scheme itself.

Architecture

Keyholders

A new user will generate a pair of keys (a public key and a private key), retain the private key for making digital signatures, and register with the issuer by sending them the public key. This is analogous to opening an account. All further interaction with issuer will be done through instructions signed with this key.

A user can generate and register temporary keys for privacy purposes. For example, a payer could hide their identity from the payee by creating and registering a temporary key which is used as an intermediate account.

Temporary keys can also be used to enhance security. For example, an Internet shop may use temporary keys for accepting payments, and immediately transfer those funds elsewhere, leaving the shop key with little or no value. This is of great benefit where the shop is operated on a potentially insecure web server, and the main funds are held elsewhere.

In both of the situations the issuer is aware of all the details, reducing the scope for fraud.

Payments

A payment consists of the following details: The item type field can represent any transferable item of value. This is achieved simply by the item type field being a hash of the value-defining contract.

The description hash field is a cryptographically secure hash of the payment description. This provides two co-operating parties with the ability to agree what the payment is for, without disclosing that information to the issuer.

The payment is only valid for the period specified on the payment. In order to handle divergence in time zones and clocks, the issuer offers a time synchronisation service.

Once a payment has been created, it can be passed to another user in return for goods or services. How this is done is left to the application level software. Current methods of transferring payments include an ascii-armoured format for use in email, and a binary format used in HTTP POSTs for a financial market and on-line shopping.

Deposit instructions

When a payee receives an electronic payment, they should check that all of the details are correct, such as the item type and quantity, and the description hash. It is important that the payee verifies that the description hash matches the description agreed for this transaction, since accepting and depositing a payment with a different description may be construed as agreeing to provide a different set of goods or services than was originally arranged.

Once the payee has verified the payment details, they should create a signed deposit instruction containing the payment, and present this to the issuer. If acceptable, the issuer will transfer the funds from the payer to the payee and return a receipt for this transaction. The payee can now be sure that the payment was successful, and can supply the goods or services.

If there was a problem with the payment (such as the payer not having enough funds), the issuer will instead return a payment failure message.

Transaction Receipts

SOX uses a transactional model of value status, in contrast to the more usual balance model.

In a transactional model, the most basic unit is a transaction, which is communicated by means of receipt. Two receipts are provided, one each for payee and payer, as there are slight differences in content. Each receipt is signed by the issuer, providing undeniable proof that the transaction is complete.

In the case of deposits, the depositor will receive the receipt in the act of depositing. In the case of the payer, the receipt becomes available during a later session. Within the payer's receipt is a copy of the payee's signed deposit instruction. This provides the payer with electronic proof that the payee received and deposited the payment.

SOX implements a secure mailbox protocol to pass receipts, and other information, across to the user. All receipts are kept by the issuer, but for efficiency reasons will be placed off-line after the users have received them (note - the transaction receipts are placed off-line, not the transactions themselves). In order that the issuer can be certain the user has received the receipt, reception of all receipts must be confirmed with signed confirmations from the users. Thereafter, users are responsible for maintaining the information.

A feature of this model is that both the user and the issuer hold transactional representations of value. Further, they hold the same essential information. Hence, there is no balance primitive available, and no need for one. It is impossible for the "balance" to be out, only for a difference in transactions to exist, which is covered by a secure delivery protocol.

Using the transactional model does introduce some complexities, in that a "roll-over" feature must be implemented in order to regularly archive away older transactions.

Payment Cancellations

A user may cancel a payment that has not yet been deposited. This is a useful method of obtaining one's status for those situations where communications have been lost just after placing an order. If the payer manages to cancel the payment, they can be sure that the payee will not be able to successfully deposit it at a later time. If the payer does not manage to cancel the payment, then this is because the payment has already been deposited, and a receipt should be available for collection. Either way, the user is certain of their status.

Cancelling a payment also turns out to be a useful feature for purchases where time is critical, one example being that of placing a bet on a sporting event. By cancelling the payment at the start of the event, the payer can be sure that the payment is not being withheld for possible deposit at a time nearer the outcome of the sporting event, thus forcing the bookmaker into accepting the bet in advance.

Transfers and Coins

Electronic transfers are achieved by the payer creating a payment and depositing it into the payers account. The payment differs from a normal payment, in that the description field need not be a hash, but can be the description itself. This allows the payee to determine the reason for the transfer.

It is possible to treat an account as a variable sized coin, although the transfer must occur between trusted parties, since there is no way for the users to prove who extracted the value from the coin.

Communication security issues

Issuer Authentication

All communications with an issuer are encrypted using the public key of the issuer, so the user can be certain of with whom they are communicating. Of course, the user needs be certain that they have the correct public key for the issuer, and this can be done by means of a certification authority, or by manually checking the fingerprint of the key. This is, however, the responsibility of the users, not of the issuer, nor of the protocol.

Message privacy and integrity

All communications are encrypted in order to prevent eavesdroppers from monitoring transmissions, and even contain random padding to make traffic analysis harder. Also, a message authentication code (MAC) is used so that both parties can be certain that no modification of the communication has occurred whilst the message was in transit.

User to user communications

User to user communications are not specified by the SOX protocols, allowing the users greater flexibility in this area. It is envisaged that these communications will be encrypted and/or signed (for example, using SSL or PGP), but it is not essential, since the payer will generally create a payment that can only be deposited by a specified payee.

How the payee obtains the correct identity of the payer is the responsibility of the payer, and could be done via a certification authority, or even manually using a second form of communication (e.g. telephone).

How the SOX system meets the requirements

SOX is based on the strength of strong algorithms to implement digital signatures, encryption and authentication. It assumes that these are infeasable to break. However, this represents a theoretical weakness. For example, weaknesses in the MD5 message digest function represent a concern. [5]

Fulfilling the security requirements

It must not be possible for anyone except the payer to create payments drawn on the payer's account.

All payments must be signed by the payer. It is the payer's responsibility to look after their secret key, and as long as they do so, it is not feasible that anyone can forge a payment from the payer.

In order that a payment cannot be deposited a second time, the issuer insists that all payments must contain an identifier, which must be unique for the validity period of the payment.

A payer must be able to prove to a third party that the payee received the payment, and what the payment was for.

After a successfull payment, a transaction receipt is provided by the issuer to the payer, and this receipt contains the signed deposit instruction from the payee. The payer can use this signed deposit instruction as electronic proof that the payee received (and deposited) the payment.

The purpose of the payment can be shown by presenting the description that matches the description hash contain in the payment.

A payee must be able to prove to a third party that it received a payment, and what the payment was for.

The payee can prove that a payment was received simply by showing the signed payment from the payer. The purpose of the payment can be shown by presenting the description that matches the description hash contain in the payment.

The issuer must be able to prove to a third party that it acted upon a payment/deposit instruction from the rightful owner of an account

The issuer will retain copies of all payment and deposit instructions from the users. Since these instructions are digitally signed, the issuer can prove it acted upon request from the user.

The payer must be able to create a payment that can only be deposited by a specified payee.

This is achieved simply by placing a the payee's ID in the payment, much as one makes a cheque payable to a specific person. The issuer will ensure that only the keyholder with this ID can deposit the payment.

It must not be possible to forge receipts from the issuer.

All receipts are digitally signed by the issuer, and as such are infeasible to forge.

All disputes between the issuer and users must be fully resolvable using the digitally signed messages.

For every transaction there exists a digitally signed instruction. In the case of a disputed transaction, the signed instruction must be presented, otherwise the transaction has not been shown to be authorised.

Disputes between users must be resolvable without involving the issuer.

All disputes between users can be resolved without involving the issuer, since after a successful transaction both parties will hold signed instructions from the other party (i.e. the payer will hold the payee's signed deposit instruction, and the payee will hold the payer's signed payment).

The system as a whole should be resistant to fraud.

It is believed that through the use of digital signatures at all stages, issuer authentication and message integrity verification, the system should be resistant to fraud from a technical standpoint.

The system should also be reasonably resistant to fraud through non-technical attacks, such as the the theft of users private key, since there is a full trail of transactions available. This is, however, somewhat dependant on circumstances.

Fulfilling the privacy requirements

Outside observers can be prevented from obtaining any useful information regarding the activities of the users.

All communications with the issuer are encrypted, and a man in the middle attack is not possible due to the host authentication. Traffic analysis can be made difficult by the use of encrypting proxies, and even by padding communications with random data.

The payee can be prevented from deriving the identity of the payer.

If the payee would like some degree of anonymity (with regard to the payer, not necessarily with regard to the issuer), the payee can create and register a new key and use this as a temporary intermediate account. Assuming that no other personal information is sent to the payee during the payer to payee communications, then the payer has achieved a fair degree of privacy.

The issuer can be prevented from deriving the purpose of payments.

An issuer does not know what a payment is for, since payments only include a hash of the payment description, not the description itself.

The issuer can be prevented from pairing-up payer withdrawals with payee deposits.

Due to the nature of the proposed system, this requirement could not be completely fulfilled. However, by creating and registering temporary keys, it is possible to confuse the issue, giving the users some degree of privacy, whilst still allowing full traceability.

Fulfilling the implementation requirements

The system should be simple.

The system does not attempt to implement any complex protocols, instead relying on simple and easy to understand concepts.

The system should be based on tried and tested technology

The system makes use of popular protocols and standards, such as PGP(tm) and HTTP. Although the PGP program is not used, many of the key formats are.

Users should be able to access issuers from behind corporate firewalls.

All communications with the issuer currently take place over HTTP connections, which should allow many corporate users access from behind their company firewall.

It must be possible for the issuer to place records off-line after a reasonable period.

It is in the issuer's interest to keep to a minimum its storage requirements. To do this, some burden is placed on the users to retain their own records. Of course the issuer will keep these records too, but they will not be as readily available, and a retrieval charge may apply. In order that the issuer can charge for access to old records, it is necessary to be able to prove that the user received the records. This is done by insisting that the user confirm received receipts before they are archived away.

Fulfilling other requirements

Flexibility - payments must be capable of representing arbitrary items

Payments can represent almost anything that the issuer wishes. The item-type field in a payment is a hash, and will usually represent a contract between the user and issuer. It is in this contract that is described what they payment represents, which can be anything ranging from an airplane to an air-mile.

Payments must be capable of having sub-cent values

Since payments can represent practically anything, the issuer can issue an item type representing 1/100th of a cent. Of course, only whole cent values can enter or leave the system, but this is not a limitation of the payment system itself.

The system as a whole should be both scalable and efficient

The payment system architecture appears to be very scalable, in that a separate issuer can be used for each type of payment, and issuers can even be split into multiple branches through the use of inter-branch clearing.

The system also appears to be quite efficient, in that storage requirements are not too large, since old records can be archived away. The encryption requirements are likewise not particularly great, and any bottlenecks in this area can be overcome by changing algorithms or using encryption hardware.

Communications with the issuer are also quite efficient, in that they are all consist of a single request and response.

Future work

Micropayments

Micropayments, based on a hash function chain, can be added relatively easily. All that is needed is for the users to generate a payment containing a hash value (the end of the hash chain), and the issuer to and payer would then give the payee need to be accompanied by a hash

Encrypting Proxies

Encrypting proxies can be used in an attempt to conceal the parties involved in a network transaction. This has already been developed, will shortly be made available.

Use from Home and Office

There are several issues to be resolved if a user wishes to use the payment system from two locations with the same key. The solution could be as simple as refusing receipts when at the office, or it could be solved with a more sophisticated "encrypted remote file system" service provided by the issuer or a third party.

Bearer bank drafts

It is possible to implement the electronic coin model on top of this payment system, by the addition of "bearer bank drafts". This would allow unconditionally untraceable payments. There are, however, many things to consider in an unconditionally untraceable payment system, and these isssues are best discussed elsewhere [6].

Transferring Keys

It is conceivable that users could transfer keys, treating them as variable sized coins. This would be another method of implementing the electronic coin model. There are however several issues to be resolved when the key transfer is between two parties who do not trust one another. In this case, it may be more suitable to use a new payment type to transfer the key.

Conclusion

The architecture of a simple and practical protocol for open network payments has been described, fulfilling all of our requirements to some degree or another.

It is believed that this system offers both issuers and users a good deal of security, and offers users a fair degree of privacy. Whilst the system as it stands does not provide unconditional untraceability, the users are given privacy through the use of temporary accounts. It is felt that this is the correct balance between the needs of users, and the needs of the issuers and authorities.

It is hoped that the flexibility of SOX, one of its major advantages over other payment systems, will lead to its use for a broad range of purposes.

Footnotes and References


(1) The secure transfer of credit card details is not classed as a payment system in the context of this paper, since a credit card holder does not generally use the credit card for receiving payments. Back

References

Written by Gary Howland, whilst with Systemics Ltd. He is now at Hot Lava. Paper Copyright © 1996 Gary Howland and Systemics Inc. All rights reserved.

[1] A micropayments system based on hash chains, such as PayWord (by Ron Rivest, MIT), is very suitable for adding to the SOX payments system. Back
[2] Achieving electronic privacy by David Chaum, Scientific American, pages 96-101, August 1992. Back
[3] During a discussion on the cypherpunks mailing list, it became clear that the price of untraceability in coin based payment system was the lost interest on deposits, since privacy can only be achieved if coins are withdrawn prior to depositing. Back
[4] PGP ("Pretty Good Privacy") is a widely used cryptographic program developed by Philip Zimmerman, and now marketed by Network Associates. Back
[5] In his 2 page paper "Cryptanalysis of MD5 Compress", published May 2 1996, Hans Dobbertin shows that there are weaknesses in the MD5 algorithm. Back
[6] A useful starting place on the issues involved in unconditionally untraceable payment systems is Marcus Jackobson's paper on revokable electronic money. ). Back

Other References

A similar hybrid system is NetCheque, NetCash, and the Characteristics of Internet Payment Services by B. Clifford Neuman and Gennady Medvinsky, presented at MIT Workshop on Internet Economics, March 1995.

A purely electronic coin payment system has been developed by Digicash bv.

Bruce Schneier: Applied Cryptography; John Wiley & Sons, 1994.

SOX, as currently implemented, uses Cryptix strong crypto software.

Systemics and SOX are trademarks of Systemics Inc. PGP is a trademark of NAI.

Copyright © 1998 Systemics Ltd. All rights reserved Mail us.