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

 Secure messaging
Secure messaging (SM) protects all or part of a command-response pair, or a concatenation of consecutive data fields (command chaining, see 5.1.1.1; use of SW1 set to ’61′), by ensuring two basic security functions: data confidentiality and data authentication. Secure messaging is achieved by applying one or more security mechanisms. Possibly explicitly identified by a cryptographic mechanism identifier template (see 5.4.2) in the control parameters of any DF (see 5.3.3), each security mechanism involves a cryptographic algorithm, a mode of operation, a key, an argument (input data) and often, initial data.
–The transmission and reception of data fields may be interleaved with the processing of security mechanisms. This specification does not preclude the determination by sequential analysis of which mechanisms and which security items shall be used for processing the remaining part of the data field.
–Two or more security mechanisms may use the same cryptographic algorithm with different modes of operation. The hereafter specified padding rules do not preclude such a feature.

SM fields and SM data objects
By definition, any command or response data field in SM format, as also the SM template (tag ’7D’), is an SM field. Each SM field shall be encoded in BER-TLV (see 5.2.2) where the context-specific class (first byte from ’80′ to ‘BF’) is reserved for SM data objects. In command-response pairs, the SM format may be selected either implicitly, i.e., known before issuing the command, or explicitly, i.e., indicated by CLA (see 5.1.1).
NOTE Command chaining and / or the use of SW1 set to ’61′ induces sequences of commands where data fields (and consequently, data objects) may be split in smaller consecutive data fields. In such a case, when using SM format, the concatenation of all the consecutive data fields in the same direction in the same

sequence is an SM field.
Table 27 shows the SM data objects specified in this document, all in the context-specific class. Some SM data objects (SM tags ’82′, ’83′, ‘B0′, ‘B1′) are recursive, i.e., the plain value field is an SM field.

Table 27 — SM data objects
Tag  Value
’80′, ’81′ Plain value not encoded in BER-TLV
’82′, ’83′ Cryptogram (plain value encoded in BER-TLVand including SM data objects, i.e., an SM field)
’84′, ’85′ Cryptogram (plain value encoded in BER-TLV, but not including SM data objects)
’86′, ’87′ Padding-content indicator byte followed by cryptogram (plain value not encoded in BER-TLV)
’89′ Command header (CLA INS P1 P2, four bytes)
’8E’ Cryptographic checksum (at least four bytes)
’90′, ’91′ Hash-code
’92′, ’93′ Certificate (data not encoded in BER-TLV)
’94′, ’95′ Security environment identifier (SEID byte)
’96′, ’97′ One or two bytes encoding Ne in the unsecured command-response pair (possibly empty)
’99′ Processing status (SW1-SW2, two bytes; possibly empty)
’9A’, ’9B’ Input data element for the computation of a digital signature (the value field is signed)
’9C’, ’9D’ Public key
’9E’  Digital signature
‘A0′, ‘A1′ Input template for the computation of a hash-code (the template is hashed)
‘A2′ Input template for the verification of a cryptographic checksum (the template is included)
‘A4′, ‘A5′ Control reference template for authentication (AT)
‘A6′, ‘A7′ Control reference template for key agreement (KAT)
‘A8′ Input template for the verification of a digital signature (the template is signed)
‘AA’, ‘AB’ Control reference template for hash-code (HT)
‘AC’, ‘AD’ Input template for the computation of a digital signature (the concatenated value fields are signed)
‘AE’, ‘AF’ Input template for the verification of a certificate (the concatenated value fields are certified)
‘B0′, ‘B1′ Plain value encoded in BER-TLVand including SM data objects, i.e., an SM field
‘B2′, ‘B3′ Plain value encoded in BER-TLV, but not including SM data objects
‘B4′, ‘B5′ Control reference template for cryptographic checksum (CCT)
‘B6′, ‘B7′ Control reference template for digital signature (DST)
‘B8′, ‘B9′ Control reference template for confidentiality (CT)
‘BA’, ‘BB’ Response descriptor template
‘BC’, ‘BD’ Input template for the computation of a digital signature (the template is signed)
‘BE’ Input template for the verification of a certificate (the template is certified)
 In this context, ISO/IEC JTC 1/SC 17 reserves any other data object of the context-specific class (first byte from ’80′ to ‘BF’).

In each SM field, bit 1 of the last byte of the tag field (tag parity) of each SM data object (context-specific class) indicates whether the SM data object shall be included (bit 1 set to 1, odd tag number) or not (bit 1 set to 0, even tag number) in the computation of a data element for authentication (cryptographic checksum, see 6.2.3.1, or digital signature, see 6.2.3.2). If present, the data objects of the other classes (e.g., interindustry data objects) shall be included in the computation. If such a computation occurs, the data element shall be the value field of a SM data object for authentication (SM tags ’8E’, ’9E’) at the end of the SM field.
There are two categories of SM data objects.
–Each basic SM data object (see 6.2) conveys a plain value, or an input or result of a security mechanism.
–Each auxiliary SM data object (see 6.3) conveys a control reference template, or a security environment identifier, or a response descriptor template.
NOTE Basic SM data objects are also used to control security operations (see ISO/IEC 7816-8[4]). Auxiliary SM data objects are also used to manage security environment (see 7.5.11). The global approach to security by secure messaging shares several security-related issues with the security operations, i.e., the atomic approach to security. Annex B illustrates the synergy between the two approaches.