?? 057-059.html
字號:
<!-- Edit EirGrabber 3.01 -->
<HTML>
<HEAD>
<TITLE>Smart Card Developer's Kit:Smart Card Commands</TITLE>
<CENTER>
<TABLE BORDER>
<TR>
<TD><A HREF="../ch03/053-056.html">Previous</A></TD>
<TD><A HREF="../ewtoc.html">Table of Contents</A></TD>
<TD><A HREF="060-062.html">Next</A></TD>
</TR>
</TABLE>
</CENTER>
<P><BR></P>
<H2><A NAME="Heading1"></A><FONT COLOR="#000077">CHAPTER 4<BR>SMART CARD COMMANDS
</FONT></H2>
<P><BIG><BIG>C</BIG></BIG>hapter 3, “Some Basic Standards for Smart Cards,” examines the foundation for smart card interoperability found in a variety of international standards. Through the answer-to-reset (ATR) mechanism, a basic communication pathway is established between a reader and a smart card. This communication pathway is a half-duplex physical channel on which either the reader can talk and the card listen, or the card can talk and the reader listen. This chapter examines the establishment and use of more complex protocols on top of this physical channel.</P>
<P>Layered directly on top of the physical channel is a <I>link-level</I> communication protocol that provides an error-free connection through which the reader can initiate actions on the card by issuing a command to the card. The card can then perform some sequence of operations, as dictated by the command from the reader, and can send a response back to the reader as well as provide a status indication regarding the command. While the standards allow for the specification of 15 or more distinct link-level protocols, there are actually two primary variants of this higher level protocol in use with smart card systems today: the T=0 protocol and the T=1 protocol.</P>
<P>Once the link-level protocol (T=0, T=1, and so on) is established, application-level protocols—that make use of the link level to communicate between application elements on the card and other application elements on the reader—can be defined. The ISO/IEC 7816-4 standard defines two such application protocols: One is aimed at providing a consistent file system for the storage and retrieval of information on a card. The application programming interface (API) that constitutes this protocol encompasses a set of function calls through which the file system can be manipulated; files can be selected by name, information can be written to files, information can be read from files, and so on. A second protocol in the form of an API for accessing security services on a card is also defined by ISO/IEC 7816-4. This API allows the card and the reader to mutually authenticate each other’s identity and provides them with mechanisms through which the two sides can keep private the information that they exchange.</P>
<P>To support the application protocol APIs, a protocol message structure is defined in ISO/IEC 7816-4, through which the function calls, their associated parameters, and status response parameters are exchanged between the reader-side application and the card-side application code. This message structure is characterized by application protocol data units (APDUs), which are conveyed between the reader- and card-side application code by the link-level protocol (generally either a T=0 or a T=1 protocol).</P>
<P>While the qualitative semantics of the file access and security APIs will be described in this chapter, a more detailed description of these APIs can be found in Appendix A, “The ISO/IEC 7816-4 Command Set.”</P>
<H3><A NAME="Heading2"></A><FONT COLOR="#000077">Link-Level Protocols</FONT></H3>
<P>When talking about communications protocols, you can generally analyze the situation in terms of the OSI (Open Systems Interconnect) Reference Model, which is shown in Figure 4.1. The OSI Reference Model describes the general communication problem between two entities in terms of seven distinct protocols that layer on top of each other (hence the term <I>seven-layer model</I>) and provide a complete mechanism through which two applications on disparate platforms can effectively exchange information with each other. A central theme of the OSI Reference Model is the strict separation of layers. That is, a layer communicates only with the layer immediately above or below it through a well-defined interface, and each layer provides a specific set of services to the entire protocol stack. In the case of the T=0 and T=1 smart card protocols, the T=1 protocol fits the OSI Reference Model fairly well as a “data link” (or link-level) protocol layer, but the T=0 protocol tends to mix elements from several different protocol layers (as defined by the OSI Reference Model).</P>
<P><A NAME="Fig1"></A><A HREF="images/04-01.jpg"><IMG SRC="images/04-01t.jpg"></A>
<BR><A HREF="images/04-01.jpg"><FONT COLOR="#000077"><B>Figure 4.1.</B></FONT></A> The OSI Reference Model.</P>
<P>At this point, it should be reiterated that the reader and the card communicate through a very strict command-and-response protocol. That is, the reader-side of the link sends a command to the card, possibly including data to be used by the card in the execution of the command, and the card then executes that command and sends a response back to the reader. This response may include data resulting from the execution of the command on the card as well as a status response regarding the execution of the command. The data structures exchanged by the reader and the card in this command-and-response protocol are referred to as <I>transmission protocol data units</I> (TPDUs). The TPDU structures used in the T=0 protocol are quite different from those used in the T=1 protocol.</P>
<P>Once the T=0 or T=1 protocol is established between the reader and the card, it is used to support application-level protocols between application software on the card and application software on the reader-side of the link. These application protocols exchange information through data structures referred to as <I>application protocol data units</I> (APDUs). The details of the various TPDU and APDU structures are reviewed in the following sections. One conclusion that can be drawn from this discussion is the fact that the T=0 protocol provides very poor layer separation between the link-level protocol and the application-level protocol. Consequently, it is found that mechanisms that would normally be based on intervening protocol layers (between the application layer and the data link layer) can be extremely awkward to implement on top of the T=0 protocol. Principal among these is “secure messaging” between application software on the card with application software on the reader-side of the link. <I>Secure messaging</I> refers to the use of cryptographic techniques to limit access to information conveyed between application components on the reader-side and application elements on the card side of the channel. Specifically, only the application components on each end of the channel should be able to understand the information transferred between them; the intervening layers should simply see the information flowing as unintelligible collections of bytes.</P><P><BR></P>
<CENTER>
<TABLE BORDER>
<TR>
<TD><A HREF="../ch03/053-056.html">Previous</A></TD>
<TD><A HREF="../ewtoc.html">Table of Contents</A></TD>
<TD><A HREF="060-062.html">Next</A></TD>
</TR>
</TABLE>
</CENTER>
</BODY></HTML>
?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -