?? 080-082.html
字號:
<!-- Edit EirGrabber 3.01 -->
<HTML>
<HEAD>
<TITLE>Smart Card Developer's Kit:Smart Card Commands</TITLE>
<CENTER>
<TABLE BORDER>
<TR>
<TD><A HREF="078-080.html">Previous</A></TD>
<TD><A HREF="../ewtoc.html">Table of Contents</A></TD>
<TD><A HREF="../ch05/083-085.html">Next</A></TD>
</TR>
</TABLE>
</CENTER>
<P><BR></P>
<P><FONT SIZE="+1"><B>The Envelope Command</B></FONT></P>
<P>The <TT>Envelope</TT> command supports the use of secure messaging via the T=0 link-level protocol. In secure messaging, the full command APDU should be encrypted. However, since the CLA and INS bytes from the APDU overlay elements of the TPDU, these bytes (in the TPDU) cannot be encrypted if the link-level protocol is still to work correctly. So the <TT>Envelope</TT> command allows a full APDU to be encrypted and then included in the <TT>Envelope</TT> command’s data section (of its APDU). The card’s APDU processor can then extract the “real” command and cause it to be executed.</P>
<P><FONT SIZE="+1"><B>The Get Response Command</B></FONT></P>
<P>The <TT>Get Response</TT> command is another command which allows the use of the T=0 link-level protocol for conveying the full range of APDUs. Specifically, the Case 4 type of APDU body cannot be supported with the T=0 protocol. That is, you can’t send a body of data to the card and then receive a body of data back as a direct response to that command. For this type of command, by using the T=0 protocol, the initial command results in a response which indicates that more data is waiting (in the card). The <TT>Get Response</TT> command is then used to retrieve that waiting data.</P>
<P>Note that no other command can be interleaved between the original command and the <TT>Get Response</TT> command.</P>
<H3><A NAME="Heading9"></A><FONT COLOR="#000077">Summary</FONT></H3>
<P>This chapter reviews the two protocol layers through which smart card-aware applications communicate between reader-side components and card-side components. The initial power-up, reset, and ATR sequence establishes a physical (half-duplex) channel between the reader and the card. The card and reader then negotiate a link-level protocol, often resolving to either a T=0 or a T=1 protocol. An application-level protocol is then established on top of the link-layer by using the APDU mechanisms defined in ISO/IEC 7816-4.
</P>
<P>Two APIs are examined qualitatively: One provides access to a file system on the smart card and the other provides access to security services on the smart card. Multiple logical channels can be supported between the reader-side application and the smart card’s APDU (file or security) processing components. Further, by using cryptographic capabilities, a rudimentary secure messaging facility can be put in place between the reader-side application components and the card-side application components.</P>
<P>A more quantitative review of the functions provided through these APIs is found in Appendix A.</P><P><BR></P>
<CENTER>
<TABLE BORDER>
<TR>
<TD><A HREF="078-080.html">Previous</A></TD>
<TD><A HREF="../ewtoc.html">Table of Contents</A></TD>
<TD><A HREF="../ch05/083-085.html">Next</A></TD>
</TR>
</TABLE>
</CENTER>
</BODY></HTML>
?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -