?? 017-019.html
字號:
<!-- Edit EirGrabber 3.01 -->
<HTML>
<HEAD>
<TITLE>Smart Card Developer's Kit:Smart Card Programming</TITLE>
<CENTER>
<TABLE BORDER>
<TR>
<TD><A HREF="015-017.html">Previous</A></TD>
<TD><A HREF="../ewtoc.html">Table of Contents</A></TD>
<TD><A HREF="019-020.html">Next</A></TD>
</TR>
</TABLE>
</CENTER>
<P><BR></P>
<H3><A NAME="Heading16"></A><FONT COLOR="#000077">Smart Card System Design</FONT></H3>
<P>Most smart card programming consists of writing programs on a host computer that send commands to and receive results from predefined or application-specific smart cards. These applications read data from and write data to the smart card and perhaps make use of the modest computing powers of the processor on the smart card. Smart cards in these applications are typically secure stores for data pertaining to the individual bringing the card to the system, such as personal identification data.
</P>
<P>In situations where no off-the-shelf card contains all the functionality needed by the application, the programmer may be able to extend the capabilities of an off-the-shelf card by writing software that runs on the card itself. This software may implement special-purpose or higher-level functions on the card that is a combination of existing operating system functions, or it may provide additional protections for the data stored on the card.</P>
<P>Finally, there may be situations where the operating system capabilities of an existing smart card need to be extended, or where a new and unique smart card needs to be manufactured. Examples of such situations include a closed system application where cost or a particularly high level of security is a critical factor, or where a particular encryption algorithm is needed to connect the smart card to an existing host system. In these situations, smart card programmers write new operating system software for smart cards partially or completely in the assembly language of the processor on the smart card.</P>
<P>Regardless of the type of software being written, the smart card programmer must be constantly aware of the two central concerns of smart card software: data security and data integrity.</P>
<H4 ALIGN="LEFT"><A NAME="Heading17"></A><FONT COLOR="#000077">Data Security</FONT></H4>
<P>Data security means simply providing data only to those who are authorized to receive it. It requires that neither data values nor even information about these data values are revealed to unauthorized parties or systems. Wherever data is stored and whenever data is moved, the smart card programmer must ensure that this requirement is satisfied.
</P>
<P>Although there are many methods for obscuring data, data security doesn’t make use of data encryption as much as it does the notion of an authorized entity. One of the most obvious attacks on a smart card is for an unauthorized entity to become authenticated as an authorized entity, then use the provided facilities of the card to access data. Because keys, passwords, and PINs stored on the card are all used to authenticate entities, particular care must be exercised in protecting this kind of data.</P>
<P>One way to ensure the data security of a smart card is to control physical access to the card. This technique is often used early in the life cycle of the card. For example, cards are manufactured under tight physical security procedures and shipped to the card customer under equally tight procedures. The keys used to protect the card during transit from manufacturer to customer are called <I>transport keys</I> and they are given only to the customer. Using the transport keys, a smart card customer can access all files on the smart card and set up a particular file system and access authorization scheme. Transport keys are like a superuser password for the card and are typically deleted from the card by the customer after they have been used to configure the card for the customer’s application.</P>
<H4 ALIGN="LEFT"><A NAME="Heading18"></A><FONT COLOR="#000077">Data Integrity</FONT></H4>
<P>Data integrity requires that all parties to a smart card transaction agree on the state of the data in the transaction. If vending machine software intends to charge a smart card electronic purse $1 for a can of soda, then at the end of the transaction, there should be $1 less on the smart card, $1 more in the vending machine, and a soda in the hands of the cardholder. Any variation—$1 added but $1 not subtracted, $1 transferred, but no soda vended, and so on—is a violation of data integrity.
</P>
<P>The primary source of breakdowns in data integrity are system failures in the middle of processing a transaction. Such failures can be accidental—for example, when a communication line from an ATM goes down—or deliberate—for example, when the cardholder prematurely removes the smart card from the reader. Programming to ensure data integrity means both guarding against its loss and detecting and repairing its loss when it occurs.</P>
<H3><A NAME="Heading19"></A><FONT COLOR="#000077">Smart Card System Architectures</FONT></H3>
<P>Because it carries neither power nor clock, there is no such thing as a stand-alone smart card. All smart cards are integrated into larger systems that themselves typically contain additional computers and data stores. For example, an ATM system will include a computer in each ATM machine, transaction servers to concentrate requests coming from many ATMs, and database machines that contain identity and account information. In fact, it is in large, distributed, multiparty systems where smart cards play one of their unique roles as a secure identity token.
</P>
<P>There have been a number of efforts to specify and de facto standardize smart card systems in addition to just smart cards themselves. Three bank card associations, Europay, MasterCard, and Visa, teamed up in early 1996 to produce EMV’96, which specifies an overall system architecture for debit and credit card applications of smart cards. Late in 1996, a work group—headed by Microsoft and including Schlumberger, Bull CP8 Transac, Hewlett-Packard, and Siemens Nixdorf Information Systems—produced a specification called PC/SC (personal computer/smart card) for connecting smart cards to personal computers and for surfacing application program interfaces to smart cards on personal computers. Next, in early 1997, IBM published a specification called the Open Smart Card Architecture and the Open Group published an architecture for Personal Security Modules. Finally, version 2.0 of the Secure Electronic Transactions (SET) specification published by MasterCard and Visa in the summer of 1997 contains yet another smart card system architecture specification based on the EMV specification and specifically tailored for credit and debit applications of smart cards.</P>
<P>One of the design challenges for a smart card programmer is distributing system functionality among the multiple computers that deal with a smart card and with which a smart card must deal. Deciding what functions go on the smart card itself, what functions go on the machine into which the smart card is inserted, and what functions go on the various machines upstream from the terminal machine comprises the heart of the application design process. Not surprisingly, these are not solely technical decisions; they directly affect both the business interests and security concerns of owners of all these various computers.</P><P><BR></P>
<CENTER>
<TABLE BORDER>
<TR>
<TD><A HREF="015-017.html">Previous</A></TD>
<TD><A HREF="../ewtoc.html">Table of Contents</A></TD>
<TD><A HREF="019-020.html">Next</A></TD>
</TR>
</TABLE>
</CENTER>
</BODY></HTML>
?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -