ISO 20038

Banking and related financial services — Key wrap using advanced encryption standard (AES)

ISO 20038:2017 defines a method for packaging cryptographic keys for transport. This method can also be used for the storage of keys under an AES key. The method uses the block cipher AES as the wrapping cipher algorithm. Other methods for wrapping keys are outside the scope of this document but can use the authenticated encryption algorithms specified in ISO/IEC 19772.

Banque et autres services financiers — Enveloppe de clé utilisant AES (norme de chiffrement avancé)

General Information

• Status: Not Published
• ICS: 35.240.40 - IT applications in banking
• Technical Committee: ISO/TC 68/SC 2 - Financial Services, security
• Drafting Committee: ISO/TC 68/SC 2 - Financial Services, security
• Current Stage: 6000 - International Standard under publication
• Start Date: 25-Apr-2026
• Completion Date: 25-Apr-2026

Relations

• Revises: ISO 20038:2017 - Banking and related financial services — Key wrap using AES
• Effective Date: 25-Mar-2023

Overview

ISO/FDIS 20038 is an international standard developed by ISO for banking and related financial services, specifically addressing key wrap methods using the Advanced Encryption Standard (AES). The standard provides a secure and interoperable method for packaging cryptographic keys for transport and storage. By leveraging AES as the core wrapping cipher, this standard ensures both the confidentiality and integrity of cryptographic keys, critical assets in secure financial transactions and operations.

Designed for use by financial institutions, payment processors, and related sectors, ISO/FDIS 20038 defines a consistent format and process for key wrapping, which is essential for key management and compliance in highly regulated environments.

Key Topics

• Key Wrap Using AES: ISO/FDIS 20038 specifies the use of AES, aligned with FIPS 197, as the key wrapping algorithm, offering strong security and global acceptance.
• Key Block Structure: Outlines a standardized format for key blocks, composed of a header, encrypted confidential data, and an authentication (integrity) value. This structure promotes interoperability across systems.
• Key Block Header (KBH): The non-encrypted section of a key block containing descriptive attributes such as version, key usage, algorithm, mode of use, exportability, and optional elements to support a variety of use cases.
• Confidential Data Encapsulation: Encrypted with AES, this component contains the cryptographic key and associated confidential attributes. Padding is used to enhance privacy and protect against key length disclosure.
• Authentication Value: Typically represented as a Message Authentication Code (MAC), the authentication value verifies the integrity and authenticity of the header and confidential data.
• Flexible Key Contexts: The format supports key blocks for both transport (exchange) and storage scenarios, enabling secure key lifecycle management.

Applications

ISO/FDIS 20038 is highly relevant to organizations requiring robust cryptographic key management, particularly in financial services. Key applications include:

• Secure Key Transport: Ensuring cryptographic keys are securely wrapped for transmission between secure cryptographic devices (SCD), such as hardware security modules (HSM), point-of-sale (POS) terminals, or ATMs.
• Key Storage: Protecting keys at rest under an AES wrapping key, compliant with internal policies and industry mandates.
• Interoperable Key Exchange: Facilitating key sharing and migration between different institutions or systems in a standardized, secure manner.
• Regulatory Compliance: Satisfying regulatory requirements and supporting auditability by enforcing the use of well-defined, secure, and documented cryptographic procedures.
• Multi-Algorithm Support: The approach allows for the wrapping of various key types (AES, TDEA, RSA, ECC), increasing flexibility while maintaining security and usability.
• Key Diversification and Derivation: Supporting robust schemes for generating unique keys tied to specific device or transaction contexts within financial networks.

Related Standards

ISO/FDIS 20038 references and is aligned with several key industry and cryptographic standards, promoting integration and compliance. Related standards include:

• ISO/IEC 19772: Authenticated encryption algorithms for use in alternative key wrapping scenarios.
• ISO 11568: Key management standards for retail financial services.
• ANSI X9.143-2022: Interoperable secure key block specifications for retail financial services.
• NIST SP 800-57 & SP 800-108: Recommendations on key management and key derivation using pseudorandom functions.
• IETF RFC 4648: Data encoding schemes (Base16, Base32, Base64) relevant for encoding cryptographic data.
• ISO 9564-5: Standards for PIN management and security.

Conclusion

Implementing ISO/FDIS 20038 enables financial institutions and related organizations to adopt a secure, standardized approach to cryptographic key transport and storage using AES. This promotes operational efficiency, regulatory compliance, and robust security across the financial services ecosystem. By following ISO/FDIS 20038, organizations can ensure that sensitive cryptographic material is managed and exchanged in a manner that is both secure and globally recognized.

Standards Content (Sample)

DRAFT
International
Standard
ISO/DIS 20038.2
ISO/TC 68/SC 2
Banking and related financial
Secretariat: BSI
services — Key wrap using
Voting begins on:
advanced encryption standard
2024-12-09
(AES)
Voting terminates on:
ICS: 35.240.40
2025-02-03
THIS DOCUMENT IS A DRAFT CIRCULATED
FOR COMMENTS AND APPROVAL. IT
IS THEREFORE SUBJECT TO CHANGE
AND MAY NOT BE REFERRED TO AS AN
INTERNATIONAL STANDARD UNTIL
PUBLISHED AS SUCH.
IN ADDITION TO THEIR EVALUATION AS
BEING ACCEPTABLE FOR INDUSTRIAL,
TECHNOLOGICAL, COMMERCIAL AND
USER PURPOSES, DRAFT INTERNATIONAL
STANDARDS MAY ON OCCASION HAVE TO
This document is circulated as received from the committee secretariat.
BE CONSIDERED IN THE LIGHT OF THEIR
POTENTIAL TO BECOME STANDARDS TO
WHICH REFERENCE MAY BE MADE IN
NATIONAL REGULATIONS.
RECIPIENTS OF THIS DRAFT ARE INVITED
TO SUBMIT, WITH THEIR COMMENTS,
NOTIFICATION OF ANY RELEVANT PATENT
RIGHTS OF WHICH THEY ARE AWARE AND TO
PROVIDE SUPPORTING DOCUMENTATION.
Reference number
ISO/DIS 20038.2:2024(en)
DRAFT
ISO/DIS 20038.2:2024(en)
International
Standard
ISO/DIS 20038.2
ISO/TC 68/SC 2
Banking and related financial
Secretariat: BSI
services — Key wrap using advanced
Voting begins on:
encryption standard (AES)
ICS: 35.240.40
Voting terminates on:
THIS DOCUMENT IS A DRAFT CIRCULATED
FOR COMMENTS AND APPROVAL. IT
IS THEREFORE SUBJECT TO CHANGE
AND MAY NOT BE REFERRED TO AS AN
INTERNATIONAL STANDARD UNTIL
PUBLISHED AS SUCH.
IN ADDITION TO THEIR EVALUATION AS
BEING ACCEPTABLE FOR INDUSTRIAL,
© ISO 2024
TECHNOLOGICAL, COMMERCIAL AND
USER PURPOSES, DRAFT INTERNATIONAL
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
STANDARDS MAY ON OCCASION HAVE TO
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
This document is circulated as received from the committee secretariat. BE CONSIDERED IN THE LIGHT OF THEIR
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
POTENTIAL TO BECOME STANDARDS TO
WHICH REFERENCE MAY BE MADE IN
or ISO’s member body in the country of the requester.
NATIONAL REGULATIONS.
ISO copyright office
RECIPIENTS OF THIS DRAFT ARE INVITED
CP 401 • Ch. de Blandonnet 8
TO SUBMIT, WITH THEIR COMMENTS,
CH-1214 Vernier, Geneva
NOTIFICATION OF ANY RELEVANT PATENT
Phone: [phone]
RIGHTS OF WHICH THEY ARE AWARE AND TO
PROVIDE SUPPORTING DOCUMENTATION.
Email: [e-mail]
Website: www.iso.org
Published in Switzerland Reference number
ISO/DIS 20038.2:2025(en)
ii
ISO/DIS 20038.2:2025(en)
Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms, definitions and abbreviations . 1
3.1 Terms and definitions .1
3.2 Abbreviations .5
4 Notation . 5
5 Key Block Elements . 6
6 Key Block Format . . 7
6.1 Introduction .7
6.2 Key block header (KBH) .8
6.2.1 General .8
6.2.2 Changing Key Headers .11
6.3 Defined values for key block headers . 12
6.3.1 Key Usage . 12
6.3.2 Algorithm .17
6.3.3 Mode of use .17
6.3.4 Key Version Number .19
6.3.5 Exportability .19
6.3.6 Optional block ID . 20
6.4 Encoding .43
6.4.1 General .43
6.4.2 RSA Key Pairs . 44
6.4.3 Elliptic Curve Cryptography (ECC) Key Pairs .45
7 Key Block Binding and Validation Methods .45
7.1 General .45
7.2 Key Block Binding Method Using Key Derivation . 46
7.2.1 General . 46
7.2.2 Key Derivation Binding Method – AES. 46
7.2.3 Key Derivation Binding Validation Method - AES . 50
8 Examples . 51
8.1 AES Key Block Example .51
8.1.1 Introduction .51
8.1.2 Constructing the key block header .51
8.2 AES key block with optional blocks .57
8.2.1 Introduction .57
8.2.2 Keys used in the example .57
8.2.3 Constructing the key block header . 58
8.3 RSA key block Example with CT optional block . 60
8.3.1 General . 60
8.3.2 Keys used in the example . 60
8.3.3 Constructing the key block header .61
8.3.4 Constructing the binary key data . 63
8.3.5 Constructing the complete key block . 64
8.4 ECC key block Example with CT certificate chain optional block . 66
8.4.1 General . 66
8.4.2 Keys used in the example . 66
8.4.3 Constructing the key block header .67
8.4.4 Constructing the binary key data . 68
8.4.5 Constructing the complete key block . 69
8.5 CTR mode without padding .70

iii
ISO/DIS 20038.2:2025(en)
Annex A (normative) Directed Key Diversification .71
Annex B (informative) Operational challenges and examples with exportability .79
Bibliography .88

iv
ISO/DIS 20038.2:2025(en)
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out through
ISO technical committees. Each member body interested in a subject for which a technical committee
has been established has the right to be represented on that committee. International organizations,
governmental and non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely
with the International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
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 ISO 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).
ISO draws attention to the possibility that the implementation of this document may involve the use of (a)
patent(s). ISO takes no position concerning the evidence, validity or applicability of any claimed patent
rights in respect thereof. As of the date of publication of this document, ISO had not received notice of (a)
patent(s) which may be required to implement this document. However, implementers are cautioned that
this may not represent the latest information, which may be obtained from the patent database available at
www.iso.org/patents. ISO shall not be held responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO's adherence to the World Trade
Organization (WTO) principles in the Technical Barriers to Trade (TBT), see www.iso.org/iso/foreword.html.
This document was prepared by Technical Committee ISO/TC 68, Financial services, Subcommittee SC 2,
Financial services, security.
This second edition cancels and replaces the first edition (ISO 20038:2017), which has been technically
revised.
The main changes are as follows:
— updated for compatibility with ANSI X9.143-2022.
A list of all parts in the ISO 20038 series can be found on the ISO website.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.

v
ISO/DIS 20038.2:2025(en)
Introduction
The secure management of cryptographic keys requires that their values and usage constraints be protected
for both confidentiality and integrity.
This document provides a method of wrapping cryptographic keys in order to provide confidentiality and
integrity protection for the keys when being transmitted or stored. The mechanism is designed to use
advanced encryption standard (AES) specified in FIPS 197 as the wrapping cipher.

vi
DRAFT International Standard ISO/DIS 20038.2:2025(en)
Banking and related financial services — Key wrap using
advanced encryption standard (AES)
1 Scope
This document defines a method for packaging cryptographic keys for transport. This method can also be
used for the storage of keys under an advanced encryption standard (AES) key. The method uses the block
cipher AES as the wrapping cipher algorithm.
Other methods for wrapping keys are outside the scope of this document but can use the authenticated
encryption algorithms specified in ISO/IEC 19772.
2 Normative references
There are no normative references in this document.
3 Terms, definitions and abbreviations
3.1 Terms and definitions
For the purposes of this document, the following terms, definitions and abbreviations apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
3.1.1
advanced encryption standard
AES
16-byte block cipher
Note 1 to entry: This is defined in ISO/IEC 18033-3
[SOURCE: ISO 11568:2023, 3.2]
3.1.2
ASCII
American Standard Code for Information Interchange
binary encoding of 7-bit characters defined by ISO/IEC 646
[SOURCE: ISO/IEC 18477-4:2017(en), 3.1.2]
3.1.3
authentication value
cryptographically generated value ((message authentication code (3.1.23)) derived from the key block header
and confidential data that can be used to validate the integrity of the data contained in the key block

ISO/DIS 20038.2:2025(en)
3.1.4
CBC
cipher block chaining
confidentiality mode whose encryption process features the combining (“chaining”) of the plaintext blocks
with the previous ciphertext blocks
[SOURCE: NIST SP800-38A: 2001]
3.1.5
cryptographic domain
set of one or more secure cryptographic devices (3.1.26) that contain or are able to use the same set of keys
Note 1 to entry: All secure cryptographic devices (3.1.26)in the domain are considered to be “equivalent” in that a key
that can be used in one secure cryptographic device (3.1.26)in the domain is also available for use by any other secure
cryptographic device (3.1.26) in the domain.
Note 2 to entry: A cryptographic domain is often defined for host processing to provide load balancing of HSMs.
Note 3 to entry: The keys are typically structured in a hierarchy where higher-level keys are used to provide protection
for lower-level keys.
3.1.6
CTR
counter mode of encryption
confidentiality mode that features the application of the forward cipher to a set of input blocks, called
counters, to produce a sequence of output blocks that are exclusive-ORed with the plaintext to produce the
ciphertext, and vice versa
[SOURCE: NIST SP800-38A:2001]
3.1.7
DEA
Data Encryption Algorithm
Cryptographic algorithm originally specified in FIPS 46, The Data Encryption Standard, which became
effective July 1977
[SOURCE: NIST SP 800-67 Rev. 2]
3.1.8
hex-ASCII
number in base 16 expressed as ASCII (3.2) characters
EXAMPLE The 32-bit message authentication code (3.1.23) result 0x12345678 (4 binary bytes) is encoded as eight
hex-ASCII characters that reads "12345678" but is stored or transmitted as 0x3132333435363738.
3.1.9
initialization vector
IV
binary value used as a starting point for the encryption of a data sequence in order to increase security by
introducing additional cryptographic variance and to synchronize cryptographic equipment
3.1.10
key block
result of performing a cryptographic process over a key and its associated data to produce a key block
header (KBH), ciphertext and authentication value (3.1.3) – the message authentication code (3.1.23)
[SOURCE: ANSI X9.143:2022, 3.15]

ISO/DIS 20038.2:2025(en)
3.1.11
key block encryption key
KBEK
key that is derived from the key block protection key (3.1.13) and that is used solely for enciphering the key
block (3.1.10)
[SOURCE: ANSI X9.143:2022, 3.16]
3.1.12
key block authentication key
KBAK
key that is derived from the key block protection key (3.1.13) and that is used solely for calculating the
message authentication code (3.1.23) over the key block (3.1.10)
[SOURCE: ANSI X9.143:2022, 3.17]
3.1.13
key block protection key
KBPK
key wrapping key (3.1.20) that is used as a derivation key from which the key block encryption key (3.1.11)
and the key block authentication key (3.1.12) are derived
Note 1 to entry: This key is used for no other purpose.
[SOURCE: ANSI X9.143:2022, 3.18]
3.1.14
key diversification
HSM secured operation to derive a key from another key by means of a key derivation function and derivation
data that contains the key attributes that shall be assigned to the derived key by the HSM.
3.1.15
key diversification key
KDK
key used in an HSM function implementing the directed key diversification scheme (see Annex A) where a
key is derived from the key diversification key according to a type A or B, bound to the key diversification
key, and a key type vector (3.1.19) that is input to the derivation function and used by the HSM to control the
attributes of the derived key
3.1.16
key encrypting key
KEK
key used exclusively to encrypt and decrypt other keys
[SOURCE: ANSI X9.143:2022, 3.19]
3.1.17
key export
secure cryptographic device (3.1.26) operation that a) unwraps a key and its attributes from a storage key
encrypting key (3.1.16) or the master file key (3.1.22) and re-encrypts that key under a key wrapping key
(3.1.20) shared with another entity or internal system; or b) wraps a clear key and its attributes that is
stored within an secure cryptographic device (3.1.26) using a key wrapping key (3.1.20) shared with another
entity or internal system
[SOURCE: ANSI X9.143:2022, 3.20]

ISO/DIS 20038.2:2025(en)
3.1.18
key import
secure cryptographic device (3.1.26) operation that unwraps a key and its attributes using a key wrapping key
(3.1.20) shared with another entity or system and then stores the key and its attributes from the key block
within one or more related secure cryptographic devices (3.1.26) or re-wraps the key and its attributes using
a storage key encrypting key (3.1.16) or the master file key (3.1.22)
[SOURCE: ANSI X9.143:2022, 3.21]
3.1.19
key type vector
KTV
Set of attributes formatted according to the directed key diversification scheme (see Annex A) and used as
input to the diversification of a key diversification key in generating a derived key
3.1.20
key wrapping key
symmetric key that determines the wrapping (3.1.30) and unwrapping (3.1.29) functions of a key wrapping
mechanism (3.1.21)
[SOURCE: ANSI X9.143:2022, 3.22]
3.1.21
key wrapping mechanism
symmetric key authenticated encryption mechanism that is intended for the protection of cryptographic
keys and other specialized data
[SOURCE: ANSI X9.143:2022, 3.23]
3.1.22
master file key
MFK
key used to encrypt other keys for storage
Note 1 to entry: Storage may be internal to the secure cryptographic device (3.1.26) housing the master file key or may
pertain to external storage (e.g. on a host system).
[SOURCE: ANSI X9.143:2022, 3.24]
3.1.23
message authentication code
MAC
cryptographic value which is the result of passing a financial message through the message authentication
algorithm using a specific key
[SOURCE: ANSI X9.143:2022, 3.25]
3.1.24
PIN
personal identification number
numeric code used to authenticate an identity
[SOURCE: ISO/IEC 19790:2012]
3.1.25
pseudorandom function
function that can be used to generate output from a random seed and a data variable such that the output is
computationally indistinguishable from truly random output

ISO/DIS 20038.2:2025(en)
3.1.26
secure cryptographic device
SCD
device that provides physically and logically protected cryptographic services and storage [e.g. PIN (3.1.24)
entry device (PED) or hardware security module (HSM)], and which can be integrated into a larger system,
such as an automated teller machine (ATM) or point of sale (POS) terminal
[SOURCE: ISO 13491-1:2016, 3.28]
3.1.27
subkey
cryptographic key that is used internally in a cryptographic algorithm, such as CMAC, and not chosen by or
exposed to the user of the algorithm
3.1.28
TDEA
Triple Data Encryption Algorithm
symmetric algorithm
Note 1 to entry: The TDEA is specified in the ISO/IEC 18033 series
[SOURCE: ISO 11568:2023, 3.87]
3.1.29
unwrapping
function in a key wrap mechanism that either produces the key data from the ciphertext or indicates that
either the ciphertext or the associated data is invalid
[SOURCE: ANSI X9.143:2022, 3.32]
3.1.30
wrapping
function in a key wrap mechanism that produces the ciphertext from and creates a validity check for the key
and associated data
[SOURCE: ANSI X9.143:2022, 3.33]
3.2 Abbreviations
For the purposes of this document, the following abbreviations apply:
ECC elliptic curve cryptography
EMV Europay, Mastercard, Visa
HMAC keyed-hash message authentication code
ID identifier
KBH key block header
RSA Rivest, Shamir and Adelman
4 Notation
The following are used to indicate field encoding in the key block:
a) nA – n-digits of alphabetic (‘A’ to ‘Z’, ‘a’ to ‘z’), for example 6A means exactly six alphabetic characters
in ASCII.
ISO/DIS 20038.2:2025(en)
b) nAN – alphanumeric (‘A’ to ‘Z’, ‘a’ to ‘z’, ‘0’ to ‘9’), for example 6AN means exactly six alphanumeric
characters in ASCII.
c) nH – hex-ASCII (‘0’ to ‘9’, ‘A’ to ‘F’), for example 6H means exactly six hex-ASCII characters.
d) nN – numeric-ASCII (‘0’-‘9’), for example 6N means exactly six decimal characters in ASCII.
e) nB – binary bytes (0x00 to 0xFF), for example 6B means exactly six bytes of binary data.
f) nPA – n printable ASCII characters. Printable ASCII characters are those with hexadecimal values in the
range 20 to 7E, inclusive. 6PA means exactly six printable ASCII characters.
g) || – used for concatenation of bitstrings, for example 30A4F || 0C1 is equal to 30A4F0C1.
h) ⊕ – xor. Bit-wise, xor is defined as 0⊕0=0, 0⊕1=1, 1⊕0=1 and 1⊕1=0. ⊕ applied to longer strings is
performed bitwise, for example 0x3FC4 ⊕ 0xED27 = 0xD2E3.
i) << – left-shift. If M is a bit string, then M<<1 means M shifted one bit to the left. For example, the bit
string 0101010<<1 is 1010100 and 1010100<<1 is 0101000. Notice that the length of M<<1 is the same as
the length of M. Left-shift can also be described as multiplying by 2, without carry.
j) 0x – Notation indicating a hexadecimal number follows. For example, 0x31 indicates 31-hexadecimal
(49-decimal).
5 Key Block Elements
The key block shall contain three parts:
a) the key block header (KBH) which contains non-sensitive attribute information about the key and the
key block;
b) the confidential data that is being exchanged or stored (i.e. the key and attributes formatted according
to the key data format);
c) the authentication value which consists of a MAC that binds the key block header and confidential data.
This general format of a key block is illustrated in Figure 1.
Figure 1 — Key Block
For TDEA and AES keys the confidential data should be padded to the maximum key length to hide its true
length (key length obfuscation padding) from an external observer. When the confidential data is padded
for key length obfuscation:
— TDEA keys less than 192 bits shall be padded to 192 bits.
— AES keys less than 256 bits shall be padded to 256 bits.
— Requirements for padding values are defined in detailed description in the next paragraph.

ISO/DIS 20038.2:2025(en)
The key length obfuscation padding is determined by the size of the key being wrapped, as described in
the previous paragraph, but the block padding is determined by the algorithm being used to encrypt the
confidential data. Because of the existence of the key length field in the information that is encrypted,
additional padding is necessary to make the block consistent with the size of block the algorithm requires.
For example, AES operates on 128 bits, so if the key is padded out to 256 bits, because of the key length field
additional block padding characters are required.
For operational and compliance reasons, it is permissible for an entity to have SCD mechanisms to:
a) verify key length, such as against an organization's policies and industry requirements;
b) obtain key length information of stored keys.
Such SCD mechanisms should be managed with SCD administrative controls requiring dual-control
execution.
6 Key Block Format
6.1 Introduction
This clause defines a secure key block that uses the methods described in clause 7.
Key blocks constructed according to this document shall also conform to the relevant key wrapping
requirements in ANSI X9.102.
The key block is a variable-length structure with a maximum length of 9999 bytes. The key block is
composed of three sub-structures: a variable-length header, a variable-length confidential data field, and an
authentication value. The header may include optional fields.
The key block shall consist of three parts:
a) The key block header (KBH), which contains attribute information about the key and the key block and
is not encrypted
1) The first section is 16 bytes with a fixed format defined in Table 1
b) The second section is variable length and optional
1) The confidential data which will be encrypted
2) Two bytes indicating the key length
3) The secret key and/or sensitive data
4) Random key length obfuscation padding as required.
5) Random cipher block padding.
c) The authentication value. The length of the authentication value shall be as follows:
1) 128 bits because the AES key derivation method is used (see subclause 7.2.2)
TDEA and AES symmetric keys should be padded with random key length obfuscation padding to the
maximum length for the algorithm, 192 bits for TDEA or 256 bits for AES. Other key types will not be padded
for key length obfuscation but are padded up to the cipher block of the wrapping method (e.g. HMAC, RSA
and ECC keys). This format is illustrated in Figure 2.

ISO/DIS 20038.2:2025(en)
Figure 2 — Key Block
6.2 Key block header (KBH)
6.2.1 General
The header shall contain attribute information about the key as defined in Table 1. The specific encoding
and acceptable characters are defined individually for each field, for example in the “Encoding” column of
Table 1. When the term “numeric” is used to describe an ASCII header byte, it means an ASCII character in
the range “0” to “9” (0x31 to 0x39). A multi-byte header field is considered numeric only when all bytes of
the field contain numeric values. Table 1 shows the format of the KBH. See subclause 6.3 for defined key
attributes.
Table 1 — Key block header
Byte # Field name Description Encoding Encrypted
0 Key block version Identifies the version of the key block, which defines the 1AN No
ID (identifier) method by which it is cryptographically protected and
layout of the block:
‘D’ (0x44) – key block protected using the AES key
derivation binding method (see subclause 7.2.1)
'E' (0x45) – key block protected using the AES key
derivation binding method for CTR mode.
Note that numeric key block version IDs are reserved for
proprietary key block definitions. Also note that multiple
key block versions may be in use at any time.
The key block version ID should not be used as a proxy for
determining which optional block elements are support-
ed. Applications should predetermine which optional
block elements are supported.
Future versions of this document might define other val-
ues. The values ‘A’, ‘B’ and ‘C’ are not used by this docu-
ment.
ISO/DIS 20038.2:2025(en)
TTaabblle 1 e 1 ((ccoonnttiinnueuedd))
Byte # Field name Description Encoding Encrypted
1-4 Key block length ASCII numeric digits providing key block length after 4N No
encoding. Length includes the entire block (header + en-
crypted confidential data + MAC) in decimal; for example,
a 112-byte key block would contain ‘0’ (0x30) in byte #0,
‘1’ (0x31) in byte #1, ‘1’ (0x31) in byte #2 and ‘2’ (0x32) in
byte #3
5-6 Key usage Provides information about the intended function of 2AN No
the protected key or sensitive data. Common functions
include encrypting data, encrypting PINs and calculating a
MAC. See Table 2 for defined values.
7 Algorithm The approved algorithm for which the protected key may 1AN No
be used. See Table 3 for defined values.
8 Mode of use Defines the operation the protected key can perform. For 1AN No
key blocks being transmitted, the mode of use is in the
context of the recipient SCD. For key blocks being stored,
the mode of use is in the context of the SCD using the key.
For example, an authentication key might be limited to
verify-only. See Table 4 for defined values.
9-10 Key version Two-digit ASCII character version number, optionally used 2AN No
number to indicate that the content of the key block is a compo-
nent, or to prevent re-injection of old keys. See Table 5 for
defined values.
11 Exportability Defines whether the protected key may be transferred 1AN No
outside the cryptographic domain in which the key is
found.
See Table 6 for defined values.
12-13 Number of op- Defines the number of optional blocks included in the key 2N No
tional blocks block. The minimum value is zero and the maximum is 99,
but it is also limited by the maximum number of bytes in
the entire key block. For example, 5 optional blocks would
be represented by ‘0’ (0x30) in byte 12 and ‘5’ (0x35) in
byte 13.
14 Key context This field indicates whether the key block is in a key ex- 1N No
– storage or change context (wrapped by a transport key) or in a stor-
exchange age context (e.g. wrapped by the MFK). The key context
value does not require a certain exportability setting.
The values are:
'0' (0x30) – Either storage or key exchange context. This
allows interoperability with legacy key blocks. Note
that this does not imply that the wrapping key for a key
block can be used for both storage and key exchange,
merely that the storage or exchange of this key block
is determined by the properties of the wrapping key.
'1' (0x31) – Storage context only. The key block is not
wrapped by a transport key for exchange between a
communicating pair.
'2' (0x32) – Key exchange context only. The key block is
wrapped by a transport key for exchange between a
communicating pair.
15 Reserved for This field is reserved for future use and is filled with 1N No
future use ASCII zero (0x30) characters.
Fields after byte 15 are only present if bytes 12-13 contain a value other than ‘00’ (0x3030)
16-17 First optional ID field for the first optional block, if one is present as in- 2AN No
block ID dicated by a value other than ‘00’ in bytes 12 and 13. The
possible ID values are defined in subclause 6.3.6.

ISO/DIS 20038.2:2025(en)
TTaabblle 1 e 1 ((ccoonnttiinnueuedd))
Byte # Field name Description Encoding Encrypted
18-19 optional block 1 If the first optional block is present, indicated by a value 2H No
length other than ‘00’ in bytes 12 and 13, then this field contains
the length of that optional block in bytes, including the
field’s ID, length and data. Byte 18 contains the high-or-
der byte of the length and byte 19 contains the low-order
byte, both in hex-ASCII form. For example, for a 24-byte
optional block (0x18 in hexadecimal notation), byte 18
would contain a '1' (0x31) and byte 19 would contain an
'8' (0x38). optional block data might be omitted, in which
case the optional block length will be '04'.
If the length of the optional block exceeds 255, this field
is set to '00' and the actual length is encoded in the next
two fields. The actual length is limited by the maximum
number of bytes in the key block length.
20-n optional block 1 This field contains the length of the field named “Extend- 2H No
length of length ed optional block 1 length”. Valid values are '01' – 'FF'. For
this document this value is always '04'.
This field is only present if the optional block 1 length
is '00'.
Extended option- The actual length of the block, expressed as a hexadecimal 4H No
al block 1 length number. For example, if the optional block length is 400
bytes (190 ), this field is '0190'.
This field is only present if the optional block 1 length
is '00'.
n-m optional block 1 If the first optional block is present, indicated by a value PA No
data other than ’00’ in bytes 12-13, then this field contains the
data for that optional block. It will contain only printable
ASCII characters.
n-m Additional op- A variable number of optional blocks can follow the first No
tional blocks, if optional block, as indicated by the count in bytes 12-13.
present Each optional block contains a 2-byte ID, 2-byte length
and variable-length data field following the same format
described for optional block 1.
Before a key in the key block format is used in a secure cryptographic device (SCD), the contents of the header
block shall be validated to ensure the correct usage is enforced. First, the SCD makes sure that the length of
the key block matches the contents of bytes 1 to 4. If the lengths do not match, the SCD returns an error and
stops processing the block. The “key usage” byte is typically checked next followed by the “algorithm” byte.
The processing of the other header bytes depends on the key usage and the algorithm used.
From 0-99 optional blocks can be included in the key block, with the limitation that the total length of the
key block shall not exceed the maximum length that can be represented by the key block length field in bytes
1-4. The total number of optional blocks is indicated by a count in bytes 12-13. Each optional block consists of
three fields: a 2-byte identifier that indicates the content of the optional block, a 2-byte length that indicates
the total number of bytes in all of the optional block’s fields and the variable-length data carried in the
optional block. See Table 7 for a list of valid identifiers.
As an example, consider an optional block that contains a key set identifier. A sample block could contain the
following data.
Identifier: ‘KS’
Length: ‘18’
Data: ‘00604B120F9292800000’
NOTE The length value equals 2+2+20 (24). The length value is encoded in Hex-ASCII; 18 hexadecimal equals 24
decimal.
ISO/DIS 20038.2:2025(en)
If more than one optional block is present, each one shall immediately follow the previous one in the key
block structure.
The total length of all optional blocks in the key block shall be a multiple of the encryption block size. This
might require padding, and if padding is needed it shall be included in a special final optional block that
is filled with an appropriate number of padding characters. For example, if the total length of all optional
blocks before padding is 90, six additional bytes are needed in order to bring the total to the next multiple
of the encryption block size, 96. A padding block would be added as the last optional block, containing the
2-byte identifier ‘PB’, a 2-byte length field ‘06’ and two characters of padding.
6.2.2 Changing Key Headers
A single key under two different headers with different attributes creates the potential for attacks.
Therefore, the SCD shall not generate a key with multiple headers or change the value of a key header except
as described in the list after this paragraph. This includes changing the header when changing the wrapping
key. Similarly, there shall be a policy that users shall not manually load the same key bound to different
attributes except under the same rules. Checking manual loading rules is generally not enforceable within
the HSM since these are distributed systems. SCDs that translate a key to a non- ANSI X9.143/TR-31 format
should maintain equivalent usage separation to the ANSI X9.143/TR-31 headers.
Legitimate changes to the headers are as follows:
a) A header may be changed to become more restrictive. The reverse operation of any of these is not
allowed (e.g. an encrypt-only key cannot become both encrypt and decrypt).
1) An exportable key may become non-exportable (i.e. exportability "E" may become "N").
2) A key that supports both encrypt and decrypt can become either encrypt-only or decrypt-only (i.e.
mode of use "B" can become mode of use "E" or "D").
3) A key that supports both generate and verify can become generate-only or verify-only (i.e. mode of
use "C" can become mode of use "G" or "V").
4) A key that supports both sign and decrypt can become sign-only or decrypt-only (i.e. mode of use
"T" can become mode of use "S" or "D").
b) SCDs may generate a key marked as non-exportable and export that key in a single key export command
or operation. Effectively, this is shorthand for internally generating an exportable version of that key,
exporting the key as non-exportable key and then changing the local copy of the key to non-exportable.
Since the original exportable version of the key is never exposed outside of the SCD, this creates a “one-
time exportable” key. The SCD shall not export keys marked as non-exportable except as part of the key
generation function.
c) Uni-directional keys need to occur in matching pairs. For example, an encrypt-only key at the sender
needs a decrypt-only (or both direction) key at the receiver. This means that reversing the mode of use
upon export can be necessary. However, this creates a potential weakness in that an SCD’s commands
could be used with a bi-directional KBPK to change the usage of the key within the SCD.
1) Keys that have strong single-direction usage requirements shall be marked non-exportable.
2) Single-direction keys that are exportable or one-time exportable should only be exported under
single-direction KBPKs.
d) optional blocks may be added, removed or changed, except for the HMAC optional block, which cannot
be removed or changed when included.
e) Keys with usage "K0" may be converted to be keys with usage "K1".

ISO/DIS 20038.2:2025(en)
6.3 Defined values for key block headers
6.3.1 Key Usage
Key usage defines the type of the key, whether it is used, for example, to encrypt data or calculate a MAC.
The key usage is identified by bytes 5 and 6. Table 2 shows the currently defined key usage values. There is
additional information for each defined value after Table 2.
Table 2 — Defined key usage values
Value Hex Definition Mode(s) of Use Allowed key block
header version ID
values
‘B0’ 0x4230 Base derivation key (BDK) ‘X’ ’D’,’E’
‘B1’ 0x4231 Initial DUKPT key ‘X’ ’D’,’E’
‘B2’ 0x4232 Base key variant key (deprecated) ‘Y’ ’D’,’E’
‘B3’ 0x4233 Key derivation key (non-ANSI X9.24 / ISO 11568) ‘X’ ’D’,’E’
‘B4’ 0x4234 Key diversificat
...

FINAL DRAFT
International
Standard
ISO/FDIS 20038
ISO/TC 68/SC 2
Banking and related financial
Secretariat: BSI
services — Key wrap using
Voting begins on:
advanced encryption standard
2026-02-27
(AES)
Voting terminates on:
2026-04-24
RECIPIENTS OF THIS DRAFT ARE INVITED TO SUBMIT,
WITH THEIR COMMENTS, NOTIFICATION OF ANY
RELEVANT PATENT RIGHTS OF WHICH THEY ARE AWARE
AND TO PROVIDE SUPPOR TING DOCUMENTATION.
IN ADDITION TO THEIR EVALUATION AS
BEING ACCEPTABLE FOR INDUSTRIAL, TECHNO­
LOGICAL, COMMERCIAL AND USER PURPOSES, DRAFT
INTERNATIONAL STANDARDS MAY ON OCCASION HAVE
TO BE CONSIDERED IN THE LIGHT OF THEIR POTENTIAL
TO BECOME STAN DARDS TO WHICH REFERENCE MAY BE
MADE IN NATIONAL REGULATIONS.
Reference number
ISO/FDIS 20038:2026(en) © ISO 2026

FINAL DRAFT
ISO/FDIS 20038:2026(en)
International
Standard
ISO/FDIS 20038
ISO/TC 68/SC 2
Banking and related financial
Secretariat: BSI
services — Key wrap using
Voting begins on:
advanced encryption standard
(AES)
Voting terminates on:
RECIPIENTS OF THIS DRAFT ARE INVITED TO SUBMIT,
WITH THEIR COMMENTS, NOTIFICATION OF ANY
RELEVANT PATENT RIGHTS OF WHICH THEY ARE AWARE
AND TO PROVIDE SUPPOR TING DOCUMENTATION.
© ISO 2026
IN ADDITION TO THEIR EVALUATION AS
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
BEING ACCEPTABLE FOR INDUSTRIAL, TECHNO­
LOGICAL, COMMERCIAL AND USER PURPOSES, DRAFT
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
INTERNATIONAL STANDARDS MAY ON OCCASION HAVE
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
TO BE CONSIDERED IN THE LIGHT OF THEIR POTENTIAL
or ISO’s member body in the country of the requester.
TO BECOME STAN DARDS TO WHICH REFERENCE MAY BE
MADE IN NATIONAL REGULATIONS.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland Reference number
ISO/FDIS 20038:2026(en) © ISO 2026

