B.2 Cryptograms

The use of cryptograms with and without padding (see 6.2.2) is shown in command and response data fields. Instead of the plain value data objects in the previous examples, data objects for confidentiality shall be used as follows.

Case a — Plain value not encoded in BER-TLV

Data field = {T – L – Padding-content indicator byte – Cryptogram}

Plain value conveyed by the cryptogram = One or more blocks = Plain value not encoded in BER-TLV, possibly padded according to the indicator byte

Case b — Plain value encoded in BER-TLV

Data field = {T – L – Cryptogram}

Plain value conveyed by the cryptogram = String of concealed bytes = BER-TLV data objects (padding depending on the algorithm and its mode of operation)

B.3 Control references

The use of control references (see 6.3.1 and 6.3.2) is shown.

Command data field = {T – L – Control reference template}, where control reference template = {T – L – File reference} – {T – L – Key reference}

B.4 Response descriptor

The use of response descriptor is shown. Command data field = {T – L – Response descriptor} where response descriptor = {T (Plain value) – ’00′ – T (Cryptographic checksum) – ’00′} Response data field = {T – L – Plain value} – {T – L – Cryptographic checksum}

B.5 ENVELOPE command

The use of the ENVELOPE command is shown. Command data field = {T – L – Padding-content indicator byte – Cryptogram} Plain value conveyed by the cryptogram =

Command APDU (starting by CLA* INS P1 P2), padding according to the indicator byte Response data field = {T -L – Padding-content indicator byte – Cryptogram} Plain value conveyed by the cryptogram =

Response APDU, padding according to the indicator byte

B.6 Synergy between secure messaging and security operations

For the purposes of this clause, the following symbols and abbreviated terms apply. CC cryptographic checksum CG cryptogram CLA** CLA with SM indication (bits 8, 7 and 6 set to 000 and bits 4 and 3 set to 11) DS digital signature MSE manage security environment PCI padding-content indicator byte PSO perform security operation SMC security module card USC user smart card

The example explains how to use a security module card (SMC) that performs security operations for producing a secured command APDU to send to a user card (USC) and for processing the corresponding secured response APDU received thereon from the USC, i.e., for producing and processing data fields in SM format. The example illustrates the synergy between the two approaches:  the atomic approach by security operations (see ISO/IEC 7816-8[4]) and the global approach by secure messaging.

The example assumes that the USC and the SMC have completed a mutual authentication procedure, based e.g., on card verifiable certificates. The authentication procedure includes a key transport or key agreement mechanism so that after this procedure, two symmetric keys are available in the USC and in the SMC:

–a symmetric session key for computing cryptographic checksums and

–a symmetric session key for computing cryptograms.

The authentication procedure initialises one or more counters in the USC and the SMC. The example does not show the maintenance and the use of such counters by the USC and the SMC.

All the command-response pairs for the SMC are PSO commands, not using secure messaging, but using SM data objects (and the SM keys set by MSE commands).

All the command-response pairs for the USC use secure messaging and the command headers are included in the computation of cryptographic checksums, i.e., CLA is switched to CLA**.

Figure B.1 shows the general principles for producing a secured command APDU.

Mifare DESFire 8K Pre-printed Cards,NXP Mifare DESFire EV1 8K Smart Card,ISO MIFARE DESFire EV1 8K Card,

The following scenario explains the computation of a digital signature (DS) whereby the usage of the private signature key requires the successful presentation of a password. The scenario proceeds in three steps.

Step 1 — Password verification

1.1 Command to SMC: MSE SET — The reference of the session key for computing cryptographic checksums is ’81′ in the example. SMC response: OK

1.2 Command to SMC: MSE SET —The reference of the session key for computing cryptograms is ’82′ in the example. SMC response: OK

1.3 Command to SMC: PSO ENCIPHER SMC response:

1.4 Command to SMC: PSO COMPUTE CC ’01′-Le} – Padding> SMC response:

— Now the interface device constructs the secured VERIFY command APDU.

1.5 Command to USC: VERIFY <{’87′-L-PCI=’01′-CG(Password)} – {’97′-’01′-Le} – {’8E’-’04′-CC}> USC response: <{’99′-’02′-SW1-SW2} – {’8E’-’04′-CC}>

1.6 Command to SMC: PSO VERIFY CC <{’80′-’04′-(’99′-’02′-SW1-SW2)} – {’8E’-’04′-CC}> SMC response: OK

Step 2 — Hash code computation

2.1 Command to SMC: PSO COMPUTE CC {’80′-L-Last block})} – {’97′-’01′-Le} – Padding> SMC response:

2.2 Command to USC: PSO HASH <{’81′-L1 (=4+L2+L3)-({’90′-L2- Intermediate Hash} – {’80′-L3-Last block})} {’8E’-’04′-CC}> — The USC stores the hash code as an internal result for computing the digital signature later on. USC response: <{’99′-’02′-SW1-SW2} – {’8E’-’04′-CC}>

2.3 Command to SMC: PSO VERIFY CC <{’80′-’04′-({’99′-’02′-SW1-SW2})} – {’8E’-’04′-CC}> SMC response: OK

Step 3 — Digital signature computation

3.1 Command to SMC: PSO COMPUTE CC SMC response:

3.2 Command to USC: PSO COMPUTE DS <{’97′-’01′-’00′} – {’8E’-’04′-CC}> USC response: <’81′-L-DS – ’8E’-’04′-CC>

3.3 Command to SMC: PSO VERIFY CC <{’80′-L1 (=2+L2)-(’81′-L2-DS)} – {’8E’-’04′-CC}> SMC response: OK