Previous Table of Contents Next


The E-Bucks E-cash Protocol and Implementation

In our storybook world, the E-Coins and E-Money e-cash purses were sufficiently complicated that it was decided to simply put the object code implementing these purses onto the FlexCash card as soft masks. They appear as Java native function calls to the monitor. Since the code implementing these purses is exactly the same as the code on the standalone E-Coins and E-Money cards, when the application flag is set to E-Coins, the card acts like an E-Coins card. When the application flag is set to E-Money, the card acts like an E-Money card.

As it turns out, the E-Bucks e-purse was implemented for a proprietary microcontroller chip, so the object code for the E-Bucks purse couldn’t be soft masked onto the FlexCash card. Fortunately, the E-Bucks e-cash protocol was very simple and could be implemented in Java. The next section describes the simple E-Bucks e-cash protocol and the Java code that implements it.

The E-Bucks E-cash Protocol

One of the simplest e-cash protocols between a merchant’s till and a customer’s smart card is a two-stage commit protocol, which goes like this:

1.  Debit
Till: “Please debit the customer’s purse by X dollars.”
Card: “Okay”
2.  Credit
Till: “Please give me permission to credit the merchant by X dollars.”
Card: “Okay”

While this is a very simple value-transfer protocol, if it is combined with some common-sense security measures it could actually be used. Here are some of the security considerations that have to be taken into account.

First, notice that the Okay that says the customer’s card has been debited does not also mean that it is okay to credit the merchant’s till. The card must give explicit authorization to perform the credit. This is a characteristic of many e-cash protocols. Each message means exactly one thing, and the protocol proceeds exactly one step at a time.

Second, notice that the merchant’s till is credited only after the card has been debited. A customer who is debited and receives nothing because a merchant wasn’t credited will complain, whereas a merchant who receives a credit without a customer being debited will not. Said a different way, if a mistake is to be made, it is better from the card issuer’s point of view for money to be destroyed than for money to be minted.

Third, while you don’t see it here, each message from the till to the card and from the card to the till is encrypted with a shared secret key. This is to counter man-in-the-middle attacks. If all an attacker posing as a valid smart card had to do was say “okay” in plain, unencrypted text, merchandise could be purchased without a valid card being debited. Furthermore, as an extra security measure, the shared key used to debit the card could be different from the shared key used to credit the till.

Fourth, each encrypted communication from the till to the card includes a transaction number, together with a challenge generated by the card. Similarly, each encrypted communication from the card to the till includes a transaction number along with a challenge generated by the till, including a transaction number and a challenge in the message counter’s replay attacks. A replay attack grabs an encrypted message off the communication channel and, without having to decrypt it, simply sends it to the recipient again later. The recipient might think it is a valid message because it is encrypted with the proper key. For example, with unique message identifiers such as the transaction number and the random challenge, an attacker could simply grab an encrypted okay message going from the card to the till and play it back to the till whenever it asked for something.

The transaction number and the challenge are explicit indicators of whether a message is a credit or a debit message. They ensure that a debit message from the till to the card will not be turned around and sent back to the till as a credit message or vice versa.

The full, simple-but-effective E-Bucks e-cash protocol looks like this:

Till: “Receive a cardholder request to debit a proffered card. Ask the card for a transaction number and a challenge.”
Card: “Generate transaction number and challenge. Send them to the till. Remember the number and the challenge.”
Till: “Generate encrypted message containing amount of debit, the transaction number, the challenge, and the debit flag. Send this message to the card.”
Card: “Check whether the debit message is authentic by finding the previously sent challenge and transaction number along with the debit message indicator when the message is decrypted. If all is well, debit the customer’s card, remember the amount, and set a flag that a request to authorize a credit is outstanding. Send an encrypted Okay back to the till.”
Till: “Generate a transaction number and a challenge. Send them to the card with a request to authorize a credit.”
Card: “Generate an encrypted message containing the remembered amount of the transaction, the transaction number, the challenge, and the credit message indicator. Clear the credit-request-outstanding flag and send the message to the till.”
Till: “Check whether the credit message is authentic by finding the previously sent challenge and transaction number along with the credit message when the message is decrypted. If all is well, credit the merchant’s till.”

This simple e-cash protocol is implemented on the E-Bucks card using the commands shown in the following list of E-Bucks and e-cash commands:

REQUEST DEBIT
Bytecodes: E216 0016 0016 0016 0016
Parameters: None
Data: None
Reply: Status plus 2 bytes, xx yy, where xx is the E-Bucks card’s current transaction number and yy is the E-Bucks card’s challenge
MAKE DEBIT
Bytecodes: E216 0216 0016 0016 0816 zz16 zz16 zz16 zz16
Parameters: None
Data: The encryption of the amount, the E-Bucks transaction number, the E-Bucks challenge, and the debit flag
Reply: Status
REQUEST CREDIT
Bytecodes: E216 0416 xx16 yy16 0016
Parameters: The till’s transaction number, xx, and the till’s challenge, yy.
Data: None
Reply: Status plus 8 bytes, zz16 zz16 zz16 zz16, which is the encryption of the till’s transaction number, the till’s challenge, the amount of the transaction from the previous MAKE DEBIT command, and the credit flag.


Previous Table of Contents Next