ISO/IEC 7816-8:2016

INTERNATIONAL ISO/IEC
STANDARD 7816-8
Third edition
2016-11-01
Identification cards — Integrated
circuit cards —
Part 8:
Commands and mechanisms for
security operations
Cartes d’identification — Cartes à circuit intégré —
Partie 8: Commandes et mécanismes pour les opérations de sécurité
Reference number
©
ISO/IEC 2016
© ISO/IEC 2016, Published in Switzerland
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form
or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior
written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of
the requester.
ISO copyright office
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO/IEC 2016 – All rights reserved

Contents Page
Foreword .iv
Introduction .v
1 Scope .1
2 Normative references .1
3 Terms and definitions .1
4 Symbols and abbreviated terms . 2
5 Interindustry commands for security operations .3
5.1 General . 3
5.2 generate asymmetric key pair command . 3
5.3 perform security operation command . 7
5.3.1 General. 7
5.3.2 compute cryptographic checksum operation .10
5.3.3 compute digital signature operation .10
5.3.4 hash operation.11
5.3.5 verify cryptographic checksum operation .11
5.3.6 verify digital signature operation .11
5.3.7 verify certificate operation .12
5.3.8 encipher operation .13
5.3.9 decipher operation .13
Annex A (informative) Examples of operations related to digital signature .14
Annex B (informative) Examples of certificates interpreted by the card .20
Annex C (informative) Examples of asymmetric key transfer .25
Annex D (informative) Alternatives to achieve the reversible change of security context .28
Annex E (informative) Example of uses for generate asymmetric key pair command .30
Bibliography .36
© ISO/IEC 2016 – All rights reserved iii

Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical
activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international
organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the
work. In the field of information technology, ISO and IEC have established a joint technical committee,
ISO/IEC JTC 1.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for
the different types of document should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject
of patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent
rights. Details of any patent rights identified during the development of the document will be in the
Introduction and/or on the ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on the meaning of ISO specific terms and expressions related to conformity
assessment, as well as information about ISO’s adherence to the WTO principles in the Technical
Barriers to Trade (TBT) see the following URL: Foreword - Supplementary information
The committee responsible for this document is ISO/IEC JTC 1, Information technology, Subcommittee
SC 17, Cards and personal identification.
This third edition cancels and replaces the second edition (ISO/IEC 7816-8:2004), which has been
technically revised.
A list of all parts in the ISO/IEC 7816 series can be found on the ISO website.
iv © ISO/IEC 2016 – All rights reserved

Introduction
ISO/IEC 7816 is a series of standards specifying integrated circuit cards and the use of such cards
for interchange. These cards are identification cards intended for information exchange negotiated
between the outside world and the integrated circuit in the card. As a result of an information exchange,
the card delivers information (computation result, stored data), and/or modifies its content (data
storage, event memorization).
— Five parts are specific to cards with galvanic contacts and three of them specify electrical interfaces:
— ISO/IEC 7816-1 specifies physical characteristics for cards with contacts;
— ISO/IEC 7816-2 specifies dimensions and location of the contacts;
— ISO/IEC 7816-3 specifies electrical interface and transmission protocols for asynchronous cards;
— ISO/IEC 7816-10 specifies electrical interface and answer to reset for synchronous cards;
— ISO/IEC 7816-12 specifies electrical interface and operating procedures for USB cards.
— All the other parts are independent from the physical interface technology. They apply to cards
accessed by contacts and/or by radio frequency:
— ISO/IEC 7816-4 specifies organization, security and commands for interchange;
— ISO/IEC 7816-5 specifies registration of application providers;
— ISO/IEC 7816-6 specifies interindustry data elements for interchange;
— ISO/IEC 7816-7 specifies commands for structured card query language;
— ISO/IEC 7816-8 specifies commands for security operations;
— ISO/IEC 7816-9 specifies commands for card management;
— ISO/IEC 7816-11 specifies personal verification through biometric methods;
— ISO/IEC 7816-13 specifies commands for handling the life cycle of applications;
— ISO/IEC 7816-15 specifies cryptographic information application.
ISO/IEC 10536 (all parts) specifies access by close coupling. ISO/IEC 14443 (all parts) and ISO/IEC 15693
(all parts) specify access by radio frequency. Such cards are also known as contactless cards.
© ISO/IEC 2016 – All rights reserved v

INTERNATIONAL STANDARD ISO/IEC 7816-8:2016(E)
Identification cards — Integrated circuit cards —
Part 8:
Commands and mechanisms for security operations
1 Scope
This document specifies interindustry commands that may be used for security operations. This
document also provides informative directives on how to construct security mechanisms with
ISO/IEC 7816-4 defined commands.
The choice and conditions of use of cryptographic mechanism in security operations may affect card
exportability. The evaluation of the suitability of algorithms and protocols is outside the scope of this
document. It does not cover the internal implementation within the card and/or the outside world.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 7816-4:2013, Identification cards — Integrated circuit cards — Part 4: Organization, security and
commands for interchange
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— IEC Electropedia: available at http://www.electropedia.org/
— ISO Online browsing platform: available at http://www.iso.org/obp
3.1
asymmetric key pair
pair of elements belonging to cryptographic techniques that use two related operations: a public
operation defined by public numbers or by a public key and a private operation defined by private
numbers or by a private key
Note 1 to entry: The two operations have the property that, given the public operation, it is computationally
infeasible to derive the private operation.
3.2
certificate
digital signature (3.3) binding a particular person or object and its associated public key
Note 1 to entry: The entity issuing the certificate also acts as tag allocation authority with respect to the data
elements in the certificate.
[SOURCE: ISO/IEC 7816-4:2012, 3.11, modified]
© ISO/IEC 2016 – All rights reserved 1

3.3
digital signature
data appended to, or cryptographic transformation of, a data string that proves the origin and the
integrity of the data string and protect against forgery, e.g. by the recipient of the data string
[SOURCE: ISO/IEC 7816-4:2012, 3.21]
3.4
key
sequence of symbols controlling a cryptographic operation (e.g. encipherment, decipherment, a private
or a public operation in a dynamic authentication, signature production, signature verification)
[SOURCE: ISO/IEC 7816-4:2012, 3.32]
3.5
non-self-descriptive certificate
certificate (3.2) consisting of a concatenation of data elements associated to a header list or extended
header list, describing the structure of the certificate
3.6
self-descriptive certificate
certificate (3.2) consisting of a concatenation of data objects
3.7
secure messaging
set of means for cryptographic protection of (parts of) command-response pairs
[SOURCE: ISO/IEC 7816-4:2012, 3.50]
4 Symbols and abbreviated terms
BER basic encoding rules of ASN.1 (see ISO/IEC 8825-1)
CCT control reference template for cryptographic checksum
CRT control reference template
CT control reference template for confidentiality
DSA digital signature algorithm
DST control reference template for digital signature
ECDSA elliptic curve digital signature algorithm
HT control reference template for hash-code
MSE manage security environment command
PSO perform security operation command
pso hash PSO command with hash operation
pso checksum PSO command with compute cryptographic checksum operation
pso sign PSO command with compute digital signature operation
pso verify checksum PSO command with verify cryptographic checksum operation
pso verify sign PSO command with verify digital signature
2 © ISO/IEC 2016 – All rights reserved

pso verify certificate PSO command with verify certificate
pso encipher PSO command with encipher operation
pso decipher PSO command with decipher operation
GQ2 modified Guillou-Quisquater protocol for zero knowledge proof
RFU reserved for future use for ISO/IEC JTC 1/SC 17
RSA Rivest, Shamir, Adleman
SE security environment
SEID security environment identifier
TLV tag, length, value
5 Interindustry commands for security operations
5.1 General
An ICC compliant with this document may support any of the commands and/or options provided in the
following clauses and subclauses.
NOTE In addition to the use of logical channels, there are other alternatives that may be used for switching
the security context. Annex D provides information about this functionality.
5.2 generate asymmetric key pair command
The generate asymmetric key pair command initiates either
— the generation and storing of an asymmetric key pair, i.e. a public key and a private key, in the card,
— the generation, storing of an asymmetric key pair and extracting generated public key, or
— the extracting previously generated public key.
The command may be preceded by a manage security environment command in order to set key
generation related parameters (e.g. algorithm reference). The command may be performed in one or
several steps, possibly using command chaining (see ISO/IEC 7816-4).
© ISO/IEC 2016 – All rights reserved 3