ii
ISO/FDIS 20038:2026(en)
Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms, definitions and abbreviated terms . 2
3.1 Terms and definitions .2
3.2 Abbreviated terms .6
4 Notation . 8
5 Key block elements . 8
6 Key block format . 9
6.1 General .9
6.2 Key block header (KBH) .10
6.2.1 General .10
6.2.2 Changing key headers . 13
6.3 Defined values for key block headers .14
6.3.1 Key usage .14
6.3.2 Algorithm .19
6.3.3 Mode of use . 20
6.3.4 Key version number .21
6.3.5 Exportability .21
6.3.6 Optional block ID . 22
6.4 Encoding .47
6.4.1 General .47
6.4.2 RSA key pairs . 48
6.4.3 Elliptic curve cryptography (ECC) key pairs . 49
7 Key block binding and validation methods .49
7.1 General . 49
7.2 Key block binding method using key derivation . 50
7.2.1 Key block binding and encryption . 50
7.2.2 Key derivation . . .51
7.2.3 Key derivation binding validation method —AES . 54
8 Examples .55
8.1 AES key block example . 55
8.1.1 General . 55
8.1.2 Constructing the key block header . 55
8.2 AES key block with optional blocks .61
8.2.1 General .61
8.2.2 Keys used in the example .61
8.2.3 Constructing the key block header .62
8.3 RSA key block example with CT optional block . 64
8.3.1 General . 64
8.3.2 Keys used in the example . 64
8.3.3 Constructing the key block header . 65
8.3.4 Constructing the binary key data .67
8.3.5 Constructing the complete key block . 68
8.4 ECC key block example with CT certificate chain optional block .70
8.4.1 General .70
8.4.2 Keys used in the example .70
8.4.3 Constructing the key block header .71
8.4.4 Constructing the binary key data . 73
8.4.5 Constructing the complete key block .74
8.5 CTR mode without padding . 75

iii
ISO/FDIS 20038:2026(en)
Annex A (informative) GBIC scheme for directed key diversification . 76
Annex B (informative) Operational challenges and examples with exportability .83
Bibliography .92

iv
ISO/FDIS 20038:2026(en)
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out through
ISO technical committees. Each member body interested in a subject for which a technical committee
has been established has the right to be represented on that committee. International organizations,
governmental and non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely
with the International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
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 ISO documents 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).
ISO draws attention to the possibility that the implementation of this document may involve the use of (a)
patent(s). ISO takes no position concerning the evidence, validity or applicability of any claimed patent
rights in respect thereof. As of the date of publication of this document, ISO had not received notice of (a)
patent(s) which may be required to implement this document. However, implementers are cautioned that
this may not represent the latest information, which may be obtained from the patent database available at
www.iso.org/patents. ISO shall not be held responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO's adherence to the World Trade
Organization (WTO) principles in the Technical Barriers to Trade (TBT), see www.iso.org/iso/foreword.html.
This document was prepared by Technical Committee ISO/TC 68, Financial services, Subcommittee SC 2,
Financial services, security.
This second edition cancels and replaces the first edition (ISO 20038:2017), which has been technically
revised.
The main changes are as follows:
— updated for compatibility with ANSI X9.143-2022.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.

v
ISO/FDIS 20038:2026(en)
Introduction
The secure management of cryptographic keys requires that their values and usage constraints be protected
for both confidentiality and integrity.
This document provides a method of wrapping cryptographic keys in order to provide confidentiality and
integrity protection for the keys when being transmitted or stored. The mechanism is designed to use
advanced encryption standard (AES) specified in FIPS 197 as the wrapping cipher.

vi
FINAL DRAFT International Standard ISO/FDIS 20038:2026(en)
Banking and related financial services — Key wrap using
advanced encryption standard (AES)
1 Scope
This document defines a method for packaging cryptographic keys for transport. This method can also be
used for the storage of keys under an advanced encryption standard (AES) key. The method uses the block
cipher AES as the wrapping cipher algorithm.
Other methods for wrapping keys are outside the scope of this document but can use the authenticated
encryption algorithms specified in ISO/IEC 19772.
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 8601-1, Date and time — Representations for information interchange — Part 1: Basic rules
ISO 9564-5, Financial services — Personal identification number (PIN) management and security —Part 5:
Methods for the generation, change, and verification of PIN
ISO 11568, Financial services — Key management (retail)
ANSI X9.24-1-2017, Retail Financial Services Symmetric Key Management Part 1: Using Symmetric Techniques
ANSI X9.24-2-2021, Retail Financial Services Symmetric Key Management - Part 2: Using Asymmetric Techniques
for the Distribution of Symmetric Keys
ANSI X9.24-3-2017, Retail Financial Services Symmetric Key Management Part 3: Derived Unique Key Per
Transaction
ANSI X9.102-2020, Symmetric Key Cryptography For the Financial Services Industry – Wrapping of Keys and
Associated Data
ANSI X9.132-xxx, Issuer PIN Generation, Verification, and Storage Methodologies Using AES
ANSI X9.143-2022, Retail Financial Services Interoperable Secure Key Block Specification
ANSI X9.139, Retail Financial Services Interoperable Secure Key Block using Asymmetric Techniques
ANS X9 TR-31, Interoperable Secure Key Exchange Key Block Specification for Symmetric Algorithms
ANS X9 TR-34, Interoperable Method for Distribution of Symmetric Keys using Asymmetric Techniques: Part 1 –
Using Factoring-Based Public Key Cryptography Unilateral Key Transport
IETF RFC 4648, The Base16, Base32, and Base64 Data Encodings, October 2006
NIST SP 800-57, Recommendation for Key Management: Part 1 – General
NIST SP 800-108, Recommendation for Key Derivation Using Pseudorandom Functions
PKCS #1 v2.1:2023, RSA Cryptography Standard

ISO/FDIS 20038:2026(en)
3 Terms, definitions and abbreviated terms
3.1 Terms and definitions
For the purposes of this document, the following terms, definitions and abbreviated terms apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
3.1.1
active
attribute setting for a directed key (3.1.9) that allows starting a cryptographic interaction
EXAMPLE MAC generate, cipher encrypt, PIN encryption, key encryption (key export).
3.1.2
advanced encryption standard
AES
16-byte block cipher
Note 1 to entry: This is defined in ISO/IEC 18033-3.
[SOURCE: ISO 11568:2023, 3.2]
3.1.3
ASCII
American Standard Code for Information Interchange
binary encoding of 7-bit characters defined by ISO/IEC 646
[SOURCE: ISO/IEC 18477-4:2017, 3.1.2, modified — The term “American Standard Code for Information
Interchange”, has been added as an admitted term.]
3.1.4
authentication value
cryptographically generated value message authentication code (3.1.29) derived from the key block header
and confidential data that can be used to validate the integrity of the data contained in the key block
3.1.5
CBC
cipher block chaining
confidentiality mode whose encryption process features the combining (i.e. “chaining”) of the plaintext
blocks with the previous ciphertext blocks
[SOURCE: NIST SP 800-38A:2001]
3.1.6
cryptographic domain
set of one or more secure cryptographic devices (SCDs) (3.1.32) that contain or can use the same set of keys
Note 1 to entry: All SCDs (3.1.32) in the domain are considered to be “equivalent” in that a key that can be used in one
SCD (3.1.32) in the domain is also available for use by any other SCD (3.1.32) in the domain.
Note 2 to entry: A cryptographic domain is often defined for host processing to provide load balancing of hardware
security modules (HSMs).
Note 3 to entry: The keys are typically structured in a hierarchy where higher-level keys are used to provide protection
for lower-level keys.
ISO/FDIS 20038:2026(en)
3.1.7
CTR
counter mode of encryption
confidentiality mode that features the application of the forward cipher to a set of input blocks, called
counters, to produce a sequence of output blocks that are exclusive-ORed with the plaintext to produce the
ciphertext, and vice versa
[SOURCE: NIST SP 800-38A:2001, modified — The admitted term “counter mode” has been changed to
“counter mode of encryption”.]
3.1.8
DEA
data encryption algorithm
cryptographic algorithm, previously specified in FIPS 46 which became effective July 1977, now withdrawn.
[SOURCE: NIST SP 800-67 Rev. 2]
3.1.9
directed key
key K in a cryptographically bilateral protocol between two parties A and B for direction A to B, if and only
if, there exist keys K , with key value of K and key attributes for active (3.1.1) on the cryptographic system
A
of an entity A and K , with key value of K and the corresponding key attribute for passive (3.1.29) on the
B
cryptographic system of an entity B
3.1.10
diversification data
derivation data for key diversification (3.1.20), containing information on the key attributes to be assigned to
the derived key by the HSM
3.1.11
diversification scheme
cryptographic scheme implemented in an HSM that specifies how diversification data (3.1.10) is processed
during key diversification (3.1.20), ensuring that different key attributes lead to cryptographically
independent key values
3.1.12
diversification scheme for directed keys
diversification scheme (3.1.11) to obtain directed keys (3.1.9) for a cryptographically bilateral protocol
between two parties identified as A and B, based on a common key diversification key (KDK) (3.1.21), which
differs for the parties in the party identifier key attribute and on a tag in the diversification data (3.1.10),
indicating the direction of the directed key (3.1.9) that determines whether the key derived from KDK party
identifier type A has the active (3.1.1) role and the key derived from KDK party identifier type B has the
passive (3.1.29) role or vice versa
3.1.13
hex-ASCII
number in base 16 expressed as American Standard Code for Information Interchange (ASCII) (3.1.3)
characters
EXAMPLE The 32-bit message authentication code (3.1.28) result 0x12345678 (4 binary bytes) is encoded as eight
hex-ASCII characters that reads “12345678” but is stored or transmitted as 0x3132333435363738.
3.1.14
initialization vector
IV
binary value used as a starting point for the encryption of a data sequence to increase security by introducing
additional cryptographic variance and to synchronize cryptographic equipment

ISO/FDIS 20038:2026(en)
3.1.15
key block
result of performing a cryptographic process over a key and its associated data to produce a key block
header, ciphertext and authentication value (3.1.4) – the message authentication code (3.1.28)
[SOURCE: ANSI X9.143:2022, 3.15]
3.1.16
key block encryption key
KBEK
key that is derived from the key block protection key (3.1.18) and that is used solely for enciphering the key
block (3.1.15)
[SOURCE: ANSI X9.143:2022, 3.16]
3.1.17
key block authentication key
KBAK
key that is derived from the key block protection key (3.1.18) and that is used solely for calculating the
message authentication code (3.1.28) over the key block (3.1.15)
[SOURCE: ANSI X9.143:2022, 3.17]
3.1.18
key block protection key
KBPK
key wrapping key (KWK) (3.1.26) that is used as a derivation key from which the key block encryption key
(3.1.16) and the key block authentication key (3.1.17) are derived
Note 1 to entry: This key is used for no other purpose.
[SOURCE: ANSI X9.143:2022, 3.18]
3.1.19
key derivation function
KDF
function to derive a key from a key generation key (KGK) using a pseudorandom function (3.1.31) with the
KGK as seed and derivation or diversification data as input
3.1.20
key diversification
key derivation function (3.1.19) using diversification data (3.1.10) in a diversification scheme (3.1.11)
3.1.21
key diversification key
KDK
key used in a hardware security module (HSM) function implementing a diversification scheme for key
diversification (3.1.20)
3.1.22
key encrypting key
KEK
key used exclusively to encrypt and decrypt other keys
[SOURCE: ANSI X9.143:2022, 3.19]
3.1.23
key export
secure cryptographic device (SCD) (3.1.32) operation that

ISO/FDIS 20038:2026(en)
a) unwraps a key and its attributes from a storage key encrypting key (3.1.22) or the master file key (MFK)
(3.1.27) and re-encrypts that key under a key wrapping key (3.1.26) shared with another entity or
internal system; or
b) wraps a clear key and its attributes that is stored within an SCD (3.1.32) using a key wrapping key
(3.1.26) shared with another entity or internal system
[SOURCE: ANSI X9.143:2022, 3.20]
3.1.24
key import
secure cryptographic device (SCD) (3.1.32) operation that unwraps a key and its attributes using a key
wrapping key (3.1.26) shared with another entity or system and then stores the key and its attributes from
the key block within one or more related SCDs (3.1.32) or re-wraps the key and its attributes using a storage
key encrypting key (3.1.22) or the master file key (MFK) (3.1.27)
[SOURCE: ANSI X9.143:2022, 3.21]
3.1.25
key type vector
KTV
set of attributes formatted according to the diversification scheme (3.1.11) used in the diversification data
(3.1.10) for defining the attributes of a key derived from a key diversification key (KDK) (3.1.21)
3.1.26
key wrapping key
KWK
symmetric key that determines the wrapping (3.1.36) and unwrapping (3.1.35) functions of a symmetric key
authenticated encryption mechanism that is intended for the protection of cryptographic keys and other
specialized data
[SOURCE: ANSI X9.143:2022, 3.22]
3.1.27
master file key
MFK
key used to encrypt other keys for storage
Note 1 to entry: Storage can be internal to the secure cryptographic device (SCD) (3.1.32) housing the MFK or can
pertain to external storage (e.g. on a host system).
[SOURCE: ANSI X9.143:2022, 3.24]
3.1.28
message authentication code
MAC
cryptographic value, which is the result of passing a financial message through the message authentication
algorithm using a specific key
[SOURCE: ANSI X9.143:2022, 3.25]
3.1.29
passive
attribute setting for a directed key that allows only reacting on a cryptographic interaction
EXAMPLE MAC verify only, cipher decrypt, PIN verify, key decryption (key import)
3.1.30
PIN
personal identification number
numeric code used to authenticate an identity or to verify access authorization
[SOURCE: ISO/IEC 19790:2025, modified — added “or to verify access authorization” to the definition.]

ISO/FDIS 20038:2026(en)
3.1.31
pseudorandom function
PRF
function that can be used to generate output from a random seed and a data variable such that the output is
computationally indistinguishable from truly random output
Note 1 to entry: The PRF is specified in the NIST SP 800–108r1-upd1.
3.1.32
secure cryptographic device
SCD
device that provides physically and logically protected cryptographic services and storage (e.g. personal
identification number (PIN) (3.1.30) entry device or hardware security module (HSM)), and which can be
integrated into a larger system, such as an automated teller machine (ATM) or point of sale terminal
[SOURCE: ISO 13491-1:2024, 3.18, modified — the example “(e.g. PIN entry device or HSM)” has been merged
with the definition.]
3.1.33
subkey
cryptographic key that is used internally in a cryptographic algorithm, such as cipher-based message
authentication code (CMAC), and not chosen by or exposed to the user of the algorithm
3.1.34
TDEA
triple data encryption algorithm
symmetric algorithm
Note 1 to entry: The TDEA is specified in the ISO/IEC 18033 series.
[SOURCE: ISO 11568:2023, 3.87, modified — the term “triple data encryption algorithm” has been changed
to an admitted term, and the abbreviated term “TDEA” has been changed to the preferred term.]
3.1.35
unwrapping
function in a key wrap mechanism that either produces the key data from the ciphertext or indicates that
either the ciphertext or the associated data is invalid
[SOURCE: ANSI X9.143:2022, 3.32]
3.1.36
wrapping
function in a key wrap mechanism that produces the ciphertext from and creates a validity check for the key
and associated data
[SOURCE: ANSI X9.143:2022, 3.33]
3.2 Abbreviated terms
AAC application authentication cryptogram
ARQC authorization request cryptogram
BDK base derivation key
CMAC cipher-based message authentication code
DAC data authentication code
DD derivation data
ISO/FDIS 20038:2026(en)
DER distinguished encoding rules
ECC elliptic curve cryptography
ECDSA elliptic curve digital signature algorithm
ECIES elliptic curve integrated encryption scheme
EMV Europay, Mastercard, Visa
GBIC German banking industry committee
HMAC keyed-hash message authentication code
HSM hardware security module
ID identifier
IKID initial key identifier
KBH key block header
KCV key check value
KDH key distribution host
KLD key loading device
KRD key receiving device
KEK key encryption key
KMS key management system
KSI key set identifier
KWK key wrapping key
MFK master file key
PAN personal account number
PED PIN encryption device
PVK PIN verification key
PVV PIN verification value
SHA secure hash algorithm
RD random data
RSA Rivest, Shamir and Adleman
TC transaction certificate
TLS transport layer security
ISO/FDIS 20038:2026(en)
4 Notation
The following are used to indicate field encoding in the key block:
a) nA: n-digits of alphabetic (“A” to “Z”, “a” to “z”), e.g. 6A means exactly six alphabetic characters in ASCII;
b) nAN: alphanumeric (“A” to “Z”, “a” to “z”, “0” to “9”), e.g. 6AN means exactly six alphanumeric characters
in ASCII;
c) nH: hex-ASCII (“0” to “9”, “A” to “F”), e.g. 6H means exactly six hex-ASCII characters;
d) nN: numeric-ASCII (“0”-”9”), e.g. 6N means exactly six decimal characters in ASCII;
e) nB: binary bytes (0x00 to 0xFF), e.g. 6B means exactly six bytes of binary data;
f) nPA: n printable ASCII characters. Printable ASCII characters are those with hexadecimal values in the
range 20 to 7E, inclusive. 6PA means exactly six printable ASCII characters;
g) ||: used for concatenation of bitstrings, v 30A4F || 0C1 is equal to 30A4F0C1;
h) ⊕: xor. Bit-wise, xor is defined as 0⊕0 = 0, 0⊕1 = 1, 1⊕0 = 1 and 1⊕1 = 0. ⊕ applied to longer strings is
performed bitwise, e.g. 0x3FC4 ⊕ 0xED27 = 0xD2E3;
i) < < : left-shift. If M is a bit string, then M < < 1 means M shifted one bit to the left, e.g. the bit string
0101010 < < 1 is 1010100 and 1010100 < < 1 is 0101000. The length of M < < 1 is the same as the length
of M. Left-shift can also be described as multiplying by 2, without carry;
j) 0x: notation indicating a hexadecimal number follows, e.g. 0x31 indicates 31-hexadecimal (49-decimal).
5 Key block elements
The key block shall contain three parts:
a) the key block header (KBH), which contains non-sensitive attribute information about the key and the
key block;
b) the confidential data that is being exchanged or stored (i.e. the key and attributes formatted according
to the key data format);
c) the authentication value, which consists of a MAC that binds the key block header and confidential data.
This general format of a key block is illustrated in Figure 1.
Figure 1 — Key block
For TDEA and AES keys, the confidential data should be padded to the maximum key length to hide its true
length (key length obfuscation padding) from an external observer. When the confidential data are padded
for key length obfuscation:
— TDEA keys less than 192 bits shall be padded to 192 bits.

ISO/FDIS 20038:2026(en)
— AES keys less than 256 bits shall be padded to 256 bits.
The key length obfuscation padding is determined by the size of the key being wrapped, but the block
padding is determined by the algorithm being used to encrypt the confidential data. Because of the existence
of the key length field in the information that is encrypted, additional padding is required to make the block
consistent with the size of block the algorithm requires. For example, AES operates on 128 bits, so if the key
is padded out to 256 bits, additional block padding characters are required because of the key length field.
For operational and compliance reasons (e.g. regulatory, contractual, industry and ecosystem standard), an
entity may have SCD mechanisms to:
a) verify key length against the policies of an organization and the requirements of industry;
b) obtain key length information of stored keys.
Such SCD mechanisms should be managed with SCD administrative controls requiring dual-control
execution.
6 Key block format
6.1 General
This clause defines a secure key block that uses the methods described in Clause 7.
Key blocks constructed according to this document shall conform to the relevant key wrapping requirements
in ANSI X9.102.
The key block is a variable-length structure with a maximum length of 9999 bytes. The key block is
composed of three sub-structures: a variable-length header, a variable-length confidential data field and an
authentication value. The header may include optional fields.
The key block shall consist of three parts:
a) The KBH, which contains attribute information about the key and the key block and is not encrypted;
1) The first section is 16 bytes with a fixed format defined in Table 1;
2) The second section is of variable length and optional.
b) The confidential data, which will be encrypted;
1) two bytes, indicating the key length (in bits) and excluding padding;
2) the secret key and any confidential attributes;
3) random padding to obfuscate the key length, if required;
4) random cipher-block padding, if required.
c) The authentication value. The length of the authentication value shall be as follows:
1) 128 bits, because the AES key derivation method is used (see 7.2.2).
TDEA and AES symmetric keys should be padded with random key length obfuscation padding to the
maximum length for the algorithm, 192 bits for TDEA or 256 bits for AES. Other key types are not padded for
key length obfuscation but are padded up to the cipher block of the wrapping method (e.g. HMAC, RSA and
ECC keys). This format is illustrated in Figure 2.

ISO/FDIS 20038:2026(en)
Figure 2 — Key Block
6.2 Key block header (KBH)
6.2.1 General
The header shall contain attribute information about the key as defined in Table 1. The specific encoding and
acceptable characters are defined individually for each field, e.g. in the “Encoding” column of Table 1. When
the term “numeric” is used to describe an ASCII header byte, it means an ASCII character in the range “0” to
“9” (0x31 to 0x39). A multi-byte header field is considered numeric only when all bytes of the field contain
numeric values.
Table 1 shows the format of the KBH. See 6.3 for defined key attributes.
Table 1 — Key block header
Byte # Field name Description Encoding Encrypted
This field identifies the version of the key block, which
defines the method by which it is cryptographically pro-
tected, as well as the layout of the block:
“D” (0x44): Key block protected using the AES key
derivation binding method for CBC mode (see
subclause 7.2).
“E” (0x45): Key block protected using the AES key
derivation binding method for CTR mode (see
Key block version
subclause 7.2).
0 1AN No
ID (identifier)
Numeric key block version IDs are reserved for propri-
etary key block definitions. Multiple key block versions
may be in use at any time.
The key block version ID should not be used as a proxy for
determining which optional block elements are support-
ed. Applications should predetermine which optional
block elements are supported.
The values “A”, “B” and “C” are not covered in this docu-
ment.
ASCII numeric digits providing key block length after
encoding. Length includes the entire block (header +
1–4 Key block length encrypted confidential data + MAC) in decimal, e.g. a 112- 4N No
byte key block contains “0” (0x30) in byte #0; “1” (0x31) in
byte #1; “1” (0x31) in byte #2; and “2” (0x32) in byte #3.

ISO/FDIS 20038:2026(en)
TTaabblle 1 e 1 ((ccoonnttiinnueuedd))
Byte # Field name Description Encoding Encrypted
This field provides information about the intended
function of the protected key or sensitive data. Common
functions include encrypting data, encrypting PINs and
5–6 Key usage 2AN No
calculating a MAC.
See Table 2 for defined values.
The approved algorithm for which the protected key may
be used.
7 Algorithm 1AN No
See Table 3 for defined values.
This field defines the operation the protected key can per-
form. For key blocks being transmitted, the mode of use
is in the context of the recipient SCD. For key blocks being
stored, the mode of use is in the context of the SCD using
8 Mode of use 1AN No
the key. For example, an authentication key can be limited
to verify-only.
See Table 4 for defined values.
Two-digit ASCII character version number, optionally used
to indicate that the content of the key block is a compo-
Key version
9–10 2AN No
nent, or to prevent re-injection of old keys.
number
See Table 5 for defined values.
This field defines whether the protected key may be
transferred outside the cryptographic domain in which
11 Exportability 1AN No
the key is found.
See Table 6 for defined values.
This field defines the number of optional blocks included
in the key block. The minimum value is zero and the max-
Number of op- imum is 99, but it is also limited by the maximum number
12–13 2N No
tional blocks of bytes in the entire key block. For example, five optional
blocks can be represented by “0” (0x30) in byte 12 and “5”
(0x35) in byte 13.
This field indicates whether the key block is in a key
exchange context (wrapped by a transport key) or in a
storage context (e.g. wrapped by the MFK).
The values are:
“0” (0x30): Either storage or key exchange context. This
allows interoperability with legacy key blocks. This
does not imply that the wrapping key for a key block
Key context can be used for both storage and key exchange, merely
14 – storage or that the storage or exchange of this key block is 1N No
exchange determined by the properties of the wrapping key.
“1” (0x31): Storage context only. The key block is not
wrapped by a transport key for exchange between a
communicating pair.
“2” (0x32): Key exchange context only. The key block is
wrapped by a transport key for exchange between a
communicating pair.
Reserved for This field is reserved for future use and is filled with
15 1N No
future use ASCII zero (0x30) characters.
Fields after byte 15 are only present if bytes 12–13 contain a value other than “00” (0x3030).
ID field for the first optional block, if one is present as in-
First optional
16–17 dicated by a value other than “00” in bytes 12 and 13. The 2AN No
block ID
possible ID values are defined in 6.3.6.

