iso-iec 7816-4 (first edition 1995-09-01).htm

7816协议

<H4><A NAME="ss5_2">5.2 Security architecture of the card</A></H4>
<P>
This clause describes the following features :
<UL>
<LI>security stataus,
<LI>security attributs,
<LI>security mechanisms.
</UL>
Security attributes are compared with the  security status to execute command and/or to access files.
<P>
<H5><A NAME="ss5_2_1">5.2.1 Security status</A></H5>
<P>
Security status represents the current state possibly achieved after completion of
<UL>
<LI>answer to reset (ATR) and possible protocol type selection (PTS) and/or
<LI>a single command or a sequence of commands possibly performing
authentication procedures.
</UL>
The security status may also result from the completion of a security procedure related to the identification of the
involved entities, if any, e.g.
<UL>
<LI>by proving the knowledge of a password (e.g. using a <A
HREF="iso7816_4.html#ss6_12">VERIFY command</A>)
<LI>by proving the knowledge of a key (e.g. using a <A HREF="iso7816_4.html#ss6_15">GET CHALLANGE command</A>
followed by an <A HREF="iso7816_4.html#ss6_14">EXTERNAL AUTHENTICATE command</A>)
<LI>by secure messaging (e.g. message authentication)
</UL>
Three security statuses are considerd :
<UL>
<LI>Global security status - It may be modified by the completion of an MF-related authentication procedure (e.g.
entity authentication by a password or by a key attached to the MF).
<LI>File-specific security status - It may be modified by the completion of a
DF-related authentication procedure (e.g. entity authentication by a password
or by a key attached to the specific DF). It may be maintained, recovered or
lost by file selection (see 6.10.2) this modification may be relevant only for
the application to which the authentication procedure belongs.
<LI>Command-specific status - It only exists during the execution of a command
involving authentication using secure messaging (see 5.6): such a command may
leave the other security status unchanged
</UL>
If the concept of logical channels is applied, the file specify security status may depend on the logical channel (see 5.5.1).
<P>
<H5><A NAME="ss5_2_2">5.2.2 Security attributes</A></H5>
<P>
The security attributes, when they exist, define the allowed actions and the
procedures to be performed to complete such actions.
<P>
Security attibutes may be associated with each file and fix the security conditions that shall be satisfied to allow
operations on the file. The security attributes of file depend on :
<UL>
<LI>its category (DF or EF),
<LI>optional parameters in its file control information and/or in that of its parent file(s).
</UL>
<B>NOTE</B> - Security attributes may also be associated to other objects (e.g.  keys).
<P>
<H5><A NAME="ss5_2_3">5.2.3 Security mechanisms</A></H5>
<P>
This part of ISO/IEC 7816 defines the following security mechanisms :
<UL>
<LI>Entity authentication with password - The card compares data received from
the outside world with secret internal data. This mechanism may be used for
protecting the right of the user.
<LI>Entity authentication with key - The entity to be euthenticated has to
prove the knowledge of the relevant key in an authentication procedure (e.g.
using a <A HREF="iso7816_4.html#ss6_15">GET CHALLENGE command</A> followed by an <A HREF="iso7816_4.html#ss6_14">EXTERNAL AUTHENTICATE command</A>).
<LI>Data authentication - Using internal data, either secret or public, the
card checks redundant data recived from the outside world. Alternately, using
secret internal data, the card computes a data element (cryptographic checksum
or digital signature) and inserts it in the data sent to the outside world.
This mechanism may be used for protecting the rights of a provider.
<LI>Data encipherment - Using secret internal data, the card deciphers a
cryptogram received in a data field. Alternately, using internal data, either
secret or public, the card computes a cryptogram and inserts it in a data
field, possibly together with other data. This mechanism may be used to
provide a confidentiality service, e.g. for key management and conditional
access. In addition to the cryptogram mechanism, data confidentiality can be
achieved by data concealment. In this case, the card computes a string of
concealing bytes and adds it by exclusive-or to data bytes received from or
sent to the outside world. This mechanism may be used for protecting privacy
and for reducing the possibilities of  message filtering.
</UL>
The result of an authentication may be logged in an internal EF according to
the requrements of the application.
<P>
<H3><A NAME="ss5_3">5.3 APDU message structure</A></H3>
A step in an application protocol consists of sending a command, processing it
in the receiving entity and sending back the response. Therefore a spcecific
response corresponds to a specific command, referred to as a command-response
pair.<BR>
An application protocol data unit (APDU) contains either a command message or
a response message, sent from the interface device to the card or conversely.<BR>
In a command-response pair, the command message and the response message may
contain data, thus inducing four cases which are summarised by <A HREF="iso7816_4.html#table4">table 4</A>.
<H6><A NAME="table4">Table 4 - Data within a command-response pair</A></H6>
<TABLE BORDER=1><TR><TH>Case</TH><TH>Command data</TH><TH>Expected response data</TH></TR>
<TR><TD>1</TD><TD>No data</TD><TD>No data</TD></TR>
<TR><TD>2</TD><TD>No data</TD><TD>Data</TD></TR>
<TR><TD>3</TD><TD>Data</TD><TD>No data</TD></TR>
<TR><TD>4</TD><TD>Data</TD><TD>Data</TD></TR>
</TABLE>
<P>
<H4><A NAME="ss5_3_1">5.3.1 Command APDU</A></H4>
<P>
Illustrated by figure 3 (see also <A HREF="iso7816_4.html#table6">table 6</A>), the command APDU defined in this part of ISO/IEC 7816 consists of
<UL>
<LI>a mandatory header of 4 bytes (CLA INS P1 P2),
<LI>a conditional body of variable length
</UL>
<TABLE BORDER=1><TR><TH>Header</TH><TH>Body</TH></TR>
<TR><TD>CLA INS P1 P2</TD><TD>[Lc field] [Data field] [Le field]</TD></TR>
</TABLE>
<H6>Figure 3 - Command APDU structure</H6>
The number of bytes present in the data field of the command APDU is denoted
by Lc.
<P>
The maximum number of bytes expected in the data field of the response APDU is
denoted by Le (length of expected data). When the Le field contains only
zeros, the maximum number of available data bytes is requested.<BR>
Figure 4 shows the 4 structures of command APDUs according to the 4 cases
defined in table 4.
<H1> I M A G E 4 </H1>
<H6>Figure 4 - The 4 structures of command APDUs</H6>
In case 1, the length Lc is null; therefore the Lc field and the data field
are empty. The length Le is also null; therefore the Le field is empty.
Consequently, the body is empty.<BR>
In case 2, the length Lc is null; therefore the Lc field and the data field
are empty. The length of Le is not null; therefore the Le field is present.
Consequently, the body consists of the Le field.<BR>
In case 3, the length Lc is not null; therefore the Lc field is present and
the data field consists of the Lc subsequent bytes. The length Le is null;
therefore the Le field is empty. Consequently, the body consists of the Lc
field followed by the data field.<BR>
In case 4, the length Lc is not null; therefore the Lc field is present and
the data field consists of the Lc subsequent bytes. The length Le is also not
null; therefore the Le field is also present. Consequently, the body consists
of the Lc field followed by the data field and the Le field.
<P>
<H4><A NAME="ss5_3_2">5.3.2 Decoding conventions for command bodies</A></H4>
<P>
In case 1, the body of the command APDU is empty. Such a command APDU carries
no length field.
<P>
In cases 2, 3 and 4 the body of the command APDU consists of a string of L
bytes denoted by B1 to BL as illustrated by figure 5. Such a body carries 1 or
2 length fields; B1 is [part of] the first length field.
<TABLE BORDER=1><TR><TH>Command body</TH></TR>
<TR><TD>B1 B2 (L bytes)</TD></TR>
</TABLE>
<H6>Figure 5 - Not empty body</H6>
In the card capabilities (see 8.3.6), the card states that, within the
command APDU, the Lc field and Le field
<UL>
<LI>either shall be short (one byte, default value)
<LI>or may be extended (explicit statement)
</UL>
Consequently, the cases 2, 3 and 4 are either short (one byte for each length
field) or extended (B1 is valued to '00' and the value of each length is coded
on 2 other bytes).
<P>
<A HREF="iso7816_4.html#table5">Table 5</A> shows the decoding of the command APDUs according to the four cases
defined in <A HREF="iso7816_4.html#table4">table 4</A> and figure 4 and according to the possible extension of Lc
and Le.
<P>
<H6><A NAME="table5">Table 5 - Decoding of the command APDUs</A></H6>
<TABLE BORDER=1><TR><TH>Conditions</TH><TH>Case</TH></TR>
<TR><TD>L=0</TD><TD>1</TD></TR>
</TABLE>
<P>
<B>Decoding conventions for Le</B><BR>
If the value of Le is coded in 1 (or 2) byte(s) where the bits are not all
null, then the value of Le is equal to the value of the byte(s) which lies in
the range from 1 to 255 (or 65535); the null value of all the bits means the
maximum value of Le: 256 (or 65536).
<P>
The first 4 cases apply to all cards.
<P>
Case 1 - L=0 : the body is empty.
<UL>
<LI>No byte is used for Lc valued to 0
<LI>No data byte is present.
<LI>No byte is used for Le valued to 0.
</UL>
Case 2S - L=1
<UL>
<LI>No byte is used for Lc valued to 0
<LI>No data byte is present.
<LI>B1 codes Le valued from 1 to 256
</UL>
Case 3S - L=1 + (B1) and (B1) != 0
<UL>
<LI>B1 codes Lc (=0) valued from 1 to 255
<LI>B2 to Bl are the Lc bytes of the data field
<LI>No byte is used for Le valued to 0.
</UL>
Case 4S - L=2 + (B1) and (B1) != 0
<UL>
<LI>B1 codes Lc (!=0) valued from 1 to 255
<LI>B2 to Bl-1 are the Lc bytes of the data field
<LI>Bl codes Le from 1 to 256
</UL>
For cards indicating the extension of Lc and Le (see 8.3.8 card
capabilities), the next 3 cases also apply.
<P>
Case 2E - L=3 and (B1)=0
<UL>
<LI>No byte is used for Lc valued to 0
<LI>No data bytes is present
<LI>The Le field consists of the 3 bytes where B2 and B3 code Le valued from 1
to 65536
</UL>
Case 3E - L=3 + (B2||B3). (B1)=0 and (B2||B3)=0
<UL>
<LI>The Lc field consists of the first 3 bytes where B2 and B3 code Lc (!=0)
valued from 1 to 65536
<LI>B4 and B2 are the Lc bytes of the data field
<LI>No byte is used for Le valued to 0
</UL>
Case 4E - L= 5 + (B2||B3),(B1)=0 and (B2||B3)=0
<UL>
<LI>The Lc field consists of the first 3 bytes where B2 and B3 code Lc (!=0)
valued from 1 to 65535
<LI>B4 to Bl-2 are the Lc bytes of the data field
<LI>The Le field consists of the last 2 bytes Bl-1 and Bl which code Le valued
from 1 to 65536
</UL>
For each transmission protocol defined in part 3 of ISO/IEC 7816 an annex
attached to this part (one per protocol) specifies the transport of the APDUs
of a command-response pair for each of the previous 4 cases.
<P>
<H4><A NAME="ss5_3_3">5.3.3 Response APDU</A></H4>
<P>
Illustrated by figure 6 (see also <A HREF="iso7816_4.html#table7">table 7</A>), the response APDU defined in this part of ISO/IEC 7816 consists of
<UL>
<LI>a conditional body of variable length