Iso iec 7816 4 standard

Add to Alert PDF. Please first log in with a verified email before subscribing to alerts. Please first verify your email before subscribing to alerts. Already Subscribed to this document. You can download and open this file to your own computer but DRM prevents opening this file on another computer, including a networked server. PDF Price. Publication date : This standard contributes to the following Sustainable Development Goal :.

CHF Buy. Life cycle Previously Withdrawn. Final text received or FDIS registered for formal approval. Proof sent to secretariat or FDIS ballot initiated: 8 weeks.

Abstract Specifies the content of the messages, commands and responses, transmitted by the interface device to the card and conversely, the structure and content of the historical bytes, structure of files and data, access methods to files and data in the card, a security architecture defining access rights to files and data in the card.

Status : Withdrawn. Publication date : Each data object as defined in 1. The file control information may be present for any file. The security status may also result from the completion of a security procedure related to the identification of the involved entities, if any, e.

If the concept of logical channels is applied, the file specify security status may depend on the logical channel see 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. 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.

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.

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. 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. Such a body carries 1 or 2 length fields; B1 is [part of] the first length field. In the card capabilities see 8. 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. 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 or ; the null value of all the bits means the maximum value of Le: or For cards indicating the extension of Lc and Le see 8.

The subsequent clauses specify coding conventions for the class byte, the instruction byte, the parameter bytes, the data field bytes and the status byte. According to table 8 used in conjunction with table 9, the class byte CLA of a command is used to indicate. Table 10 shows the INS codes that are consequently invalid.

The parameter bytes P1-P2 of a command may have any value. The data fields of some commands e. The data fields of some other commands e. The status bytes SW1-SW2 of a response denote the processing state in the card. For each command, an appropriate clause provides more detailed meanings.

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.

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.

Command-response pairs work as currently described. 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.

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.

After closing the logical channel number will be available for re-use. The basic logical channel shall not be closed. 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.