ISO/FDIS 20038:2026(en)
TTaabblle 1 e 1 ((ccoonnttiinnueuedd))
Byte # Field name Description Encoding Encrypted
If the first optional block is present, indicated by a value
other than “00” in bytes 12 and 13, then this field contains
the length of that optional block in bytes, including the
field’s ID, length and data. Byte 18 contains the high-or-
der byte of the length and byte 19 contains the low-order
byte, both in hex-ASCII form. For example, for a 24-byte
optional block (0x18 in hexadecimal notation), byte 18
Optional block 1
18–19 2H No
contains a “1” (0x31) and byte 19 contains an “8” (0x38).
length
Optional block data can be omitted, in which case the
optional block length is “04”.
If the length of the optional block exceeds 255, this field
is set to “00” and the actual length is encoded in the next
two fields. The actual length is limited by the maximum
number of bytes in the key block length.
This field contains the length of the field named “Extend-
ed optional block 1 length”. Valid values are “01” – “FF”.
Optional block 1
For this document this value is always “04”.
20–21 2H No
length of length
This field is only present if the optional block 1 length is
“00”.
The actual length of the block, expressed as a hexadecimal
number. For example, if the optional block length is 400
Extended option-
bytes (190 ), this field is “0190”.
22–25 4H No
al block 1 length
This field is only present if the optional block 1 length is
“00”.
If the first optional block is present, indicated by a value
Optional block 1 other than “00” in bytes 12–13, then this field contains
n…m PA No
data the data for that optional block. It contains only printable
ASCII characters.
A variable number of optional blocks can follow the first
Additional op- optional block, as indicated by the count in bytes 12–13.
m+1…p tional blocks, if Each optional block contains a 2-byte ID, 2-byte length No
present and variable-length data field following the same format
described for optional block 1.
Before a key in the key block format is used in a SCD, the contents of the header block shall be validated to
ensure the correct usage is enforced. First, the SCD makes sure that the length of the key block matches the
contents of bytes 1 to 4. If the lengths do not match, the SCD returns an error and stops processing the block.
The “key usage” byte is typically checked next followed by the “algorithm” byte. The processing of the other
header bytes depends on the key usage and the algorithm used.
From 0 to 99, optional blocks can be included in the key block. The total length of the key block shall not
exceed the maximum length that can be represented by the key block length field in bytes 1-4. The total
number of optional blocks is indicated by a count in bytes 12-13. Each optional block consists of three
fields: a 2-byte identifier that indicates the content of the optional block; a 2-byte length that indicates the
total number of bytes in all of the optional block’s fields – possibly extended to a variable length field if the
optional block length of length fields are used; and the variable-length data carried in the optional block. See
Table 7 for a list of valid identifiers.
For example, consider an optional block that contains a key set identifier. A sample block can contain the
following data:
— Identifier: “KS”
— Length: “18”
— Data: “00604B120F9292800000”

ISO/FDIS 20038:2026(en)
NOTE The length value equals 2+2+20 (24). The length value is encoded in Hex-ASCII; 18 hexadecimal equals 24
decimal.
If more than one optional block is present, each one shall immediately
...

ISO/FDIS 20038
ISO/TC 68/SC 2
Secretariat: BSI
Date: 2026-02-12
Banking and related financial services — Key wrap using
advanced encryption standard (AES)
Banque et autres services financiers — Enveloppe de clé utilisant AES

FDIS stage
ISO/FDIS 20038.:2026(en)
All rights reserved. Unless otherwise specified, or required in the context of its implementation, 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
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: + 41 22 749 01 11
E-mail: [e-mail]
Website: www.iso.org
Published in Switzerland
iii
ISO/FDIS 20038:2026(en)
Contents
Foreword . v
Introduction . vi
1 Scope . 1
2 Normative references . 1
3 Terms, definitions and abbreviated terms . 2
3.1 Terms and definitions . 2
3.2 Abbreviated terms . 7
4 Notation . 8
5 Key block elements . 8
6 Key block format . 9
6.1 General . 9
6.2 Key block header (KBH) . 10
6.3 Defined values for key block headers . 15
6.4 Encoding . 53
7 Key block binding and validation methods . 55
7.1 General . 55
7.2 Key block binding method using key derivation . 56
8 Examples . 63
8.1 AES key block example . 63
8.2 AES key block with optional blocks . 73
8.3 RSA key block example with CT optional block . 77
8.4 ECC key block example with CT certificate chain optional block . 84
8.5 CTR mode without padding . 89
Annex A (informative) GBIC scheme for directed key diversification. 91
Annex B (informative) Operational challenges and examples with exportability . 99
Bibliography . 112

iv
ISO/FDIS 20038.:2026(en)
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out through
ISO technical committees. Each member body interested in a subject for which a technical committee has been
established has the right to be represented on that committee. International organizations, governmental and
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
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
ISO documents 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).
ISO draws attention to the possibility that the implementation of this document may involve the use of (a)
patent(s). ISO takes no position concerning the evidence, validity or applicability of any claimed patent rights
in respect thereof. As of the date of publication of this document, ISO had not received notice of (a) patent(s)
which may be required to implement this document. However, implementers are cautioned that this may not
represent the latest information, which may be obtained from the patent database available at
www.iso.org/patents. ISO shall not be held responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO's adherence to the World Trade
Organization (WTO) principles in the Technical Barriers to Trade (TBT), see www.iso.org/iso/foreword.html.
This document was prepared by Technical Committee ISO/TC 68, Financial services, Subcommittee SC 2,
Financial services, security.
This second edition cancels and replaces the first edition (ISO 20038:2017), which has been technically
revised.
The main changes are as follows:
— updated for compatibility with ANSI X9.143-2022.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.
v
ISO/FDIS 20038:2026(en)
Introduction
The secure management of cryptographic keys requires that their values and usage constraints be protected
for both confidentiality and integrity.
This document provides a method of wrapping cryptographic keys in order to provide confidentiality and
integrity protection for the keys when being transmitted or stored. The mechanism is designed to use
advanced encryption standard (AES) specified in FIPS 197 as the wrapping cipher.
vi
Banking and related financial services — Key wrap using advanced
encryption standard (AES)
1 Scope
This document defines a method for packaging cryptographic keys for transport. This method can also be used
for the storage of keys under an advanced encryption standard (AES) key. The method uses the block cipher
AES as the wrapping cipher algorithm.
Other methods for wrapping keys are outside the scope of this document but can use the authenticated
encryption algorithms specified in ISO/IEC 19772.
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 8601-1, Date and time — Representations for information interchange — Part 1: Basic rules
ISO 9564-5, Financial services — Personal identification number (PIN) management and security —Part 5:
Methods for the generation, change, and verification of PIN
ISO 11568, Financial services — Key management (retail)
ANSI X9.24-all parts1-2017, Retail Financial Services Symmetric Key Management Part 1: Using Symmetric
Techniques
ANSI X9.24-2-2021, Retail Financial Services Symmetric Key Management - Part 2: Using Asymmetric
Techniques for the Distribution of Symmetric Keys
ANSI X9.24-3-2017, Retail Financial Services Symmetric Key Management Part 3: Derived Unique Key Per
Transaction
ANSI X9.102-2020, Symmetric Key Cryptography For the Financial Services Industry – Wrapping of Keys and
Associated Data
ANSI ANSI X9.132-xxx, Issuer PIN Generation, Verification, and Storage Methodologies Using AES
ANSI X9.143-2022, Retail Financial Services Interoperable Secure Key Block Specification
ANSI X9.139, Retail Financial Services Interoperable Secure Key Block using Asymmetric Techniques
ANS X9 TR-31, Interoperable Secure Key Exchange Key Block Specification for Symmetric Algorithms
ANS X9 TR-34, Interoperable Method for Distribution of Symmetric Keys using Asymmetric Techniques: Part 1 –
Using Factoring-Based Public Key Cryptography Unilateral Key Transport
IETF RFC 4648, The Base16, Base32, and Base64 Data Encodings, October 2006
NIST SP 800-57, Recommendation for Key Management: Part 1 – General
NIST SP 800-108, Recommendation for Key Derivation Using Pseudorandom Functions

