Check out the new USENIX Web site. next up previous
Next: The client software distribution Up: The Resilient On-line Transaction Previous: The Resilient On-line Transaction

The registration procedure

Let us assume that a customer has an account with a bank. The registration procedure has two steps: a registration with a bank and a registration with a merchant. First, the customer generates a random number tex2html_wrap_inline264 , chooses a secret p, and calculates a hash C := H(n,b) of her name n and date of birth b. If the combination of n and b is not sufficient to identify a customer from others, one may add more detailed information. The customer writes tex2html_wrap_inline264 , B, and C on a diskette for private use, say tex2html_wrap_inline284 , and writes C and tex2html_wrap_inline288 on a different diskette for registration, say tex2html_wrap_inline290 . Then she sends tex2html_wrap_inline290 to the bank B with her account number a, e.g. by registered mail or personal delivery to a branch of the bank.

When the diskette tex2html_wrap_inline290 is received, the bank makes a link between the customer's account and tex2html_wrap_inline300 , and sends an acknowledgement with a random tex2html_wrap_inline302 back to the customer. The customer stores tex2html_wrap_inline302 on her private diskette tex2html_wrap_inline284 . This is the registration procedure with the bank.

The registration procedure with the merchant is as follows: The customer generates a random number tex2html_wrap_inline308 , stores it on her private diskette tex2html_wrap_inline284 , and then sends the merchant a diskette tex2html_wrap_inline312 containing C and tex2html_wrap_inline316 in the same way as in the above procedure. Then the merchant registers the customer's information on his database, and sends an acknowledgement with a unique merchant secret tex2html_wrap_inline318 back to the customer. tex2html_wrap_inline318 is a uniquely issued value for each customer, and will be used for verification of the merchant in transactions by a bank. The customer stores tex2html_wrap_inline318 on tex2html_wrap_inline284 , calculates tex2html_wrap_inline326 , and sends tex2html_wrap_inline328 with the merchant name M to the bank. Then the bank constructs tex2html_wrap_inline332 with tex2html_wrap_inline318 and tex2html_wrap_inline300 , and adds tex2html_wrap_inline332 and M to the customer's information.

In this procedure, since we have not assumed secure communication paths between the customer and the merchant/bank, we used physical transfer of shared secrets by diskette. If a secure path is available such as SSL/TLS [DA97] or SSH [Ylö96], we can replace diskette transfer by such a path. As a further alternative, the customer can send tex2html_wrap_inline342 to the merchant in a physical transaction between her smartcard and the merchant terminal.

Thus the customer can establish a relationship with a merchant either when she is on the merchant's premises, or when she has a secure link to the merchant, or when the bank is on-line. At the same time, the customer could establish a payment limit for the merchant (though we omit the details).

In some cases like closed user group services, the merchant needs to authenticate the customer's eligibility for the service. During the registration procedure, the merchant can request appropriate information such as a membership, age, etc., for the verification and provide classified services in the transaction procedure up to customers' eligibility.

PROTOCOL


next up previous
Next: The client software distribution Up: The Resilient On-line Transaction Previous: The Resilient On-line Transaction

Jong-Hyeon Lee, Computer Laboratory, University of Cambridge, 1998.