?? 008-009.html
字號:
<!-- Edit EirGrabber 3.01 -->
<HTML>
<HEAD>
<TITLE>Smart Card Developer's Kit:Smart Card Programming</TITLE>
<CENTER>
<TABLE BORDER>
<TR>
<TD><A HREF="006-008.html">Previous</A></TD>
<TD><A HREF="../ewtoc.html">Table of Contents</A></TD>
<TD><A HREF="010-012.html">Next</A></TD>
</TR>
</TABLE>
</CENTER>
<P><BR></P>
<P><FONT SIZE="+1"><B>Host Programs</B></FONT></P>
<P>By far, most smart card software will be host software and will be written against existing smart cards, either commodity off-the-shelf smart cards available from smart card manufacturers or smart cards created by major smart card issuers such as bank associations, telecommunication companies, retailers, and national governments. The operating system on these widely distributed smart cards implements a characteristic set of commands—usually 20 or 30—to which the smart card responds. Host software sends commands to the card operating system that executes them on the smart card processor and returns the results. Some examples of commands are “Decrement the amount of money in purse 1 by $1.50,” “Authenticate user with PIN 1234,” and “Read and return the second record from file 5.”
</P>
<P>There are more functions you might like a smart card to perform than can fit in the resources of today’s smart cards. At this time, there is not an all-purpose smart card operating system or an all-purpose, off-the-shelf smart card. For example, some standard cards are particularly good for payment and loyalty applications, some standard smart cards are particularly good for network and cryptological applications, and some smart cards are particularly good for mobile telephone applications. Also, some off-the-shelf cards offer collections of general-purpose—if low-level—functions. One of the first tasks of a host software programmer is to choose the smart card that will be included in the system.</P>
<P>A host smart card program must accomplish two tasks before it begins to conduct business with a smart card. First, it must ensure that the smart card it is dealing with is authentic. Second, it must convince the card that it is authentic. No business can be conducted before this mutual trust has been established. Actually filling the role the smart card was intended to perform—provide some digital cash or produce a digital signature—is typically only a very small part of the total interaction between a command language host program and the smart card operating system.</P>
<H4 ALIGN="LEFT"><A NAME="Heading6"></A><FONT COLOR="#000077">High-Level Language Card Programs</FONT></H4>
<P>Late in 1996, the smart card manufacturer Schlumberger introduced the first off-the-shelf smart card that could accept and run programs written in a high-level programming language, namely Java. Until the advent of the Java Card, the only way to get software onto a smart card was to have it written and loaded into a smart card by a smart card manufacturer. This was a long, tedious, and surprisingly error-prone process. It was also a very expensive process and precluded all but the largest organizations from creating purpose-built smart cards. Some smart card manufacturers used high-level languages such as Forth and C to create card software, but the capability of using these tools to program the card itself was not passed on to the owner of the card and certainly not to the cardholder.
</P>
<P>One use of a Java program running on a smart card is to implement a specialized set of commands for use by a host program. The Java program receives commands from the host program, executes them on the card, and returns results just like the operating system in an off-the-shelf smart card. Using this technique, a Java Card can either emulate an existing non-Java Card, extend an existing card with new commands, or become a wholly new card for use by host software.</P>
<P>Theoretically, a Java smart card program could implement any command set whatsoever. However, due to both memory constraints for containing the program on the card and time constraints for running the program, the functionality of the Java program is limited by the functionality of the underlying operating system services it can call on. For example, you likely would not want to perform encryption using very secure keys purely in Java on the card (because of the computational loading on the card), but rather would call on cryptographic functionality in the native card operating system and perhaps in a crypto coprocessor in the microcomputer itself.</P>
<P>Java programs that are both stored and executed on the card have also opened up the possibility of breaking out of the master/slave relationship between host software and card software and thus have enabled new classes of smart card applications. Although the underlying communication channel is still a half-duplex channel (that is, a channel over which either end can send information to the other end, but in only one direction at a time), a smart card programmer can now arrange for the card to control and send commands to the host rather than the other way around.</P><P><BR></P>
<CENTER>
<TABLE BORDER>
<TR>
<TD><A HREF="006-008.html">Previous</A></TD>
<TD><A HREF="../ewtoc.html">Table of Contents</A></TD>
<TD><A HREF="010-012.html">Next</A></TD>
</TR>
</TABLE>
</CENTER>
</BODY></HTML>
?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -