📄 262-265.html
字号:
<!-- Edit EirGrabber 3.01 -->
<HTML>
<HEAD>
<TITLE>Smart Card Developer's Kit:The FlexCash Card: An E-commerce Smart Card Application</TITLE>
<CENTER>
<TABLE BORDER>
<TR>
<TD><A HREF="257-262.html">Previous</A></TD>
<TD><A HREF="../ewtoc.html">Table of Contents</A></TD>
<TD><A HREF="265-268.html">Next</A></TD>
</TR>
</TABLE>
</CENTER>
<P><BR></P>
<H3><A NAME="Heading6"></A><FONT COLOR="#000077">The E-Bucks E-cash Protocol and Implementation</FONT></H3>
<P>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 <TT>E-Coins</TT>, the card acts like an E-Coins card. When the application flag is set to <TT>E-Money,</TT> the card acts like an E-Money card.</P>
<P>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.</P>
<H4 ALIGN="LEFT"><A NAME="Heading7"></A><FONT COLOR="#000077">The E-Bucks E-cash Protocol</FONT></H4>
<P>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:
</P>
<DL>
<DD><B>1.</B> Debit
<BR>Till: “Please debit the customer’s purse by <I>X</I> dollars.”
<BR>Card: “Okay”
<DD><B>2.</B> Credit
<BR>Till: “Please give me permission to credit the merchant by <I>X</I> dollars.”
<BR>Card: “Okay”
</DL>
<P>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.
</P>
<P>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.</P>
<P>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.</P>
<P>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.</P>
<P>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 <I>replay attack</I> 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.</P>
<P>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.</P>
<P>The full, simple-but-effective E-Bucks e-cash protocol looks like this:</P>
<DL>
<DD>Till: “Receive a cardholder request to debit a proffered card. Ask the card for a transaction number and a challenge.”
<DD>Card: “Generate transaction number and challenge. Send them to the till. Remember the number and the challenge.”
<DD>Till: “Generate encrypted message containing amount of debit, the transaction number, the challenge, and the debit flag. Send this message to the card.”
<DD>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.”
<DD>Till: “Generate a transaction number and a challenge. Send them to the card with a request to authorize a credit.”
<DD>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.”
<DD>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.”
</DL>
<P>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:
</P>
<DL>
<DD><TT>REQUEST DEBIT</TT>
<DD>Bytecodes: E2<SUB>16</SUB> 00<SUB>16</SUB> 00<SUB>16</SUB> 00<SUB>16</SUB> 00<SUB>16</SUB>
<DD>Parameters: None
<DD>Data: None
<DD>Reply: Status plus 2 bytes, <I>xx yy</I>, where <I>xx</I> is the E-Bucks card’s current transaction number and <I>yy</I> is the E-Bucks card’s challenge
<DD><TT>MAKE DEBIT</TT>
<DD>Bytecodes: E2<SUB>16</SUB> 02<SUB>16</SUB> 00<SUB>16</SUB> 00<SUB>16</SUB> 08<SUB>16</SUB> zz<SUB>16</SUB> zz<SUB>16</SUB> zz<SUB>16</SUB> zz<SUB>16</SUB>
<DD>Parameters: None
<DD>Data: The encryption of the amount, the E-Bucks transaction number, the E-Bucks challenge, and the debit flag
<DD>Reply: Status
<DD><TT>REQUEST CREDIT</TT>
<DD>Bytecodes: E2<SUB>16</SUB> 04<SUB>16</SUB> xx<SUB>16</SUB> yy<SUB>16</SUB> 00<SUB>16</SUB>
<DD>Parameters: The till’s transaction number, xx, and the till’s challenge, yy.
<DD>Data: None
<DD>Reply: Status plus 8 bytes,
<I>zz</I><SUB>16</SUB> <I>zz</I><SUB>16</SUB> <I>zz</I><SUB>16</SUB> <I>zz</I><SUB>16</SUB>, which is the encryption of the till’s transaction number, the till’s challenge, the amount of the transaction from the previous <TT>MAKE DEBIT</TT> command, and the credit flag.
</DL>
<P><BR></P>
<CENTER>
<TABLE BORDER>
<TR>
<TD><A HREF="257-262.html">Previous</A></TD>
<TD><A HREF="../ewtoc.html">Table of Contents</A></TD>
<TD><A HREF="265-268.html">Next</A></TD>
</TR>
</TABLE>
</CENTER>
</BODY></HTML>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -