ISO 7816 part 4, section..1 2 3 4 5 6 7 8 9 annex.. A B C D E F
For the latest version of ISO7816 part 4, please contact ISO in Switzerland.
5.1 Data structures
5.2 Security architecture of the card
5.3 APDU message structure
5.4 Coding conventions for command headers, data fields and response trailers
5.5 Logical channels
5.6 Secure messaging
This clause contains information on the logical structure of data as seen at the interface, when processing interindustry commands for interchange. The actual storage location of data and structural information beyond what is described in this clause are outside the scope of ISO/IEC 7816.
5.1.1 File organization
5.1.2 File referencing methods
5.1.3 Elementary file structures
5.1.4 Data referencing methods
5.1.4.1 Record referencing
5.1.4.2 Data unit referencing
5.1.4.3 Data object referencing
5.1.5 File control information
This part of ISO/IEC 7816 supports the following two categories of files :
The logical organization of data in a card consists of following structural hierachy of dedicated files :
The following two types of EFs are defined :
Figure 1 illustrates an example of the logical file organization in a card.
Figure 1 – Logical file organization (example)
When a file cannot be implicitly selected, it shall be possible to select it by at least one of the following methods :
The following structures of EFs are defined :
The following attributes are defined for EFs structured in records :
The card shall support at least one of the following four methods for structuring EFs :
Figure 2 shows those for EF structures.
Figure 2 – EF structures
NOTE – The arrow on the figure references the most recently written record.
Data may be referenced as records, as data units or as data objects. Data is considered to be stored in a single continuous sequence of records (within an EF of record structure) or of data units (within an EF of transparent structure). Reference to a record or to a data unit outside an EF is an error.
Data referencing method, record numbering method and data unit size are EF-dependent features. The card can provide indications in the ATR, in the ATR file and in any file control information. When the card provides indications in several places, the indication valid for a given EF is the closest one to that EF within the path from the MF to that EF.
Within each EF of record structure, each record can be referenced by a record identifier and/or by a record number. Record identifiers and record numbers are unsigned 8-bit integers with values in the range from ’01’ to ‘FE’. The value ’00’ is reserved for special purposes. The value ‘FF’ is RFU.
Referencing by record identifier shall induce the management of a record pointer. A reset of the card, a SELECT FILE and any command carrying a valid short EF identifier can affect the record pointer. Referencing by record number shall not affect the record pointer.
Referencing by record identifier – Each record identifier is provided by an application. If a record is a SIMPLE-TLV data object in the data field for a message (see 1.4.4), then the record identifier is the first byte of the data object. Within an EF of record structure, records may have the same record identifier, in which case data contained in the records may be used for discriminating between them.
Each time a reference is made with a record identifier, an indication shall specify the logical position of the target record the first or last occurrence, the next or previous occurrence relative to the record pointer :
Each time a reference is made with a record identifier, an indication shall specify the logical position of the target record the first or last occurrence, the next or previous occurrence relative to the record pointer :
The following additional rules are defined for linear structures and for cyclic structures :
Referencing by record number – Within each EF of record structure, the record numbers are unique and sequential :
The following additional rule is defined for linear structures and for cyclic structures :
Within each EF of transparent structure, each data unit can be referenced by an offset (e.g. in READ BINARY command). It is an unsigned integer, limited to either 8 or 15 bits according to an option in the respective command. Valued to 0 for the first data unit of the EF, the offeset is incremented by 1 for every subsequent data unit.
By default, i.e. if the card gives no indication, the size of the date unit is one byte.
NOTES
Each data object (as defined in 1.4.4) is headed by a tag which references it. Tags are specified in this part and other parts of ISO/IEC 7816.
The file control information (FCI) is the string of data bytes available in response to a SELECT FILE command. The file control information may be present for any file. Table 1 introduces 3 templates intended for conveying file control information when coded as BER-TLV data objects.
Tag | Values |
---|---|
’62’ | File control parameters (FCP template) |
’64’ | File management data (FMD template) |
‘6F’ | File control information (FCI template) |
Table 1 – Template relevant to FCI
The 3 templates may be retrieved according to selection options of the SELECT FILE command . If the FCP or FMD option is set, then the use of the corresponding template is mandatory. If the FCI option is set then the use of the FCI template is optional.
Part of the file control information may additionally be present in a working EF under control of an application and referenced under tag ’87’. The use of the FCP or FCI template is mandatory for the coding of file control information in such an EF.
File control information not coded according to this part of ISO/IEC 7816 may be introduced as follows :
Table 2 – File control parameters
Tag | L | Value | Applies to |
---|---|---|---|
’80’ | 2 | Number of data bytes in the file, excluding structural information. | Transparent EFs |
’81’ | 2 | Number of data bytes in the file, including structural information if any | Any file |
’82’ | 1 | File descriptor byte (see table 3) | Any file |
’82’ | 2 | File descriptor byte followed by data coding byte (see table 86) | Any file |
’82’ | 3 or 4 | File descriptor byte followed by data coding byte and maximum record length. | EFs with record structure |
’83’ | 2 | File identifier | Any file |
’84’ | 1 to 16 | DF name | DFs |
’85’ | var. | Proprietary information | Any file |
’86’ | var. | Security attributes (coding outside the scope of this part of ISO/IEC 7816) | Any file |
’87’ | 2 | Identifier of an EF containing an extension of the FCI | Any file |
’88’ to ‘9E’ | RFU | ||
‘9FXY’ | RFU |
Table 3 – File descriptor bytey
b8 b7 b6 b5 b4 b3 b2 b1 | Meaning |
---|---|
0 x — — — — — — | File accessibility |
0 0 — — — — — — | Not shareable file |
0 1 — — — — — — | Shareable file |
0 — x x x — — — | File type |
0 — 0 0 0 — — — | Working EF |
0 — 0 0 1 — — — | Internal EF |
0 — 0 1 0 — — — | Reserved |
0 — 0 1 1 — — — | for |
0 — 1 0 0 — — — | proprietary |
0 — 1 0 1 — — — | types |
0 — 1 1 0 — — — | of EFs |
0 — 1 1 1 — — — | DF |
0 — — — — x x x | EF structure |
0 — — — — 0 0 0 | No information given |
0 — — — — 0 0 1 | Transparent |
0 — — — — 0 1 0 | Linear fixed, no further info |
0 — — — — 0 1 1 | Linear fixed SIMPLE-TLV |
0 — — — — 1 0 0 | Linear variable, no further info |
0 — — — — 1 0 1 | Linear variable SIMPLE-TLV |
0 — — — — 1 1 0 | Cyclic, no further info |
0 — — — — 1 1 1 | Cyclic, SIMPLE-TLV |
1 x x x x x x x | RFU |
Shareable means that the file supports at least concurrent access on different logical channels.
This clause describes the following features :
5.2.1 Security status
5.2.2 Security attributes5.2.3 Security mechanisms
5.2.3 Security mechanisms
Security attributes are compared with the security status to execute command and/or to access files.
Security status represents the current state possibly achieved after completion of
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.
Three security statuses are considerd :
If the concept of logical channels is applied, the file specify security status may depend on the logical channel (see 1.5.1).
The security attributes, when they exist, define the allowed actions and the procedures to be performed to complete such actions.
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 :
NOTE – Security attributes may also be associated to other objects (e.g. keys).
The security attributes, when they exist, define the allowed actions and the procedures to be performed to complete such actions.
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 :
NOTE – Security attributes may also be associated to other objects (e.g. keys).
This part of ISO/IEC 7816 defines the following security mechanisms :
The result of an authentication may be logged in an internal EF according to the requirements of the application.
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.
5.3.1 Command APDU
5.3.2 Decoding convention for command bodies
5.3.3 Response APDU
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.
In a command-response pair, the command message and the response message may contain data, thus inducing four cases which are summarised by table 4.
Table 4 – Data within a command-response pair
Case | Command data | Expected response data |
---|---|---|
1 | No data | No data |
2 | No data | Data |
3 | Data | No data |
4 | Data | Data |
Illustrated by figure 3 (see also table 6), the command APDU defined in this part of ISO/IEC 7816 consists of
Header | Body |
---|---|
CLA INS P1 P2 | [Lc field] [Data field] [Le field] |
Figure 3 – Command APDU structure
The number of bytes present in the data field of the command APDU is denoted by Lc.
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.
Figure 4 shows the 4 structures of command APDUs according to the 4 cases defined in table 4.
Figure 4 – The 4 structures of command APDUs
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.
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.
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.
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.
In case 1, the body of the command APDU is empty. Such a command APDU carries no length field.
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.
Command Body |
---|
B1 B2 (L bytes) |
Figure 5 – Not empty body
In the card capabilities (see 8.3.6), the card states that, within the command APDU, the Lc field and Le field
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).
Table 5 shows the decoding of the command APDUs according to the four cases defined in table 4 and figure 4 and according to the possible extension of Lc and Le.
Table 5 – Decoding of the command APDUs
Conditions | Case |
---|---|
L=0 | 1 |
Decoding conventions for Le
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).
The first 4 cases apply to all cards.
Case 1 – L=0 : the body is empty.
Case 2S – L=1
Case 3S – L=1 + (B1) and (B1) != 0
Case 4S – L=2 + (B1) and (B1) != 0
For cards indicating the extension of Lc and Le (see 8.3.8 card capabilities), the next 3 cases also apply.
Case 2E – L=3 and (B1)=0
Case 3E – L=3 + (B2||B3). (B1)=0 and (B2||B3)=0
Case 4E – L= 5 + (B2||B3),(B1)=0 and (B2||B3)=0
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.
Illustrated by figure 6 (see also table 7), the response APDU defined in this part of ISO/IEC 7816 consists of
Body | Trailer |
---|---|
[Data field] | SW1 SW2 |
The number of bytes present in the data field of the response APDU is denoted by Lr.
The trailer codes the status of the receiving entity after processing the command-response pair.
NOTE – If the command is aborted, then the response APDU is a trailer coding an error condition on 2 status bytes.
5.4.1 Class byte
5.4.2 Instruction byte
Table 6 shows the contents of the command APDU.
Table 6 – command APDU contents
Code | Name | Length | Description |
---|---|---|---|
CLA | Class | 1 | Class of instruction |
INS | Instruction | 1 | Instruction code |
P1 | Parameter 1 | 1 | Instruction parameter 1 |
P2 | Parameter 2 | 1 | Instruction parameter 2 |
Lc field | Length | variable 1 or 3 | Number of bytes present in the data field of the command |
Data field | Data | variable=Lc | String of bytes sent in the data field of the command |
Le field | Length | variable 1 or 3 | Maximum number of bytes expected in the data field of the response to the command |
Table 7 shows the contents of the response APDU.
Table 7 – response APDU contents
Code | Name | Length | Description |
---|---|---|---|
Data field | Data | variable=Lr | String of bytes received in the data field of the response |
SW1 | Status byte 1 | 1 | Command processing status |
SW2 | Status byte 2 | 1 | Command processing qualifier |
The subsequent clauses specify coding conventions for the class byte, the instruction byte, the parameter bytes, the data field bytes and the status byte. Unless otherwise specified, in those bytes, RFU bits are coded zero and RFU bytes are coded ’00’.
According to table 8 used in conjunction with table 9, the class byte CLA of a command is used to indicate
Table 8 – Coding and meaning of CLA
Value | Meaning |
---|---|
‘0X’ | Structure and coding of command and response according to this part of ISO/IEC 7816 (for coding of ‘X’ see table 9) |
10 to 7F | RFU |
8X, 9X | Structure of command and response according to this part of ISO/IEC 7816. Except for ‘X’ (for coding, see table 9), the coding and meaning of command and response are proprietary | AX Unless otherwise specified by the application context, structure and coding of command and response according to this part of ISO/IEC 7816 (for coding of ‘X’, see table 9) | SW1 SW2 |
B0 to CF | Structure of command and response according to this part of ISO/IEC 7816 |
D0 to FE | Proprietary structure and coding of command and response |
FF | Reserved for PTS |
Table 9 – Coding and meaning of nibble ‘X’ when CLA=’0X’,’8X’,’9X’ or ‘AX’
b4 b3 b2 b1 | Meaning |
---|---|
x x — — | Secure messaging (SM) format |
0 x — — | No SM or SM not according to 1.6 |
0 0 — — | No SM or no SM indication |
0 1 — — | Proprietary SM format |
1 x — — | Secure messaging according to 1.6 |
1 0 — — | Command header not authenticated |
1 1 — — | Command header authenticated (see 1.6.3.1 for command header usage) |
— — x x | Logical channel number (according to 1.5) (b2 b1 = 00 when logical channels are not used or when logical channel #0 is selected |
The instruction byte INS of a command shall be coded to allow transmission with any of the protocols defined in part 3 of ISO/IEC 7816. Table 10 shows the INS codes that are consequently invalid.
Table 10 – Invalid INS codes
b8 b7 b6 b5 b4 b3 b2 b1 | Meaning |
---|---|
x x x x x x x 1 | Odd values |
0 1 1 0 x x x x | ‘6X’ |
1 0 0 1 x x x x | ‘9X’ |
Table 11 shows the INS codes defined in this part of ISO/IEC 7816. When the value of CLA lies within the range from ’00’ to ‘7F’, the other values of INS codes are to be assigned by ISO/IEC JTC 1 SC17.
Table 11 – INS codes defined in this part of ISO/IEC 7816
Value | Command name | Clause |
---|---|---|
‘0E’ | ERASE BINARY | 6.4 |
’20’ | VERIFY | 6.12 |
’70’ | MANAGE CHANNEL | 6.16 |
’82’ | EXTERNAL AUTHENTICATE | 6.14 |
’84’ | GET CHALLENGE | 6.15 |
’88’ | INTERNAL AUTHENTICATE | 6.13 |
‘A4’ | SELECT FILE | 6.11 |
‘B0’ | READ BINARY | 6.1 |
‘B2’ | READ RECORD(S) | 6.5 |
‘C0’ | GET RESPONSE | 7.1 |
‘C2’ | ENVELOPE | 7.2 |
‘CA’ | GET DATA | 6.9 |
‘D0’ | WRITE BINARY | 6.2 |
‘D2’ | WRITE RECORD | 6.6 |
‘D6’ | UPDATE BINARY | 6.3 |
‘DA’ | PUT DATA | 6.10 |
‘DC’ | UPDATE DATA | 6.8 |
‘E2’ | APPEND RECORD | 6.7 |
The parameter bytes P1-P2 of a command may have any value. If a parameter byte provides no further qualification, then it shall be set to ’00’.
Each data field shall have one of the following three structures.
This part of ISO/IEC 7816 supports the following two types of TLV-coded data objects in the data fields :
ISO/IEC 7816 uses neither ’00’ nor ‘FF’ as tag value.
Each BER-TLV data object shall consists of 2 or 3 consecutive fields (see ISO/IEC 8825 and annex D).
Each SIMPLE-TLV data object shall consist of 2 or 3 consecutive fields.
The data fields of some commands (e.g. SELECT FILE ), the value fields of the SIMPLE-TLV data object and the value field of the some primitive BER-TLV data objects are intended for encoding one or more data elements.
The data fields of some other commands (e.g. record-oriented commands) and the value fields of the other primitive BER-TLV data objects are intended for encoding one or more SIMPLE-TLV data objects.
The data fields of some other commands (e.g. object-oriented commands) and the value fields of the constructed BER-TLV data objects are intended for encoding one or more BER-TLV data objects.
NOTE – Before between or after TLV-coded data objects, ’00’ or ‘FF’ bytes without any meaning may occur (e.g. due to erase or modified TLV-coded data objects).
The status bytes SW1-SW2 of a response denote the processing state in the card. Figure 7 shows the structural scheme of the values defined in this part of ISO/IEC 7816.
Figure 7 – Structural scheme of status bytes
NOTE – When SW1=’63’ or ’65’, the state of the non-volatile memory is changed. When SW1=’6X’ except ’63’ and ’65’, the state of the non-volatile memory is unchanged.
Due to specifications in part 3 of ISO/IEC 7816, this part does not define the following values of SW1-SW2 :
The following values of SW1-SW2 are defined whichever protocol is used (see examples in annex A).
NOTE – A functionality similar to that offered by ’61XX’ may be offered at application level by ‘9FXX’. However, applications may use ‘9FXX’ for other purposes.
Table 12 completed by tables 13 to 18 shows the general meanings of the values of SW1-SW2 defined in this part of ISO/IEC 7816. For each command, an appropriate clause provides more detailed meanings.
Tables 13 to 18 specify values of SW2 when SW1 is valued to ’62’, ’63’, ’65’, ’68’, ’69’ and ‘6A’. The values of SW2 not defined in tables 13 to 18 are RFU, except the values from ‘F0’ to ‘FF’ which are not defined in this part of ISO/IEC 7816.
Table 12 – Coding of SW1-SW2
SW1-SW2 | Meaning |
---|---|
Normal processing | |
‘9000’ | No further qualification |
’61XX’ | SW2 indicates the number of response bytes still available (see text below) |
Warning processings | |
’62XX’ | State of non-volatile memory unchanged (further qualification in SW2, see table 13) |
’63XX’ | State of non-volatile memory changed (further qualification in SW2, see table 14) |
Execution errors | |
’64XX’ | State of non-volatile memory unchanged (SW2=’00’, other values are RFU) |
’65XX’ | State of non-volatile memory changed (further qualification in SW2, see table 15) |
’66XX’ | Reserved for security-related issues (not defined in this part of ISO/IEC 7816) |
Checking errors | |
‘6700’ | Wrong length |
’68XX’ | Functions in CLA not supported (further qualification in SW2, see table 16) |
’69XX’ | Command not allowed (further qualification in SW2, see table 17) |
‘6AXX’ | Wrong parameter(s) P1-P2 (further qualification in SW2, see table 18) |
‘6B00’ | Wrong parameter(s) P1-P2 |
‘6CXX’ | Wrong length Le: SW2 indicates the exact length (see text below) |
‘6D00’ | Instruction code not supported or invalid |
‘6E00’ | Class not supported |
‘6F00’ | No precise diagnosis |
Table 13 – Coding of SW2 when SW1=’62’
b8 b7 b6 b5 b4 b3 b2 b1 | Meaning |
---|---|
x x x x x x x 1 | Odd values |
0 1 1 0 x x x x | ‘6X’ |
1 0 0 1 x x x x | ‘9X’ |
Table 14 – Coding of SW2 when SW1=’63’
SW2 | Meaning |
---|---|
’00’ | No information given |
’81’ | File filled up by the last write |
‘CX’ | Counter provided by ‘X’ (valued from 0 to 15) (exact meaning depending on the command) |
Table 15 – Coding of SW2 when SW1=’65’
SW2 | Meaning |
---|---|
’00’ | No information given |
’81’ | Memory failure |
Table 16 – Coding of SW2 when SW1=’68’
SW2 | Meaning |
---|---|
’00’ | No information given |
’81’ | Logical channel not supported |
’82’ | Secure messaging not supported |
Table 17 – Coding of SW2 when SW1=’69’
SW2 | Meaning |
---|---|
’00’ | No information given |
’81’ | Command incompatible with file structure |
’82’ | Security status not satisfied |
’83’ | Authentication method blocked |
’84’ | Referenced data invalidated |
’85’ | Conditions of use not satisfied |
’86’ | Command not allowed (no current EF) |
’87’ | Expected SM data objects missing |
’88’ | SM data objects incorrect |
Table 18 – Coding of SW2 when SW1=’6A’
SW2 | Meaning |
---|---|
’00’ | No information given |
’80’ | Incorrect parameters in the data field |
’81’ | Function not supported |
’82’ | File not found |
’83’ | Record not found |
’84’ | Not enough memory space in the file |
’85’ | Lc inconsistent with TLV structure |
’86’ | Incorrect parameters P1-P2 |
’87’ | Lc inconsistent with P1-P2 |
’88’ | Referenced data not found |
A logical channel, as seen at the interface, works as a logical link to a DF.
There shall be independence of activity on one logical channel from activity on another one. That is, command interdependencies on one logical channel shall be independent of command interdependencies on another logical channel. However, logical channels may share application-dependent security status and therefore may have security-related command interdependencies across logical channels (e.g. password verification).
Commands referring to a certain logical channel carry the respective logical channel number in the CLA byte (see tables 8 and 9 ). Logical channels are numbered from 0 to 3. If a card supports the logical channel mechanism, then the maximum number of available logical channels is indicated in the card capabilities (see 8.3.6).
Command-response pairs work as currently described. This part of ISO/IEC 7816 supports only command-response pairs which shall be completed before initiating a subsequent command-response pair. There shall be no interleaving of commands and their responses across logical channels; between the receipt of a command and the sending of the response to that command only channel is opened it remains open until explicity closed by a MANAGE CHANNEL command .
NOTES
The basic logical channel is permanently available. When numbered, its number is 0. When the class byte is coded according to table 8 and 9 , the bits b1 and b2 code the logical channel number.
A logical channel is opened by successful completion of
The close function of the MANAGE CHANNEL command may be used to explicitly close a logical channel using the logical channel number. After closing the logical channel number will be available for re-use. The basic logical channel shall not be closed.
5.6.1 SM format concept
5.6.2 Plain value data object
5.6.3 Data object for authentication
5.6.3.1 Cryptographic checksum data object
5.6.3.2 Digital signature data object
5.6.4 Data objects for confidentiality
5.6.5 Auxiliary security data objects
5.6.5.1 Control references
5.6.5.2 Response descriptor5.6.6 SM status conditions
The goal of secure messaging (SM) is to protect [part of] the messages to and from a card by ensuring two basic security functions: data authentication and data confidentiality.
Secure messaging is achieved by applying one or more security mechanisms. Each security mechanism involves an algorithm, a key, an argument and often, initial data.
In each message involving security mechanisms based on cryptography, the data field shall comply with the basic encoding rules of ASN.1 (see ISO/IEC 8825 and annex D), unless otherwise indicated by the class byte (see 1.4.1).
In the data field, the present SM format may be selected
The SM format defined in this part of ISO/IEC 7816 is BER-TLV coded.
In the context-specific class, the bit 1 of the tag fixes whether the SM-related data object shall (b1=1) or not (b1=0) be integrated in the computation of a data object for authentication. If present, the data objects of the other classes shall be integrated in such a computation.
Encapsulation is mandatory for data not coded in BER-TLV and for BER-TLV, including SM-related data objects. Encapsulation is optional for BER-TLV, not including SM-related data objects. Table 19 shows plain data objects for encapsulation.
Table 19 – Plain value data objects
Tag | Value |
---|---|
‘B0′,’B1’ | BER-TLV, including SM-related data objects |
‘B2′,’B3’ | BER-TLV, but not SM-related data objects |
’80’,’81’ | not BER-TLV-coded data |
’99’ | SM status information (e.g. SW1-SW2) |
The computation of cryptographic checksums (see ISO/IEC 9797) involves an initial check block, secret key and a block cipher algorithm that need not be reversible. The algorithm under control of the related key basically transforms a current input block of k bytes (typically 8 or 16) into a current output block of the same length.
The computation of a cryptographic checksum is performed in the following consecutive stages :
The padding consists of one mandatory byte valued to ’80’ followed, if needed, by 0 to k-1 bytes set to ’00’, until the respective data block is filled up to k bytes. Padding for authentication has no influence on transmission as the padding bytes shall not be transmitted.
The mode of operation is “cipher block chaining” (see ISO/IEC 10116). The first input is the exclusive-or of the initial check block with the first data block. The first output results from the first data block. The first output results from the first input. The current input is the exclusive-or of the previous output with the current data block. The current output results from the current input. The final check block is the last output.
Table 20 shows the cryptographic checksum data object.
Table 20 – Cryptographic checksum data object
Tag | Value |
---|---|
‘8E’ | Cryptographic checksum (at least 4 bytes) |
The digital signature computation is typically based upon asymmetric cryptographic techniques. There are two types of digital signatures :
The computation of a digital signature with appendix implies the use of a hash function (see ISO/IEC 10118). The data input either consists of the value of the digital signature input data object (see table 21 ), or is determined by the mechanism define in 1.6.3.1.
The computation of a digital signature related data objects.
Table 21 – Digital signature related data objects
Value
Tag | |
---|---|
‘9A’,’BA’ | Digital signature input data |
‘9E’ | Digital signature |
Data objects for confidentiality are intended for carrying a cryptogram which plain value consists of one of the following 3 cases :
Padding has to be indicated when the plain value consists of not BER-TLV coded data. When padding is applied but not indicated the rules defined in 1.6.3.1 shall apply.
Table 22 – Data objects for confidentiality
Tag | Value |
---|---|
’82’,’83’ | BER-TLV, including SM-related data objects |
’84’,’85’ | BER-TLV, but not SM-related data objects |
’86’,’87’ | Padding indicator byte (see table 23) followed by cryptogram (plain not coded in BER-TLV) |
Every data object for confidentiality may use any cryptographic algorithm and any mode of operation owning to an appropriate algorithm reference (see 1.6.5.1). In the absence of an algorithm reference and when no mechanism is implicitly selected for confidentiality a default mechanism shall apply.
For the computation of a cryptogram which is preceded by the padding indicator, the default mechanism is block cipher in “electronic code book” mode (see ISO/IEC 10116). The use of a block cipher may involve padding. Padding for confidentiality has an influence on transmission, the cryptogram (one or more blocks is longer than the plain text).
Table 23 shows the padding indicator byte
Table 23 – Padding indicator byte
Value | Meaning |
---|---|
’00’ | No further indication |
’01’ | Padding as defined in 1.6.3.1 |
’02’ | No padding |
’80’ to ‘8E’ | Proprietary |
Other values are RFU |
For the computation of a cryptogram not preceded by a padding indicator byte, the default mechanism is a stream cipher with exclusive-or of the string of data bytes to be concealed with a concealing string of the same length. Concealment thus requires no padding and the data objects concealed in the value field are recovered by the same operation.
An algorithm, a key and, possibly initial data may be selected for each security mechanism
Each command message may carry a response descriptor template fixing the data objects required in response. Inside the response descriptor, the security mechanisms are not yet applied: the receiving entity shall apply them for constructing the response.
Table 24 shows the control reference templates.
Table 24 – Control reference templates
Tag | Meaning |
---|---|
‘B4′,’B5’ | Template valid for cryptographic checksum |
‘B6′,’B7’ | Template valid for digital signature |
‘B8′,’B9’ | Template valid for confidentiality |
The last possible position of a control reference template is just before the first data object to which the referred mechanism applies. For example, the last possible position of a template for cryptographic checksum is just before the first data object integrated in the computation.
Each control reference remains valid until a new control reference is provided for the same mechanism. For example, a command may fix control references for the next command.
Each control reference template is intended for carrying control reference data objects (see table 25 ): an algorithm reference, a file reference, a key reference, an initial data reference and only in a control reference template for confidentiality a cryptogram contents reference.
The algorithm reference fixes an algorithm and its mode of operation (see ISO/IEC 9979 and 10116). Structure and coding of the algorithm reference are not defined in this part of ISO/IEC 7816.
The file reference denotes the file where the key reference is valid. If no file reference is present, then the key reference is valid in the current DF.
The key reference identifies the key to be used.
The initial data reference, when applied to cryptographic checksums, fixes the initial check block. If no initial data reference is present and no initial check block is implicitly selected, then the null block shall be used. Moreover, before transmitting the first data object for confidentiality using a stream cipher, a template for confidentiality shall provide auxiliary data for initializing the computation of the string of concealing bytes.
The cryptogram contents reference specifies the content of the cryptogram (e.g. secret key, initial password, control words). The first byte of the value field is named the type cryptogram descriptor byte and is mandatory. The range ’00’ to ‘7F’ is RFU. The range ’80’ to ‘FF’ is proprietary.
Table 25 – Control reference data objects
Tag | Value |
---|---|
’80’ | Alogorithm reference |
File reference | |
’81’ | – file identifier or path |
’82’ | – DF name |
Key reference | |
’83’ | – for direct use |
’84’ | – for computing a session key |
Initial data reference | |
’85’ | – L=0, null block |
’86’ | – L=0, chaining block |
’87’ | – L=0, previous initial value block plus one L=k, initial value block |
Auxiliary data | |
’88’ | – L=0, previous exchanged challenge plus one L!=0, no further indication |
’89’-‘8D’ | – L=0, index of a proprietary data element, L!=0, value of a proprietary data element |
‘8E’ | Cryptogram contents reference |
The response descriptor template, if present in the data field of the command APDU, shall fix the structure of the corresponding response. Empty data objects shall list all data needed for producing the response.
The security items (algorithms, key and initial data) used for processing the data field of a command message may be different from those used for producing the data field of the subsequent response messsage.
The following rules shall apply
Table 26 shows the response descriptor template.
Table 26 – Response descriptor template
Tag | Value |
---|---|
‘BA’,’BB’ | Response descriptor |
In any command using secure messaging the following specific error conditions may occur:
SW1=’69’ with SW2=