ISO/IEC 7816-4
Identification cards — Integrated circuit cards — Part 4: Organization, security and commands for interchange
Cartes d’identification — Cartes à circuit intégré — Partie 4: Organisation, sécurité et commandes pour les échanges

Basic SM data objects
SM data objects for encapsulating plain values
Encapsulation is mandatory for SM fields and for data not encoded in BER-TLV. It is optional for BER-TLV, not including SM, data objects. Table 28 shows SM data objects for encapsulating plain values.

Table 28 — SM data objects for encapsulating plain values
Tag Value
‘B0′, ‘B1′ ‘B2′, ‘B3′ ’80′, ’81′ ’89′ ’96′, ’97′ ’99′ Plain value encoded in BER-TLVand including SM data objects (i.e., an SM field) Plain value encoded in BER-TLV, but not including SM data objects Plain value not encoded in BER-TLV Command header (CLA INS P1 P2, four bytes) One or two bytes encoding Ne in the unsecured command-response pair (possibly empty) Processing status (SW1-SW2, two bytes; possibly empty)

SM data objects for confidentiality
Table 29 shows SM data objects for confidentiality.

Table 29 — SM data objects for confidentiality
Tag Value
’82′, ’83′ ’84′, ’85′ ’86′, ’87′ Cryptogram (plain value encoded in BER-TLVand including SM data objects, i.e., an SM field) Cryptogram (plain value encoded in BER-TLV, but not including SM data objects) Padding-content indicator byte (see Table 30) followed by cryptogram (plain value not encoded in BER-TLV)

A security mechanism for confidentiality consists of an appropriate cryptographic algorithm in an appropriate mode of operation. In the absence of explicit indication and when no mechanism is implicitly selected for confidentiality, a default mechanism shall apply.
–For computing a cryptogram to be preceded by a padding indication, the default mechanism is a block cipher in “electronic code book” mode, which may involve padding. Padding for confidentiality may have an influence on transmission: the cryptogram (one or more blocks) may be longer than the plain value.
–For computing a cryptogram not to be preceded by a padding indication, the default mechanism is a stream cipher. In this case, the cryptogram is the exclusive-or of the string of data bytes to conceal with a concealing string of the same length. Concealment thus requires no padding and the string of data bytes is recovered by the same operation.
Padding and / or content shall be indicated when the plain value is not encoded in BER-TLV. If padding applies but is not indicated, the rules specified in 6.2.3.1 apply. Table 30 shows the padding-content indicator byte.

Table 30 — Padding-content indicator byte
Value Meaning
’00′ ’01′ ’02′ No further indication Padding as specified in 6.2.3.1  No padding
’1X’ ’2X’ ’3X’ ’4X’ One to four secret keys for enciphering information, not keys (‘X’ is a bitmap with any value from ’0′ to ‘F’) ’11′ indicates the first key (e.g., an “even”control word in a pay TV system) ’12′ indicates the second key (e.g., an “odd”control word in a pay TV system) ’13′ indicates the first key followed by the second key (e.g., a pair of control words in a pay TV system) Secret key for enciphering keys, not information (‘X’ is a reference with any value from ’0′ to ‘F’) (e.g., in a pay TV system, either an operational key for enciphering control words, or a management key for enciphering operational keys) Private key of an asymmetric key pair (‘X’ is a reference with any value from ’0′ to ‘F’) Password (‘X’ is a reference with any value from ’0′ to ‘F’)
’80′ to ’8E’ Proprietary
Any other value is reserved for future use by ISO/IEC JTC 1/SC 17.

SM data objects for authentication
Table 31 shows SM data objects for authentication.

Table 31 — SM data objects for authentication
Tag Value
’8E’ ’90′, ’91′ ’92′, ’93′ ’9C’, ’9D’ ’9E’ Cryptographic checksum (at least four bytes) Hash-code Certificate (data not encoded in BER-TLV) Public key  Digital signature
Input data objects (see also ISO/IEC 7816-8[4])
’9A’, ’9B’ ‘A0′, ‘A1′ ‘A2′ ‘A8′ ‘AC’, ‘AD’ ‘AE’, ‘AF’ ‘BC’, ‘BD’ ‘BE’ Input data element for the computation of a digital signature (the value field is signed) Input template for the computation of a hash-code (the template is hashed) Input template for the verification of a cryptographic checksum (the template is included) Input template for the verification of a digital signature (the template is signed) Input template for the computation of a digital signature (the concatenated value fields are signed) Input template for the verification of a certificate (the concatenated value fields are certified) Input template for the computation of a digital signature (the template is signed) Input template for the verification of a certificate (the template is certified)

Cryptographic checksum data element
The computation of a cryptographic checksum involves an initial check block, a secret key and either a block cipher algorithm (see ISO/IEC 18033[18]), or a hash-function (see ISO/IEC 10118[12]).
The computation method may be part of the system specifications. Alternately, a cryptographic mechanism identifier template, see 5.4.2, may identify a standard (e.g., ISO/IEC 9797-1[7]) fixing a computation method.
Unless otherwise specified, the following computation method shall be used. Under the control of the key, the algorithm basically converts a current input block of k bytes (typically 8, 16 or 20) into a current output block of the same size. The computation is performed in the following consecutive stages.
Initial stage — The initial stage shall set either one of the following blocks as the initial check block:
–the null block, i.e., k bytes set to ’00′,
–the chaining block, i.e., a result from former computations, namely for a command, the final check block of the previous command and for a response, the final check block of the previous response,
–the initial value block provided e.g., by the outside world,
–the auxiliary block resulting from converting auxiliary data under the control of the key. If the auxiliary data is less than k bytes, then bits set to 0 head it up to the block size.

Sequential stage(s) — The command header (CLA INS P1 P2) may be encapsulated for protection (SM tag ’89′). However, if bits 8 to 6 of CLA are set to 000 and bits 4 and 3 to 11 (see 5.1.1), then the first data block consists of the command header (CLA INS P1 P2) followed by one byte set to ’80′ and k–5 bytes set to ’00′.
The cryptographic checksum shall include any secure messaging data object having an odd tag number and any data object with the first byte not from ’80′ to ‘BF’. Those data objects shall be included data block by data block in the current check block. The splitting into data blocks shall be performed as follows.
–The blocking shall be continuous at the border between adjacent data objects to include.
–The padding shall apply at the end of each data object to include followed either by a data object not to include, or by no further data object. The padding consists of one mandatory byte set 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.
In this mechanism, the mode of operation is “cipher block chaining” (see ISO/IEC 10116[11]). The first input is the exclusive-or of the initial check block with 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.
Final stage — The final check block is the last output. The final stage extracts a cryptographic checksum (first m bytes, at least four) from the final check block.

Digital signature data element
The digital signature schemes rely on asymmetric cryptographic techniques (see ISO/IEC 9796[6], 14888[16]). The computation implies a hash-function (see ISO/IEC 10118[12]). The data input consists of the value field of a digital signature input data object, or of the concatenation of the value fields of data objects forming a digital signature input template.