Load protocol

There are many modes of loading value onto the card, such as off-line load using Load Security Access Modules (LSAM), on-line account-based loads, and on-line non-account-based loads. In this abstract we will only cover on-line account-based loads. In the on-line account-based load, there is a payment agency involved with which the card holder has an account (or registration). The load is mediated by the payment agency, and the account is debited.

  

Figure 8: Load protocol

Informally, when a user with a card wants to load value onto his card (using an on-line account based method), he communicates with his payment agency using the load/unload device. Once a load of a particular value is requested by the card, the payment agency (which acts as a trusted party), instructs the load/unload server to load the monetary value onto the card (while guaranteeing payment). All further messages between the load/unload server and card go via the payment agency (or the client), and the payment agency and the load/unload server commit the transaction based on acknowledgments from the two end parties. The load/unload server logs the transaction, and clears the payment with the payment agency via a clearing system.

A sketch of the protocol is shown in Figure 8. There are three parties invloved: the load/unload server (LUS), the card (SM), and the payment agency (AG). The first step of the Load protocol (not shown) is itself a high level protocol between an account holder and a payment agency. This protocol ensures a monetary value transfer from the smartcard holder to the payment agency. For example, if the payment agency is your bank, this payment protocol is an electronic authorization to debit your account. As to how this protocol is defined is independent of the card-based system, except for the fact that it should be able to associate a SM ID, a unique transaction ID for this SM ID, and an amount with this transaction to be used in the composite transaction.

All the messages between SM and LUS go via the payment agency (or the load/unload client in the payment agency). However, note that in this protocol there is no way for the server ${\em LUS}$ to prove to the payment agency that the load into the card actually happened, since the key is symmetric. In other words the signature (i.e., signed ack) in the protocol--it could have been generated by the server itself. Thus, the server is assumed to be a trusted party.

The Unload protocol is symmetrically opposite to the one of Figure 8.