?? 109-112.html
字號:
<!-- Edit EirGrabber 3.01 -->
<HTML>
<HEAD>
<TITLE>Smart Card Developer's Kit:The Schlumberger Multiflex Smart Card</TITLE>
<CENTER>
<TABLE BORDER>
<TR>
<TD><A HREF="107-109.html">Previous</A></TD>
<TD><A HREF="../ewtoc.html">Table of Contents</A></TD>
<TD><A HREF="../ch06/113-117.html">Next</A></TD>
</TR>
</TABLE>
</CENTER>
<P><BR></P>
<P>From the point of view of a smart card system designer, if you put a key file in the directory of a particular application, that key file defines the keys needed to access the files for that directory and all its subdirectories. If you don’t provide key files in an application’s directory, the key files in the directories above the application define the keys needed to access the application’s files. In other words, your Multiflex card implements <I>hierarchical access control</I>.</P>
<P>In a typical scenario, there will be one PIN file in the master file that establishes cardholder authentication and access privileges throughout the card. Then there are external authentication files with each application that govern who can read data gathered by the application and the parameters of running the application.</P>
<H3><A NAME="Heading14"></A><FONT COLOR="#000077">Tracking EEPROM Usage</FONT></H3>
<P>Nonvolatile memory (NVM) is a precious resource on a smart card and you will find yourself keeping track of every byte. Each file in NVM takes up some extra administrative bytes besides the bytes you actually use. These overhead bytes describe the file, including its size, its type, and its access conditions. Furthermore, each record in a record file also contains some overhead “green bytes.” Table 5.15 gives the size of these per-file and per-record overheads:
</P>
<TABLE WIDTH="100%"><CAPTION ALIGN=LEFT><B>Table 5.15.</B> EEPROM usage in Schlumberger’s 3K Multiflex card.
<TR>
<TH WIDTH="25%" ALIGN="LEFT">File Type
<TH WIDTH="19%" ALIGN="LEFT">File Type Byte
<TH WIDTH="28%" ALIGN="LEFT">File Header Overhead
<TH WIDTH="28%" ALIGN="LEFT">Per Record Overhead
<TR>
<TD COLSPAN="4"><HR>
<TR>
<TD>Directory file
<TD>38<SUB>16</SUB>
<TD>24 bytes
<TD>
<TR>
<TD>Transparent file
<TD>01<SUB>16</SUB>
<TD>16 bytes
<TD>
<TR>
<TD>Record file with fixed-length records
<TD VALIGN="TOP">02<SUB>16</SUB>
<TD VALIGN="TOP">16 bytes
<TD VALIGN="TOP">4 bytes
<TR>
<TD>Record file with variable-length records
<TD VALIGN="TOP">04<SUB>16</SUB>
<TD VALIGN="TOP">16 bytes
<TD VALIGN="TOP">4 bytes
<TR>
<TD>Cyclic file
<TD>06<SUB>16</SUB>
<TD>16 bytes
<TD>4 bytes
<TR>
<TD COLSPAN="4"><HR>
</TABLE>
<P>The information we received back from selecting the master file said that there were 2,832 unused bytes on what is advertised as a 3,008 byte Multiflex card. Where are the 176 missing bytes? The numbers in Table 5.16 and a little extra knowledge of the Multiflex operating system give a full accounting of the missing 176 bytes.
</P>
<TABLE WIDTH="100%"><CAPTION ALIGN=LEFT><B>Table 5.16</B> Overhead bytes in the virgin 3k Multiflex card.
<TR>
<TH WIDTH="70%" ALIGN="LEFT">Description
<TH WIDTH="30%" ALIGN="LEFT">Overhead
<TR>
<TD COLSPAN="2"><HR>
<TR>
<TD>Operating system
<TD>26 bytes
<TR>
<TD>Header information for master file (3F00)
<TD>24 bytes
<TR>
<TD>Header information for serial number file (0002)
<TD>16 bytes
<TR>
<TD>Contents of serial number file (0002)
<TD>8 bytes
<TR>
<TD>Header information for protection key file (0011)
<TD>16 bytes
<TR>
<TD>Contents of transport key file
<TD>38 bytes
<TR>
<TD>Flags, testing, random number generator, ATR
<TD>48 bytes
<TR>
<TD>Total
<TD>176 bytes
<TR>
<TD COLSPAN="2"><HR>
</TABLE>
<H3><A NAME="Heading15"></A><FONT COLOR="#000077">Summary</FONT></H3>
<P>This chapter is by no means a substitute for complete documentation of the 3K Multiflex card. Complete documentation would cover every bit of every command, in every file and every card state, condition, and response. Here we have merely tried to give you a first-hand sense for the mind-set of a smart card by considering in detail a few selected features of one real one. Above all, observe that a smart card is very suspicious. Its basic attitude is to trust no one and to always assume that there are hostile forces out there trying to trick it.
</P>
<P>Your task as a smart card application programmer is to mold this suspicious attitude to your particular situation; to allow the card to trust just enough to get the job done but no more. Initially, you will probably err on the side of trusting too much; of not putting in enough protection; of not tailoring the access conditions carefully enough. It is a lot easier to think about how to get a job done than it is to think about how to prevent somebody from not doing the job correctly. After you’ve designed your smart card application, it will be a good idea to give it to a cantankerous friend and challenge them to break it.</P><P><BR></P>
<CENTER>
<TABLE BORDER>
<TR>
<TD><A HREF="107-109.html">Previous</A></TD>
<TD><A HREF="../ewtoc.html">Table of Contents</A></TD>
<TD><A HREF="../ch06/113-117.html">Next</A></TD>
</TR>
</TABLE>
</CENTER>
</BODY></HTML>
?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -