Previous | Table of Contents | Next |
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 couldnt 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.
One of the simplest e-cash protocols between a merchants till and a customers smart card is a two-stage commit protocol, which goes like this:
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 customers card has been debited does not also mean that it is okay to credit the merchants 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 merchants till is credited only after the card has been debited. A customer who is debited and receives nothing because a merchant wasnt 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 issuers point of view for money to be destroyed than for money to be minted.
Third, while you dont 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 counters 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:
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:
Previous | Table of Contents | Next |