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

Auxiliary SM data objects
Table 32 shows auxiliary SM data objects.

Table 32 Auxiliary SM data objects
Tag Value
’94′, ’95′ ‘A4′, ‘A5′ ‘A6′, ‘A7′ ‘AA’, ‘AB’ ‘B4′, ‘B5′ ‘B6′, ‘B7′ ‘B8′, ‘B9′ ‘BA’, ‘BB’ Security environment identifier (SEID byte) Control reference template valid for authentication (AT) Control reference template valid for key agreement (KAT) Control reference template valid for hash-code (HT) Control reference template valid for cryptographic checksum (CCT) Control reference template valid for digital signature (DST) Control reference template valid for confidentiality (CT) Response descriptor template

Control reference templates
Six control reference templates are defined, valid for authentication (AT), key agreement (KAT), hash-code (HT), cryptographic checksum (CCT), digital signature (DST) and confidentiality (CT) using either symmetric or asymmetric cryptographic techniques (CT-sym and CT-asym). Each security mechanism involves a cryptographic algorithm in a mode of operation and uses a key and, possibly, initial data. Such items are selected either implicitly, i.e., known before issuing the command, or explicitly, i.e., by control reference data objects nested in control reference templates. Within the control reference templates, the context-specific class (first byte from ’80′ to ‘BF’) is reserved for control reference data objects. In a SM field, 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 valid for cryptographic checksum (CCT) is just before the first data object to include in the computation. Each control reference remains valid until a new control reference is provided for the same mechanism. For example, a command may provide control references for the next command.

Control reference data objects in control reference templates
Each control reference template (CRT) is a set of control reference data objects: a cryptographic mechanism reference, a file and key reference, an initial data reference, a usage qualifier and, only in a control reference template for confidentiality, a cryptogram content reference.
–The cryptographic mechanism reference denotes a cryptographic algorithm in a mode of operation. The control parameters of any DF (see tag ‘AC’ in Table 12) may contain cryptographic mechanism identifier templates (see 5.4.2). Each one indicates the meaning of a cryptographic mechanism reference.
–The file reference (same encoding as in 5.3.1.2) 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, possibly an application DF. The key reference unambiguously identifies the key to use.
–The initial data reference, when applied to cryptographic checksums, indicates the initial check block. If no initial data reference is present and no initial check block implicitly selected, then the null block applies. 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.
Table 33 lists control reference data objects and indicates to which control reference template they are relevant. All the control reference data objects are in the context-specific class.

Table 33 Control reference data objects in control reference templates
Tag Value AT  KAT HT CCT DST CT-asym CT-sym
’80′ Cryptographic mechanism reference x x x x x x x
File and key references
’81′ —File reference (same encoding as 5.3.1.2) x x x x x x x
’82′ —DF name (see 5.3.1.1) x x x x x x x
’83′ —Reference of a secret key (for direct use) —Reference of a public key —Qualifier of reference data x x x x x x x x x x x
’84′ —Reference for computing a session key —Reference of a private key x x x x   x x x x
‘A3′ Key usage template (see text below) x x x x x x x
Initial data reference: Initial check block
’85′ —L=0, null block     x x     x
’86′ —L=0, chaining block     x x     x
’87′ —L=0, previous initial value block plus one      L=k, initial value block     x x x     x
Initial data reference: Auxiliary data elements (see also 5.4.3)
’88′ —L=0, previous exchanged challenge plus one      L>0, no further indication       x x x x
’89′ to ’8D’ —L=0, index of a proprietary data element      L>0, value of a proprietary data element       x x     x
’90′ —L=0, hash-code provided by the card     x   x    
’91′ —L=0, random number provided by the card     L>0, random number   x   x x x x x  
’92′ —L=0, time stamp provided by the card     L>0, time stamp     x   x x x x  
’93′ —L=0, previous digital signature counter plus one     L>0, digital signature counter     x   x x x x x x
’94′ Challenge or data element for deriving a key x     x     x
 
’95′ Usage qualifier byte(see text below) x x   x x x x
’8E’ Cryptogram content reference(see text below)           x x
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’).

A CRT may contain interindustry data objects, e.g., certificate holder authorization (tag ’5F4C’, see 6.3.4) in AT, header list or extended header list (tags ’5D’ and ’4D’, see 8.5.1) in HT or DST.