Table 1 — generate asymmetric key pair command-response pair
CLA As defined in ISO/IEC 7816-4
INS ‘46’ or ‘47’
P1 See Table 2
P2 ‘00’ (no information provided) or reference of the private key to be generated coded according
to ISO/IEC 7816-4:2013, Table 94
L field Absent for encoding N = 0, present for encoding N > 0
c c c
Data field Absent, or
Proprietary data if P1-P2 set to ‘0000’, or
One or more CRTs associated to the key generation if P1-P2 different from ‘0000’ (see notes)
A CRT may include an extended header list
L field Absent for encoding N = 0, present for encoding N > 0
e e e
Data field Absent, or
Public key as a sequence of data elements (INS=‘46’), or
Public key as a sequence of data objects (INS=‘47’), or
Public key as a sequence of data objects according to an extended header list (INS=‘47’)
SW1-SW2 See ISO/IEC 7816-4:2013, Tables 5 and 6 where relevant, e.g. 6 985
NOTE 1 Several CRTs are present when the key pair is generated for several uses. In a data field, a CRT may
have a zero length.
Table 2 — P1 coding
b8 b7 b6 b5 b4 b3 b2 b1 Value
0 0 0 0 0 0 0 0 No information given
1 — — — — x x x Additional information given
1 — — — — — — x Key generation
1 — — — — — — 0 - Generate asymmetric key pair
1 — — — — — — 1 - Access to an existing public key
1 — — — — — x — Format of returned public key data
1 — — — — — 0 — - Proprietary format
1 — — — — — 1 — - Output format according to extended header list
1 — — — — x — — Output indicator
1 — — — — 0 — — - Public key data in response data field
1 — — — — 1 — — - No response data if Le field absent or proprietary if Le field present
— x x x x — — — 0000, other values are RFU
NOTE 2 The private key may be stored in an internal EF the reference of which is known before issuing the
command or in a DO’7F48’ as cardholder private key template.
NOTE 3 The public part may be stored for example in a DO’7F49’ as cardholder public key template.
For extracting a previously generated public key (i.e. no generation), the command data field shall be
empty or shall contain a CRT, possibly including an extended header list.
NOTE 4 In those cases when only access to a previously generated public key is requested, P2 is either ‘00’ or
references the private key.
The response data field shall be
— either absent,
— a public key as a sequence of data elements (INS=‘46’),
4 © ISO/IEC 2016 – All rights reserved

— a public key as a sequence of data objects (INS=‘47’) from Table 3, or
— a public key as a DO’7F49’ (INS=‘47’) nesting data objects from Table 3.
If the command data field does not indicate any format of public key data, it shall be implicitly known
before issuing the command (e.g. as part of the security environment). When command data field
indicates an extended header list within a CRT, it covers public key data objects and other requested
data object.
EXAMPLE Annex E provides a set of examples on the use of this command.
If the algorithm is not indicated in the command, then the algorithm is known before issuing the
command. In the public key template, the context-specific class (first byte from ‘80’ to ‘BF’) is reserved
for public key data objects.
Table 3 — Public key data objects
Tag Value
‘7F49’ Interindustry template for nesting one set of public key data objects with the following tags
‘06’ Object identifier of any further information, optional
‘80’ Algorithm reference as used in control reference data objects for secure messaging, optional
Set of public key data objects for RSA
‘81’ Modulus (a number denoted as n coded on x bytes)
‘82’ Public exponent (a number denoted as v, e.g. 65 537)
Set of public key data objects for DSA
‘81’ First prime (a number denoted as p coded on y bytes)
‘82’ Second prime (a number denoted as q dividing p-1, e.g. 20 bytes)
‘83’ Basis (a number denoted as g of order q coded on y bytes)
Public key (a number denoted as y equal to g to the power x mod p where x is the private key coded
‘84’
on y bytes)
Set of public key data objects for ECC
‘81’ Prime (a number denoted as p coded on z bytes)
‘82’ First coefficient (a number denoted as a coded on z bytes)
‘83’ Second coefficient (a number denoted as b coded on z bytes)
‘84’ Generator (a point denoted as PB on the curve, coded on 2z + 1 or 2z or z + 1 bytes)
‘85’ Order (a prime number denoted as q, order of the generator PB, coded on z bytes)
Public key (a point denoted as PP on the curve, equal to x times PB where x is the private key, coded
‘86’
on 2z + 1 or 2z or z + 1 bytes)
‘87’ Co-factor
Set of public key data objects for GQ2
‘81’ Modulus (a number denoted as n coded on x bytes)
Number of basic numbers (a number denoted as m coded on 1 byte. If tag ‘83’ is present, then tag
‘83’ ‘A3’ shall be absent and the m basic numbers denoted as g, g .g are the first m prime numbers
2 m
2, 3, 5, 7, 11…)
‘84’ Verification parameter (a number denoted as k coded on 1 byte)
NOTE In this context, ISO/IEC JTC 1/SC 17 reserves any other data object of the context-specific class (first byte in the
range ‘80’ to ‘BF’).
a
The RSA Okamoto-Schnorr signature scheme, is considered a blind signature process, which is an interactive procedure
between a signer and a recipient. It allows a recipient to obtain a signature of a message of the recipient’s choice without
[7][8][9][10]
giving the signer any information about the actual message or the resulting signature. DO’73’ may be used in the
data field for returning multi-part digital signature response comprised of concatenation of context-specific data objects
defined by the application.
© ISO/IEC 2016 – All rights reserved 5

Table 3 (continued)
Tag Value
Set of m basic numbers denoted as g, g .g each one coded on 1 byte with tag ‘80’. (If tag ‘A3’ is
2 m,
‘A3’
present, then tag ‘83’ shall be absent).
a
Set of public key data objects for RSA Okamoto-Schnorr signature scheme
‘81’ p the first large prime number
‘82’ q the second large prime number such that q|(p − 1), with q a divisor of (p − 1)
Zp* the set of integers U modulo p such as 0 < U < p and gcd (U,p) = 1, gcd() being the greatest
‘83’
common divisor
‘84’ Zq* the set of integers U’ modulo q such as 0 < U’ < q and gcd (U’,q) = 1
g the first element of Zp* of order q such as g is a generator of Gq and Gq a cyclic group of prime
‘85’
order q
‘86’ h the second element of Zp* of order q different from g
-r -s
y the public key, an integer denoted as y=g h mod p where (s,r) is the secret key, and s and r are
‘87’
two elements of (Zq*), and h of (Zp*)
NOTE In this context, ISO/IEC JTC 1/SC 17 reserves any other data object of the context-specific class (first byte in the
range ‘80’ to ‘BF’).
a
The RSA Okamoto-Schnorr signature scheme, is considered a blind signature process, which is an interactive procedure
between a signer and a recipient. It allows a recipient to obtain a signature of a message of the recipient’s choice without
[7][8][9][10]
giving the signer any information about the actual message or the resulting signature. DO’73’ may be used in the
data field for returning multi-part digital signature response comprised of concatenation of context-specific data objects
defined by the application.
NOTE 5 For other Blind Signature schemes, e.g. Blind RSA signature (with data objects related to RSA), Blind
Schnorr signature (with data objects related to DSA and/or ECDSA), Okamoto-Guillou-Quisquater blind signature
scheme (with data objects related to GQ2), the OID under template ‘7F49’ determines the nature and meaning of
any further or different data objects, i.e. the following indications may be denoted by the OID
— blind signature type, e.g. RSA, Schnorr, Okamoto-Schnorr, Okamoto-Guillou-Quisquater),
— cryptographic Hash function,
— generic description of the token/credential (message) to be signed,
— attributes generic structure, and/or
— type of control upon signed message, i.e. partially blind, fully blind or restrictive blind signature (in some
mechanisms, the signer does not totally lose control over the signed message since the signer can include
explicit information in the resulting signature based on some agreement with the recipient. Such blind
signatures are called partially blind signatures. Other mechanisms allow a recipient to receive a blind
signature on a message not known to the signer but the choice of the message is restricted and must conform
to certain rules. Such schemes are called restrictive blind signature mechanisms).
For the coding of the DO stating information about the private part of the key pair, Table 4 applies.
6 © ISO/IEC 2016 – All rights reserved

Table 4 — Private key data objects
Tag Value
‘7F48’ Interindustry template for nesting one set of private key data object with the following tags
‘82’ public exponent (optional)
‘92’ parameter p
‘93’ parameter q
‘94’ parameter 1/q mod p
‘95’ parameter d mod (p – 1)
‘96’ parameter d mod (q –1)
Interindustry template for nesting one set of ECDSA/ECDH private key data object with the
‘7F48’
following tags
‘92’ Private key
‘06’ object identifier of related curve (optional)

