With the advent of computational grids, cluster owners are making their compute resources available to users outside of their own organisation. However, the provision of these resources is not without cost, both in maintenance and overheads. Owners may want to recoup these costs from their users. One solution is a micropayments system where users pay a charge based on the submitted compute job. We can develop such a system on top of Secure WebCom, using the naming and security infrastructures as the base.
Micropayments schemes are intended to support very low-value payments, in the order of C0.01, or less. Micropayment schemes [17, 35, 142] typically rely upon the notion of a digital coin that represents a fraction of a pre-agreed contract. Each coin is linked to this contract, and can only be redeemed when the coin is presented with the contract.
One means to support a micropayment system is through the use of one-way hash functions, such as MD5 [151] or SHA1 [91]. These hash functions are designed so that they are easy to compute, but computationally difficult to reverse. One way hash-based micropayment schemes [17, 37, 142] typically operate as follows: a payer (the principal making the payment) generates a fresh random seed s, and computes hn(s), where h() is a cryptographic one-way hash function. If s is
known only to the payer, then([hn−1(s), n − 1, val] . . . [h1(s), 1, val]) provides an ordered chain
of micropayments, each one worth val. Initially, the payer provides a payee with[hn(s), n, val],
which acts as a contract for(n − 1) micropayments.
As the seed is known only to the payer, and the hash function is computationally difficult to reverse, coins cannot be forged. Furthermore, as contracts are crytographically signed, presumably with strong cryptographic algorithms, they cannot be forged. Therefore, once a coin is presented for payment, the payer cannot repudiate the payment; only he could have given the payee the coin, and so the coin should be redeemed.
A payee (the principal receiving the payment) who has securely received i micropayments,
([hn−1(s), n − 1, val] . . . [hn−i(s), n − i, val]), can use the hash function h() to check their validity
against the initial contract. Since h() is a one-way hash function it is not feasible for the payee to
forge or compute the next(i + 1)thpayment (before it is paid). Micropayments may be cashed in at
any time; the payer keeps track of contracts issued, and any payments made, to guard against double spending.
Example 8.1 Consider an online business where a company, represented by public key KCompis providing a service to a customer, represented by key KCust. Figure 8.2 shows a simple micro-
payment protocol. The customer is trusted by the company to create payment contracts that the company will later redeem. KComphas received a contract from KCust. KCustsends KCompn− i
8.2 Micropayments 147 KCust KComp - {KComp, hn(s)}KCust - hn−1(s) - hn−2(s) - hn−i(s)
Figure 8.2: Making Micropayments
The company will later redeem these payments by presenting the contract along with the last coin received by the customer.
△
This approach to micropayments has been proposed and used in payment schemes proposed by [17, 37, 142]. For example, in [17], the payer threads digital coins (issued by a bank) through the hash chain such that each micropayment reveals an authentic digital coin that can be reimbursed by the original bank.
8.2.1 Micropayments in KeyNote
We use the KeyNote trust management system [29] to provide support for micropayment authori- sation of services between public keys across networks. This architecture writes the micropayment contracts in terms of KeyNote credentials. The payer writes a contract credential for the payee, stating the terms of the contract, for example the value of each coin. This credential is used by the payee to ensure the validity of any coin received and is presented, along with the coins received, by the payee, when redeeming the contract.
Example 8.2 A company (public key KComp) expects payments for providing services X and Y. They trusts banks Bank1 or Bank2 to guarantee payments for the customers of their services up to a certain limit ( C50.00). This is expressed by the KeyNote policy credential in Figure 8.3.
Authorizer: "POLICY"
Licensees: "kBank1" || "kBank2" Conditions: @Val * Num <= 50.0 &&
Service == "X" || Service == "Y"; Figure 8.3: The Company’s Policy
This policy credential defines the conditions under which the public keys KBank1and KBank2
are trusted by the company. These conditions are defined in terms of attributesVal(micropayment value val), Num(number of micropayments n in contract) and Service. Figure 8.4 provides a micropayment contract credential that a customer (public key KCust) buys from Bank1. It is signed
by the owner of public key KBank1, delegating authority over the contract to the customer.
Authorizer: "kBank1" Licensees: "kCust"
Conditions: @Val==0.01 && Num=1000 && Contract == "tIyJelErKyLtYoIJQPw/bQ=="; Signature: ....
Figure 8.4: Customer’s Contract Credential
Attribute Contract provides the initial contract value [hn(s), n, val] where s is the secret
seed known only to the bank and customer. This particular contract is for a maximum of 1,000 micropayments valued at C0.01 each. Alternatively, the bank could decide to write a different credential that delegates authority to generate contracts directly to the customer.
When requesting service X, the customer provides[h1000−i(s), ...] as the ith micropayment to
Alice; in this case we assume that KCusthas already made payments[h999(s), ...] to [h999−i(s), ...]
to the company. The company uses the trust management system to determine, given the creden- tials, whether the customer is authorised for the particular request. Attribute bindings [V al =
0.001; N um = 1000; Service = X; Contract = hi(v)] define the circumstances of the request.
The company uses the KeyNote query engine to search for a delegation chain that links the trusted key KBank1(from her policy credential) to KCust(the requester) and satisfies the circumstances of
the request. △
By casting micropayments in terms of trust management, we obtain a framework that provides flexibility in managing complex payment and service authorisation trust relationships. For exam- ple, the company might decide to out-source their support for service X to Alice by writing an appropriate KeyNote credential that delegates their authority (contract with the customer) to Alice. Similarly a bank can create contract credentials for customers, who can then delegate these contract credentials to their service providers. In such an architecture, the service provider can then invoice the bank directly, by providing both contract credentials.
Example 8.3 Figure 8.5 shows a simple payment invoicing protocol. As before KComp has re-
ceived a contract from KCust. KCustsends KCompn−i micropayments using this contract. KComp
wishes to claim for these payments and so must invoice KCust. KCompgenerates an invoice detail-
ing the last hash received, the number of payments that are being claimed, and a time-stamp of this transaction. KCompsigns this invoice and sends it to KCust, with a copy of the original contract.
8.2 Micropayments 149 KBank KCust - {KCust, hn(s)}KBank - hn−1(s) - hn−2(s) - hn−i(s)
{KBank, hn−i(s), n − i, timestamp}KCust,
{KCust, hn(s)}KBank Figure 8.5: Invoicing
KCust now checks the validity of the contract, and that no claims for invoiced payments have
been made before. Once KCustis happy with the transaction KCompis credited with the required
payment. △
8.2.2 Security Analysis
There are several security risks associated with the micropayment scheme outlined above. These include the risk of double spending, where a bank’s customer attempts to use the same contract to pay multiple service providers; and the risk of double invoicing, where the service provider attempts to cash in the same contract multiple times.
Double spending is difficult to prevent in a distributed environment. However, this can be de- tected after the fact when the second service provider attempts to redeem the contract. At this point, a dispute resolution protocol will be used. In the case of a customer attempting to spend the same contract multiple times, the fact that both of the service providers hold a signed credential from the customer, delegating the contract to that provider, proves that the customer is attempting fraud.
Double invoicing is a simpler problem to address. As each invoice is presented to the bank, the bank can check to ensure that this contract has not been previously redeemed. This requires that the bank must store all redeemed contract credentials for all time. However, this cost can be reduced when the contract credentials are only valid for a fixed time period. The bank must only then store redeemed contracts that are still valid.
8.2.3 Micropayments in Secure WebCom
We can implement this scheme in Secure WebCom by modifying the trust management-based se- curity manager so that it explicitly supports micropayments [64]. The micropayments security manager maintains a database of received coins, along with a list of current contracts. When a node
is scheduled to a WVM for execution, it must be accompanied by a digital coin, called a cyclot. This coin forms part of the domain tuple of the node name, such as the name shown in Figure 8.6. The information contained in such names is used by the access control mechanism to enforce the
(Snam
(Lnam ["kBank1","kCust","Contract 9LIwhTqls1ZuKdgfgHcSzQ==" "Iter 10","Cyclot Xnd5ft1qHlEoU9k91/rf1A=="]) (Lnam ["kBank1","kCust","kAlice","SampleAp")
(Lnam ["kBank1","kCust","SampleAp","SampleOp"]) [(Lnam ["kBank1","kCust","SampleAp","InputOp"])] [(Lnam ["kBank1","kCust","SampleAp","OutputOp"])] )
Figure 8.6: A Node Name including a digital coin
pay-per-execute requirement. In this example, KBank1 has created a contract for KCust, who is
using this contract to pay KAliceto execute applicationSampleAp.
The security manager extracts the contract, iteration and cyclot information from the name. This information could form the base of a trust management check, as described in Section 8.2.1, or using a very simple access control mechanism, calculate whether hashing theCyclotvalueItertimes results in theContracthash.
Using the trust management mechanism, the initial overhead incurred by a WebCom server when computing a micropayment contract for a client is offset by the subsequent computational burden that is off loaded (and paid for, task by task) to the client. Client side checking of payments carries minimal overhead, becoming part of the existing credential based authorisation check. It is possible that the child can cache the last valid coin they receive and, therefore, only need to compute one hash to ensure the next coin is valid, without requiring a trust management check.
8.2.4 Discussion
Blaze et al [35, 95] use KeyNote to manage trust for a micro-billing based payment scheme. Their scheme is similar to IBM’s minipay scheme [86], whereby a credential represents an electronic cheque issued by the authoriser to the licensee. KeyNote is used by the payer (merchant) to deter- mine whether or not an off-line payment from a particular payee (customer) should be trusted, or whether the payee should go online to validate the payment and payee. The scheme is intended for small value payments (under $1.00). Since each payment transaction requires a public key crypto- graphic operation it may not be practical for very small payments where the cost of processing is high relative to the value of the payment.
In [163], Shirkly argues that micropayments struggle to attain widespread usage because of their very nature. He states that users require “predictable and simple pricing” whereas micropayments “waste the user’s mental effort in order to conserve cheap resources”. When a user interacts with