ISO/FDIS 20038:2026(en)
PKCS #1 v2.1:2023, RSA Cryptography Standard
3 Terms, definitions and abbreviated terms
3.1 Terms and definitions
For the purposes of this document, the following terms, definitions and abbreviationsabbreviated terms apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https://www.iso.org/obp
— IEC Electropedia: available at https://www.electropedia.org/
3.1.1
active
attribute setting for a directed key (3.1.9) that allows starting a cryptographic interaction
EXAMPLES EXAMPLE MAC generate, cipher encrypt, PIN encryption, key encryption (key export)).
3.1.2
advanced encryption standard
AES
16-byte block cipher
Note 1 to entry: This is defined in ISO/IEC 18033-3.
[SOURCE: ISO 11568:2023, 3.2]
3.1.3
ASCII
American Standard Code for Information Interchange
binary encoding of 7-bit characters defined by ISO/IEC 646
[SOURCE: ISO/IEC 18477-4:2017(en),, 3.1.2], modified — The term “American Standard Code for Information
Interchange”, has been added as an admitted term.]
3.1.4
authentication value
cryptographically generated value [message authentication code (3.1.29)](3.1.29) derived from the key block
header and confidential data that can be used to validate the integrity of the data contained in the key block
3.1.5
CBC
cipher block chaining
confidentiality mode whose encryption process features the combining (“(i.e. “chaining”) of the plaintext
blocks with the previous ciphertext blocks
[SOURCE: NIST SP800 SP 800-38A:2001]
3.1.6
cryptographic domain
set of one or more secure cryptographic devices (3.1.33)SCDs) (3.1.32) that contain or are able tocan use the
same set of keys
ISO/FDIS 20038:2026(en)
Note 1 to entry: All secure cryptographic devicesSCDs (3.1.32) in the domain are considered to be “equivalent” in that a
key that can be used in one secure cryptographic deviceSCD (3.1.32) in the domain is also available for use by any other
secure cryptographic deviceSCD (3.1.32) in the domain.
Note 2 to entry: A cryptographic domain is often defined for host processing to provide load balancing of hardware
security modules (HSMs.).
Note 3 to entry: The keys are typically structured in a hierarchy where higher-level keys are used to provide protection
for lower-level keys.
3.1.7
CTR
counter mode of encryption
confidentiality mode that features the application of the forward cipher to a set of input blocks, called counters,
to produce a sequence of output blocks that are exclusive-ORed with the plaintext to produce the ciphertext,
and vice versa
[SOURCE: NIST SP800 SP 800-38A:2001], modified — The admitted term “counter mode” has been changed
to “counter mode of encryption”.]
3.1.8
DEA
data encryption algorithm
cryptographic algorithm originally, previously specified in FIPS 46 which became effective July 1977, now
withdrawn.
[SOURCE: NIST SP 800-67 Rev. 2]
3.1.9
directed key
key K in a cryptographically bilateral protocol between two parties A and B for direction A to B, if and only if,
there exist keys KA, with key value of K and key attributes for active (3.1.1) on the cryptographic system of an
entity A and K , with key value of K and the accordingcorresponding key attribute for passive (3.1.29) on the
B
cryptographic system of an entity B
3.1.10
diversification data
derivation data for key diversification (3.1.20), containing information on the key attributes to be assigned to
the derived key by the HSM
3.1.11
diversification scheme
cryptographic scheme implemented in an HSM that specifies how diversification data (3.1.10) is processed
during key diversification (3.1.20), ensuring that different key attributes lead to cryptographically independent
key values
3.1.12
diversification scheme for directed keys
diversification scheme (3.1.11) to obtain directed keys (3.1.9) for a cryptographically bilateral protocol between
two parties identified as A and B, based on a common key diversification key (KDK) (3.1.21), which differs for
the parties in the party identifier key attribute and on a tag in the diversification data (3.1.10), indicating the
direction of the directed key (3.1.9) that determines whether the key derived from key diversification key KDK
party identifier type A has the active (3.1.1) role and the key derived from key diversification keyKDK party
identifier type B has the passive (3.1.29) role or vice versa
ISO/FDIS 20038:2026(en)
3.1.13
hex-ASCII
number in base 16 expressed as American Standard Code for Information Interchange (ASCII) (3.1.3)
characters
EXAMPLE The 32-bit message authentication code (3.1.28) result 0x12345678 (4 binary bytes) is encoded as eight
hex-ASCII characters that reads "“12345678"” but is stored or transmitted as 0x3132333435363738.
3.1.14
initialization vector
IV
binary value used as a starting point for the encryption of a data sequence in order to increase security by
introducing additional cryptographic variance and to synchronize cryptographic equipment
3.1.15
key block
result of performing a cryptographic process over a key and its associated data to produce a key block header,
ciphertext and authentication value (3.1.4) – the message authentication code (3.1.28)
[SOURCE: ANSI X9.143:2022, 3.15]
3.1.16
key block encryption key
KBEK
key that is derived from the key block protection key (3.1.18) and that is used solely for enciphering the key
block (3.1.15)
[SOURCE: ANSI X9.143:2022, 3.16]
3.1.17
key block authentication key
KBAK
key that is derived from the key block protection key (3.1.18) and that is used solely for calculating the message
authentication code (3.1.28) over the key block (3.1.15)
[SOURCE: ANSI X9.143:2022, 3.17]
3.1.18
key block protection key
KBPK
key wrapping key (KWK) (3.1.26) that is used as a derivation key from which the key block encryption key
(3.1.16) and the key block authentication key (3.1.17) are derived
Note 1 to entry: This key is used for no other purpose.
[SOURCE: ANSI X9.143:2022, 3.18]
3.1.19
key derivation function
KDF
function to derive a Keykey from a Key Generation Keykey generation key (KGK) using a pseudorandom
function (3.1.31) with the KGK as seed and derivation or diversification data as input.
3.1.20
key diversification
key derivation function (3.1.19) using diversification data (3.1.10) in a diversification scheme (3.1.11)
ISO/FDIS 20038:2026(en)
3.1.21
key diversification key
KDK
key used in an a hardware security module (HSM) function implementing a diversification scheme for key
diversification (3.1.20)
3.1.22
key encrypting key
KEK
key used exclusively to encrypt and decrypt other keys
[SOURCE: ANSI X9.143:2022, 3.19]
3.1.23
key export
secure cryptographic device (3.1.26)SCD) (3.1.32) operation that
a) a) unwraps a key and its attributes from a storage key encrypting key (3.1.16)(3.1.22) or the master file
key (3.1.22)MFK) (3.1.27) and re-encrypts that key under a key wrapping key (3.1.20)(3.1.26) shared with
another entity or internal system; or
b) b) wraps a clear key and its attributes that is stored within a secure cryptographic device (3.1.26)an SCD
(3.1.32) using a key wrapping key (3.1.20)(3.1.26) shared with another entity or internal system
[SOURCE: ANSI X9.143:2022, 3.20]
3.1.24
key import
secure cryptographic device (3.1.26)SCD) (3.1.32) operation that unwraps a key and its attributes using a key
wrapping key (3.1.20)(3.1.26) shared with another entity or system and then stores the key and its attributes
from the key block within one or more related secure cryptographic devices (3.1.26)SCDs (3.1.32) or re-wraps
the key and its attributes using a storage key encrypting key (3.1.16)(3.1.22) or the master file key (3.1.22)MFK)
(3.1.27)
[SOURCE: ANSI X9.143:2022, 3.21]
3.1.25
key type vector
KTV
set of attributes formatted according to the diversification scheme (3.1.11)(3.1.11) used in the diversification
data (3.1.10)(3.1.10) for defining the attributes of a key derived from a key diversification key (3.1.21)KDK)
(3.1.21)
3.1.26
key wrapping key
KWK
symmetric key that determines the wrapping (3.1.30)(3.1.36) and unwrapping (3.1.29)(3.1.35) functions of a
symmetric key authenticated encryption mechanism that is intended for the protection of cryptographic keys
and other specialized data
[SOURCE: ANSI X9.143:2022, 3.22]
3.1.27
master file key
MFK
key used to encrypt other keys for storage
ISO/FDIS 20038:2026(en)
Note 1 to entry: Storage maycan be internal to the secure cryptographic device (3.1.26)SCD) (3.1.32) housing the
MFKmaster file key or maycan pertain to external storage (e.g. on a host system).
[SOURCE: ANSI X9.143:2022, 3.24]
3.1.28
message authentication code
MAC
cryptographic value, which is the result of passing a financial message through the message authentication
algorithm using a specific key
[SOURCE: ANSI X9.143:2022, 3.25]
3.1.29
passive
attribute setting for a directed key that allows only reacting on a cryptographic interaction
EXAMPLE MAC verify only, cipher decrypt, PIN verify, key decryption (key import)
3.1.30 3.1.30
PIN
personal identification number
numeric code used to authenticate an identity or to verify access authorization
[SOURCE: ISO/IEC 19790:2012]2025, modified — added “or to verify access authorization” to the definition.]
3.1.31
pseudorandom function
PRF
function that can be used to generate output from a random seed and a data variable such that the output is
computationally indistinguishable from truly random output
Note 1 to entry: The PRF is specified in the NIST SP800- SP 800–108r1-upd1.
3.1.32
secure cryptographic device
SCD
device that provides physically and logically protected cryptographic services and storage (e.g. personal
identification number (PIN (3.1.24)) (3.1.30) entry device or hardware security module), (HSM)), and which
can be integrated into a larger system, such as an automated teller machine (ATM) or point of sale terminal
[SOURCE: ISO 13491-1:20162024, 3.28]18, modified — the example “(e.g. PIN entry device or HSM)” has been
merged with the definition.]
3.1.33
subkey
cryptographic key that is used internally in a cryptographic algorithm, such as cipher-based message
authentication code (CMAC,), and not chosen by or exposed to the user of the algorithm
3.1.34
TDEA
triple data encryption algorithm
symmetric algorithm
Note 1 to entry: The TDEA is specified in the ISO/IEC 18033 series.
[SOURCE: ISO 11568:2023, 3.87]
ISO/FDIS 20038:2026(en)
3.1.35[SOURCE: ISO 11568:2023, 3.87, modified — the term “triple data encryption algorithm” has been
changed to an admitted term, and the abbreviated term “TDEA” has been changed to the preferred term.]
3.1.35
unwrapping
function in a key wrap mechanism that either produces the key data from the ciphertext or indicates that
either the ciphertext or the associated data is invalid
[SOURCE: ANSI X9.143:2022, 3.32]
3.1.36
wrapping
function in a key wrap mechanism that produces the ciphertext from and creates a validity check for the key
and associated data
[SOURCE: ANSI X9.143:2022, 3.33]
3.2 Abbreviated terms
AAC application authentication cryptogram
ARQC authorization request cryptogram
BDK base derivation key
CMAC cipher-based message authentication code
DAC data authentication code
DD derivation data
DER distinguished encoding rules
ECC elliptic curve cryptography
ECDSA elliptic curve digital signature algorithm
ECIES elliptic curve integrated encryption scheme
EMV Europay, Mastercard, Visa
GBIC German banking industry committee
HMAC keyed-hash message authentication code
HSM hardware security module
ID identifier
IKID initial key identifier
KBH key block header
KCV key check value
KDH key distribution host
KLD key loading device
KRD key receiving device
KEK key encryption key
KMS key management system
KSI key set identifier
ISO/FDIS 20038:2026(en)
KWK key wrapping key
MFK master file key
PAN personal account number
PED PIN encryption device
PVK PIN verification key
PVV PIN verification value
SHA secure hash algorithm
RD random data
RSA Rivest, Shamir and Adleman
TC transaction certificate
TLS transport layer security
4 Notation
The following are used to indicate field encoding in the key block:
a) nA: n-digits of alphabetic (“A” to “Z”, “a” to “z”), e.g. 6A means exactly six alphabetic characters in ASCII;
b) nAN: alphanumeric (“A” to “Z”, “a” to “z”, “0” to “9”), e.g. 6AN means exactly six alphanumeric characters
in ASCII;
c) nH: hex-ASCII (“0” to “9”, “A” to “F”), e.g. 6H means exactly six hex-ASCII characters;
d) nN: numeric-ASCII (“0”-”9”), e.g. 6N means exactly six decimal characters in ASCII;
e) nB: binary bytes (0x00 to 0xFF), e.g. 6B means exactly six bytes of binary data;
f) nPA: n printable ASCII characters. Printable ASCII characters are those with hexadecimal values in the
range 20 to 7E, inclusive. 6PA means exactly six printable ASCII characters;
g) ||: used for concatenation of bitstrings, v 30A4F || 0C1 is equal to 30A4F0C1;
h) ⊕: xor. Bit-wise, xor is defined as 0⊕0= = 0, 0⊕1= = 1, 1⊕0= = 1 and 1⊕1= = 0. ⊕ applied to longer
strings is performed bitwise, e.g. 0x3FC4 ⊕ 0xED27 = = 0xD2E3;
i) < < : left-shift. If M is a bit string, then M<< < < 1 means M shifted one bit to the left, e.g. the bit string
0101010<< < < 1 is 1010100 and 1010100<< < < 1 is 0101000. The length of M<< < < 1 is the same as
the length of M. Left-shift can also be described as multiplying by 2, without carry;
j) 0x: notation indicating a hexadecimal number follows, e.g. 0x31 indicates 31-hexadecimal (49-decimal).
5 Key block elements
The key block shall contain three parts:
a) the key block header (KBH)), which contains non-sensitive attribute information about the key and the
key block;
b) b) the confidential data that is being exchanged or stored (i.e. the key and attributes formatted
according to the key data format);
ISO/FDIS 20038:2026(en)
c) the authentication value, which consists of a MAC that binds the key block header and confidential data.
This general format of a key block is illustrated in Figure 1.Figure 1.

Figure 1 — Key block
For TDEA and AES keys, the confidential data should be padded to the maximum key length to hide its true
length (key length obfuscation padding) from an external observer. When the confidential data isare padded
for key length obfuscation:
— TDEA keys less than 192 bits shall be padded to 192 bits.
— AES keys less than 256 bits shall be padded to 256 bits.
The key length obfuscation padding is determined by the size of the key being wrapped, but the block padding
is determined by the algorithm being used to encrypt the confidential data. Because of the existence of the key
length field in the information that is encrypted, additional padding is required to make the block consistent
with the size of block the algorithm requires. For example, AES operates on 128 bits, so if the key is padded
out to 256 bits, additional block padding characters are required because of the key length field.
For operational and compliance reasons, (e.g. regulatory, contractual, industry and ecosystem standard), an
entity may have secure cryptographic device (SCD) mechanisms to:
a) verify key length, such as against an organization'sthe policies of an organization and industrythe
requirements of industry;
b) obtain key length information of stored keys.
Such SCD mechanisms should be managed with SCD administrative controls requiring dual-control execution.
6 Key block format
6.1 Introduction
6.1 General
This clause defines a secure key block that uses the methods described in Clause 7.
Key blocks constructed according to this document shall conform to the relevant key wrapping requirements
in ANSI X9.102.
The key block is a variable-length structure with a maximum length of 9999 bytes. The key block is composed
of three sub-structures: a variable-length header, a variable-length confidential data field and an
authentication value. The header may include optional fields.
ISO/FDIS 20038:2026(en)
The key block shall consist of three parts:
a) The KBH, which contains attribute information about the key and the key block and is not encrypted;
1) The first section is 16 bytes with a fixed format defined in Table 1;
2) The second section is of variable length and optional.
b) theThe confidential data, which will be encrypted;
1) two bytes, indicating the key length (in bits) and excluding padding;
2) the secret key and any confidential attributes;
3) random padding to obfuscate the key length, if required;
4) random cipher-block padding, if required.
c) The authentication value. The length of the authentication value shall be as follows:
1) 128 bits, because the AES key derivation method is used (see 7.2.2).
TDEA and AES symmetric keys should be padded with random key length obfuscation padding to the
maximum length for the algorithm, 192 bits for TDEA or 256 bits for AES. Other key types are not padded for
key length obfuscation but are padded up to the cipher block of the wrapping method (e.g. HMAC, RSA and
ECC keys). This format is illustrated in Figure 2.

Figure 2 — Key Block
6.2 Key block header (KBH)
6.2.1 General
The header shall contain attribute information about the key as defined in Table 1.Table 1. The specific
encoding and acceptable characters are defined individually for each field, e.g. in the “Encoding” column of
Table 1.Table 1. When the term “numeric” is used to describe an ASCII header byte, it means an ASCII character
in the range “0” to “9” (0x31 to 0x39). A multi-byte header field is considered numeric only when all bytes of
the field contain numeric values.
ISO/FDIS 20038:2026(en)
Table 1Table 1 shows the format of the KBH. See subclause 6.3 6.3 for defined key attributes.
Table 1 — Key block header
Byte # Field name Description Encoding Encrypted
This field identifies the version of the key block, which
defines the method by which it is cryptographically
protected, as well as the layout of the block:
— “D” (0x44): Key block protected using the AES key
derivation binding method for CBC mode (see
subclause 7.2).
— “E” (0x45): Key block protected using the AES key
derivation binding method for CTR mode (see
Key block
subclause 7.2).
0 version ID 1AN No
(identifier)
Numeric key block version IDs are reserved for
proprietary key block definitions. Multiple key block
versions may be in use at any time.
The key block version ID should not be used as a proxy
for determining which optional block elements are
supported. Applications should predetermine which
optional block elements are supported.
The values “A”, “B” and “C” are not covered in this
document.
ASCII numeric digits providing key block length after
encoding. Length includes the entire block (header +
Key block encrypted confidential data + MAC) in decimal, e.g. a 112-
1-–4 4N No
length byte key block contains “0” (0x30) in byte #0; “1” (0x31)
in byte #1; “1” (0x31) in byte #2; and “2” (0x32) in byte
#3.
This field provides information about the intended
function of the protected key or sensitive data. Common
functions include encrypting data, encrypting PINs and
5-–6 Key usage 2AN No
calculating a MAC.
See Table 2 for defined values.
The approved algorithm for which the protected key may
be used.
7 Algorithm 1AN No
See Table 3 for defined values.
This field defines the operation the protected key can
perform. For key blocks being transmitted, the mode of
use is in the context of the recipient SCD. For key blocks
being stored, the mode of use is in the context of the SCD
8 Mode of use 1AN No
using the key. For example, an authentication key can be
limited to verify-only.
See Table 4 for defined values.
Two-digit ASCII character version number, optionally
used to indicate that the content of the key block is a
Key version
9-–10 2AN No
component, or to prevent re-injection of old keys.
number
See Table 5 for defined values.
This field defines whether the protected key may be
11 Exportability transferred outside the cryptographic domain in which 1AN No
the key is found.
ISO/FDIS 20038:2026(en)
Byte # Field name Description Encoding Encrypted
See Table 6 for defined values.
This field defines the number of optional blocks included
in the key block. The minimum value is zero and the
12-– Number of maximum is 99, but it is also limited by the maximum
2N No
13 optional blocks number of bytes in the entire key block. For example, five
optional blocks can be represented by “0” (0x30) in byte
12 and “5” (0x35) in byte 13.
This field indicates whether the key block is in a key
exchange context (wrapped by a transport key) or in a
storage context (e.g. wrapped by the MFK).
The values are:
— “0” (0x30): Either storage or key exchange context.
This allows interoperability with legacy key blocks.
This does not imply that the wrapping key for a key
block can be used for both storage and key exchange,
Key context –
merely that the storage or exchange of this key block
14 storage or 1N No
is determined by the properties of the wrapping key.
exchange
— “1” (0x31): Storage context only. The key block is not
wrapped by a transport key for exchange between a
communicating pair.
— “2” (0x32): Key exchange context only. The key block
is wrapped by a transport key for exchange between a
communicating pair.
Reserved for This field is reserved for future use and is filled with
15 1N No
future use ASCII zero (0x30) characters.
Fields after byte 15 are only present if bytes 12-–13 contain a value other than “00” (0x3030).
ID field for the first optional block, if one is present as
16-– First optional
indicated by a value other than “00” in bytes 12 and 13. 2AN No
17 block ID
The possible ID values are defined in 6.3.6.
If the first optional block is present, indicated by a value
other than “00” in bytes 12 and 13, then this field
contains the length of that optional block in bytes,
including the field’s ID, length and data. Byte 18 contains
the high-order byte of the length and byte 19 contains the
low-order byte, both in hex-ASCII form. For example, for
a 24-byte optional block (0x18 in hexadecimal notation),
18-– Optional block 1
2H No
byte 18 contains a “1” (0x31) and byte 19 contains an “8”
19 length
(0x38). Optional block data can be omitted, in which case
the optional block length is “04”.
If the length of the optional block exceeds 255, this field is
set to “00” and the actual length is encoded in the next
two fields. The actual length is limited by the maximum
number of bytes in the key block length.
This field contains the length of the field named
“Extended optional block 1 length”. Valid values are
20-– Optional block 1
“01” – “FF”. For this document this value is always “04”.
2H No
21 length of length
This field is only present if the optional block 1 length is
“00”.
ISO/FDIS 20038:2026(en)
Byte # Field name Description Encoding Encrypted
The actual length of the block, expressed as a
hexadecimal number. For example, if the optional block
Extended
22-–
length is 400 bytes (190 ), this field is “0190”.
10 16
optional block 1 4H No
length
This field is only present if the optional block 1 length is
“00”.
If the first optional block is present, indicated by a value
optionalOptiona other than “00” in bytes 12-–13, then this field contains
n…m PA No
l block 1 data the data for that optional block. It contains only printable
ASCII characters.
A variable number of optional blocks can follow the first
Additional optional block, as indicated by the count in bytes 12-–13.
m+1…
optional blocks, Each optional block contains a 2-byte ID, 2-byte length  No
p
if present and variable-length data field following the same format
described for optional block 1.
Before a key in the key block format is used in a SCD, the contents of the header block shall be validated to
ensure the correct usage is enforced. First, the SCD makes sure that the length of the key block matches the
contents of bytes 1 to 4. If the lengths do not match, the SCD returns an error and stops processing the block.
The “key usage” byte is typically checked next followed by the “algorithm” byte. The processing of the other
header bytes depends on the key usage and the algorithm used.
From 0- to 99, optional blocks can be included in the key block. The total length of the key block shall not
exceed the maximum length that can be represented by the key block length field in bytes 1-4. The total
number of optional blocks is indicated by a count in bytes 12-13. Each optional block consists of three fields:
a 2-byte identifier that indicates the content of the optional block; a 2-byte length that indicates the total
number of bytes in all of the optional block’s fields – possibly extended to a variable length field if the optional
block length of length fields are used; and the variable-length data carried in the optional block. See Table 7
for a list of valid identifiers.
For example, consider an optional block that contains a key set identifier. A sample block can contain the
following data:
— — Identifier: “KS”
— Length: “18”
— Data: “00604B120F9292800000”
NOTE The length value equals 2+2+20 (24). The length value is encoded in Hex-ASCII; 18 hexadecimal equals 24
decimal.
If more than one optional block is present, each one shall immediately follow the previous one in the key block
structure.
The total length of all optional blocks in the key block shall be a multiple of the encryption block size. This can
require padding. If padding is required, it shall be included in a special final optional block that is filled with
an appropriate number of padding characters. For example, if the total length of all optional blocks before
padding is 90, six additional bytes are required in order to bring the total to the next multiple of the encryption
block size, 96. A padding block is added as the last optional block, containing the 2-byte identifier “PB”, a 2-
byte length field “06” and two characters of padding.
ISO/FDIS 20038:2026(en)
6.2.2 Changing key headers
A single key under two different headers with different attributes creates the potential for attacks. Therefore,
the SCD shall not generate a key with multiple headers or change the value of a key header except as described
in the list in this subclause (6.2.2). This includes changing the header when changing the wrapping key.
Similarly, there shall be a policy that users shall not manually load the same key bound to different attributes
except under the same rules. Checking manual loading rules is generally not technically enforceable within
the HSM since these are distributed systems. SCDs that translate a key to a non-ISO 20038 format should
maintain equivalent usage separation to the ISO 20038 headers.
Legitimate changes to the headers are as follows:
a) a) A header may be changed to become more restrictive. The reverse operation of any of these is
not allowed (e.g. an encrypt-only key cannot become both encrypt and decrypt).
1) An exportable key may become non-exportable (i.e. exportability “E"” may become "“N").”).
2) A key that supports both encrypt and decrypt can become either encrypt-only or decrypt-only (i.e.
mode of use "“B"” can become mode of use "“E"” or "“D").”).
3) A key that supports both generate and verify can become generate-only or verify-only (i.e. mode of
use "“C"” can become mode of use "“G"” or "“V").”).
4) A key that supports both sign and decrypt can become sign-only or decrypt-only (i.e. mode of use
"“T"” can become mode of use "“S"” or "“D").”).
5) A key diversification keyKDK of type “unassigned” (mode of Use “L”) can become mode of use “J” or
“K”.
b) SCDs may generate a key marked as non-exportable and export that key in a single key export command
or operation. Effectively, this is shorthand for internally generating an exportable version of that key,
exporting the key as non-exportable key and then changing the local copy of the key to non-exportable.
Since the original exportable version of the key is never exposed outside of the SCD, this creates a “one-
time exportable” key. The SCD shall not export keys marked as non-exportable except as part of the key
generation function.
c) Uni-directional keys have a mode of use that restricts to either starting or completing a cryptographic
interaction, such as encrypt-only or decrypt-only. Uni-directional keys are required to occur in matching
pairs in order to be functional. For example, an encrypt-only key at the sender needs a decrypt-only (or
bi-directional: both encrypt &and decrypt mode of use) key at the receiver. This means that reversing the
mode of use upon export can be necessary. However, this creates a potential weakness in that an SCD’s
commands can be used with a bi-directional KBPK to change the usage of the key within the SCD.
1) Keys that have uni-directional mode of use requirements shall be marked non-exportable.
2) Uni-directional keys that are exportable or one-time exportable should only be exported under uni-
directional KBPKs.
d) Optional blocks may be added, removed or changed, except for cases where a key usage requires the
optional block, e.g. the HMAC optional block, which cannot be removed or changed when included.
e) Keys with usage "“K0"” may be converted to be keys with usage "“K1".”.
ISO/FDIS 20038:2026(en)
6.3 Defined values for key block headers
6.3.1 Key usage
Key usage defines the type of the key, whether it is used, for example, to encrypt data or calculate a MAC. The
key usage is identified by bytes 5 and 6. Table 2 shows the currently defined key usage values. There is
additional information for each defined value after Table 2.
Table 2 — Defined key usage values
Allowed key block
Value Hex Definition Mode(s) of use header version ID
values
“B0” 0x4230 Base derivation key (BDK) “X” “D”,””,“E”
Initial derived unique key per transaction
“B1” 0x4231 “X” “D”,””,“E”
(DUKPT) key
“B3” 0x4233 Key derivation key (non-ANSI X9.24/ ISO 11568) “X” “D”,””, “E”
“B4” 0x4234 Key diversification keyKDK for directed keys “J”, “K”, “L” “D”,””,“E”
“BG” 0x4247 Multi-level derivation key “X” “D”,””,“E”
“C0” 0x4330 Card verification key “C”, “G”, “V” “D”,””,“E”
“D0” 0x4430 Symmetric key for data encryption “B”, “D”, “E” “D”,””,“E”
“D1” 0x4431 Asymmetric key for data encryption “B”, “D”, “E” “D”,””,“E”
“D2” 0x4432 Data encryption key for decimalization table “B”, “D”, “E” “D”,””,“E”
“D3” 0x4433 Data encryption key for sensitive data “B”, “D”, “E” “D”,””,“E”
EMV/chip issuer master key: application
“E0” 0x4530 “X” “D”,””,“E”
cryptograms
EMV/chip issuer master key: secure messaging
“E1” 0x4531 “X” “D”,””,“E”
for confidentiality
EMV/chip issuer master key: secure messaging
“E2” 0x4532 “X” “D”,””,“E”
for integrity
EMV/chip issuer master key: data authentication
“E3” 0x4533 “X” “D”,””,“E”
code
“E4” 0x4534 EMV/chip issuer master key: dynamic numbers “X” “D”,””,“E”
“E5” 0x4535 EMV/chip issuer master key: card personalization “X” “D”,””,“E”
“E6” 0x4536 EMV/chip issuer master key: other “X” “D”,””,“E”
EMV/chip asymmetric key pair for EMV/smart-
“E7” 0x4537 “B”, “D”, “E” “D”,””,“E”
card-based PIN/PIN block encryption
“F0” 0x4630 EMV/chip card key: application cryptograms “X” “D”,””,“E”
EMV/chip card key: secure messaging for
“F1” 0x4631 “X” “D”,””,“E”
Confidentiality
EMV/chip card key: secure messaging for
“F2” 0x4632 “X” “D”,”E”
integrity
“F3” 0x4633 EMV/chip card key: data authentication code “X” “D”,””,“E”
“F4” 0x4634 EMV/chip card key: dynamic numbers “X” “D”,””,“E”
“F5” 0x4635 EMV/chip card key: card personalization “X” “D”,””,“E”
ISO/FDIS 20038:2026(en)
Allowed key block
Value Hex Definition Mode(s) of use header version ID
values
“F6” 0x4636 EMV/chip card key: other “X” “D”,””,“E”
EMV/chip card asymmetric key pair for
“F7” 0x4637 “B”, “D”, “E” “D”,””,“E”
EMV/smart-card-based PIN/PIN block encryption
“I0” 0x4930 Initialization vector (IV) “N” “D”,””,“E”
“K0” 0x4B30 Key encryption key or key wrapping key “B”, “D”, “E” “D”,””,“E”
“K1” 0x4B31 KBPK, ANSI X9.143/ANS X9 TR-31 “B”, “D”, “E” “D”,””,“E”
Asymmetric key pair (KRD), ANSI
“K2” 0x4B32 “B”, “D”, “E” “D”,””,“E”
X9.139/ANS X9 TR-34
Asymme
...