or
curve information (optional):
‘93’ —  p is the prime specifying the base field;
‘94’ —  A 1st coefficient of the equation y^2 = x^3 + A*x + B mod p defining the elliptic curve;
‘95’ —  B 2nd coefficient of the equation y^2 = x^3 + A*x + B mod p;
‘96’ —  G = (x,y) base point, i.e., a point in E of prime order, with x and y being its x- and y-coordinates;
‘97’ —  q prime order of the group generated by G;
‘98’ —  h cofactor of G in E, i.e. #E[GF(p)]/q.
NOTE In this context, ISO/IEC JTC 1/SC 17 reserves any other data object of the context-specific class (first byte in the
range ‘80’ to ‘BF’).
5.3 perform security operation command
5.3.1 General
The perform security operation command initiates the following security operations:
— computations, such as
— computation of a cryptographic checksum,
— computation of a digital signature, or
— computation of a hash-code;
— verifications, such as
— verification of a cryptographic checksum,
— verification of a digital signature, or
— verification of a certificate;
— encipherment; or
— decipherment.
© ISO/IEC 2016 – All rights reserved 7

P1 defines the expected response data, see Table 6. P2 defines the command data, see Table 7. Values of
tag of SM data object defined in ISO/IEC 7816-4 are used for P1 and P2.
P1 and P2 also define operation of this command. It depends on each operation defined in subsequent
subclauses which value is used for P1 and P2. If the security operation requires several commands to
complete, then command chaining may apply (see ISO/IEC 7816-4).
The perform security operation command may be preceded by a manage security environment
command.
For example, the security object reference as well as the cryptographic mechanism reference shall be
either implicitly known or specified in a CRT in a manage security environment command.
NOTE A security object reference is a reference of a secret key, a reference of a public key, a reference data, a
reference for computing a session key or a reference of a private key. See ISO/IEC 7816-4.
Such a command can be performed only if the security status satisfies the security attributes for the
operation. The successful execution of the command may be subject to successful completion of prior
commands (e.g. verify before the computation of a digital signature).
If present (e.g. implicitly known by the card or because it is part of the command data field), a header
list or an extended header list defines the order and the data items that form the input for the security
operation.
For this command, when a verification related operation is considered, SW1-SW2 set to ‘6300’ or ‘63CX’
indicates that a verification failed, ‘X’ ≥ ‘0’ encodes the number of further allowed retries.
Table 5 — perform security operation command-response pair with INS=‘2A’
CLA As defined in ISO/IEC 7816-4
INS ‘2A’
P1 See Table 6
P2 See Table 7
L field Absent for encoding N = 0, present for encoding N > 0
c c c
Data field Absent or value of the data object specified in P2
L field Absent for encoding N = 0, present for encoding N > 0
e e e
Data field Absent or value of the data object specified in P1
SW1-SW2 See ISO/IEC 7816-4:2013, Tables 5 and 6 where relevant, e.g. 6985
Table 6 — P1 coding for defining the expected response data field
Value Meaning
‘00’ The response data field is absent
‘80’ Plain value not encoded in BER-TLV
‘82’ Cryptogram (plain value encoded in BER-TLV DO and including SM DOs)
‘84’ Cryptogram (plain value encoded in BER-TLV DO, but not including SM DOs)
‘86’ Padding-content indicator byte followed by cryptogram (plain value not encoded in BER-TLV DO)
‘8E’ Cryptographic checksum
‘90’ Hash-code
‘9E’ Digital signature
NOTE Any other value is reserved for future use by ISO/IEC JTC 1/SC 17.
8 © ISO/IEC 2016 – All rights reserved

Table 7 — P2 coding for defining the command data field
Value Meaning
‘00’ The command data field is absent
‘80’ Plain value not encoded in BER-TLV
‘82’ Cryptogram (plain value encoded in BER-TLV DO and including SM DOs)
‘84’ Cryptogram (plain value encoded in BER-TLV DO, but not including SM DOs)
‘86’ Padding-content indicator byte followed by cryptogram (plain value not encoded in BER-TLV DO)
‘92’ Certificate (data not encoded in BER-TLV DO)
‘9A’ Input data element for the computation of a digital signature
‘A0’ 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 integrated)
‘A8’ Input template for the verification of a digital signature (the template is signed)
‘AC’ Input template for the computation of a digital signature (the concatenated value fields are signed)
‘AE’ Input template for the verification of a certificate (the concatenated value fields are certified)
‘BC’ 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)
NOTE Any other value is reserved for future use by ISO/IEC JTC 1 SC 17.
The PSO command with INS = ’2B’ allows security operation commands with extensions. The functions
are distinguished by function numbers in P1, defined in Table 9. Input DOs are conveyed in the command
data field.
Optionally, the last DO is an extended header list describing the output.
Table 8 — perform security operation command-response pair with INS=‘2B’
CLA As defined in ISO/IEC 7816-4:2013, 5.4.1
INS ‘2B’
P1 ‘xx’ function number, to distinguish the different variants of PSO, see Table 9
P2 ‘00’, output DO defined in command data field
L field present for encoding N > 0
c c
Either input DO(s) (see Table 7) or DO’73’, and optionally an extended header list describing the
Data field
output (primitive or constructed) (see Table 6)
L field Absent for encoding N = 0
e e
Data field Absent or output either according to the extended header list or DO’73’
SW1-SW2 See ISO/IEC 7816-4:2013, Tables 5 and 6 where relevant, e.g. 6985
© ISO/IEC 2016 – All rights reserved 9

Table 9 — Function numbers for PSO command
Value Meaning
‘01’ Compute cryptographic checksum
‘02’ Compute digital signature
‘03’ Hash operation
‘04’ Verify cryptographic checksum
‘05’ Verify digital signature
‘06’ Verify certificate
‘07’ Encipher
‘08’ Decipher
NOTE Any other value is RFU.
5.3.2 through 5.3.9 provide further specifications for the case of the even INS code.
5.3.2 compute cryptographic checksum operation
The compute cryptographic checksum operation initiates the computation of a cryptographic
checksum.
Table 10 — Parameters and data fields for compute cryptographic checksum operation
P1 ‘8E’
P2 ‘80’
Command data field Data for which the cryptographic checksum is computed

Response data field Cryptographic checksum
5.3.3 compute digital signature operation
The compute digital signature operation initiates the computation of a digital signature. The
algorithm may be either a digital signature algorithm or a combination of a hash algorithm and a digital
signature algorithm. Annex A provides examples of digital signature operations.
For the computation of a digital signature, the data to be signed or integrated in the signing process are
transmitted in the command data field or submitted in a previous command, e.g. pso hash. In P2, the
digital signature is specified with tag values of SM data object ‘9A’, ‘AC’ or ‘BC’ according to Table 6.
Table 11 — Parameters and data fields for compute digital signature operation
P1 00’ or ‘9E
P2 ’00’, ‘9A’, ‘AC’ or ‘BC
Command data field Absent (data already in the card), or
If P2 = ‘9A’, data to be signed or integrated in the signature process, or
If P2 = ‘AC’, data objects, the concatenated value fields of which are signed or integrated
in the signature process, or
If P2 = ‘BC’, data objects to be signed or integrated in the signature process

Response data field Absent (digital signature stored in the card), or digital signature
10 © ISO/IEC 2016 – All rights reserved

5.3.4 hash operation
The hash operation initiates the computation of a hash-code by performing
— either the complete computation inside the card, or
— a partial computation inside the card.
The HT (‘AA’, ‘AB’) indicates the algorithm reference for computing a hash-code (see ISO/IEC 7816-4).
The input data shall be presented to the card in successive input blocks (one or more at a time), the
length of which is algorithm dependent. Depending on the hash algorithm, the last input data have a
length equal or shorter than the block length. The padding mechanism, if appropriate, is part of the
definition of the hash algorithm.
Even if no data are transmitted (i.e. empty command data when P2=‘80’), P1 shall be set to ‘90’. This is
applicable, for example, when data is already in the card.
For the resulting hash-code, the following two cases have to be distinguished
— either the card stores the hash-code for a subsequent command; then the L field is not present, or
e
— the card delivers the hash-code in the response; then the L field has to be set to the appropriate
e
length.
Table 12 — Parameters and data fields for hash operation
P1 ’00’ or ‘90’
P2 ’00’, ‘80’ or ‘A0’
Command data field If P2 = ‘80’, data to hash, or absent (e.g. for initialization or data already in the card), or
If P2 = ‘A0’, data objects relevant for hashing (e.g. ‘90’ for intermediate hash-code, ‘80’
for data to hash)
Response data field Hash-code or absent
5.3.5 verify cryptographic checksum operation
The verify cryptographic checksum operation initiates the verification of a cryptographic checksum.
Table 13 — Parameters and data fields for verify cryptographic checksum operation
P1 ‘00’
P2 ‘A2’
Command data field Data objects relevant to the operation (e.g. ‘80’, ‘8E’)

