?? 064-068.html
字號:
<!-- Edit EirGrabber 3.01 -->
<HTML>
<HEAD>
<TITLE>Smart Card Developer's Kit:Smart Card Commands</TITLE>
<CENTER>
<TABLE BORDER>
<TR>
<TD><A HREF="062-064.html">Previous</A></TD>
<TD><A HREF="../ewtoc.html">Table of Contents</A></TD>
<TD><A HREF="068-071.html">Next</A></TD>
</TR>
</TABLE>
</CENTER>
<P><BR></P>
<P>Each time a command TPDU is sent from the reader to the card, a response TPDU is returned from the card to the reader. This response TPDU is made up of a number of procedure bytes. The first byte of this TPDU is an ACK byte. This byte is a repeat of the INS byte from the command TPDU to which this response is made. The second byte is the NULL byte. This byte is a way for the card to mark time while it processes the indicated command. While it is processing, the reader-side of the channel is waiting for the response TPDU. If the response does not arrive within a specified time-out period, the reader may start an RST sequence to reinitialize the protocol between the reader and the card. This is prevented if at least one <TT>NULL</TT> byte is received by the reader from the card.</P>
<P>SW1 is a status byte from the card to tell the reader the result of the requested instruction. The allowed values for SW1 are actually defined as part of the application protocol. For certain instructions, the card may have data bytes to be returned to the reader. In this case, a second status byte labeled SW2 is returned to the reader. This acts as a trigger for the reader to now execute another command called a <TT>GetResponse</TT> command, which will actually return the data bytes generated by execution of the previous command.</P>
<P>As you can see, the T=0 protocol is a relatively optimized protocol for moving commands and responses between the card and reader. It tends to blur the distinctions between the application-layer protocol and the link-layer protocol, with many of its constituent elements actually being defined within the application-layer protocol.</P>
<H4 ALIGN="LEFT"><A NAME="Heading4"></A><FONT COLOR="#000077">The T=1 Protocol</FONT></H4>
<P>The T=1 protocol is a block-oriented protocol. This means that a well-defined collection of information—or <I>block</I>—is moved as a single unit between the reader and the card. Embedded within this block structure may be an APDU defined for a specific application. This facility is a good illustration that the T=1 protocol provides excellent layering between the link protocol layer and the application protocol layer. Moving information in a block, however, requires that the block be transferred (between the reader and the card) error free, or else the protocol can easily get lost. The error detection and correction, then, is a significantly more complex operation than was the case with the T=0 protocol.</P>
<P>Error detection in the T=1 protocol is done by using either a <I>longitudinal redundancy character</I>, which is essentially a slightly more complex form of parity checking than was done in the T=0 protocol, or by using a <I>cyclic redundancy check</I> character, which is guaranteed to detect any single-bit errors in a transmitted block. The specific CRC algorithm used is defined in detail in the ISO 3309 standard. When an error is detected within a block by the received end of the channel, it signals the transmitting end to repeat sending the block received in error.</P>
<P>The T=1 protocol makes use of three different types of blocks, as illustrated in Figure 4.3. Each has the same structure, but serves a different purpose:</P>
<DL>
<DD><B>•</B> Information block—This block is used to convey information between application software in the card and application software on the reader-side of the channel.
<DD><B>•</B> Receive ready block—This block is used to convey either positive or negative acknowledgments from one end of the channel to the other. A positive acknowledgment indicates that a block was correctly received while a negative acknowledgment indicates that an error was detected (via checking the LRC or CRC) in the received block.
<DD><B>•</B> Supervisory block—This block is used to convey control information between the card and the reader.
</DL>
<P><A NAME="Fig3"></A><A HREF="images/04-03.jpg"><IMG SRC="images/04-03t.jpg"></A>
<BR><A HREF="images/04-03.jpg"><FONT COLOR="#000077"><B>Figure 4.3.</B></FONT></A> T=1 protocol components.</P>
<P>Each T=1 block comprises three fields:
</P>
<DL>
<DD><B>•</B> Prologue field—A mandatory field in the block which is 3 bytes in length. It includes the following three elements:
<DL>
<DD><B>•</B> NAD—Node address
<DD><B>•</B> PCB—Protocol control byte
<DD><B>•</B> LEN—Length
</DL>
<DD><B>•</B> Information field—An optional field in the block that may be up to 254 bytes in length.
<DD><B>•</B> Epilogue field—A mandatory field in the block that is either 1 or 2 bytes in length.
</DL>
<P>The NAD element is used to identify the addresses of the source of the block and the intended destination for the block. This addressing facility is of greatest use when the T=1 protocol is being used to support multiple logical connections between the card and multiple application connection points on the reader-side of the channel. When used, the NAD contains two subfields:
</P>
<DL>
<DD><B>•</B> SAD—Source address is indicated by the low order three bits of the NAD byte.
<DD><B>•</B> DAD—Destination address is indicated by bits five through seven of the NAD byte.
</DL>
<P>In situations where multiple logical channels are not being used, the NAD field is set to all zeros. The two other bits of the NAD byte, those not used for the SAD or the DAD, are used to convey information related to controlling the V<SUB>PP</SUB> (EEPROM programming power).</P>
<P>The PCB element is used to indicate the type of block (either an information, a receive ready, or a supervisory block). The 2 high-order (most significant) bits of the PCB byte are used to denote the various types:</P>
<DL>
<DD><B>•</B> A high-order bit set to <TT>0</TT> indicates an information block.
<DD><B>•</B> The 2 high-order bits set to <TT>1</TT> indicates a supervisory block.
<DD><B>•</B> The high-order bit set to <TT>1</TT> and the next bit set to <TT>0</TT> indicates a receive-ready block.
</DL>
<P>T=1 is a relatively complex protocol. For purposes of this discussion, the protocol is viewed as was the T=0 protocol; that is, as a reliable channel for moving APDUs between application software elements on the card and on the reader-side of the communication channel. The other protocols that can be defined through the ATR or PTS sequence (that is, T=2, …, T=14, T=15) serve this same purpose.
</P>
<H3><A NAME="Heading5"></A><FONT COLOR="#000077">Application-Level Protocols</FONT></H3>
<P>The ISO/IEC 7816-4 standard moves from the realm of defining base system functionality for smart cards into the realm of functionality directly useful to application software found on the smart card. Two areas of functionality are addressed:
</P>
<DL>
<DD><B>•</B> First, a file system is defined with a completely specified hierarchical structure. A set of functions are defined; these functions comprise an API through which application software on the reader-side of the channel can access the files and information in those files within this file system.
<DD><B>•</B> Second, a series of security functions are defined which can be used to limit access to application software on the card or to files and information in those files within the card’s file system.
</DL>
<P><BR></P>
<CENTER>
<TABLE BORDER>
<TR>
<TD><A HREF="062-064.html">Previous</A></TD>
<TD><A HREF="../ewtoc.html">Table of Contents</A></TD>
<TD><A HREF="068-071.html">Next</A></TD>
</TR>
</TABLE>
</CENTER>
</BODY></HTML>
?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -