ISO/DIS 25186:2025(en)

ISO/TC 68/SC 2/WG 13

Date: 2025-05-22

Secretariat: BSI

Financial services — Methods for the Generation, Change and Verification of Card Security Codes

© ISO 2025

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

Email: copyright@iso.org

Website: www.iso.org

Published in Switzerland

Contents

Foreword iv

Introduction v

1 Scope 1

2 Normative references 1

3 Terms and definitions 1

4 Generation and Verification of Card Security Code (CSC) 4

4.1 CSC Algorithm 4

4.2 Generation 4

4.3 Verification 5

4.4 Time Varying Parameter 5

5 Requirements for the MAC algorithm and key size 5

Annex A (informative) Worked Examples 6

A.1 CSC calculation 6

A.1.1 Worked Example 1 6

A.1.2 Worked Example 2 7

A.1.3 Worked Example 3 8

A.1.4 Worked Example 4 9

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/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.

A list of all parts in the ISO ##### 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.

Introduction

Payment cards commonly carry a static 3-digit or 4-digit card security code used for authenticating remote commerce transactions. Card security codes can be also by dynamically generated on devices with cryptographic computation capabilities such as smart cards and phones, or retrieved from another system.

This document provides requirements and guidance for methods for generation, change, and verification of Card Security Codes (CSCs). Requirements and guidance are designed to support secure and interoperable implementations.

This document identifies ciphers and algorithms from ISO/IEC 18033-3, ISO/IEC 10118-3 and ISO/IEC 9797 that are specifically approved for secure banking purposes.

Financial Services — Methods for the Generation, Change, and Verification of Card Security Codes

This document defines a method for generating and verifying Card Security Codes using CMAC or HMAC.

Key management mechanisms associated with these processes are out of scope of this document.

The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.

ISO/IEC 9797‑1, Information technology — Security techniques — Message Authentication Codes (MACs) — Part 1: Mechanisms using a block cipher

ISO/IEC 9797‑2, Information security — Message authentication codes (MACs) — Part 2: Mechanisms using a dedicated hash-function

ISO/IEC 18033‑3, Information technology — Security techniques — Encryption algorithms — Part 3: Block ciphers

ISO/IEC 10118‑3, IT Security techniques — Hash-functions — Part 3: Dedicated hash-functions

For the purposes of this document, the following terms and definitions 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

CMAC

Cipher-based Message Authentication Code as defined in ISO/IEC 9797-1.

Note 1 to entry: Within this document, references to CMAC refer to algorithm 5 in ISO/IEC 9797-1 used with a 16-byte block cipher.

[SOURCE: ISO/IEC 9797-1]

3.2

Card Security Code

CSC

A cryptographic checksum generated by a card issuer or its agent for the purpose of providing authentication of a PAN and its Service Code with Expiry Date

3.3

Dynamic CSC

A type of CSC which is generated immediately before use.

3.4

HMAC

Hashed message authentication code as defined as algorithm 2 in ISO/IEC 9797-2.

[SOURCE: ISO/IEC 9797-2]

3.5

message authentication code

MAC

String of bits which is the output of a MAC algorithm

[SOURCE: ISO 9797-1:2011]

3.6

message authentication code algorithm

MAC algorithm

Algorithm for computing a function which maps strings of bits and a secret to fixed-length strings of bits, satisfying the following two properties:

— For any key and any input string, the function can be computed efficiently;

— For any fixed key, and given no prior knowledge of the key, it is computationally infeasible to compute the function value on any new input string, even given knowledge of a set of input strings and corresponding function values, where the value of the ith input string might have been chosen after observing the value of the first i-1 function values (for integers i > 1)

[SOURCE: ISO 9797-1:2011]

3.7

primary account number

PAN

assigned number, composed of an issuer identification number, an individual account identification and an accompanying check digit as specified in ISO/IEC 7812-1, which identifies the card issuer and cardholder