Response data field Absent
NOTE The value field of DO’80’ contains data or data elements covered by the value field of DO’8E’ as
cryptographic checksum.
5.3.6 verify digital signature operation
The verify digital signature operation initiates the verification of a digital signature delivered as
a data object in the command data field. Other verification relevant data are either transmitted in a
command chaining process or present in the card. The algorithm may be either a digital signature
algorithm or a combination of a hash algorithm and a digital signature algorithm. Annex A provides
examples of digital signature operations.
© ISO/IEC 2016 – All rights reserved 11

The public key as well as the algorithm may be
— either implicitly known,
— referenced in a DST (‘B6’) of a manage security environment command, or
— available as a result from a previous verify certificate operation.
If the algorithm reference in the card declares a signature only algorithm, then the data consists of
a hash-code, or the signature is of message recovery type [see ISO/IEC 9796 (all parts)]. Otherwise,
the hash-code calculation is performed in the card and the algorithm reference additionally contains a
reference to a hash algorithm.
Table 14 — Parameters and data fields for verify digital signature operation
P1 ‘00’
P2 ‘A8’
Command data field Data objects relevant to the operation (e.g. either ‘9A’, ‘AC’ or ‘BC’, and ‘9E’)

Response data field Absent
If the command data field contains an empty data object, then the card is expected to know all data
relevant for verification.
5.3.7 verify certificate operation
For the verification of a certificate, the digital signature of a certificate to be verified is delivered as a
data object in the command data field. Annex B provides relevant examples of how to implement this
operation, which may help the reader to better understand this subclause.
The public key of the certification authority to be used in the verification process is either implicitly
selected or may be referenced in a DST using the manage security environment command. The
algorithm to apply is implicitly known or may be referenced in a DST. If other data objects are to be
used in the verification process (e.g. hash-code), then these data objects shall be present in the card or
shall be transmitted using the command chaining process.
It is recommended for the public key of the certification authority to be on the card.
The following two cases have to be distinguished:
— if the certificate is self-descriptive (P2 = ‘BE’), then the card retrieves a public key identified by its
tag in the (recovered) certificate content;
— if the certificate is not self-descriptive (P2 = ‘AE’), then the card retrieves a public key in the
certificate either implicitly or explicitly by using the public key tag in a header-list describing the
content of the certificate.
If the retrieved public key is stored in the card, that key may be the default key for the subsequent
operation (e.g verify digital signature).
Practical implementations recommend that tag ‘7F21’ is not used in the data field, on behalf of the
contained templates/DOs of the card verifiable certificates. Next edition of this document may
deprecate the use of ‘7F21’ in this operation.
12 © ISO/IEC 2016 – All rights reserved

Table 15 — Parameters and data fields for verify certificate operation
P1 ‘00’
P2 ‘92’, ‘AE’ or ‘BE’
Command data field Data elements or data objects relevant to the operation.
If P2 = ‘92’, data element to be used in the certificate verification process, (see
ISO/IEC 7816-4:2013, Table 49)
If P2 = ‘BE’, or ‘AE’ data objects to be used in the certificate verification process. The
allowed DOs may be those of a Card Verifiable Certificate (see ISO/IEC 7816-4:2013,
Table 49)
Response data field Absent
If a partial message recovery scheme is used and part of the information is already stored in the card,
then the data object for auxiliary data is expected to be sent empty, with the data to be inserted later by
the card.
5.3.8 encipher operation
The encipher operation enciphers data transmitted in the command data field or data in a card. The
usage of this operation may be restricted.
NOTE The operation may be used for generating diversified keys.
Table 16 — Parameters and data fields for encipher operation
P1 ‘82’, ‘84’, ‘86’ (cryptogram according to ISO/IEC 7816-4:2013, Table 49)
P2 ’00’ or ‘80’ (plain value)
Command data field Absent (data already in the card) or data to be enciphered

Response data field Enciphered data as mandated by the P1 value, according to ISO/IEC 7816-4:2013.
5.3.9 decipher operation
The decipher operation deciphers data transmitted in the command data field. The usage of this
operation may be restricted.
Table 17 — Parameters and data fields for decipher operation
P1 ’00’ or ‘80’ (plain value)
P2 ‘82’, ‘84’, ‘86’ (cryptogram according to ISO/IEC 7816-4:2013, Table 49)
Command data field Data to be deciphered as mandated by the P2 value, according to ISO/IEC 7816-4:2013,
Table 49.
Response data field Absent (deciphered data remains in the card) or deciphered data
© ISO/IEC 2016 – All rights reserved 13

Annex A
(informative)
Examples of operations related to digital signature
A.1 General
This annex provides examples of how to operate with digital signatures. Examples provided here are in
line with EN 14890-1.
A.2 Sequences of commands for managing a security environment
Table A.1 represents a sequence of manage security environment commands to SET DST, CCT and CT
components of the current SE and finally, to STORE the current SE under a SEID indicated in P2.
Table A.1 — Setting of security environment components
Command Operation P1-P2 Command data field
MSE set dst ‘41B6’ {‘84’ − L − Key reference} – {‘91’ − L = 0}
MSE set cct ‘41B4’ {‘83’ − L − Key reference} – {‘87’ − L − Initialization value}
MSE set ct ‘41B8’ {‘83’ − L − Key reference}
MSE store (SEID = 1) ‘F201’ Absent
The SET DST operation references the private key to use in the signature computation and specifies
the integration of a random number in the digital signature input. The SET CCT operation references
a secret key and an initial value to use for the computation of a cryptographic checksum. The SET CT
operation references a secret session key to use for confidentiality.
A.3 Sequences of commands for digital signature computation
Table A.2 shows the syntax for producing a digital signature by using a signature scheme with appendix.
The input is a hash-code completed with padding bytes. This example illustrates the calculation of a
digital signature with combined algorithm including a hash operation. In this example, the hash input is
delivered to the card.
Table A.2 — First example of digital signature scheme with appendix
Command Operation P1-P2 Command data field Response data field
MSE restore ‘F301’ Absent Absent
PSO compute digital signa- ‘9E9A’ Hash-code with padding bytes Digital signature
ture
NOTE 1 This example is purely illustrative and its value is limited in terms of implementation as a result of
possible export controls that might apply and indeed for general security reasons (avoidance of repeat signatures
is desirable in some circumstances).
Table A.3 shows the syntax for producing a digital signature by using a signature scheme with appendix.
The digital signature input consists of the hash-code without padding bytes.
14 © ISO/IEC 2016 – All rights reserved

Table A.3 — Second example of digital signature scheme with appendix
Command Operation P1-P2 Command data field Response data field
MSE restore ‘F301’ Absent Absent
PSO compute digital signa- ‘9E9A’ Hash-code without padding Digital signature
ture bytes
NOTE 2 In order to avoid export restrictions, a combined signature and hash algorithm may be used.
NOTE 3 In some circumstances, avoidance of repeat signatures, although desirable, cannot be achieved.
Table A.4 shows a signature scheme with appendix. The digital signature input contains a hash-code
without padding bytes delivered to the card and the card is requested to generate a random number
as required in the extended header-list of the DST in the command data field of the MSE command. As
specified by tag ‘BC’ in P2, a concatenation of data objects (hash-code provided to the card and random
number provided by the card) is signed.
Table A.4 — Third example of digital signature scheme with appendix
Command Operation P1-P2 Command data field Response
data
field
MSE set ‘41B6’ {‘4D’ − L − (‘90’ − L − ‘91’ − L=0)} – {‘84’ − L − Key reference} Absent
PSO compute ‘9EBC’ {‘90’ − L − Hash-code} Digital
digital signature
signature
Table A.5 shows the syntax for digital signature with limited message recovery. The data to be signed
are configured in accordance with a signature scheme giving limited message recovery using data
objects presented in the command data field, whereby the digital signature counter is used as internal
message provided by the card.
Table A.5 — Fourth example of digital signature scheme with appendix
Command Operation P1-P2 Command data field Response data field
MSE restore ‘F302’ Absent Absent
PSO compute digital ‘9EAC’ {‘90’ − L − Hash-code} Digital signature
signature
NOTE 4 Padding for computing the hash-code as well as the digital signat
...