[SOURCE: ISO 9564-1:2017, 3.22]

3.8

PAN sequence number

PSN

number which identifies and differentiates cards with the same PAN

3.9

Primary account number token

PAN Token

surrogate value used in place of the original PAN in certain, well-defined situations, but that is not used in place of the original PAN in every way that the original PAN is used

[SOURCE: ISO 9564-1:2017, 3.23]

3.10

Static CSC

A type of CSC which is generated during card issuance and remains static for the life of the card.

A CSC is calculated using the following method:

1) Apply the MAC algorithm using a dedicated CSC key to the data listed in Table 1.

Fields containing decimal digits should be encoded as sequences of 4-bit nibbles, where each nibble represents a single decimal digit. A separator with hexadecimal value ‘F’ should be added between all fields, including when the field value is omitted. To ensure the encoded result aligns with a byte boundary, a padding field containing a single ‘F’ is conditionally appended.

Table 1 — Input fields for CSC calculation

2) From the result of Step 1 proceeding from left to right, 4 bits at a time, extract all 4-bit nibbles that correspond to decimal digits (0-9) and concatenate to form a string of decimal digits.

3) If Step 2 does not produce clen digits, then from the result of Step 1, going from left to right, 4 bits at a time, extract 4-bit nibbles that correspond to the hexadecimal characters in the set {'A'–'F'}, subtract decimal 10 from each extracted hexadecimal digit to give a decimal digit in the range 0-5, and concatenate the resulting digits to the right of the digits extracted in Step 2.

4) Select the clen leftmost digits of the decimal string created in the previous step as output as the CSC.

Note: Step 3 will not generate digits in the range 6-9 and therefore the output will be biased, this bias has been acknowledged and accepted as the probability of step 3 being used is very small.

Generation shall be performed by executing the CSC algorithm and using the output as the CSC.

To help prevent replay attacks, the generation process shall ensure each freshly generated CSC is unique, except by chance. Diversification data shall be used in systems where the combination of account data and service code do not ensure a unique-per-generation CSC.

Verification uses the CSC algorithm to calculate the expected CSC and compares this value to the received value.

Diversification data shall be used in situations where two generated CSCs would otherwise be identical.

Suggested techniques for diversification data generation are listed below, other techniques are also possible providing a unique per generation CSC is output:

— A time stamp. To ensure unique per generation CSCs, the resolution of the time stamp should be higher than the expected minimum period between CSC generation operations for a specific account.:

— One second for a dynamic CSC

— One day for a static CSC

When using a time stamp as diversification data, the verifier shall validate the time stamp against either the current time or the previously recorded time of generation.

— A nonce or counter created by the generator, where the verifier confirms that the diversification data has not been reused for this combination of account data and service code

— A challenge created by the verifier and used for dynamic CSC generation. The verifier shall use the same challenge when validating the received CSC.

— A random number

The MAC algorithm used shall be either CMAC or HMAC.

CMAC shall only be used with a 16-byte block cipher and key of 128 bits or longer.

When using HMAC, a hashing algorithm with an output of at least 256 bits shall be used with a minimum key size of 128 bits.

1. 
   (informative)
   
   Worked Examples
   1. Worked Example 1

This example uses a 16-digit PAN with no diversification data.

Table A.1 — Worked Example 1

• 1. Worked Example 2

This example uses a 19-digit PAN with derivation data and no service code. Conditional padding is added after the CSC length field to create an even number of nibbles for submission to the CMAC function.

Table A.2 — Worked Example 2

• 1. Worked Example 3

This example uses HMAC-SHA256 with a 16 -digit PAN with no diversification data, and a 3-digit service code.

Table A.3 — Worked Example 3

• 1. Worked Example 4

This example uses a 19-digit PAN with diversification data and a 3-digit service code and outputs a 4-digit CSC using HMAC-SHA256.

Table A.4 — Worked Example 4