1270A622-001.1 Card Issuance Firmware 1119-0902 - CIP

payShield 9000
User Manual for

Card Issuance Firmware (1119-0902) -
Card Issuing Processing
www.thales-esecurity.com
payShield 9000 – Card Issuance Firmware (1119-09xx) - Card Issuing Processing
>> Revision Status
Document No. Software Version Built on Base … Publication Date

1270A622-001 1119-0902 payShield 9000 v1.3e July 2012
1270A622-001.1 1119-0902 payShield 9000 v1.3e July 2012
ii Thales e-Security
payShield 9000 – Card Issuance Firmware - Card Issuing Processing
>> References
The following documents are referenced in this document:
1 payShield 9000 Installation Manual
2 payShield 9000 Console Reference Manual
3 payShield 9000 Security Operations Manual
4 payShield 9000 Host Command Reference Manual
5 payShield 9000 Host Programmers Manual
6 payShield 9000 General Information Manual

7 User Manual for Card Issuance Firmware (1119-09xx) - Visa Open
Platform
>> Abbreviations
The following abbreviations are used in this document:
Abbreviation Meaning
3DES Triple DES
ANSI American National Standard Institute
CBC Cipher Block Chaining
DES Data Encryption Standard
ECB Electronic Code Book
HSM Host Security Module
LMK Local Master Key
PIN Personal Identification Number
Thales e-Security iii

Card Issuance Firmware - Card Issuing Processing
>> List of Chapters
>> Introduction ........................................................................................ 13
>> Console Commands ............................................................................. 17
>> Host Commands.................................................................................. 20
>> Appendix A: Local Master Key Variants ................................................ 110
>> Appendix B: Algorithm Identifiers ........................................................ 111
>> Appendix C: PKCS#1Pad Mode (Pad Mode Identifier = 01) ..................... 112
>> Appendix D: Public Key Encoding ......................................................... 114
>> Appendix E: Self-Signed CA Public Key Format (Visa) ............................. 115
>> Appendix F: Self-Signed Issuer Public Key Format (Visa) ......................... 118
>> Appendix G: Issuer Public Key Format (Visa) ......................................... 120
>> Appendix H: Format of Static Data Authentication Block ........................ 124
>> Appendix I: Format of Visa Cash Card Certificate .................................. 125
>> Appendix J: Self-Signed CA Public Key Format (MCI/EPI/JCB) ................ 128
>> Appendix K: Self-Signed Issuer Public Key Format (MCI/EPI) .................. 130
>> Appendix L: Issuer Public Key Certificate Format (MCI/EPI) ................... 132
>> Appendix M: Encryption of Tag-Length-Value (TLV) Fields ........................ 134
>> Appendix N: Multos Padding ............................................................... 135
>> Appendix O: Triple DES CBC Mode of Encryption/Decryption .................. 136
>> Appendix P: Multos KTU Format ......................................................... 137
>> Appendix Q: Checksum Algorithm ........................................................ 139
>> Appendix R: Format of ICC Certificate .................................................. 140
>> Appendix S: Mastercard PIN Block Format ........................................... 142
>> Appendix T: Multos Encryption Algorithm ............................................. 143
>> Appendix U: Alternative Output Formats for Private Key ........................ 144
4 Thales e-Security
>> Appendix V: Encryption of Chinese Remainder Theory Components .......... 145
>> Appendix W: ZS Command Output for PIN Block Format ........................ 147
>> Appendix X: RSA CRT Components Format Definition............................. 148
>> Appendix Y: Diversifying a Key from a Master Key ................................. 149
>> Appendix Z: Commands & Responses for the P3SAM Card .................... 150
>> Appendix AA: Encoding of a Private Key ............................................... 156
>> Appendix BB: JCB PIN Block Format ................................................... 159
>> Appendix CC: Multos Version 3.0 Public Key Certificate ......................... 160
>> Appendix DD: Multos Version 4.0 Public Key Certificate ........................ 162
>> Appendix EE: Multos CA Public Key Format .......................................... 165
>> Appendix FF: Multos Version Public Key Format (Version 1) ................... 166
>> Appendix GG: Multos Public Key Authentication .................................... 168
>> Appendix HH: EMV 2000 Session Key Calculation ................................. 169
>> Appendix II: EMV 2000 Session Key Output Key Formats....................... 172
>> Appendix AAA: Application Specific Error Codes .................................... 173
>> Appendix BBB: List of Authorisable Activities ........................................ 174
Thales e-Security 5
>> Table of Contents
>> Revision Status ...................................................................................... ii
>> References ........................................................................................... iii
>> Abbreviations ........................................................................................ iii
>> List of Chapters .................................................................................... 4
>> Table of Contents .................................................................................. 6
>> End User License Agreement ................................................................ 10
>> Introduction ........................................................................................ 13

Overview ............................................................................................ 13
Structure of this document ................................................................... 13
PCI HSM Certification and Compliance .................................................... 14
Key Type Table ................................................................................... 14
>> Console Commands ............................................................................. 17

General ............................................................................................. 17
List of Console Commands (Alphabetical) ................................................ 17
List of Console Commands (Functional) ................................................... 17
Miscellaneous Commands .................................................................... 18
Generate Mutual Authentication Key .................................................... 19
>> Host Commands.................................................................................. 20

General ............................................................................................. 20
Multiple LMKs .................................................................................... 20
List of Host Commands (Alphabetical)..................................................... 22
List of Host Commands (Functional) ....................................................... 24
Personalisation Commands................................................................... 26
Translate a secure data block to card specific format............................. 27
Encrypt & Authenticate data block ...................................................... 29
Generate Welcome XLS Diversified Key ............................................... 31
RSA Key Management Commands for EMV-type Schemes ......................... 33
Generate Issuer RSA Key Set (Visa)..................................................... 35
Generate Issuer RSA Key Set (MCI) ..................................................... 38
Validate a Certification Authority Self-Signed Certificate (Visa) .................. 40
Validate a Certification Authority Self-Signed Certificate (MCI) ................... 42
Validate an Issuer Public Key Certificate (Visa)....................................... 44
Validate an Issuer Public Key Certificate (MCI) ....................................... 47
Import or Export an encrypted RSA Private Key ..................................... 49
Key Management Commands ............................................................... 51
Master DES key set-up commands for VSDC and Visa Cash .................... 51
Master DES key set-up commands for M/Chip Lite and M/Chip Select ..... 52
Card Issuing Commands for VSDC or UKIS .............................................. 54
6 Thales e-Security
Generate Card Unique DES Keys ......................................................... 55

Generate Static Data Authentication Signature ...................................... 58
Generic Card Issuing Commands for M/Chip Lite, M/Chip Select, & Generic
MULTOS Applications .......................................................................... 60
Translate a KTU ............................................................................... 64
Generate Multos Application Signature ................................................ 67
Hash Data Using Multos Asymmetric Hash Algorithm ............................ 69
Multos ALU Generator ...................................................................... 72
Import Hash Modulus ....................................................................... 78
Translate PIN .................................................................................. 80
Construct all ICC Public Key related data elements................................. 82
Generate ICC Public/Private Keyset .................................................... 85
Generate ICC Derived Keys ................................................................ 88
Generate EMV2000 Session Keys ...................................................... 91
Import Multos CA Public Key .............................................................. 93
Miscellaneous Commands .................................................................... 95
Generate or Verify MAC on Data using Session Key under KEK ................ 97
Generate and Verify MAC .................................................................. 99
Diversified key for Easy Entry/Dedicated Funding Account ..................... 101
Translate PIN ................................................................................ 103
Generate Audit Record.................................................................... 105
Verify Audit Record......................................................................... 107
Reset Audit Record Index ................................................................ 109
>> Appendix A: Local Master Key Variants................................................ 110
>> Appendix B: Algorithm Identifiers ........................................................ 111
>> Appendix C: PKCS#1Pad Mode (Pad Mode Identifier = 01) ..................... 112
>> Appendix D: Public Key Encoding ......................................................... 114
>> Appendix E: Self-Signed CA Public Key Format (Visa) ............................. 115
>> Appendix F: Self-Signed Issuer Public Key Format (Visa) ......................... 118
>> Appendix G: Issuer Public Key Format (Visa) ......................................... 120
>> Appendix H: Format of Static Data Authentication Block ........................ 124
>> Appendix I: Format of Visa Cash Card Certificate .................................. 125
>> Appendix J: Self-Signed CA Public Key Format (MCI/EPI/JCB) ................ 128
>> Appendix K: Self-Signed Issuer Public Key Format (MCI/EPI) .................. 130
>> Appendix L: Issuer Public Key Certificate Format (MCI/EPI) ................... 132
>> Appendix M: Encryption of Tag-Length-Value (TLV) Fields ........................ 134
>> Appendix N: Multos Padding ............................................................... 135
Thales e-Security 7
>> Appendix O: Triple DES CBC Mode of Encryption/Decryption .................. 136
>> Appendix P: Multos KTU Format ......................................................... 137
>> Appendix Q: Checksum Algorithm ........................................................ 139
>> Appendix R: Format of ICC Certificate .................................................. 140
>> Appendix S: Mastercard PIN Block Format ........................................... 142
>> Appendix T: Multos Encryption Algorithm ............................................. 143
>> Appendix U: Alternative Output Formats for Private Key ........................ 144
>> Appendix V: Encryption of Chinese Remainder Theory Components .......... 145
>> Appendix W: ZS Command Output for PIN Block Format ........................ 147
PIN Block Format Mode 0 ............................................................... 147
PIN Block Format Mode 1 ............................................................... 147
>> Appendix X: RSA CRT Components Format Definition............................. 148
>> Appendix Y: Diversifying a Key from a Master Key ................................. 149
>> Appendix Z: Commands & Responses for the P3SAM Card .................... 150
Get Key Version ............................................................................. 150
Get Challenge ................................................................................ 151
Mutual Authenticate A .................................................................... 152
Mutual Authenticate B .................................................................... 153
>> Appendix AA: Encoding of a Private Key ............................................... 156

ASN.1 encoding of a PRIVATE Key .................................................... 156
Private Key Exponent/Modulus format ............................................... 157
>> Appendix BB: JCB PIN Block Format ................................................... 159
>> Appendix CC: Multos Version 3.0 Public Key Certificate ......................... 160
>> Appendix DD: Multos Version 4.0 Public Key Certificate ........................ 162
Notation ....................................................................................... 162
>> Appendix EE: Multos CA Public Key Format .......................................... 165
>> Appendix FF: Multos Version Public Key Format (Version 1) ................... 166
>> Appendix GG: Multos Public Key Authentication .................................... 168
>> Appendix HH: EMV 2000 Session Key Calculation ................................. 169
>> Appendix II: EMV 2000 Session Key Output Key Formats ....................... 172
>> Appendix AAA: Application Specific Error Codes .................................... 173
8 Thales e-Security
>> Appendix BBB: List of Authorisable Activities ........................................ 174
Thales e-Security 9
>> End User License Agreement
(“EULA”)
Please read this Agreement carefully.
Opening this package or installing any of the contents of this package or using this product in
any way indicates your acceptance of the terms and conditions of this License.
This document is a legal agreement between Thales e-Security Ltd., (“THALES”) and the company that has purchased a THALES
product containing a computer program (“Customer”). If you do not agree to the terms of this Agreement, promptly return the
product and all accompanying items (including cables, written materials, software disks, etc.) at your mailing or delivery ex pense to the
company from whom you purchased it or to Thales e-Security, Ltd, Meadow View House, Crendon Industrial Estate, Long Crendon,
Aylesbury, Bucks HP18 9EQ, United Kingdom and you will receive a refund.
1. OWNERSHIP. Computer programs, ("Software") provided by THALES are provided either separately or as a bundled part of a computer
hardware product. Software shall also be deemed to include computer programs which are intended to be run solely on or within a
hardware machine, (“Firmware”).Software, including any documentation files accompanying the Software, ("Documentation")
distributed pursuant to this license consists of components that are owned or licensed by THALES or its corporate affiliates. Other
components of the Software consist of free software components (“Free Software Components”) that are identified in the text files
that are provided with the Software. ONLY THOSE TERMS AND CONDITIONS SPECIFIED FOR, OR APPLICABLE TO, EACH SPECIFIC FREE
SOFTWARE COMPONENT SHALL BE APPLICABLE TO SUCH FREE SOFTWARE COMPONENT. Each Free Software Component is the
copyright of its respective copyright owner. The Software is licensed to Customer and not sold. Customer has no ownership rights in
the Software. Rather, Customer has a license to use the Software. The Software is copyrighted by THALES and/or its suppliers. You
agree to respect and not to remove or conceal from view any copyright or trademark notice appearing on the Software or
Documentation, and to reproduce any such copyright or trademark notice on all copies of the Software and Documentation or any
portion thereof made by you as permitted hereunder and on all portions contained in or merged into other programs and
Documentation.
2. LICENSE GRANT. THALES grants Customer a non-exclusive license to use the Software with THALES provided computer equipment
hardware solely for Customer’s internal business use only. This license only applies to the version of Software shipped at the time of
purchase. Any future upgrades are only authorised pursuant to a separate maintenance agreement. Customer may copy the
Documentation for internal use. Customer may not decompile, disassemble, reverse engineer, copy, or modify the THALES owned or
licensed components of the Software unless such copies are made in machine readable form for backup purposes. In addition,
Customer may not create derivative works based on the Software except as may be necessary to permit integration with other
technology and Customer shall not permit any other person to do any of the same. Any rights not expressly granted by THALES to
Customer are reserved by THALES and its licensors and all implied licenses are disclaimed. Any other use of the Software by any other
entity is strictly forbidden and is a violation of this EULA. The Software and any accompanying written materials are protected by
international copyright and patent laws and international trade provisions.
3. NO WARRANTY. Except as may be provided in any separate written agreement between Customer and THALES, the software is
provided "as is." To the maximum extent permitted by law, THALES disclaims all warranties of any kind, either expressed or implied,
including, without limitation, implied warranties of merchantability and fitness for a particular purpose. THALES does not w arrant that
the functions contained in the software will meet any requirements or needs Customer may have, or that the software will operate
error free, or in an uninterrupted fashion, or that any defects or errors in the software will be corrected, or that the software is
compatible with any particular platform. Some jurisdictions do not allow for the waiver or exclusion of implied warranties so they may
not apply. If this exclusion is held to be unenforceable by a court of competent jurisdiction, then all express and implied warranties
shall be limited in duration to a period of thirty (30) days from the date of purchase of the software, and no warranties shall apply after
that period.
4. LIMITATION OF LIABILITY. In no event will THALES be liable to Customer or any third party for any incidental or consequential
damages, including without limitation, indirect, special, punitive, or exemplary damages for loss of business, loss of profits, business
interruption, or loss of business information) arising out of the use of or inability to use the program, or for any claim by any other
party, even if THALES has been advised of the possibility of such damages. THALES’ aggregate liability with respect to its obligations
under this agreement or otherwise with respect to the software and documentation or otherwise shall be equal to the purchase price.
10 Thales e-Security
However nothing in these terms and conditions shall however limit or exclude THALES’ liability for death or personal injury resulting
from negligence, fraud or fraudulent misrepresentation or for any other liability which may not be excluded by law. Because some
countries and states do not allow the exclusion or limitation of liability for consequential or incidental damages, the above limitation
may not apply.
5. EXPORT RESTRICTIONS. The software is subject to the export control laws of the United Kingdom, the United States and other
countries. This license agreement is expressly made subject to all applicable laws, regulations, orders, or other restrictions on the
export of the software or information about such software which may be imposed from time to time. Customer shall not export the
software, documentation or information about the software and documentation without complying with such laws, regulations,
orders, or other restrictions.
6. TERM & TERMINATION. This EULA is effective until terminated. Customer may terminate this EULA at any time by destroying or
erasing all copies of the Software and accompanying written materials in Customer’s possession or control. This license will terminate
automatically, without notice from THALES if Customer fails to comply with the terms and conditions of this EULA. Upon such
termination, Customer shall destroy or erase all copies of the Software (together with all modifications, upgrades and merged portions
in any form) and any accompanying written materials in Customer’s possession or control.
7. SPECIAL PROCEDURE FOR U.S. GOVERNMENT. If the Software and Documentation is acquired by the U.S. Government or on its
behalf, the Software is furnished with "RESTRICTED RIGHTS," as defined in Federal Acquisition Regulation ("FAR") 52.227-19(c)(2), and
DFAR 252.227-7013 to 7019, as applicable. Use, duplication or disclosure of the Software and Documentation by the U.S. Government
and parties acting on its behalf is governed by and subject to the restrictions set forth in FAR 52.227-19(c)(1) and (2) or DFAR 252.227-
7013 to 7019, as applicable.
8. TRANSFER RIGHTS. Customer may transfer the Software, and this license to another party if the other party agrees to accept the terms
and conditions of this Agreement. If Customer transfers the Software, it must at the same time either transfer all copies whether in
printed or machine-readable form, together with the computer hardware machine on which Software was intended to operate to the
same party or destroy any copies not transferred; this includes all derivative works of the Software. FOR THE AVOIDANCE OF DOUBT,
IF CUSTOMER TRANSFERS POSSESSION OF ANY COPY OF THE SOFTWARE TO ANOTHER PARTY, EXCEPT AS PROVIDED IN THIS SECTION
8, CUSTOMER’S LICENSE IS AUTOMATICALLY TERMINATED.
9. GOVERNING LAW AND VENUE. This License Agreement shall be construed, interpreted and governed either by the laws of England
and Wales or by the laws of the State of New York, United States of America, in both cases without regard to conflicts of laws and
provisions thereof. If the Software is located or being used in a country located in North America, South America, Central America or
the Caribbean region, the laws of the State of the State of New York, United States of America shall apply and the exclusive forum for
any disputes arising out of or relating to the EULA, including the determination of the scope or applicability of this EULA to arbitrate,
shall be shall be settled by arbitration in accordance with the Arbitration Rules of the International Chamber of Commerce (“ICC”) by
one arbitrator appointed in accordance with said Rules. The arbitration shall be administered by the ICC. The arbitration shall be held
in New York City (State of New York), and shall be conducted in the English language. Either Party may seek interim or provisional
relief in any court of competent jurisdiction if necessary to protect the rights or property of that party pending the appointment of the
arbitrator or pending the arbitrator’s determination of the merits of the dispute. The arbitration award will be in writing and will
specify the factual and legal basis for the award. The arbitration award will be final and binding upon the parties, and any judgment on
the award rendered by the arbitrator may be entered by any court having jurisdiction thereof. If the Software is located or being used
in any other location throughout the world, then in that event the laws of England and Wales shall apply and the exclusive forum for
any disputes arising out of or relating to this EULA shall be an appropriate court sitting in England, United Kingdom.
4.
Thales e-Security 11
This page is intentionally left blank.
12 Thales e-Security
>> Introduction
>> Introduction
Overview
This manual describes the commands used in the P3 Card Issuance Firmware that
have been enhanced to use Thales Key Scheme formatted keys so that standard base
commands can be used to generate import and export keys. Additional commands
are also included which allow the personalisation of some global platform and
proprietary chip cards.
This firmware is different code to the base (i.e. standard) payShield 9000 firmware,
but is created by adding the functionality defined in this manual to the functionality of
the base software that it is built on. This means that the Card Issuing Firmware
replaces the standard firmware, but inherits the functionality of the base software.
The standard payShield 9000 manuals should be used to understand the functionality
deriving from the standard software. The version of base firmware that this release of
Card Issuing Firmware is developed against is shown in the Revision Status at the
start of this document in the “Built on Base …” column.
The Card Issuing Firmware supports a number of Credit, Debit and Electronic Purse
initiatives. The particular schemes supported are:
Visa Smart Credit Debit (VSDC) specified in the Visa Integrated circuit card
Specification (VIS), Version 1.4 and 1.5. This also covers the UK subset known
as UK Integrated circuit card Specification (UKIS) Version 3.0.
MasterCard M/Chip Lite (version 2 and 4) and M/Chip Select (version 2 and 4)
credit and debit schemes. The latter runs on the Multos multi-application card.
The Visa defined Easy Entry and Dedicated Funding Account applications are also
covered, although both of these are being phased out.
The JCB J/Smart credit/debit scheme.
In addition support has also been included to enable the generation of Multos ALUs in
a relatively application independent way. There may be some constraints for some
Multos applications imposed by the available memory of the HSM. These are noted in
the text.
As well as the functions defined in this specification, there exists a supplementary
specification which describes additional functions which have been developed to
support the Global Platform scripting language. Global Platform (previously known as
Visa Open Platform) is a multi-application card which is gaining in popularity. In many
respects, Global Platform and the Multos platform are competing technologies. Since
the Global Platform support functions which Thales offers operate in isolation from the
functions defined in this document, they are described in a separate manual - Card
Issuance Firmware (1119-09xx) - Global Platform Scripting.
Structure of this document

The functions described in this document fall into the following categories:
Functions for the set up and management of top level RSA keys for Visa
Cash, VSDC (and UKIS), M/Chip Lite, M/Chip Select, and JCB Lite. Where
Thales – Information Technology Security 13

>> Introduction
necessary, duplicate functions are provided to handle the differences

between the Visa and MasterCard formatting rules.
Functions to enable the setting up of top level DES keys for Visa Cash, VSDC
(and UKIS), M/Chip Lite and M/Chip Select.
Functions to support the issuance of Visa Cash cards.
Functions to support the Issuance of VSDC cards.
Functions to support the Issuance of M/Chip Lite and M/Chip Select cards.
The functions in this section also support the generic ALU building
requirements.
Miscellaneous functions to support key sharing with personalisation systems
and a number of other aspects of generating smart card data.
These functions are all used by Card Issuers during the process of generating
cryptographic smart card data which will be placed on the card during the
personalization process.
The commands using public key cryptography are based on the standard public key
functionality available in the Thales Host Security Module family but with additional
commands to support EMV-type certificates. These commands are based on a
selectable public key algorithm and a selectable hash algorithm. Initially only the RSA
public key algorithm and the SHA-1 hash algorithm are supported. Other algorithms
will be included later if required.
Optional Licence HSM9-LIC002 must be installed on the payShield 9000 if
commands using the RSA algorithm need to be used.
PCI HSM Certification and Compliance

This firmware is not PCI HSM certified. (See Chapter 10 of the payShield 9000
General Information Manual for information about PCI HSM certification of the
payShield 9000.)
Key Type Table

The HSM uses a set of generic commands to generate, export and import keys.
These generic commands refer to a ‘permissions’ table to determine the allowable
actions when operating with a certain LMK pair and variant. This permissions table
(known as the Key Type Table) tells the generic commands whether the generation,
import or export under certain LMK pairs is allowed, and also whether or not
Authorized state is required to perform that action.
The Key Type Table to be used by this application is shown below:
>> Introduction
Variant  0 1 2 3 4 5 6 7 8 9
 LMK  G E I G E I G E I G E I G E I G E I G E I G E I G E I G E I
Pair Code
ZMK
ZMK
04 - (Comp)
00
05 A U A U U A U
ZPK
06 –
01
07 U A U
PVK
CSCK
TPK
14 - CVK
02 TMK
15
U A U U A U U A U U A U U A U U A U U A U U A U U A U U A U
TAK KMA
16 -
03
17 U A U U A U U A U U A U U A U U A U U A U U A U U A U U A U
DTAB IPB
18 –
04
20 –
05
WWK
22 –
06
KEK CMK KEK (Comp) CMK (Comp)

24 –
07
25 U A U U A U U A U U A U
ZAK
26 -
08
BDK MK-AC MK-SMI MK-SMC MK-DAK MK-DN MK-CVC3 KME KMD

28 –
09
ZEK
30 –
0A
DEC
32 –
0B
33 U
RSA-SK HMAC
34 –
0C
35 U A U
RSA-MAC
36 –
0D
37
DK-AC DK-SMI DK-SMC DK-DAK DK-DN

38 –
0E
Not all key type codes are available in all commands for security reasons.
The Key Type code used within commands is formed by using the Variant code as
the first character then the LMK pair code as the second character. For example
the code for a ZPK is 001.
The payShield 9000 HSM provides a set of commands for key generation, key
export and key import. An export command is one that translates a key from LMK
encryption to encryption under a ZMK or an RSA public key, for sending to another
party. Import is the reverse, for receiving keys and translating to local storage. The
Key Type Table controls ‘permitted actions’ for the console and host commands
used to generate, import and export keys.

>> Introduction
Errors are reported when an action breaks the rules imposed by the table. For
example:
29 : Key function not permitted
The table above shows the actions that can be applied to each specific LMK pair.
For each key type, the 3 boxes below the key type refer, from left to right, to:
G = Generate. E = Export. I = Import.
Each of these 3 boxes contains one of the following entries to define permissions:
blank = Not allowed.
A = allowed in Authorized State.
U = allowed Unconditionally, i.e. without Authorized State.
>> Console Commands
>> Console Commands
General
This Chapter details any console commands which are in addition to or are modified
from the base Software.
Abbreviations
See the General section in the chapter on Host Commands.
List of Console Commands (Alphabetical)

Host
Function Page
Command
DQ Generate Mutual Authentication Key 19
List of Console Commands (Functional)

Console
Function Page
Command
Miscellaneous Commands 18
Generate Mutual Authentication Key DQ 19

>> Console Commands
Miscellaneous Commands
Command Page
Generate Mutual Authentication Key 19

>> Console Commands
Generate Mutual Authentication Key Variant  Keyblock 

Online  Offline  Secure 
Authorization: Not Required
Command: DQ
Function: To create a P3SAM Mutual Authentication Key (KMA) encrypted

under a ZCMK and LMK.
Authorization: Authorisation never required.
Inputs: ZCMK, encrypted under LMK pair 04-05 (32 H or 1A+32H

or 1A+48H)
Outputs: KMALMK - The Mutual Authentication Key encrypted under the

LMK pair 16-17 variant 1. (32 H or 1A+32H or 1A+48H)
KMAZMK - The Mutual Authentication Key encrypted under the
ZMK (32 H or 1A+32H or 1A+48H)
KMA Key check value (6H)
Errors: KEY PARITY ERROR - the plaintext key does not have odd
parity on each byte. Re-enter the correct value.
MASTER KEY PARITY ERROR - the contents of LMK storage
have been corrupted or erased. Do not continue - inform the
Security Department
Example: Online> DQ<Return>

Enter ZCMK: A XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX<Return>
KMA encrypted under LMK: A XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX
KMA encrypted under ZMK: A XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX
Key check value: XX XX XX
Online>

>> Host Commands
>> Host Commands
General
This Chapter details all the commands available with their responses and possible
error codes.
A number of abbreviations are used throughout. They are:
L : Encrypted PIN length. Set at installation.

m : Message header length. Set at installation.
n : Variable length field.
A : Alphanumeric (can include any non-control type) characters.
H : Hexadecimal character ('0'...'9', 'A'...'F').
N : Numeric Field ('0'...'9').
C : Control character.
B : Binary data (byte) (X'00...X'FF).
D : Binary coded decimal (BCD) character ('0'...'9').
For example:
32 H : Indicates that thirty-two hexadecimal characters are required.
mA: Indicates the string of "message header length" alphanumeric
characters.
For convenience, the STX and ETX control characters, which bracket every
command and response when using Asynchronous communications, are not shown
in the details that follow.
In a command to the HSM, any key can be replaced by a reference to internal user
storage. In the details that follow, a key is always shown as if it is to be sent with
each command; in every case the key can be replaced by the index flag K and a
three-digit pointer value.
The HSM can be used in systems where there may be Atalla security equipment at
other network nodes. This is achieved by the inclusion of an Atalla variant in those
commands that translate a key from/to encryption under a ZMK. This has the
effect of modifying the ZMK before it is used to decrypt/encrypt in accordance with
the method used by the Atalla equipment. The HSM can support 1 or 2 digit Atalla
variants.
When a disabled host command is invoked, the error code 68 is returned.
Multiple LMKs
This firmware supports Multiple LMKs, as described in the payShield 9000 user
manuals. The ID of the LMK required by each command can be specified by using
>> Host Commands
the “%” delimiter followed by the LMK ID, immediately before the optional end of
message delimiter. This is shown in the host command structures that follow.
For backwards compatibility, if these optional Multiple LMK fields are omitted, the
default LMK will be used.

>> Host Commands
List of Host Commands (Alphabetical)

Host
Command Function Page
(Response)
HI (HJ) Generate Card Unique DES Keys 55
HK (HL) Generate Static Data Authentication Signature 58
HW (HX) Generate or Verify MAC on Data using Session Key 97

under KEK
IU (IV) Generate Issuer RSA Key Set (Visa) 35
IW (IX) Validate a Certification Authority Self-Signed Certificate 40

(Visa)
IY (IZ) Validate an Issuer Public Key Certificate (Visa) 44
JM (JN) Generate Issuer RSA Key Set (MCI) 38
JO (JP) Validate a Certification Authority Self-Signed Certificate 42

(MCI)
JQ (JR) Validate an Issuer Public Key Certificate (MCI) 47
JY (JZ) Diversified key for Easy Entry/Dedicated Funding 101

Account
P0 (P1) Translate a secure data block to card specific format 27
P2 (P3) Encrypt & Authenticate data block 29
P4 (P5) Generate Welcome XLS Diversified Key 31
WG (WH) Generate Audit Record 105
WI (WJ) Verify Audit Record 107
WK (WL) Reset Audit Record Index 109
WM (WN) Generate EMV2000 Session Keys 91
XY (XZ) Import Multos CA Public Key 93
YA (YB) Import or Export an encrypted RSA Private Key 49
ZE (ZF) Translate PIN 103
ZG (ZH) Translate a KTU 64
ZI (ZJ) Generate Multos Application Signature 67
ZK (ZL) Generate and Verify MAC 99

>> Host Commands
Host
Command Function Page
(Response)
ZM (ZN) Hash Data Using Multos Asymmetric Hash Algorithm 69
ZO (ZP) Multos ALU Generator 72
ZQ (ZR) Import Hash Modulus 78
ZS (ZT) Translate PIN 80
ZU (ZV) Construct all ICC Public Key related data elements 82
ZW (ZX) Generate ICC Public/Private Keyset 85
ZY (ZZ) Generate ICC Derived Keys 88

>> Host Commands
List of Host Commands (Functional)

Host
Function Command Page
(Response)
Personalisation Commands 26
Translate a secure data block to card specific format P0 (P1) 27
Encrypt & Authenticate data block P2 (P3) 29
Generate Welcome XLS Diversified Key P4 (P5) 31
RSA Key Management Commands for EMV-type 33

Schemes
Generate Issuer RSA Key Set (Visa) IU (IV) 35
Generate Issuer RSA Key Set (MCI) JM (JN) 38
Validate a Certification Authority Self-Signed Certificate IW (IX) 40

(Visa)
Validate a Certification Authority Self-Signed Certificate JO (JP) 42

(MCI)
Validate an Issuer Public Key Certificate (Visa) IY (IZ) 44
Validate an Issuer Public Key Certificate (MCI) JQ (JR) 47
Import or Export an encrypted RSA Private Key YA (YB) 49
Key Management Commands 51

Master DES key set-up commands for VSDC and Visa 51
Cash
Master DES key set-up commands for M/Chip Lite 52
and M/Chip Select
Card Issuing Commands for VSDC or UKIS 54

Generate Card Unique DES Keys HI (HJ) 55
Generate Static Data Authentication Signature HK (HL) 58
Generic Card Issuing Commands for M/Chip Lite, 60

M/Chip Select, & Generic MULTOS Applications
Translate a KTU ZG (ZH) 64
Generate Multos Application Signature ZI (ZJ) 67
Hash Data Using Multos Asymmetric Hash Algorithm ZM (ZN) 69

>> Host Commands
Host
Function Command Page
(Response)
Multos ALU Generator ZO (ZP) 72
Import Hash Modulus ZQ (ZR) 78
Translate PIN ZS (ZT) 80
Construct all ICC Public Key related data elements ZU (ZV) 82
Generate ICC Public/Private Keyset ZW (ZX) 85
Generate ICC Derived Keys ZY (ZZ) 88
Generate EMV2000 Session Keys WM (WN) 91
Import Multos CA Public Key XY (XZ) 93
Miscellaneous Commands 95
Generate or Verify MAC on Data using Session Key HW (HX) 97
under KEK
Generate and Verify MAC ZK (ZL) 99
Diversified key for Easy Entry/Dedicated Funding JY (JZ) 101

Account
Translate PIN ZE (ZF) 103
Generate Audit Record WG (WH) 105
Verify Audit Record WI (WJ) 107
Reset Audit Record Index WK (WL) 109

>> Host Commands
Personalisation Commands
Available Commands
Command Page
Translate a secure data block to card specific format 27
Encrypt & Authenticate data block 29
Generate Welcome XLS Diversified Key 31

>> Host Commands
Variant  Keyblock 
Translate a secure data block to card
specific format
Authorisation: Not required
Function: Translate secure data block for ST card.
State: Online
Field Length & Type Details
COMMAND MESSAGE
Message header mA Subsequently returned to the Host unchanged.
Command Code 2A Value 'P0' (0=zero).
Decrypt / Encrypt 2N Decryption / Encryption mode:

Mode
00 = ECB / ECB
01 = ECB / CBC
10 = CBC / ECB
11 = CBC / CBC
Decrypt Key Type 3H 002, 102, 202, 302, 402, 502, 602, 702, 802 or 902
Decryption key 32 H or 1A+32H Decryption key encrypted under LMK pair 14-15, Variant indicated by
or 1A+48H 'Decryption Key Type'
Decryption IV 8B Decryption Initialisation Vector
(only present if Decrypt / Encrypt Mode = 10 or 11)
Encryption Variant 3H 002, 102, 202, 302, 402, 502, 602, 702, 802 or 902
Encryption key 32 H or 1A+32H Encryption Key encrypted under LMK pair 14-15, Variant indicated by
or 1A+48H 'Encryption Key Type'
Encryption IV 8B Encryption Initialisation Vector
(only present if Decrypt / Encrypt Mode = 01 or 11)
Header Length 2H Length of the following header information (must be even)
Header nH Output header for PIN Try Limits, counter and other future values
Delimiter 1A Value ;
Sensitive Data Length 3H Length of the following Sensitive Data
Sensitive Data nB Sensitive Data in 8 byte blocks
Delimiter 1A Value ;
Trailer Length 2H Length of the following trailer information
Trailer nH Output trailer for padding in 8 byte blocks

>> Host Commands
Delimiter 1A Value '%'. Optional; if present, the following field must be present.
LMK Identifier 2N LMK identifier; min value = '00'; max value is defined by licence; must
be present if the above Delimiter is present.
End message delimiter 1C Must be present if a message trailer is present. Value X'19.
Message trailer nA Optional. Maximum length 32 characters.

RESPONSE MESSAGE
Message header mA Returned to the Host unchanged.
Response Code 2A Value 'P1'.
Error Code 2N 00 : No error
10 : Decrypt KEY parity error

11 : Encrypt KEY parity error
12 : No keys loaded in user storage

13 : LMK error, report to supervisor
15 : Invalid input data
21 : Invalid user storage index
50 : Invalid Decrypt / Encrypt mode
53 : Invalid Decrypt KEY Length
54 : Invalid Encrypt KEY Length

58 : Invalid Encryption Variant
80 : Invalid header length error
81 : Sensitive data length error
82 : Invalid trailer length error

Any standard error code
Encrypted Sensitive nB Encrypted Sensitive Data encrypted under Encryption Key

Data
End message delimiter 1C Present only if present in the command message. Value X'19.
Message trailer nA Present only if present in the command message. Maximum length 32
characters.
>> Host Commands
Encrypt & Authenticate data block
Function: To encrypt a data block using a derived encryption key DKENC (derived from
a master key MKENC). The input data block can be in the clear or
encrypted under a KEK or a ZPK.
State: Online
Notes: If a value does not fully occupy a field, this should also be padded out with
0x00s.
COMMAND MESSAGE
Command Code 2A Value 'P2'
Pattern Byte 2H Pattern Byte
Pattern Offset 3N Pattern Offset, range 000 to 791
Pattern Length 2N Pattern Length, range 00 to 99
Encryption Method 1N 0 = Clear Input Data Block, following field not present.
1 = ZPK encrypted under LMK pair 06-07
2 = KEK encrypted under LMK pair 24-25 Variant 1
KEY 32 H or 1A+32H If Encryption Method = 0, this field is not present

or 1A+48H If Encryption method = 1, Input Data Block encrypted under a ZPK
If Encryption Method = 2, Input Data Block encrypted under a KEK
MK-smi 32 H or 1A+32H Master Key MK-smi encrypted under LMK pair 28-29 Variant 2
or 1A+48H
Derivation Data 32 H Derivation Data
Derivation Method 2N Derivation Method, range 01 – 02
Datablock Multiplier 2N Number of Input Data 16 hexadecimal character data blocks. Range 01
to 99.
Input Data Block nH Input data block in multiples of 16 hexadecimal characters.

>> Host Commands

RESPONSE MESSAGE
Error Code 2N 00 – No error

10 – KEY parity error
11 – MK-smi parity error

50 – Invalid Pattern Offset
51 – Invalid Pattern Length
52 – Invalid Encryption Method

53 – Invalid Datablock Multiplier
54 – Invalid Derivation Method
55 – Invalid Input Data Block length
56 – Invalid Pattern Offset
Number of following 2N Number of following data blocks, range 01 to 99.

blocks
Encrypted data block(s) nH Encrypted data blocks in multiples of 16 Hex characters
Check Digit 16 H Check Digit
characters.
>> Host Commands
Generate Welcome XLS Diversified Key
Function: This function generates a diversified key from a master key and card
number using a proprietary algorithm for the Welcome Real-time Extended
Loyalty Application (XLS).
State: Online
Notes:
COMMAND MESSAGE
Command Code 2A Value “P4”
Master Key Type 3H Key Type, under which Keys are encrypted:
002 = LMK pair 14-15
003 = LMK pair 16-17
004 = LMK pair 18-19
005 = LMK pair 20-21
006 = LMK pair 22-23
008 = LMK pair 26-27
009 = LMK pair 28-29
00A = LMK pair 30-31

00E = LMK pair 38-39
Master Key 32 H or 1A+32H Master key encrypted under the LMK pair defined by the Master Key
Type and variant defined by Key Variant.
Diversification Data 8B 8 bytes of clear text diversification data
KEK 32 H or 1A+32H The KEK encrypted under LMK pair 24-25 variant 1.
or 1A+48H

>> Host Commands

RESPONSE MESSAGE

03 : Invalid diversification data length
04 : Invalid Master Key Type
10 : Parity error on Master key
11 : Parity error on KEK

Key 1A+32H Generated key encrypted under LMK ‘Key Type’, Variant ‘Key Variant’ with
length Key Length
characters.
>> Host Commands
RSA Key Management Commands for EMV-type Schemes
The commands in this section allow the Card Issuer to set up the appropriate RSA
keys in readiness for the card issuing process. The following step by step
description shows how the commands are intended to be used. Further notes
describing how each function is used in the context of Visa Cash/VSDC/UKIS,
M/Chip Lite/M/Chip Select and JCB Lite are given with each command.
The Issuer creates his own RSA keyset by using one of the Generate Issuer RSA
Key Set commands. The key length will have to be defined (typically 512, 640,
768, 896, 1024, 2048 or 4096 bits) and the public exponent chosen. The
public key exponent varies from scheme to scheme with the most common
values being 3 and 65537. The Private Key part of the keyset is returned to the
host system encrypted under the HSM’s Local Master Key. This must be stored
on the host database. The Public Key (PK) part of the keyset is also returned to
the host system in two formats; a self signed certificate and the Public Key
protected with a MAC. The self signed certificate is in the format required for
transportation to the scheme Certification Authority (CA). It is normally
transferred directly to a floppy disk (probably via a connected PC) for transport
to the Certification Authority. The exact format details of how the self signed PK
certificate is to be written to the floppy disk is to be determined by the scheme
provider (eg Visa, Europay, Mastercard, JCB).
If the PK is to be stored on the local database it is recommended that it is
protected from alteration by storing the MAC as well. In this way, the
authenticity of the PK can be later verified using the Verify MAC on PK
command.
The Certification Authority (probably the Scheme Provider) will read the self
signed PK certificate from the floppy disk and generate the Issuer PK certificate
by signing the Issuer PK and other data using the (already generated) CA Private
Key. The CA may sign the Issuer PK using several CA Private Keys of different
key lengths to produce several different Issuer PK certificates. This is to allow
the issuer to migrate to longer key length (and hence more secure) certificates
in the future if necessary. The certificate(s) are written to a floppy disk for
transportation back to the Issuer together with the Output Extension and
possibly a Detached Signature. At the same time, the Certification Authority
PK(s) (in the form of self signed certificate(s)) may also be written to a floppy
disc for transportation back to the Issuer. This will allow the Issuer to verify the
CA PK certificate and the Issuer Certificate(s) when they arrive.
The Issuer reads the floppy disk(s) and places the certificate(s) and the CA PK(s)
on the host database. The certificates are then verified. First it is necessary to
verify the CA self signed certificate(s) using one of the Validate Certification
Authority Self-Signed Certificate commands. These commands return the CA
Public Key and a MAC which should be stored for later use.
The Issuer Certificate is verified using one of the Validate an Issuer Public Key
Certificate commands. These commands return the Issuer PK, a MAC over
that PK and an indicator of successful validation. It is possible at this stage to
compare the Issuer PK and the MAC with that obtained when the Issuer Keyset
was generated to ensure that the PK returned from the Certification Authority is

>> Host Commands
the same as that sent. The Validate an Issuer Public Key Certificate command
also allows the Issuer SK (stored when the Issuer Keyset was generated) to be
submitted so that a cryptographic check of consistency between the two can be
made. The Visa variant of this command also allows the Visa Detached
Signature to be validated. At any stage in the future the authenticity of the CA
PK(s) and the Issuer PK(s) can be verified using the Verify MAC on PK
command. The Issuer Certificate(s) may also be verified at any time by using the
Validate an Issuer Public Key Certificate command again.
The appropriate stored Issuer Certificates will be placed on each card issued to
enable the terminals to perform Static Data Authentication or Dynamic Data
Authentication on the card data.
During the card issuing process it is necessary to have available the appropriate
Issuer Private Key (SK) within the HSM. It may be held (in encrypted form) on
the host database and sent to the HSM every time it is used. Alternatively, to
save on communication time, it may be pre-loaded into each HSM requiring it
using the Load Private Key command. It is the responsibility of the host
application to keep track of the SK loaded at any time. Different HSM
configurations can store a different number of SK(s) simultaneously. In this case
the stored SK is referenced by a Key Index number.
At infrequent intervals it is normal to change the Local Master Keys (LMKs) of
the HSMs. When this happens it is necessary to translate all keys encrypted
under the old LMKs to encryption under the new LMKs. The Private Key(s) can
be translated using the Translate SK command. The MACs protecting the Public
Key(s) can be translated using the Translate MAC on PK command.
An additional RSA Private key import/export function is also provided for flexibility.
Available Commands
Command Page
Generate Issuer RSA Key Set (Visa) 35
Generate Issuer RSA Key Set (MCI) 38
Validate a Certification Authority Self-Signed Certificate 40

(Visa)
Validate a Certification Authority Self-Signed Certificate 42

(MCI)
Validate an Issuer Public Key Certificate (Visa) 44
Validate an Issuer Public Key Certificate (MCI) 47
Import or Export an encrypted RSA Private Key 49

>> Host Commands
Generate Issuer RSA Key Set (Visa)
Licence HSM9-LIC002.
Authorization: Required
Activity: command.IU.host
Function: To generate an Issuer RSA Key Set and return the Public Key in the form
of a Visa -style EMV Self-Signed Certificate. This function is suitable for use
with Visa Cash (Public Key variant) and the Visa Smart Debit Credit (VSDC)
scheme.
State: Online
Notes: Depending on key size, this function may take a long time to execute (up to
a minute or more). If an even Public Exponent is supplied, then an error
will be returned by the HSM and no processing will take place.
If the function is being used to generate keys for use with Visa Cash (Public
Key), the Signature Identifier must be set to 03 (meaning RSA with a public
exponent of 65537), the first byte of the 11 byte Data Block must be hex
60 (Visa Service Identifier = Visa Cash) and if the public exponent field is
supplied, it is ignored.
COMMAND MESSAGE
Command Code 2A Value “IU”
Hash Identifier 2N Identifier of algorithm used to hash data.

Valid values
01 SHA-1
Signature Identifier 2N Identifier of signature algorithm.
Valid values
01 RSA
03 RSA with exponent 65535
Must be 03 for Visa Cash.
Key Length 4N Modulus length in bits (must be a multiple of 8)
minimum value = 0400, maximum value = 2040
Data Block 11 B Data block to be included in the self-signed certificate (comprises Visa
Service Identifier, Certificate Format, Issuer Identification Number and
Certificate Expiration Date) See Appendix E.
Tracking Number 3D 6 digit tracking number to be included in the self-signed certificate.

See Appendix E.

>> Host Commands
Authentication Data nA Optional; additional data to be included in the MAC calculation (must
not include “;”)
Delimiter 1A Delimiter to indicate end of Authentication Data field; value “;”
Public Exponent Length 4N Optional; length in bits of the Public Exponent; must be supplied if
Public Exponent present in command message
Public Exponent nB Optional; if supplied then it must be odd; if not supplied then a default
exponent of 65537 is assumed
5End message delimiter 1C Must be present if a message trailer is present. Value X'19.

RESPONSE MESSAGE
Response Code 2A Value 'IV'.
Error Code 2N 00 - No error

02 - Key length error
13 - LMK error - report to Supervisor

15 - Error in input data
17 - HSM not in Authorised State

47 - DSP error - report to Supervisor
50 - Invalid signature identifier

51 - Inconsistent Signature Identifier
52 - Public exponent length error
53 - Public exponent is even

79 - Invalid hash identifier
MAC 4B MAC on Public Key and Authentication data calculated using of LMK
pair 36-37
Public Key nB Public Key, DER encoded in ASN.1 format (sequence of modulus and
exponent)
Certificate Length 4N Length in bytes of Self-Signed Certificate
Self-Signed Certificate nB Self -signed certificate (the concatenation of the

Unsigned Issuer Public Key Input Extension and the Self-Signed Issuer
Public Key Data). See APPENDIX F.
Hash Length 2N Length in hex characters of hash result in next field. This length will
depend on the hash algorithm specified in the command message. For
SHA-1, this length will be 40.
Hash Value nH Hash value of self signed Issuer Public Key data
>> Host Commands
Private Key Length 4N Length (in bytes) of the Private Key field
Private Key nB Private key, encrypted using LMK pair 34-35
characters.

>> Host Commands
Generate Issuer RSA Key Set (MCI)
Activity: command.JM.host
Function: To generate an Issuer RSA Key Set and return the Public Key in the form
of a MasterCard/Europay-format Self-Signed Issuer Public Key Certificate.
State: Online
Notes: Depending on key size, this function may take up to a minute or more to
execute. This command may be used with an odd Public Exponent.
This command uses the “Europay” method of generating key pairs.
COMMAND MESSAGE
Command Code 2A Value “JM”
Valid values
01 SHA-1
Signature Identifier 2N Identifier of signature algorithm.

Valid values
01 RSA
Key Length 4N Modulus length in bits (must be a multiple of 8)
minimum value = 0400, maximum value = 2040
Data Block 9B Data block to be included in the Self-Signed Certificate (comprises

Certificate Subject ID (4 bytes), Expiry Date (2 bytes) and Certificate
Serial Number (3 bytes)). See APPENDIX K.
Issuer Public Key Index 3B Issuer Public Key Index. See APPENDIX K.
Delimiter 1A Delimiter to indicate end of Authentication Data field; value “;”
Public Exponent Length 4N Optional; length in bits of the Public Exponent; must be supplied if
Public Exponent present in command message
Public Exponent nB Optional; if supplied then it must be odd; if not supplied then a default
exponent of 65537 is assumed
>> Host Commands


RESPONSE MESSAGE
Response Code 2A Value 'JN'.
02 - Key length error
08 - Invalid public exponent

13 - LMK error – report to Supervisor

47 - DSP error – report to Supervisor

50 - Invalid signature identifier
79 - Invalid hash identifier
MAC 4B MAC on Public Key and Authentication Data calculated using LMK 36-
37
exponent)
Certificate Length 4N Length in bytes of Self-Signed Certificate
Self-Signed Issuer nB Self-Signed Issuer Public Key Certificate (the concatenation of the Clear
Public Key Certificate Data and the Self-Signed Certificate). See APPENDIX K.
Hash Value nH Hash value of self signed Issuer Public Key data
Private Key Length 4N Length (in bytes) of the Private Key field
Private Key nB Private Key, encrypted using LMK pair 34-35
characters.

>> Host Commands
Validate a Certification Authority Self-
Signed Certificate (Visa)
Activity: command.IW.host
Function: To validate a Visa format Self-signed Certification Authority (CA) certificate.
State: Online
Notes:
COMMAND MESSAGE
Command Code 2A Value “IW”
Certificate Length 4N Length (in bytes) of CA Self-Signed Certificate
CA Self-Signed nB CA self-signed certificate (concatenation of Unsigned Visa CA Public

Key Output Extension and Self-Signed Visa CA Public Key Data). See
Certificate APPENDIX E.
Delimiter 1A Delimiter, value “;”

RESPONSE MESSAGE
Response Code 2A Value 'IX'.

>> Host Commands

51 - Hash validation failure (unsigned)
52 - Hash validation failure (self-signed)
79 - Invalid hash algorithm

80 - Certificate length error
81 - Invalid Certificate Format
MAC 4B MAC on Public Key and Authentication Data, calculated using of LMK pair
36-37
Public Key nB Public key, DER encoded in ASN.1 format
(sequence of modulus, exponent)
Expiration Date 2D The Certificate Expiration Date (MMYY) recovered from the certificate.
characters.

>> Host Commands
Validate a Certification Authority Self-
Signed Certificate (MCI)
Activity: command.JO.host
Function: To validate a MasterCard/Europay-style Self-Signed Certification Authority

(CA) Certificate.
State: Online
Notes:
COMMAND MESSAGE
Command Code 2A Value “JO”
Certificate Length 4N Length (in bytes) of CA Self-Signed Certificate
CA Self-Signed nB CA Self-Signed Certificate (concatenation of the Clear Data and the

Self-Signed Certificate). See APPENDIX J.
Certificate
Delimiter 1A Delimiter, value “;”

RESPONSE MESSAGE
Response Code 2A Value 'JP'.
08 - Invalid public key


>> Host Commands

50 - Invalid trailer
51 - Invalid certificate format

52 - Invalid subject ID
54 - Invalid public key data

55 - Invalid public key algorithm indicator
56 - Hash validation failure


81 - Invalid header
MAC 4B MAC on Public Key and Authentication Data, calculated using LMK 36-37
Public Key nB Public key, DER encoded in ASN.1 format
Hash Length 2N Length in hex of hash results in next field. This length will depend on
the hash algorithm specified in the command message. For SHA-1,
this length will be 40.
Hash Value nH Hash value of self signed CA Public Key data
Expiry Date 2D The Certificate Expiry Date (MMYY) recovered from the certificate.
Certificate Serial 3B The Certificate Serial Number recovered from the certificate
Number
characters.

>> Host Commands
Validate an Issuer Public Key Certificate
(Visa)
Activity: command.IY.host
Function: To validate an Issuer public key certificate and return the Public Key with its
associated MAC.
State: Online
Notes: To validate an Issuer public key certificate and return the Public Key with its
associated MAC.
COMMAND MESSAGE
Command Code 2A Value “IY”
MAC 4B MAC on CA Public Key and Authentication Data, calculated using of LMK
pair 36-37
CA Public Key nB CA Public key, DER encoded in ASN.1 format

(sequence of modulus, exponent).
CA Authentication Data nA Optional; additional data to be included in the MAC calculation over the
CA public key (must not include “;”)
Delimiter 1A Delimiter to indicate end of authentication data field; value “;”
Certificate Length 4N Length (in bytes) of the Issuer Certificate
Public Key Certificate 4N Offset to start of Issuer Public Key Certificate within the Issuer
Offset Certificate
Issuer Certificate nB Issuer certificate, comprising the Unsigned Issuer Public Key Output
Extension and the Issuer Public Key Certificate (See APPENDIX G)
Delimiter 1A Delimiter to indicate end of Issuer Certificate field; value “;”
Issuer Authentication nA Optional; additional data to be included in the MAC calculation over the
Data Issuer Public Key (must not include “;”)
Delimiter 1A Delimiter, to indicate end of Authentication Data field; value “;”. Note: this
is a mandatory field.
Private Key Length 4N Optional; length (in bytes) of the Private Key (must be present if Private
key field is present)
Private Key nB Optional; Private key, encrypted using LMK pair 34-35
>> Host Commands
Delimiter 1A Delimiter, to indicate end of Private Key field; value “;”. Note: this is a
mandatory field.
Detached Signature 4N Optional; length in bytes of Detached Signature field

Length
Detached Signature nB Optional; Detached Signature created by signing the combined certificate
data with the CA Private key.

RESPONSE MESSAGE
Response Code 2A Value 'IZ'.
01 - MAC verification failure

03 - Invalid Certificate Extension Format

04 - CA PK does not conform to encoding rules
09 - Inconsistent Signature Identifier


49 - Private key error - report to Supervisor
75 - Invalid public key / Private key pair

76 - Public key length error
77 - Detached Signature error - bad format

78 - Private key length error
79 - Detached Signature error - bad Object ID

81 - Detached Signature length error
82 - Invalid Public Key Certificate

83 - Detached Signature error
MAC 4B MAC on Issuer Public Key and Authentication Data, calculated using LMK
pair 36-37
Issuer Public Key nB Issuer Public key, DER encoded in ASN.1 format

>> Host Commands

SHA-1 this length will be 40
Hash Value nH Hash Value calculated over Issuer Public Key and related data (see
APPENDIX G).
characters.
>> Host Commands
Validate an Issuer Public Key Certificate
(MCI)
Function: To validate an Issuer public key certificate and return the Public Key with its
associated MAC.
State: Online
Notes:
COMMAND MESSAGE
Command Code 2A Value “JQ”
MAC 4B MAC on CA Public Key and Authentication Data, calculated using LMK
pair 36-37
CA Public Key nB CA Public key, DER encoded in ASN.1 format

(Sequence of modulus, exponent).
CA Authentication Data nA Optional; additional data to be included in the MAC calculation over the
CA public key (must not include “;”)
Delimiter 1A Delimiter to indicate end of authentication data field; value “;”
Certificate Length 4N Length (in bytes) of the Issuer Certificate
Public Key Certificate 4N Offset to start of Issuer Public Key Certificate within the Issuer
Offset Certificate
Issuer Certificate nB Issuer Certificate, comprising the Clear Data and the Issuer Public Key
Certificate (See APPENDIX L)
Delimiter 1A Delimiter to indicate end of Issuer Certificate field; value “;”
Issuer Authentication nA Optional; additional data to be included in the MAC calculation over the
Data Issuer Public Key (must not include “;”)
Delimiter 1A Delimiter, to indicate end of Authentication Data field; value “;”
Private Key Length 4N Optional; length (in bytes) of the Private Key (must be present if Private
Key field is present)
Private Key nB Optional; Private Key, encrypted using LMK pair 34-35

>> Host Commands


RESPONSE MESSAGE
Response Code 2A Value 'JR'.

04 - CA PK does not conform to encoding rules

06 - Invalid public key algorithm indicator

47 - DSP error – report to Supervisor

49 - Private Key error – report to Supervisor
75 - Invalid public key / Private Key pair

76 - Public key length error
78 - Private Key length error

81 - Invalid header
82 - Invalid trailer
83 - Invalid certificate format
84 - Invalid subject ID
MAC 4B MAC on Issuer Public Key and Authentication Data, calculated using LMK
36-37
Issuer Public Key nB Issuer Public key, DER encoded in ASN.1 format
Hash Value nH Hash value of Issuer Public Key data
Expiry Date 2D The Certificate Expiry Date (MMYY) recovered from the certificate.
Certificate Serial 3B The Certificate Serial Number recovered from the certificate
Number
characters.
>> Host Commands
Import or Export an encrypted RSA Private
Key
Activity: command.YA.host
Function: To import or export the five components that make up a RSA private key
(P, Q, D1, D2, Q-1 mod P) in a format suitable for P3.
State: Online
Notes: The external key is ASN.1 encoded and encrypted under a double length
ZMK using CBC encryption. The command expects Q-1 mod P as the final
parameter, not the alternative P-1 mod Q.
The private key components must be a multiple of 8 bits (e.g. 1024 bits
and 1032 bits are valid, however any values in between are not valid)
COMMAND MESSAGE
Command Code 2A Value “YA”
ZMK 32 H or 1A+32H Zone Master Key, encrypted under LMK pair 04-05
or 1A+48H
Mode Flag 2N 00 = RSA Private Key Import

01 = RSA Private Key Export
Input Private Key 4N Length in bytes of the following field

Length
Input Private Key nB If Mode Flag = 00:
ASN.1 encoded private key, padded with nulls to a multiple of 8 bytes and
encrypted under the ZMK using the CBC mode of DES with a zero IV. See
APPENDIX AA.
If Mode Flag = 01:
Private Key encrypted under LMK pair 34-35

>> Host Commands

RESPONSE MESSAGE
Response Code 2A Value 'YB'.
Error Code 2N 00 : No error

10 – ZMK parity error
12 – No keys loaded in user storage
13 – LMK error - report to Supervisor
15 – Error in input data

17 – Not in Authorised State
21 – Invalid user storage index
50 – Private Key does not conform to encoding rules

51 – Private key modulus is not a multiple of 8 bits
80 – Private Key length error
81 – Invalid mode flag

Private Key Length 4n Length of following field
Private Key nH If Mode Flag = 00:

Private Key encrypted under LMK pair 34-35
If Mode Flag = 01:

ASN.1 encoded private key, padded with nulls to a multiple of 8 bytes and
encrypted under the ZMK using the CBC mode of DES with a zero IV. See
APPENDIX AA.
characters.
>> Host Commands
Key Management Commands
Master DES key set-up commands for VSDC and Visa Cash
Use Base commands for Generating exporting and importing
There are three separate DES Master Keys required to support the VSDC scheme.
The UKIS specification calls for a subset of two of these keys. Visa Cash calls for
two DES Master Keys. These functions also support Master Keys for the Visa Easy
Entry and Dedicated Funding Account applications. These keys are all double length
keys but are referred to as two separate single length keys in this specification.
They are:
Derivation Master Key for Application Cryptograms (DMKA AC and DMKBAC) used
to derive the Unique DES Key or Keys for Application Cryptograms (UDKA AC and
UDKBAC) which are placed on each card and used to generate or validate the
ARQC/ARPC/TC/AAC.
Derivation Master Key for Message Authentication Codes (DMKA MAC and
DMKBMAC) used to derive the Unique DES Key or Keys for MACs (UDKA MAC and
UDKBMAC) which are placed on each card and used to produce the MAC session
keys for secure messaging.
Derivation Master Key for Encryption (DMKAENC and DMKBENC) used to derive
the Unique DES Key or Keys for Encryption (UDKA ENC and UDKBENC) which are
placed on each card and used to produce Encryption session keys for secure
messaging.
Master Update Key (KMUA and KMUB) used to produce the double length
Derived Update Key (KDU), which is installed onto a card and used during the
card update process.
Master Load Key (KMLA and KMLB) used to produce the double length Derived
Load Key (KDL), which is installed onto the card and used during the funds
reload process.
The set-up commands are provided in two forms, as HSM Console Commands and
as Host Commands. HSM Console Commands allow the keys to be set up with no
intervention by the host system. The HSM provides a simple terminal dialogue with
the user resulting in the appropriate key being displayed encrypted under the HSM’s
Local Master Key. The host must allow this encrypted key to be entered manually
and stored in the key database. The Host Commands allow the keys to be setup
under the control of the host system.
The Master keys may either be generated by the HSM and translated to encryption
under a Zone Control Master Key (ZCMK) for export to other systems, or Imported
from another system under a ZCMK and translated to encryption under an LMK for
local storage.
The terms KEYA and KEYB is used to describe the left half (KEYA) and right half
(KEYB) of any one of the keys identified above. The term KEYAB refers to the
concatenation of KEYA and KEYB to form a double length key.
Key Check Values (KCV) are also produced by the functions described. A KCV is the
result of encrypting a block of zeros with the key. The 64 bit result is expressed as
6 hexadecimal digits.

>> Host Commands
Three KCVs are produced for each double length key:

a) A KCV for the left half of the key (ie KEYA), called KCVA.
b) A KCV for the right half of the key (ie KEYB), called KCVB.
c) A KCV for the complete double length key (KEYAB). This is produced by
encrypting a block of zeros with the left half of the key (KEYA), followed by
decryption using the right half of the key (KEYB), followed by encryption using
the left half of the key (KEYA) again. This is called KCVAB.
The key management functions in this specification all use double length Zone
Control Master Keys (ZCMKs). Accordingly the HSM should be configured to use
double length zone master keys using the CS console command. This will ensure
that when zone master keys are generated or installed, double length keys are
used.
Master DES key set-up commands for M/Chip Lite and M/Chip
Select
Use Base commands for Generating exporting and importing
There are five separate Issuer Master Keys required to support the
MasterCard/Europay chip credit/debit schemes M/Chip Lite and M/Chip Select.
These are:
Issuer Master Key for Application Cryptograms (IMKAC) used to derive the ICC
Master Key for Application Cryptograms (MKAC) which are placed on each card
and used to generate or validate the ARQC/ARPC/TC/AAC.
Issuer Master Key for Secure Message MACing (IMKSMM) used to derive the ICC
Derived Keys for Secure Message MACing (IDKSMM) which are placed on each
card and used to produce the MAC session keys for secure messaging.
Issuer Master Key for Secure Message Encryption (IMKSME) used to derive the
ICC Derived Keys for Secure Message Encryption (MKSME) which are placed on
each card and used to produce Encryption session keys for secure messaging.
Issuer Master Key for Data Authentication Code Generation (IMK DAC) used to
generate the Data Authentication Code (DAC) used as part of the Static Data
Authentication process. It is not always used.
Issuer Master Key for Dynamic Number Generation (IMKIDN) used to derive the
ICC Derived Key for Dynamic Number Generation (MKIDN) which are placed on
each card and used to generate Dynamic Numbers. This is part of the Dynamic
Data Authentication Scheme. It is not always used.
These functions allow for the management of a Transport Key and a Zone PIN Key
(ZPK) which is used to encrypt a PIN while in transit from Issuer to P3.
The set-up commands are provided in two forms, as HSM Console Commands and
as a single Host Command. HSM Console Commands allow the keys to be set up
with no intervention by the host system. The HSM provides a simple terminal
dialogue with the user resulting in the appropriate key being displayed encrypted
under the HSM’s Local Master Key. The host must allow this encrypted key to be
entered manually and stored in the key database. The Host Commands allow the
keys to be set up under the control of the host system.
>> Host Commands
The Master Keys, ZPK and the Transport Key may either be generated by the HSM
and translated to encryption under a Zone Control Master Key (ZCMK) for export to
other systems, or imported from another system under a ZCMK and translated to
encryption under an LMK for local storage.
Key Check Values (KCV) are also produced by the functions described. A KCV is the
result of encrypting a block of zeros with the key. The 64 bit result is expressed as
16 hexadecimal digits.
Control Master Keys (ZCMKs). Accordingly the HSM should be configured to use
double length zone master keys using the CS console command. This will ensure
that when Zone Master Keys are generated or installed, double length keys are
used.

>> Host Commands
Card Issuing Commands for VSDC or UKIS

The cryptographic functions required in order to issue a card containing the VSDC
or UKIS application are:
Generate the UDKs for Application Cryptograms (AC), UDKA AC and UDKBAC
Generate the UDKs for Message Authentication Codes (MAC) UDKA MAC and
UDKBMAC
Generate the UDKs for Message Encryption UDKA ENC and UDKBENC
(All the above keys are generated in a single call to the HSM)
Generate an RSA signature over certain card data
The functions to perform these tasks (together with some others which may be
found useful during system testing) are given in the following subsections.
Note:
The function to generate UDKs each have a UDK Modification Flag and UDK
Modification Field parameters included. This is to allow for future extensions to the
standards. They are not required for the current versions of VSDC and UKIS. If the
Modification field is used, it is the responsibility of the host application to ensure
that, in systems where only a single length UDK is employed, both halves of the
Modification field are identical.
Available Commands
Command Page
Generate Card Unique DES Keys 55
Generate Static Data Authentication Signature 58

>> Host Commands
Generate Card Unique DES Keys
Function: Used by Issuer to produce the UDKs to be loaded onto the card. Since
these keys need to be transported to the card personalisation system, they
are supplied encrypted under a previously defined double length Key
Exchange Key (KEK). This function generates UDKAC, UDKMAC and
optionally, UDKENC
State: Online
Notes:
COMMAND MESSAGE
Command Code 2A Value “HI”
KEK(LMK) 32 H or 1A+32H KEK encrypted under Variant 1 of LMK pair 24-25

or 1A+48H
PAN/PAN Sequence 8B PAN and PAN Sequence Number pre-formatted into 8 byte field
No
DMKAC (LMK) 32 H or 1A+32H DMKAC encrypted under Variant 1 of LMK pair 28-29.
or 1A+48H
UDKAC Modification Flag 1N Flag indicating presence (1) or absence (0) of UDKAC Modification Field
to follow.
UDKAC Modification 16 B UDKAC Modification Field. Only supplied if UDKAC Modification Flag is set
Field to 1
DMKMAC(LMK) 1N Flag indicating presence (1) or absence (0) of DMKMAC(LMK).

Modification Flag Modification Fields to follow.
DMKAMAC (LMK) 16 H DMKAMAC encrypted under Variant 2 of LMK pair 28-29.
DMKBMAC(LMK) 16 H DMKBMAC encrypted under Variant 2 of LMK pair 28-29.
UDKMAC Modification 1N Flag indicating presence (1) or absence (0) of UDKMAC Modification
Flag Field to follow.
UDKMAC Modification 16 B UDKMAC Modification Field. Only supplied if UDKMAC Modification Flag is
Field set to 1.

>> Host Commands
Control Flag 1N Flag to control output values produced by this command. The following
values apply:
0 = No Encryption UDKs and single length KCVs

1 = Encryption Keys and single length KCVs
2 = No Encryption UDKs and double length KCVs

3 = Encryption keys and double length KCVs
DMKAENC(LMK) 16 H DMKAENC encrypted under Variant 3 of LMK pair 28-29. Only present
if Control Flag = 1 or 3
DMKBENC (LMK) 16 H DMKBENC encrypted under Variant 3 of LMK pair 28-29. Only present if
Control Flag = 1 or 3
UDKENC Modification 1N Flag indicating presence (1) or absence (0) of UDKENC Modification
Flag Field to follow. Only present if Control Flag =1 or 3
UDKENC Modification 16 B UDKENC Modification Field Only present if Control Flag = 1 or 3, and
Field UDKENC Modification Flag (above ) = 1

RESPONSE MESSAGE
Response Code 2A Value 'HJ'.

08 - Parity error on KEK
09 - Parity error on DMKAC

10 - Parity error on DMKMAC
11 - Parity error on DMKENC
12 - No keys in user storage

13 - LMK error - report to supervisor

21 - Invalid user storage index
50 - Invalid UDKAC Modification Flag
51 - Invalid UDKMAC Modification Flag

52 - Invalid UDKENC Modification Flag
53 - Invalid Control Flag

UDKAAC(KEK) 8B UDKAAC encrypted under KEK
UDKBAC(KEK) 8B UDKBAC encrypted under KEK
KCVAAC 8B Key Check Value for UDKAAC if Control Flag is 0 or 1. Set to zeros if
>> Host Commands

Control Flag is 2 or 3.
KCVB AC 8B Key Check Value for UDKBAC if Control Flag is 0 or 1. Key Check Value for
UDKAAC and UDKBAC if Control Flag is 2 or 3.
UDKAMAC(KEK) 8B UDKAMAC encrypted under KEK. Only present if DMKMAC(LMK)

Modification Flag is set to 1.
UDKBMAC(KEK) 8B UDKBMAC encrypted under KEK. Only present if DMKMAC (LMK)

Modification Flag is set to 1.
KCVAMAC 8B Key Check Value for UDKAMAC if Control Flag is 0 or 1. Set to zeros if
Control Flag is 2 or 3. Only present if DMKMAC(LMK) Modification Flag
is set to 1.
KCVBMAC 8B Key Check Value for UDKBMAC if Control Flag is 0 or 1. Key Check Value
for UDKAMAC and UDKBMAC if Control Flag is 2 or 3. Only present if
DMKMAC(LMK) Modification Flag is set to 1.
UDKAENC(KEK) 8B Field only present if Control Flag = 1 or 3. UDKA ENC encrypted under
KEK.
UDKBENC(KEK) 8B Field only present if Control Flag = 1 or 3. UDKBENC encrypted under

KEK.
KCVAENC 8B Field only present if Control Flag is 1 or 3. Key Check Value for UDKAENC if
Control Flag is 1. Set to zeros if Control Flag is 3.
KCVBENC 8B Field only present if Control Flag is 1 or 3. Key Check Value for UDKBENC if
Control Flag is 1. Key Check Value for UDKAENC and UDKBENC if Control
Flag is 3.
characters.

>> Host Commands
Generate Static Data Authentication
Signature
Function: To sign card data using the Issuer’s Private Key. Automatic DAC
generation is provided as an option (used by MasterCard/Europay
schemes)
State: Online
Notes:
COMMAND MESSAGE
Command Code 2A Value “HK”

Valid values
01 SHA-1
02 MD5
03 ISO 10118-2
04 No hash
Data Authentication 2B Data authentication code. A value must always be supplied but it will be
Code ignored if the optional parameters at the end are supplied in which
case the DAC is calculated.
Data Length 4N Length of Static Authentication Data field
Static Authentication nB Static authentication data

Data
Delimiter 1A Delimiter; indicates end of Static Authentication Data field; value “;”
Private Key Flag 2N Flag to indicate location of the Private key;

if flag = 99 use Private key provided with command
else flag = index of stored Private key
Private Key Length 4N Length (in bytes) of the Private Key (only present if flag = 99)
Private Key nB Private key, encrypted using LMK pair 34-35 (only present if flag = 99)
Delimiter 1A Optional Delimiter; Value “;”. Indicates the presence of the following 2
fields which allow a DAC to be calculated.
PAN/PSN 8B Optional, only present if the optional Delimiter field is present. PAN and
PAN Sequence number pre-formatted into an 8 byte field.
>> Host Commands
IMKDAC (LMK) 32 H or 1A+32H Optional, only present if the optional Delimiter field is present. Issuer
or 1A+48H Master Key for Data Authentication Code, encrypted under Variant 6 of
LMK 28-29.

RESPONSE MESSAGE
Response Code 2A Value 'HL’.
10 – Parity error on IMKDAC

13 – LMK error – report to Supervisor

47 – DSP error – report to Supervisor
49 – Private key error – report to Supervisor
50 – Invalid Private key flag

78 – Private key length error
79 – Invalid hash identifier

80 – Data length error
Signature Length 4N Length (in bytes) of the signature
Signature nB Calculated signature
characters.

>> Host Commands
Generic Card Issuing Commands for M/Chip Lite, M/Chip

Select, & Generic MULTOS Applications
The cryptographic functions required in order to issue a M/Chip Lite cards or a
Multos card containing M/Chip Select are:
a) Generate the following and return encrypted under an LMK:
ICC Derived Key for Application Cryptograms, IDKAC
ICC Derived Key for Secure Message MACing, IDKSMM
ICC Derived Key for Secure Message Encryption, IDKSME.
ICC Derived Key for producing ICC Dynamic Numbers (part of the Dynamic
Data Authentication scheme), IDKIDN
All the above keys are generated in a single call to the HSM although the
generation of IDKIDN is optional. This functions allows all the (DES) Derived
Keys to be generated in readiness for ALU generation (M/Chip Select on
MULTOS cards) or for passing to the Personalisation System (M/Chip Lite
cards). They are all returned either encrypted under a Local Master Key for
temporary storage (M/Chip Select on MULTOS cards) or encrypted under a
KEK (M/Chip Lite cards).
b) Generate ICC Keyset (M/Chip Select/MULTOS only).
c) Generate all ICC Public Key data. (M/Chip Select/Multos only)
Create ICC Public Key Certificate. This takes the ICC Public key in its standard
HSM format and creates three separate data elements; the ICC Certificate, the
ICC Public Key Remainder, and the ICC Public Key Exponent. None of these are
encrypted.
d) Generate Static Data Authentication Signature. This is the same function as
used for VSDC (see VSDC section, HK command) although in this case it will be
used with the optional feature to generate its own DAC rather than use the one
supplied.
e) PIN Translate (M/Chip Select/Multos only). This function takes an encrypted
PIN block as produced by the Issuer (in the format specified by MasterCard) and
translates it to a format required for ALU generation and encrypts it under an
LMK for temporary local storage.
The following commands relate to the generation of Multos ALUs for any
application:
a) Import Hash Modulus. The Hash Modulus is supplied by the Multos CA and is
used to hash the AU prior to generating the Multos Application Signature.
b) Generate KTU. This function takes the sensitive data elements of the AU
(Derived keys, ICC Private Key, PIN), combines them, encrypts them and builds a
modified KTU (KTU’) referring to the encrypted elements. It also generates a
checksum over certain sensitive elements.
c) Hash Data. This function implements the asymmetric hash algorithm used in
Multos as the first stage producing the Application Signature. It uses a
>> Host Commands
previously imported Hash Modulus. It allows data greater than the HSM buffer
size to be hashed by providing a chaining capability.
d) Generate Application Signature. This function produces the Multos Application
Signature by signing (previously hashed data) using the Application Signature
Private Key.
e) Translate a modified Key Transport Unit (KTU’) to a standard Multos KTU
format. The KTU’ will be encrypted with a double length DES key, whilst the KTU
will be encrypted with an RSA public key, specific to the Multos card being
personalised.
f) Import a Multos Certification Authority RSA public key and translate it to ASN.1
DER encoded format.
MULTOS TERMINOLOGY
The following Multos terminology may help the reader’s understanding of the
commands specified in this document.
Nomenclature Meaning
mkd_pk_c Multos smart card public key certificate
tkpk_ck Multos Certification Authority public key
FURTHER DISCUSSION ON GENERIC ALU GENERATION IN THE HSM

Multos cards support the loading of one or more applications. Each application is
comprised of a number of elements:
The Application Unit (AU) – this is the code, data and other relevant parts of the
application. Some parts of the code or data may be encrypted using key contained
in the KTU (see below).
The Application Signature – produced by hashing and signing the AU using the
Application Provider Private key. The card is able to check the signature because
there is a corresponding Application Load Certificate which is placed on the card
at the same time as the ALU. The ALC contains the Application Provider’s public
key, signed by the Multos CA private key. The card first verifies the authenticity of
the ALC (using the CA public key already on the card), and then using the
Application Provider’s public key, verifies the Application Signature.
The Key Transformation Unit (KTU) – this carries one or more Area Descriptors
(AD). Each AD defines a portion of the AU which is encrypted and the DES key that
was used to encrypt it. The whole KTU is eventually encrypted using the public key
of the destination card. However at the time it is first generated the destination
card’s public key is not known so it is encrypted under a KEK shared with the
personalisation system. It is known as a KTU’ (KTU prime) at this stage. At the
personalisation system, the card’s public key is located and the KTU’ is translated
to a the real KTU (decrypting from under the KEK and re-encrypting under the
public key of the card.

>> Host Commands
The purpose of the functionality described sections in this specification is to allow a

host system to build sections the AU (the parts which contain sensitive data) from a
series of plain text and cipher text components, calculate a checksum over specified
parts of the data, and encrypt the whole section. The same functionality can also be
used to build a KTU’. This functionality must be carried out inside an HSM since the
sensitive data may be keys and PINs which must never be exposed outside a tamper
resistant enclosure.
The basic concepts are:
1. The host handles all parts of the AU except those sections which contain
sensitive data. These sections must eventually be encrypted and the details of
each such section contained as an Area Descriptor in the KTU’.
2. The sensitive sections are constructed inside an HSM by loading a series of
basic elements into a dedicated buffer area. Some elements of these sensitive
sections are not encrypted and so are loaded as plaintext. Other elements are
loaded as cipher text but the HSM decrypts them before inserting the data into
the buffer.
3. A checksum may be calculated over parts of the sensitive area. This checksum
is always calculated over the plaintext data in the buffer. The result is returned
to the host and may subsequently be loaded back into another part of the
buffer.
4. A random key can be generated and returned to the host (encrypted under a
local master key)
5. Data in the buffer can only be extracted from the HSM after it has been
encrypted using a previously generated random key. The data may have to be
retrieved from the HSM in a series of blocks which must be smaller than the
HSM’s communications buffer size.
There are a number of possible areas in the HSM where the buffer area may exist.
The best one is to use parts of the tamper protected memory where the Local Master
Keys are stored. Of the 2048m bytes of tamper protected RAM in the standard
HSM, the first 488 bytes are used for LMK storage. The next 488 bytes are used for
storage of an old LMK (but only on a temporary basis), the next 414 bytes are not
currently used, and the last 656 bytes may be used for storage of an RSA private key.
Provided the host ensures that no LMK translation activities are performed, and that
no RSA private key is stored in the HSM, 1560 bytes can be allocated in tamper
protected RAM. If this is insufficient, the whole 8K byes of memory allocated to the
User storage area can be used. This is not however tamper protected. It may be
considered acceptable to use this area in certain circumstances since at worst it
contains only the data for a single AU. To get at such data will require that the HSM is
stopped at the critical moment and broken into. It is unlikely that this can be achieved
without leaving evidence that this has happened. These size limitations are much less
of a problem in the high speed HSM and future models.
A special function is to be provided which allocates the memory to be used as the
buffer area. It will be allocated as follows in a standard model HSM:
Requests up to 414 bytes will use the unused part of tamper protected RAM
Requests from 415 to 902 bytes will use the “Old LMK” area and the unused area
Requests from 903 to 1560 bytes will use all tamper protected RAM except the
current LMK area
>> Host Commands
Requests from 1561 to 8192 bytes will use the User storage area.
The request function will return a status indication to indicate whether or not the
request has been satisfied from tamper protected memory.
Available Commands
Command Page
Translate a KTU 64
Generate Multos Application Signature 67
Hash Data Using Multos Asymmetric Hash Algorithm 69
Multos ALU Generator 72
Import Hash Modulus 78
Translate PIN 80
Construct all ICC Public Key related data elements 82
Generate ICC Public/Private Keyset 85
Generate ICC Derived Keys 88
Generate EMV2000 Session Keys 91
Import Multos CA Public Key 93

>> Host Commands
Translate a KTU
Activity: command.ZG.host
Function:
To translate a (modified) Key Transformation Unit (KTU’) from encryption
under a double length Key Encryption Key (KEK) to the standard Multos
format KTU, encrypted under an RSA public key.
State: Online
Notes:
If the length of the KTU’ is less than the length of the RSA public key
modulus, then random padding will be appended to the KTU’ prior to
encryption with the public key.
This command will handle public keys up to a modulus length of 2048 bits.
COMMAND MESSAGE
Command Code 2A Value “ZG”
KEK 32 H or 1A+32H KEK, encrypted under Variant 1 of LMK pair 24-25

or 1A+48H
Version Flag 1N Flag to indicate Multos version

Flag = 0 – Multos v3.0
Flag = 1 – Multos v4.0
Flag = 2 – Multos v4.0 with hash verification
KTU’ Length 3N Length in bytes of the next field
KTU’ nB Modified KTU’, encrypted under the KEK
Delimiter 1A Value “;”
mkd_pk_c Length 3N Length in bytes of the next field
mkd_pk_c nB Smart card Multos public key certificate (see APPENDIX CC (if Version
Flag = 0) or APPENDIX DD (if Version Flag = 1) for format)
MAC 4B MAC on tkck_pk and authentication data, calculated using LMK pair
36-37
tkck_pk nB Multos CA public key, DER encoded in ASN.1 format

>> Host Commands
Authentication Data nA Optional. Additional data included in the MAC calculation (must not
include “;”)
Delimiter 1A Value “;” (only present if Version Flag = 2)
HashModMAC 4B MAC on HashMod and authentication data, calculated using LMK 36-
37 (only present if Version Flag = 2)
HashMod nB Multos Hash Modulus, DER encoded in ASN.1 format (only present if
Version Flag = 2)
include “;” - only present if Version Flag = 2)
End Message Delimiter 1C Optional. Must be present if a message trailer is present. Value X'19

RESPONSE MESSAGE
Response Code 2A Value 'ZH'.

02 - KTU’ error
03 - Invalid version flag

04 - Public key does not conform to encoding rules
07 – Modulus length error

10 - KEK parity error
12 - No keys loaded in user storage


80 - KTU’ length error

81 - mkd_pk_c length error
82 – Incompatible lengths
83 - Invalid lengths
84 - Invalid CA public key length
85 – HashMod MAC verification failure

86 – Card Certificate validation failure
KTU Length 3N Length in bytes of the next field

>> Host Commands
KTU nB Standard Multos KTU, encrypted under the smart card RSA public key
characters.
>> Host Commands
Generate Multos Application Signature
Activity: command.ZI.host
Function: To generate a Multos Application Signature on a message using a Private

Key. If required this command adds random padding to the data to be
signed.
State: Online
Notes: It is the responsibility of the calling application to ensure that the message
data to be signed is numerically smaller than the Private key modulus. This
can be achieved by making sure that the most significant bit of the most
significant byte is cleared.
COMMAND MESSAGE
Command Code 2A Value “ZI”
Mode Flag 1N Mode of operation of this command. Only the value 0 is valid in this
version of the specification.
Private Key Flag 2N Flag to indicate location of the Private key;
if flag = 99 use Private key provided with command

else flag = index of stored Private key
Private Key Length 4N Length (in bytes) of the following field (only present if flag = 99)
Private Key nB Private key, encrypted using LMK pair 34-35 (only present if flag = 99)
Delimiter 1A Delimiter, to indicate end of Private Key field; value “;”
Data Length 4N Length of message data to be signed (in bytes)
Message Data nB Data to be signed

>> Host Commands

RESPONSE MESSAGE
Response Code 2A Value 'ZJ'.

03 – Invalid Private Key type
04 – Invalid Mode Flag
05 – Invalid Private Key Flag

49 – Private Key error – report to Supervisor

78 – Private Key length error
80 – Message length error
81 – Message too long for supplied Private Key

Signature Length 4N Length (in bytes) of the signature
Signature nB Calculated signature
characters.
>> Host Commands
Hash Data Using Multos Asymmetric Hash
Algorithm
Function: To perform the Multos Asymmetric Hash over supplied data.
State: Online
Notes: This command uses a value known as the Hash Modulus to perform the
hashing operation in conjunction with the exponent included within the DER
encoded Hash Modulus. The function expects to see this public key in the
normal format ie DER encoded in ASN.1 format. Another command is
provided to import this hash modulus which manipulates it into the format
required by this function.
This command may be called several times in succession if the size of the
input data length exceeds the HSM buffer size. In this case the Digest
output from the first call will be used at the Chain Value to the subsequent
call.
Note 1. The length of the Chain Value (or Digest), known as the
hash_chain_length is determined by the calling application. For current
versions of Multos the length is 16 or 20. The size of the Hash Modulus,
known as the hash_modulus_length determines the size of the data which
is processed at each iteration. This is 72, 96 or 128 in current versions
of Multos. This data consists of the Chain Value (from the previous
iteration) and the next hash_block_length bytes of data to be processed.
(hash_block_length = hash_modulus_length - hash_chain_length). Therefore
for current versions of Multos hash_block_length is 56 (for 72 modulus
length & 16 chain length) or 108 (for 128 modulus length & 20 chain
length). It is the responsibility of the calling application to ensure the
correct modulus length and chain length are specified in accordance with
Multos requirements.
Note 2. This command does not add any padding to the supplied data. It
therefore expects the data to be supplied as a multiple of
hash_block_length bytes. It the responsibility of the calling application to
add any padding in accordance with Multos requirements.
COMMAND MESSAGE
Command Code 2A Value “ZM”
Mode Flag 1N Flag to identify different modes of operation of this command. The only
defined value in this version of the command is 0.

>> Host Commands
MAC 4B MAC in the Public Key and Authentication Data calculated using LMK
pair 36-37.
Public Key nB Public Key, DER Encoded in ASN.1 format (sequence of modulus and
exponent)
Authentication Data nA Optional; additional data included in the MAC calculation (must not
include “;”)
Delimiter 1A Value “;”, delimiter for optional Authentication data.
hash_chain_length 2N Length of the Chain Value.
Chain Value nB Allows chaining of this command so that the output of one call can be
used as the Chain Value for the next call. In the case of the first or
only block of data being hashed, it is the calling application’s
responsibility to supply the required Initial Chain Value in this
parameter. For Multos this is a block containing bytes all set to X’55.
Terminator 1A Terminator for Chain Value field; value “;”.
Length of Data 5N Defines length in bytes of next field
Data nB Data to be hashed. It is the responsibility of the calling application to

supply data in multiples of hash_block_length bytes.

>> Host Commands

RESPONSE MESSAGE
Response Code 2A Value 'ZN'.

01 – MAC Validation failure
05 – Public Key does not conform to encoding rules
06 – Invalid hash_chain_length
07 – hash_chain_length inconsistent with supplied Chain Value
12 – No keys in user storage


80 – Data Length error
81 – Data supplied not a multiple of hash_block_length bytes long
Digest nB The hash value result for the supplied data using the supplied public key.
This is hash_chain_length bytes long.
characters.

>> Host Commands
Multos ALU Generator
Activity: command.ZO.host
Function: Operates as a Generic ALU and KTU’ generator. Multiple calls to this
function establish a memory area in the HSM, load it with a number of
plain text and cipher text blocks (the cipher text blocks are decrypted on
entry), possibly calculate a checksum or a hash, and finally encrypt and
output the data. The host is responsible for loading the appropriate data to
form either part of an ALU or a KTU. It is also the host’s responsibility to
ensure that no other commands are sent to the HSM which might corrupt
any data already loaded into the HSM’s memory.
State: Online
Notes:
COMMAND MESSAGE
Command Code 2A Value “ZO”
Sub Command Code 2H 01 – Allocate HSM memory block

02 – Load Plain Text data
03 – Load Cipher Text data
04 – Calculate checksum
05 – Generate and return random DES key
06 – Encrypt and return data

07 – Move data in HSM memory block
08 – Deallocate HSM memory block
09 – Calculate Hash
(Sub-command parameters dependent on Sub Command Code, as defined in the following sections)

>> Host Commands
Subcommand Code 01 – Allocate HSM memory block
Memory Block Size 2B Size of memory block required. If a memory block is already allocated, it
will be deallocated before a new one is allocated.
Initial fill value 1B Byte value to place in every byte of memory block
Sub Command Code 02 – Load Plaintext data
Block Offset 2B Indicates the offset from the start of the HSM’s allocated memory block
to start operating upon.
Data length 2B Length of next field
Data nB Data to load
Sub Command 03 – Load Ciphertext data
Ciphertext type 1B If no optional variant is supplied the Pin block uses LMK38/39 variant
9. If variant 9 is supplied in the optional field a different value is stored.
0x00 PIN Block encrypted under LMK pair 38-39 Variant 9 or other
variant as specified later.
0x01 Single length DES Key encrypted under LMK pair 38-39 Variant 9
or other variant as specified later.
0x02 Double length DES key EBC encrypted under LMK pair 38-39
Variant 9 or other variant as specified later.
0x03 RSA private key (HSM format) encrypted under LMK pair 38-39
Variant 9 or other variant as specified later.
0x04 Data ECB encrypted under LMK pair 38-39 variant 9.
Ciphertext length 2B Length of next field
- 0x0008 for PIN block

- variable but a multiple of 8 bytes for single length DES Keys
- variable but a multiple of 16 bytes for double length DES keys
- variable for RSA private key

- variable for Data but a multiple of 8 bytes
Ciphertext data nB Data to be decrypted and loaded into buffer. Encrypted under LMK 38-
39 Variant 9. In the case of an RSA private key the 5 CRT components
are concatenated together and loaded in the order dp, dq, p, q, q -1 mod
p as described in APPENDIX X. There is no padding between
components.
Delimiter 1B Value “;”, Optional, Only present when the Variant Override is present.
Variant Override 1H Optional. If supplied, this variant is used instead of Variant 9 in the
Ciphertext Type above.

>> Host Commands
Sub Command Code 04 – Calculate Checksum
Length 2B Number of bytes over which to calculate checksum. Minimum allowed is

a value of 8 representing an 8 byte length.
Checksum Method 1B 0x00 – Standard Multos checksum as defined in APPENDIX Q.
(no other values acceptable in this version of the specification)
Checksum IV 4B Initial value (or value so far) of Checksum
Sub Command Code 05 – Generate and return DES Key
Key Type 1B 0x01 = Single length DES key
0x02 = Double length DES key
Sub Command Code 06 – Encrypt and return data
Length 2B Number of bytes to encrypt and return. Must be a multiple of 8.
Encryption Method 1B 0x01 = Multos method (APPENDIX T)

0x02 = ECB encryption
0x03 = CBC encryption (triple DES CBC encryption is defined in

APPENDIX O) A default IV of ‘0’ is assumed.
0x04 = CBC encryption with supplied IV

0x05 = Multos encryption with supplied IV
Encryption Key Type 1B 0x01 = Single Length Random DES key encrypted under LMK pair 38-
39 variant 9.
0x02 = Double Length Random DES key encrypted under LMK pair 38-
39 variant 9 using ECB mode.
0x03 = KEK encrypted under LMK pair 24-25 variant 1 using ECB
mode.
Encryption Key 8 B or 16B 8B for single length DES key, 16B for double length DES key or KEK
IV 8B IV value - Only present if Encryption method = 0x04 or 0x05
Sub Command Code 07 – Move data
from which data is to be moved.
Length 2B Number of bytes to move starting from Block Offset.
New Block Offset 2B Indicates the offset from the start of the HSM’s allocated memory block
to which data is to be moved. Note that locations from which data in
moved are null filled
>> Host Commands
Sub Command Code 08 – Deallocate HSM memory block
(None)
Response for Mode Flag = 0

RESPONSE MESSAGE
Response Code 2A Value 'ZP’.
Key Area 256 B AU Key Area (encrypted under key in Area Descriptor 1 of KTU’)
PIN Area 8B AU PIN Area (encrypted under key in Area Descriptor 2 of KTU’). Only
present if PIN Block Present flag is set to 1.
KTU’ nB Always has Area Descriptor 1. Also has Area Descriptor 2 if PIN Block
Present Flag =1. The length will be the length requested in the input data.
The KTU’ is returned encrypted under the supplied KEK.
characters.
Response for Mode Flag = 1

RESPONSE MESSAGE
Response Code 2A Value 'ZP’.

59 – Invalid Checksum or Hash length requested
60 – Unknown sub command
61 – No available memory block of size requested
62 – No memory block allocated

63 – Memory access outside bounds of allocated buffer.
64 – Unknown Ciphertext type
65 – Error decrypting ciphertext
66 – Unknown Checksum method
67 – Unknown key type

68 – Unknown encryption method
69 – Length requested is not a multiple of 8 bytes

>> Host Commands

70 – Error decrypting key
71 – Length error
72 – Encrypted data length greater than 2048

73 – Unknown Hash method or Hash mode
(Sub-command response parameters dependent on Sub Command Code, as defined in the following sections)
characters.
Subcommand Code 01 – Allocate HSM memory block
(possible error codes: 61)
Memory Block Status

Flag 1B 0x01 = Memory allocated in Tamper Protected area
0x02 = Memory allocated in other area
Sub Command Code 02 – Load Plaintext data
(Possible error codes: 62, 63)
Number of bytes loaded 2B Total number of bytes loaded
Sub Command 03 – Load Ciphertext data
(Possible error codes: 62, 63, 64, 65)
Number of bytes loaded 2 Total number of bytes loaded
Sub Command Code 04 – Calculate Checksum
(Possible error codes: 59, 62, 63, 66 )
Checksum 4B The resultant Checksum
Sub Command Code 05 – Generate and return DES Key
(Possible error codes: 67)
Returned Random Key 8 B or 16 Randomly generated key encrypted under Variant 9 of LMK 38-39. For a
B double length key, it is returned encrypted using EBC mode.
>> Host Commands
Sub Command Code 06 – Encrypt and return data
(Possible error codes: 62, 63, 67, 68, 69, 72)
Length of Encrypted data 2B Length of next field
Encrypted data nB Returned data
Sub Command Code 07 – Move data
(None) (Possible error codes: 62, 63)
Sub Command Code 08 – Deallocate HSM memory block
(None) (Possible error codes: 62)

>> Host Commands
Import Hash Modulus
Activity: command.ZQ.host
Function: To import the Multos Hash Modulus and convert it into the form of a
standard HSM Public Key for local storage
State: Online
Notes:
COMMAND MESSAGE
Command Code 2A Value “ZQ”
Mode Flag 1N Flag to identify different modes of operation of this command. Only the
values 0 or 1 are valid for this version of the command.
Length of Hash 2H Length in bytes of next field

Modulus
Hash Modulus nB Multos Hash Modulus
Public Exponent Length 4N Only present if Mode Flag = 1; length in bits of the Public Exponent;
must be supplied if Public Exponent present in command message
Public Exponent nB Only present if Mode Flag = 1; if supplied then it must be odd; if not
supplied then a default exponent of 3 is assumed

>> Host Commands

RESPONSE MESSAGE
Response Code 2A Value 'ZR'.

08 - Invalid public exponent
12 - No keys in user storage


exponent) contains the imported Hash Modulus and a Public Exponent.
MAC 4B MAC over the Public Key and optional Authentication Data. Calculated
using LMK pair 36-37
characters.

>> Host Commands
Translate PIN
Function: To translate a PIN from encryption under a Zone PIN Key (ZPK) to
encryption under the LMK.
State: Online
Notes:
COMMAND MESSAGE
Command Code 2A Value “ZS”
Mode Flag 1N Flag to identify different modes of operation of this command. Only the
values 0 and 1 are valid in this version of the specification.
Mode flag = 0 means use the output PIN block format specified in PIN
Block Format Mode 0.
Mode flag = 1 means use the output PIN block format specified in PIN
Block Format Mode 1.
ZPK 32 H or 1A+32H Zone PIN Key encrypted under LMK pair 06-07
or 1A+48H
PIN Block 16 H The PIN Block to be translated
PIN Block Format 2H The format code for the PIN block including the new format described
in APPENDIX S (cannot be pin block format 35)
Account number 12 N The 12 rightmost digits of the Account number, may be ignored
depending on PIN block type

>> Host Commands

RESPONSE MESSAGE
Response Code 2A Value 'ZT'.

10 – ZPK Parity error

20 – PIN Block data error

23 – Invalid PIN Block Format Code
24 – PIN is fewer than 4 or more than 12 digits
Output PIN Block 8B The translated PIN Block encrypted under LMK pair 38-39 variant 9. The
plain text PIN Block is as described in 0 PIN Block Format Mode 1 or 0
PIN Block Format Mode 0 depending on the value of the Mode Flag in
the command data.
characters.

>> Host Commands
Construct all ICC Public Key related data
elements
Activity: command.ZU.host
Function: To obtain all public key related data for an ICC and get it into a form ready
to be included in a Multos AU. This function takes as input a previously
generated ICC Public Key in the standard HSM format. The public key data
elements to be produced are the ICC Certificate (containing the ICC public
key, produced using the Issuer’s Private Key), the ICC Public Key
Remainder, and the ICC Public Exponent.
State: Online
Notes:
COMMAND MESSAGE
Command Code 2A Value “ZU”
Mode Flag 1N Flag to identify different modes of operation of this command. Only
Mode 0 is valid in this version of the command.
Valid values
01 SHA-1.
Signature Identifier 2N Identifier of signature algorithm used to sign data. Only the Valid values
01 RSA.
MAC 4B MAC on Public Key and Authentication data calculated using LMK pair
36-37.
ICC Public Key nB Public Key, DER encoded in ASN.1 format (sequence of modulus and
exponent).
Authentication data nA Optional; additional data to be included in the MAC calculation (must
Delimiter 1A Delimiter to indicate end of Authentication Data field; value “;”.
PAN 10 B Application PAN. This supplied is left justified and padded on the right
with hex F.
Exp Date 2B Certificate Expiration Date.
Cert Ser Num 3B Certificate Serial Number.

>> Host Commands
Static Data Length 2H Length in bytes of next field.
Static Data nB Static Data to be Authenticated, up to 255 bytes.
Terminator 1A Terminator indicating end of Static Data field. Value “;”
Issuer Private Key Flag 2N Flag to indicate location of the Issuer Private Key; if flag = 99 use
Private Key provided with command, else flag = index of stored Private
Key.
Issuer Private Key 4N Length in bytes of the following field (only present if flag = 99).
Length
Issuer Private Key nB Issuer Private Key, encrypted using LMK pair 34-35 (only present if
flag = 99).

RESPONSE MESSAGE
Response Code 2A Value 'ZV'.

01 – MAC verification failure
02 – Public Key does not conform to encoding rules
03 – Invalid Issuer Private Key Flag
05 – Invalid Hash Identifier

06 – Invalid Crypto Algorithm Identifier


49 – Issuer Private Key error – report to Supervisor

78 – Issuer Private Key length error
ICCCERT length 2H Length of next field.
ICCCERT nB ICC Certificate, see APPENDIX R.
ICC Public Key 2H Length in bytes of the following field. May indicate zero if N C <= NI –
Remainder length 42.

>> Host Commands
ICC Public Key nB ICC Public Key Remainder. If the above field indicates zero
Remainder length(because NC <= NI – 42), this field will not exist.
ICC Public Exponent 2H ICC Public Exponent length in bytes.

Length
ICC Public Exponent nB ICC Public Exponent
characters.
>> Host Commands
Generate ICC Public/Private Keyset
Function: To generate an ICC Keyset.
State: Online
Notes: Depending on key size, this function may take a significant time to execute.
If a Public Exponent is supplied in the command message, it must be an
odd value (i.e. the least significant bit must equal 1). If an even Public
Exponent is provided, an error code will be returned by the command.
See also APPENDIX U for discussion on alternative Chinese Remainder
Theorem output formats.
COMMAND MESSAGE
Command Code 2A Value “ZW”
Mode Flag 1N Indicates the mode of operation of this command

0 = Generate Keys using Standard method with q>p
1 = Generate Keys using Europay method with q>p
2 = Generate Keys using Standard method with p>q
3 = Generate Keys using Europay method with p>q
The Europay method does not force the use of strong primes.
Key Length 4N Modulus length in bits; min 0400, max 4096. Must be set to between
0512 and 4096 if the Private key Output Format is 02 (Multos)
Private Key Output

format 2N Output format for Private Key:
01 = Standard HSM format, encrypted under LMK pair 34-35.

02 = MCPA format, encrypted under LMK pair 38-39 variant 9.
03 = Output in the form of 5 Chinese Remainder Theorem

components encrypted under the KEK.
04 = Output the private key exponent (d) and modulus (n) under the
KEK. See APPENDIX F (Private Key Exponent/Modulus format)
for the format of this key.
KEK(LMK) 32 H or 1A+32H Double Length KEK for encrypting the 5 Chinese Remainder Theorem
or 1A+48H components or the private exponent and the modulus. Encrypted under
Variant 1 of LMK pair 24-25. Only present when the Private key
Output Format is set to 03 or 04.

>> Host Commands
Encrypt Mode 1N Mode used to encrypt the Private Exponent and Modulus:
0 = ECB mode
1 = CBC mode
Only supplied if Private Key Output Format = 04
IV 8B Initialisation Vector.
Only supplied if Encrypt Mode = 1 and Private Key Output Format = 04
Length Bytes 1N The number of bytes that are used to specify the length of the key data
section. Valid entries are 0, 1 or 2. If this value is zero then no
length data will be present in the output. See APPENDIX AA (Private
Key Exponent/Modulus format).
Only supplied if Private Key Output Format = 04
Public Key Encoding 2N Encoding rules for public key (must allow public key length to be
inferred).
01 = DER encoding in ASN.1 format
Public Exponent Length 4N Indicates the length (in bits) of the public exponent
Public Exponent nB Must be an odd value
Terminator 1A Mandatory terminator, “;”
Authentication data nA Optional; additional data to be included in the MAC calculation (must

RESPONSE MESSAGE
Response Code 2A Value 'ZX'.
02 – Invalid private key formatting code

03 – Invalid public key encoding type

05 – Key Length error
06 – Public exponent length error
07 – Incompatible Key Length

08 – Supplied public exponent is even (except 2)
09 : Invalid Encrypt Mode
10 – Parity error on KEK
11 : Invalid Length Bytes value
>> Host Commands


Public Key nB Public key, encoded appropriately
MAC 4B MAC over the Public Key and any supplied Authentication Data
calculated using LMK 36-37.
Private Key Length 4N Length (in bytes) of the following field. Only present for Output Formats
01 and 02.
Private Key nB Private key, formatted and encrypted as defined in the supplied Private
Key Output format parameter. Only present for Output Formats 01,
02 and 04.
If output Format 04 is chosen this will be the private key exponent

under the KEK.
Modulus (KEK) nB Only present If Output Format is 04.
The modulus whose length = ‘Key Length’. Encrypted under the KEK
and in the format as specified in APPENDIX AA (Private Key
Exponent/Modulus format).
Private Key Component 1B Length in bytes of each of the following 5 fields. Only present for Output
Length. Format 03.
p (KEK) nB Prime p encrypted under KEK using triple DES CBC (see APPENDIX P).
Only present for Output Format 03.
q (KEK) nB Prime q encrypted under KEK using triple DES CBC (see APPENDIX P).
Only present for Output Format 03.
d1 (KEK) nB d1 = d mod (p-1) encrypted under KEK using triple DES CBC (see
APPENDIX P). Only present for Output Format 03.
d2 (KEK) nB d1 = d mod (p-1) encrypted under KEK using triple DES CBC (see
q-1 mod p (KEK) nB Modular inverse of q encrypted under KEK using triple DES CBC (see
characters.

>> Host Commands
Generate ICC Derived Keys
Function: Used by Issuer to produce the ICC Derived Keys for the MCPA application
or Europay PN&PL scheme. This function generates IDKAC, IDKSMI,
IDKSMC, and optionally, IDKIDN. These keys are returned encrypted either
under an LMK for local storage (ready for inclusion in the ALU for a Multos
card) or under a KEK for transmission to a Personalisation system (ready
for a Europay “Off-The-Shelf” (OTS) card.
State: Online
Notes:
COMMAND MESSAGE
Command Code 2A Value “ZY”
Mode Flag 1N If Mode Flag = 0 the Dynamic Number Derived Key is not generated.
Output for MULTOS cards
If Mode Flag = 1 the Dynamic Number Derived Key is generated.
Output for MULTOS cards
If Mode Flag = 2 the Dynamic Number Derived Key is not generated.
Output for OTS cards
If Mode Flag = 3 the Dynamic Number Derived Key is generated.

Output for OTS cards
KEK(LMK) 32 H or 1A+32H Key Exchange Key encrypted under Variant 1 of LMK pair 24-25. Only
or 1A+48H present for Mode Flag = 2 or 3.
PAN/PAN Sequence 8B PAN and PAN Sequence Number pre-formatted into 8 byte field
No
IMKAC(LMK) 32 H or 1A+32H Issuer Master Key for Authentication Cryptograms, IMK AC, encrypted
under Variant 1 of LMK pair 28-29.
IMKSMI(LMK) Flag 1N Flag indicating presence (1) or absence (0) of IMKSMI(LMK).
IMKSMI(LMK) 32 H or 1A+32H Issuer Master Key for Secure Message Integratory, IMK SMI, encrypted
under Variant 2 of LMK pair 26-27. Only present if above = 1.
IMKSMC(LMK) Flag 1N Flag indicating presence (1) or absence (0) of IMKSMC(LMK).
IMKSMC(LMK) 32 H or 1A+32H Issuer Master key for Secure Message Confidentiality, IMK SMC ,
encrypted under Variant 3 of LMK pair 26-27. Only present if above =
1.
>> Host Commands
IMKIDN(LMK) Flag 1N Flag indicating presence (1) or absence (0) of IMKIDN(LMK). Only
present if Mode Flag = 1 or 3.
IMKDN(LMK) 32 H or 1A+32H Issuer Master Key for ICC Dynamic Numbers, IMK DN, encrypted under
Variant 5 of LMK pair 26-27. Only present when Mode Flag = 1 or 3
and above = 1.

RESPONSE MESSAGE
Response Code 2A Value 'ZZ'.

04 – Mode Flag error
07 – KEK Parity error

08 – Parity error on IMKAC
09 – Parity error on IMKSMI
10 – Parity error on IMKSMC

11 – Parity error on IMKIDN
13 – LMK error – report to supervisor


IDKAC(LMK) 16 B IDKAC encrypted under LMK Pair 38-39, variant 1, ECB Mode. Only
present for Mode Flag = 0 or 1
IDKSMI(LMK) 16 B IDKSMI encrypted under LMK Pair 38-39, variant 2, ECB Mode. Only
present for Mode Flag = 0 or 1 and when IDKSMM(LMK) Flag = 1.
IDKSMC(LMK) 16 B IDKSMC encrypted under LMK pair 38-39, variant 3, ECB Mode. Only
present for Mode Flag = 0 or 1 and when IDKSMC (LMK) Flag = 1.
IDKIDN(LMK) 16 B IDKIDN encrypted under LMK Pair 38-39, variant 5, ECB Mode. Only
present when Mode Flag = 1 and when IDKIDN(LMK) Flag = 1.
IDKAC(KEK) 16 B IDKAC encrypted under KEK, ECB Mode. Only present for Mode Flag =
2 or 3.
KCV(IDKAC) 8B Key Check Value for IDKAC. Only present for Mode Flag = 2 or 3.
IDKSMI(KEK) 16 B IDKSMI encrypted under KEK, ECB Mode. Only present for Mode Flag =
2 or 3 and when IDKSMI(LMK) Flag = 1.

>> Host Commands
KCV(IDKSMI ) 8B Key Check Value for IDKSMI. Only present for Mode Flag = 2 or 3 and
when IDKSMI(LMK) Flag = 1.
IDKSMC(KEK) 16 B IDKSMC encrypted under KEK, ECB Mode. Only present for Mode Flag =
2 or 3 and when IDKSME(LMK) Flag = 1.
KCV(IDKSMC ) 8B Key Check Value for IDKSMC. Only present for Mode Flag = 2 or 3 and
when IDKSMC(LMK) Flag = 1.
IDKDN(KEK) 16 B IDKDN encrypted under KEK, ECB Mode. Only present when Mode Flag
= 3 and when IDKDN(LMK) Flag = 1.
KCV(IDKDN) 8B Key Check Value for IDKDN. Only present for Mode Flag = 3 and when
IDKDN(LMK) Flag = 1.
characters.
>> Host Commands
Generate EMV2000 Session Keys
Function: Used to calculate the EMV 2000 session and intermediate keys.
This function generates the session key and various levels of parent’s keys
from ICC Master Keys such as MKac, MKenc/smc & MKmac/smi.
These keys are retuned encrypted under an LMK for local storage (ready
for inclusion in the ALU for a Multos card) or under a KEK for transmission
to a Personalisation system. Odd parity should be applied to the calculated
intermediate keys and the final session keys. APPENDIX HH details the
calculation of the required keys.
The mechanism to calculate these keys is based on multiple iterations,
each iteration using a different piece of data from the ATC. The number of
iterations is specified as the height, which can be either 16 or 8, 16
iterations if the ATC is processed as single bit at a time and 8 if the ATC is
processed 2 bits at a time.
State: Online
Notes:
COMMAND MESSAGE
Command Code 2A Value “WM”
Mode Flag 1N If Mode Flag = 0 Input & Output Keys under LMK
If Mode Flag = 1 Input & Output Keys under KEK
If Mode Flag = 2..9 RFU
KEK(LMK) 32 H or 1A+32H Key Exchange Key encrypted under Variant 1 of LMK pair 24-25. Only
or 1A+48H present for Mode Flag = 1.
ATC 2B Application Transaction Counter (ATC) used to determine the path for
session key calculation.
IV 16 B Input Initial Vector used for 1st run iteration.
Branches 1N Number of branches per iteration,
Branches equal to either 2 or 4.

If Branches = 2 Height = 16,
if Branches = 4 Height = 8.
Levels Required 1N Number of keys (session & intermediate) to be retuned.

Maximum number of keys output per input key = 9.

>> Host Commands
Number of Input Keys 1N Number of keys to be processed, from 1 to 9.
Input Keys nB 1 or more 16B DES keys encrypted under Variant 9 of LMK pair 38-
39 if Mode Flag = 0, or encrypted under the KEK if Mode Flag = 1.
The number of keys is determined by ‘Number of Input Keys’.

RESPONSE MESSAGE
Response Code 2A Value 'WN'.

04 – Mode Flag error
07 – KEK Parity error
08 – Invalid Branches
10 – Invalid Levels Required
11 – Invalid Number of Input Keys

13 – LMK error – report to supervisor
5x – Parity error on input key x
(covers errors codes 51..59)
Length of Output Key 2B Unsigned Integer giving length in bytes of following field.
Block
Output Key Block nB 1 or more 16B DES keys, number of keys equal to Levels Required *
Number of Input Keys.
The keys will be encrypted under Variant 9 of LMK pair 38-39 if Mode
Flag = 0, or encrypted under the KEK if Mode Flag = 1.
See APPENDIX II for details of the block
characters.
>> Host Commands
Import Multos CA Public Key
Activity: command.XY.host
Function: To import a Multos CA public key (tkck_pk) and reformat it into standard
HSM format.
State: Online
Notes:
COMMAND MESSAGE
Command Code 2A Value “XY”
Version Flag 1N Flag to indicate tkck_pk format
Flag = 0 - Multos v3.0 or v4.0 (see APPENDIX EE)

Flag = 1 - TKCK format (see APPENDIX FF)
tkck_pk Length 3N Length in bytes of the next field
tkck_pk nB Multos CA public key, in Multos format (see APPENDIX EE)
include “;”)

>> Host Commands

RESPONSE MESSAGE
Response Code 2A Value 'XZ'.

03 - Invalid version flag
04 - Public key does not conform to encoding rules

80 - tkck_pk length error
MAC and tkck_pk 3N Combined length in bytes of the next two fields
Length
MAC 4B MAC on public key and authentication data, calculated using LMK pair
36-37
tkck_pk nB Multos CA public key, DER encoded in ASN.1 format
characters.
>> Host Commands
Miscellaneous Commands
This section describes HSM commands which are applicable to Visa Cash, VSDC,
M/Chip Lite and M/Chip Select applications. These include:
a) A set of three Console commands to allow a double length Key Exchange Key
(KEK) and the Card manufacturer’s Master Key (CMK) to be generated and
exported or imported in component form from the Card Issuer or Card
Manufacturer. The KEK is used for encryption of all other keys passed between
Issuer and Personalizer. The CMK is a key shared between the card
manufacturer and the card Personalizer and is given specific names for
particular schemes and manufacturers. The originator of the key will use the
commands DM and DI, the recipient of the key will use the command DH and
DI. All three commands are provided so that the Issuer can act as originator or
recipient.
b) A set of 3 console commands and 3 host commands to allow a double length
Key Exchange Key (KEK) and the Card manufacturer’s Master Key (CMK) to be
generated and exported or imported using a previously established Zone
Control Master Key (ZCMK) from the Card Personaliser or Card Manufacturer.
The three console commands permit the KEK or CMK to be set up with no
intervention by the connected host system. The three host commands allow
the host system to handle the set up of the keys which enables the process to
be more automatic if required.
c) A function to allow data produced by the Card Issuers to be verified by the Card
Personalizer. This is achieved by the use of the standard Message
Authentication Code (MAC) technique.
d) Generate MAC. This is an extended version of the command described
in c) above (the existing HW command). It allows use of a single or
double length MAC session key, and overcomes the HSM buffer size
limitation by allowing chaining of data. It also allows for different MAC
algorithms.
Control Master Keys (ZCMKs) irrespective of the setting of the single-
length/double-length parameter in the CS console command . Accordingly the HSM
should be configured to use double length zone master keys using the CS console
command. This will ensure that when zone master keys are generated or installed,
double length keys are used.
The term KEY is a generic term meaning any of the applicable keys for the function
concerned. An asterisk preceding the key indicates that a key is double length.

>> Host Commands
Available Commands
Command Page
Generate or Verify MAC on Data using Session Key under 97

KEK
Generate and Verify MAC 99
Diversified key for Easy Entry/Dedicated Funding Account 101
Translate PIN 103
Generate Audit Record 105
Verify Audit Record 107
Reset Audit Record Index 109

>> Host Commands
Generate or Verify MAC on Data using
Session Key under KEK
Function: To Generate or Verify a MAC over a variable length block of data. The size
of the data is limited only by the size of the HSM’s input buffer. The key
used to generate the MAC is encrypted under a KEK and either generated
by the function and returned or supplied with the data.
State: Online
Notes:
COMMAND MESSAGE
Command Code 2A Value “HW”
Mode Flag 1N 0 = Generate MAC
1 = Verify MAC

or 1A+48H
MK(KEK) 16 H or 1A+32H MAC generation key encrypted under KEK. Only present if Mode Flag =
or 1A+48H 1
MAC 4B MAC to be verified. Only present if Mode Flag = 1.
Data Length 2B Unsigned Integer giving length in bytes of following field.
Data nB Data over which MAC is to be verified.

>> Host Commands

RESPONSE MESSAGE
Response Code 2A Value 'HX'.

01 - MAC failed
04 - Mode Flag not 0 or 1
10 - KEK parity error
11 - MAC Key parity error

12 - No keys loaded in user storage
13 - LMK error, report to supervisor

80 - Data length error
MK(KEK) 16 H or 1A+32H MAC generation key encrypted under KEK. Only present if Mode Flag =
or 1A+48H 0
MAC 4B Calculated MAC. Only present if Mode Flag = 0
characters.
>> Host Commands
Generate and Verify MAC
Function: To Generate or Verify a MAC over a variable length block of data. The size
of the data is limited only by the size of the HSM’s input buffer. If the data
to be MACed is larger than the HSM buffer size, it may be broken down
and treated as a first, one or more middle and one end block. The key
used to generate the MAC (single or double length) is encrypted under a
KEK and either generated by the function and returned, or supplied with
the data. The MAC Algorithm is selectable by the calling application.
State: Online
Notes: This command is a more powerful version of the HW (HX) command,

which is limited to a single block of data and single length keys
COMMAND MESSAGE
Command Code 2A Value “ZK”
Mode Flag 1N 0 = Generate MAC

1 = Verify MAC
MAC algorithm Flag 1N 0 = ANSI X9.9 method
1 = ANSI X9.19 method

2 = ANSI X9.52 method
Block Type 1N 0 = Only block

1 = First block
2 = Middle block
3 = End block

or 1A+48H
MK(KEK) 16 H or 1A+32H MAC generation key encrypted under KEK. Present if Mode Flag = 1
or 1A+48H (verify, all Block Types) and if Block Type is 2 or 3 for Mode Flag = 0.
Will be 16H long if MAC Algorithm Flag is set to 0 and 32 H long if set
to 1 or 2
MAC 4B MAC to be verified. Only present if Mode Flag = 1 and Block Type = 0
or 3.
IV in 8B Initial Value input. Only present for Block Type = 2 or 3.

>> Host Commands
Data Length 2B Unsigned Integer giving length in bytes of following field.
Data nB Data over which MAC is to be verified.

RESPONSE MESSAGE
Response Code 2A Value 'ZL'.

01 – MAC failed
03 – Block Type not 0, 1, 2 or 3
04 – Mode Flag not 0 or 1
05 – MAC Algorithm not 0, 1 or 2
10 – KEK parity error

11 – MAC Key parity error
12 – No keys loaded in user storage

13 – LMK error, report to supervisor
80 – Data length error
81 – Data not a multiple of 8 bytes long (only for
Block Types 1 and 2)

MK(KEK) 32 H or 1A+32H MAC generation key encrypted under KEK. Only present for Block
or 1A+48H Types 0 or 1 when Mode Flag = 0. Will be 16H long if MAC Algorithm
Flag is 0 and 32H long if MAC Algorithm Flag is 1 or 2.
MAC 4B Calculated MAC. Only present if Mode Flag = 0 and Block Type = 0 or 3
IV out 8B Only present for Block Type = 1 or 2.
characters.
>> Host Commands
Diversified key for Easy Entry/Dedicated
Funding Account
Function: Generate a KDE Diversified from the KME or a KDD Diversified from the
KMD. The result is returned encrypted in TLV format, ready for passing to
the personalisation machine.
State: Online
Notes: The KME is the master key for controlling access to cards with the Easy
Entry application. The KMD is the master key for cards with a dedicated
funding account (which works in conjunction with Visa Cash)
The KDE and KDD are Diversified keys used to MAC information that is
written to the areas on the card that handle these applications.
The derivation process is described in APPENDIX Y.
Note that the an algorithm code of ‘01’ is not valid and APPENDIX Y
describes the process of diversifying a key when the algorithm code has a
value of ‘02’.
COMMAND MESSAGE
Command Code 2A Value “JY”
809 – KME, Master Key for Easy Entry

Key Type 3N LMK pair 28-29, Variant 8
909 – KMD, Master Key for DFA
LMK pair 28-29, Variant 9
Master Key 32 H or 1A+32H The encrypted Master Key under the appropriate variant of the LMK
or 1A+48H
Derivation Data 8B Data used to create the Diversified key
KEK 32 H or 1A+32H KEK encrypted under variant 1 of LMK 24-25

or 1A+48H
Key Version 1B
Algorithm Code 1B Algorithm code

>> Host Commands

RESPONSE MESSAGE
Response Code 2A Value 'JZ'.
09 – KEK parity error
10 – Master Key Parity Error

Diversified Key Data 27 B Dependent on value of Key Type Indicator:

Block
0 – Key is KDE
1 – Key is KDD
1-2 Tag X’9F6F
3 Length X’18
4 Key Version
5 Algorithm Code
6 Key Length X’10
7-22 Key 16 bytes
23 Length of KCV X’03
24-26 KCV 3 bytes
27 Padding X’00
Bytes 4 to 27 are encrypted under the KEK. Bytes 1 to 3 are in clear
text.
characters.
>> Host Commands
Translate PIN
Function: To translate a PIN from encryption under a Zone PIN Key (ZPK) to
encryption under the LMK or ZPK under the specified PIN block format.
State: Online
Notes:
COMMAND MESSAGE
Command Code 2A Value “ZE”
Mode Flag 1N 0 = Output PIN Block format fixed at 0

1 = Output PIN Block format & Enc Key user definable
ZPK 32 H or 1A+32H Zone PIN Key encrypted under LMK pair 06-07
or 1A+48H
PIN Block 16 H The PIN Block to be translated
Input PIN Block Format 2N The format code for the PIN block.
Account number 12 N The 12 rightmost digits of the Account number may be ignored
depending on PIN block type.
Output Encryption Key 1N 0 = LMK 38-39 Variant 9

Flag
1 = ZPK
Only present for Mode Flag 1.
Output PIN Block 2H The Output format for the PIN block. Only present for Mode Flag 1.
Format

>> Host Commands

RESPONSE MESSAGE
Response Code 2A Value 'ZF'.

05 - Invalid Enc. Key Mode Flag
10 – ZPK Parity error

20 – PIN Block data error

23 – Invalid Input PIN Block Format Code
24 – PIN is fewer than 4 or more than 12 digits

25 – Invalid Output PIN Block Format Code
Output PIN Block 8B The translated PIN Block encrypted under the requested encryption key
characters.
>> Host Commands
Generate Audit Record
Function: To generate an audit record from the data passed in. An internal counter
must be kept and incremented for each audit record. It will be used to
assign each audit record a unique number. A block will be returned
containing this unique number, the date, time and data itself. A MAC will
be generated over all this data and appended, together with the MAC key.
State: Online
Notes:
COMMAND MESSAGE
Command Code 2A Value “WG”
Data Length 2B Unsigned Integer giving length in bytes of following field in the range 1
– 1024.
Data nB Data to be placed into Audit Record.

>> Host Commands

RESPONSE MESSAGE
Response Code 2A Value ‘WH’.

80 – Invalid data size
Audit Record Size 2B The size of the following field
Audit Record nB The Audit Record comprising of :
ID – 4 Bytes
Timestamp – 4 Bytes
Data Length – 2 Bytes
Data – n Bytes
MAC over above data – 4 Bytes
MAC Key – 16 Bytes (encrypted under
LMK pair 28-29 v1)
characters.
>> Host Commands
Verify Audit Record
Function: To verify an audit record.
State: Online
Notes:
COMMAND MESSAGE
Command Code 2A Value “WI”
Audit Record Length 2B Unsigned Integer giving length in bytes of following field.
Audit Record nB The Audit Record Data. This is a block of data consisting of :
ID – 4 Bytes
Timestamp – 4 Bytes
Data Length – 2 Bytes
Data – n Bytes
MAC over above data – 4 Bytes
MAC Key – 16 Bytes (encrypted under

LMK pair 28-29 v1)

>> Host Commands

RESPONSE MESSAGE
Response Code 2A Value ‘WJ’.

01 – MAC Verification Error
10 – Parity Error on MAC Key
characters.
>> Host Commands
Reset Audit Record Index
Function: To reset the counter that is kept internally and used by the Generate Audit
Record and Verify Audit Record commands.
State: Online
Notes:
COMMAND MESSAGE
Command Code 2A Value “WK”

RESPONSE MESSAGE
Response Code 2A Value ‘WL’.
characters.

>> Appendix A: Local Master Key Variants
>> Appendix A: Local Master Key Variants
Variants of the Local Master Key in the HSM are used for encryption of defined
keys or key components. These variants are calculated as follows:
1. Select the appropriate LMK or LMK pair:
e.g. 0123 4567 89AB CDEF

e.g. 0123 4567 89AB CDEF 3131 3131 3131 3131
2. Identify which Variant of the LMK is required and select the following offset
values as appropriate:
Variant 1: “A6”
3. Combine the selected offset with the first byte of the LMK or LMK pair (i.e. “01”
above) using the exclusive-or operation.
4. Replace the leftmost byte of the LMK or LMK pair with the result of step 3 and
use the resulting key as the specified Variant:
e.g. Variant 1 = A723 4567 89AB CDEF
e.g. Variant 1 = A723 4567 89AB CDEF 3131 3131 3131 3131
The HSM currently supports up to 9 LMK variants, with offset values as follows:
Variant 1: “A6”
Variant 2: “5A”
Variant 3: “6A”
Variant 4: “DE”
Variant 5: “2B”
Variant 6: “50”
Variant 7: “74”
Variant 8: “9C”
Variant 9: “FA”
>> Appendix B: Algorithm Identifiers
>> Appendix B: Algorithm Identifiers
Signature Algorithm
01 RSA
03 RSA with public exponent of 65537 (Visa Cash only)
Hash Algorithm
01 SHA-1
02 MD5
03 ISO 10118-2
04 No hash
Encryption Algorithm
01 RSA
Pad Mode
01 PKCS#1, - See also Error! Reference source not found.
Public Key Encoding

01 DER encoding for ASN.1, - See also Error! Reference source not
found.

>> Appendix C: PKCS#1Pad Mode (Pad Mode Identifier = 01)
>> Appendix C: PKCS#1Pad Mode (Pad

Mode Identifier = 01)
The PKCS #1 standard defines the padding method to be used before operating
with a public or Private RSA key. The data to be encrypted or decrypted is padded
as follows:
00 BT PS 00 D,
where 00 is a single byte equal to 00, BT is a single byte indicating the block type,
PS is a padding string and D is the data. The total length of the padded block will
be equal to the length (in bytes) of the RSA key modulus.
BT will take the value 01 for a Private key operation and the value 02 for a public
key operation.
PS will consist of bytes FF....FF for block type 01 and random non-zero bytes for
block type 02. PS must contain at least 8 bytes.
The data block D will comprise a single byte 04, followed by a byte to indicate the
length (L) of the rest of D. Thus, D will be either:
04 L hash value, or
04 L DES key
When using this padding mode, the following validity checks will be carried out:
1. For a validation operation (Validate Certificate, Validate Signature):
the length of the data to be validated is equal to the length (in bytes) of
the modulus of the key to be used for the validation - if not, return error
code 76
the first byte of the clear data block is 00 - if not, return error code 77
the second byte of the clear data block is 01 - if not, return error code 77
subsequent bytes consist of at least 8 bytes of binary 1s, followed by a
zero byte - if not return error code 77
the next two bytes are 04 and a byte indicating the length (in bytes) of the
rest of D - if not then return error code 77
the remaining k-2 bytes (where k is the length of D, in bytes) are
compared with the hash of the supplied data - if the two values are not
equal then return error code 02
2. For a generation operation (Generate Signature):
the length (in bytes) of the hash of the supplied data is at most m-13
(where m is the length, in bytes, of the modulus of the key to be used) - if
not, return error code 76
3. For an import key operation (Import DES Key):
the length of the imported key block is equal to the length (in bytes) of the
modulus of the Private key to be used to decrypt the block - if not, return
error code 76
the first byte of the clear data block is 00 and the second byte is 02 - if
not, return error code 77
subsequent bytes consist of at least 8 bytes of random non-zero bytes,
followed by a zero byte - if not, return error code 77
>> Appendix C: PKCS#1Pad Mode (Pad Mode Identifier = 01)
the next two bytes are 04 and a byte indicating the length (in bytes) of the
rest of D (which must be 08 or 10 to indicate a single or double length
DES key) - if not then return error code 77
4. For an export key operation (Export DES Key):
the modulus of the public key to be used must be at least 13 bytes longer
than the DES key to be encrypted - if not, return error code 76

>> Appendix D: Public Key Encoding
>> Appendix D: Public Key Encoding
The HSM supports the following public key encoding types:

Type = 01 (DER encoding for an ASN.1 public key)
An ASN.1 RSAPublicKey has the following definition :

RSAPublicKey : : = SEQUENCE {
modulus INTEGER, - - n
publicExponent INTEGER - - e }
>> Appendix E: Self-Signed CA Public Key Format (Visa)
>> Appendix E: Self-Signed CA Public Key

Format (Visa)
Field Name Length Description

&
Format
Header 1b Hex value ‘20’ NOT SIGNED
Visa Service Identifier 4b Identifies specific Visa NOT SIGNED

Service
10 10 00 00 - CCPS
20 10 00 00 - CCPS
30 10 00 00 - CCPS
60 10 cc ce - Visa
Cash (ccc = currency
code, e = currency
exponent)
Length of Visa CA 2b Length of Visa CA Public NOT SIGNED

Public Key Modulus Key in Hex. (Number of
(N) bytes)
Visa CA Public Key 1b Identifies cryptographic NOT

Algorithm Indicator algorithm used to
SIGNED
generate the Visa CA
Public Key
Length of Visa CA 1b Length of Visa CA Public NOT SIGNED

Public Key Exponent Key Exponent in Hex.
(Number of bytes)
Registered Application 5b Identifies Visa NOT SIGNED

Provider Identifier
(RID)
Visa CA Public Key 1b Unique Visa CA Public Key NOT SIGNED

Index Serial Number
Visa CA Public Key var b Unsigned Visa CA Public NOT SIGNED

Modulus (N) Key Modulus
Visa CA Public Key var b Exponent of Visa CA NOT SIGNED

Exponent (e) Public Key

Hash Result 20 b Hash of RID, Visa CA NOT SIGNED

Public Key Index, Visa CA
Public Key Modulus (N),
Visa CA Public Key
Exponent (e) data
elements above.
Unsigned Visa CA Public Key Output Extension

Field Name Length & Description

Format
Header 1b Hex. value ‘21’
Visa Service Identifier 4b Identifies specific Visa Service

10 10 00 00 - CCPS
20 10 00 00 - CCPS
30 10 00 00 - CCPS
60 10 cc ce - Visa
code, e = currency
exponent)
Registered Application 5b Identifies Visa

Provider Identifier
(RID)
Visa CA Public Key 1b Unique Visa CA Public Key Serial Number

Index
Certificate Expiration 2n MMYY after which this certificate is

Date invalid.
Visa CA Public Key 1b Identifies cryptographic algorithm used to

Algorithm Indicator generate the Visa CA Public Key
Leftmost portion of var b (N - [36+e]) bytes of the Visa CA Public

Visa CA Public Key Key Modulus (N)
Modulus (N)
Hash Algorithm 1b Identifies the hash algorithm used to

Indicator produce the Hash Result.
Visa CA Public Key 1b Length of Exponent e of Visa CA Public

Exponent Length Key (Number of bytes)
Visa CA Public Key var b Exponent of Visa CA Public Key

Exponent (e)
Hash Result 20 b Hash of Visa CA Public Key and its

related information, ie RID, Visa CA Key
Index, Visa CA Public Key Modulus (N),
Visa CA Public Key Exponent.
Self Signed Visa CA Public Key Data

>> Appendix F: Self-Signed Issuer Public Key Format (Visa)
>> Appendix F: Self-Signed Issuer Public

Key Format (Visa)

Format
Header 1b Hex value ‘22’ NOT

SIGNED
Length of Issuer Public 1b Length of Issuer Public Key NOT

Key in Hex. (Number of bytes) SIGNED
Issuer Public Key var b Unsigned Issuer’s Public NOT

Key SIGNED
Issuer Public Key 1b Length of Issuer Public Key NOT

Exponent Length Exponent (Number of SIGNED
bytes)
Issuer Public Key var b Issuer Public Key Exponent, NOT

Exponent SIGNED
e = (1 to NI/4)
Tracking Number 3n Assigned by Visa NOT

SIGNED
Unsigned Issuer Public Key Input Extension

>> Appendix F: Self-Signed Issuer Public Key Format (Visa)

Format
Visa Service Identifier 4b Identifies specific Visa Service

10 10 00 00 - CCPS
20 10 00 00 - CCPS
30 10 00 00 - CCPS
60 10 cc ce - Visa
code, e = currency
exponent)
Certificate Format 1b Hex value ’02’
Issuer Identification 4 cn Issuer BIN, left justified and padded on

Number the right with hex. ‘F’s).
Certificate Expiration 2n MMYY after which this certificate is

Date invalid.
Tracking Number 3n Transmittal Track Number assigned by

Visa

Indicator produce the Hash Result.
Issuer’s Public Key 1b Identifies the digital signature algorithm to

Algorithm Indicator be used with the Issuer’s Public Key.
Issuer Public Key 1b Identifies the length of the Issuer Public

Length Key. (Number of bytes)

Exponent Length Key Exponent (Number of bytes). Note,
this field will be 03 (65537 requires 3
bytes) for Visa Cash
Leftmost Digits of var b Leftmost Digits N-(39 + e) digits of

Issuers Public Key Issuers Public Key
Issuer Public Key var b Issuer Public Key Exponent (e = 1 to

Exponent Ni/4).
Hash Result 20 b Hash of Issuer’s Public Key and its related

information.
Self-Signed Issuer Public Key Data

>> Appendix G: Issuer Public Key Format (Visa)
>> Appendix G: Issuer Public Key Format

(Visa)

Format
Header 1b Hex. value ‘24’ NOT SIGNED
Visa Service Identifier 4b Identifies specific Visa NOT SIGNED

Service
10 10 00 00 - CCPS
20 10 00 00 - CCPS
30 10 00 00 - CCPS
60 10 cc ce - Visa
code, e = currency
exponent)
Issuer Identification 4 cn Issuer BIN, left justified and NOT SIGNED

Number padded on the right with
hex. ‘F’s).
Certificate Serial 3b Certificate Serial Number NOT SIGNED

Number assigned by Visa CA
Certificate Expiration 2n MMYY after which this NOT SIGNED

Date certificate is invalid.
IPK Remainder Length 1b Length of IPK Modulus (N) NOT SIGNED

Remainder.
Issuer Public Key var b Field only present if NI > NCA NOT SIGNED
Modulus (N) - 36, and consists of the NI-
Remainder NCA + 36 least significant
bytes of the Issuer Public
Key Modulus (N)
Issuer Public Key 1b Length of Issuer Public Key NOT SIGNED

Exponent Length Exponent e in hex. (number
of bytes)
Issuer Public Key var b Exponent (e = 1 to Ni / 4). NOT SIGNED

Exponent This field is not included in
the hash calculation for Visa
Cash.
CA Public Key Index 1b CA Public Key Index for CA NOT SIGNED

Public Key used to sign the
Issuer Public Key Certificate
Unsigned Issuer Public Key Output Extension


Format
Recovered Data 1b Hex. value ‘6A’

Header
Certificate Format 1b Hex. value ‘02’
Issuer Identification 4 cn Leftmost 3-8 digits, starting with position

Number 1, from the PAN (padded to 8 digits as
required, on the right with hex. ‘F’s)
Certificate Expiration 2n MMYY after which this certificate is invalid

Date
Certificate Serial 3b Binary number unique to this certificate

Number assigned by the Certification Authority

Indicator produce the Hash Result in the digital
signature scheme
Issuer Public Key 1b Identifies the digital signature algorithm to

Algorithm Indicator be used with the Issuer Public Key

Length Key Modulus in bytes

Exponent Length Key Exponent in bytes
Issuer Public Key var b If NI NCA 36, this field consists of the
Modulus (N) or full Issuer Public Key Modulus (N) right
Leftmost portion of padded with NCA – 36 – NI ‘BB’ bytes. If NI
the Issuer Public Key > NCA – 36, this field consists of the NCA –
Modulus (N) 36 most significant bytes of the Issuer
Public Key Modulus (N).
Hash Result 20 b Hash of the Issuer Public Key and its

related information
Recovered Data 1b Hex. value ‘BC’

Trailer
Issuer Public Key Certificate


Format
Block Format Code 1b Hex. value ‘01’
Padding Characters var b Hex. value ‘FF’. The length of the padding
is equal to the Signing key modulus - 38.
Separator 1b Hex. value ‘00’
Algorithm Indicator 15 b Hex. value

(for SHA-1)
‘3021300906052b0e03021a05000414’
Hash Results 20 b SHA-1 Hash of the concatenation of the

Output Extension and the IPK Certificate
Issuer Public Key Detached Signature

>> Appendix H: Format of Static Data Authentication Block
>> Appendix H: Format of Static Data

Authentication Block

Format

Header
Signed Data Format 1b Hex. value ‘03’

signature scheme
Data Authentication 2b Issuer-assigned code

Code
Pad Pattern (NI - 26) b Pad pattern consisting of (NI - 26) bytes of
value hex ‘BB’
Hash Result 20 b Hash of the Static Application Data to be

authenticated

Trailer
Format of Signed Static Application Data

>> Appendix I: Format of Visa Cash Card Certificate
>> Appendix I: Format of Visa Cash Card

Certificate
Name Description Length Notes
Certificate Format 1 ‘04’
BINIEP Issuer ID 3 BIN Assigned to Issuer
IDIEP SVC Serial Number 5 Unique Account number for this

Purse Application assigned by
Issuer
Pad 2 ‘FFFF’
DEXPCCERT Certificate Expiration 2 MMYY, after which this

date certificate is invalid
IDCCERT Certificate Serial 3 Binary number unique to this

Number certificate assigned by the
issuer.
ALHCCERT Hash Algorithm 1 Identifies the hash algorithm

Indicator used to produce the Hash Result
below. ‘01’ means SHA-1.
ALGCCERT Card Public Key 1 Identifies the digital signature

Algorithm indicator algorithm to be used with the
Card Public Key (‘03 for RSA
with Public Exponent of 63337)
LMODC Card Key Modulus 1 Length of Card Public Key

length Modulus
Length of Card Public 1 Dependent on ALGCCERT. If this is

Key Exponent ‘03’, (indicating an exponent
65537) the value is ‘03’ (3
Bytes)
MODLC Leftmost bytes of the LMODI-42 The leftmost bytes of the Card
Card Key Modulus Key Modulus, left justified and
padded with hex ‘BB’ if
necessary. If NC>NI-42, this field
consists of the NI-42 most
significant bytes of the Card
Public Key Modulus.

MODRC Card Key Modulus 0 or NC- This field only present if NC>NI-
Remainder NI+42 42 and consists of NC-NI+42
least significant bytes of the Card
Public Key Modulus.
Card Public Key Data to be signed by the Issuer (ie input to hash algorithm)
Name Description Length Notes
Recovered Data Header 1 ‘6A’
Certificate Format 1 ‘04’
BINIEP Issuer ID 3 BIN Assigned to Issuer
IDIEP SVC Serial Number 5 Unique Account number for this

Purse Application assigned by
Issuer
Pad 2 ‘FFFF’
DEXPCCERT Certificate Expiration 2 MMYY, after which this

date certificate is invalid
IDCCERT Certificate Serial 3 Binary number unique to this

Number certificate assigned by the
issuer.
ALHCCERT Hash Algorithm 1 Identifies the hash algorithm

Indicator used to produce the Hash Result
below. ‘01’ means SHA-1.
ALGCCERT Card Public Key 1 Identifies the digital signature

Algorithm indicator algorithm to be used with the
Card Public Key (‘03 for RSA
with Public Exponent of 63337)
LMODC Card Key Modulus 1 Length of Card Public Key

length Modulus
Length of Card Public 1 Dependent on ALGCCERT. If this is

Key Exponent ‘03’, (indicating an exponent
65537) the value is ‘03
MODLC Leftmost bytes of the LMODI-42 The leftmost bytes of the Card
Card Key Modulus Key Modulus, left justified and
padded with hex ‘BB’ if
necessary. If NC>NI-42, this field
consists of the NI-42 most
significant bytes of the Card
Public Key Modulus.
Hash Result 20 Hash of Card Public Key and its

related information
Recovered data trailer 1 ‘BC’
Content of the Card Certificate (Deciphered)

>> Appendix J: Self-Signed CA Public Key Format (MCI/EPI/JCB)
>> Appendix J: Self-Signed CA Public Key

Format (MCI/EPI/JCB)

Format
ID of Certificate Subject 5b The “Registered Application NOT SIGNED

Provider Identifier” (RID)
Public Key Index 1b Public Key Index, which NOT SIGNED

uniquely identifies a Public Key
Subject Public Key 1b Indicates the algorithm to be NOT SIGNED

Algorithm Indicator used with the Public Key, set to
“01” (hex) meaning RSA.
Subject Public Key 1b Length of Public Key Modulus NOT SIGNED

Length (equal to NCA)
Subject Public Key 1b Length of Public Key Exponent NOT SIGNED

Exponent Length (from 01 to 04 bytes))
Leftmost Digits of NCA-37 b NCA-37 most significant bytes NOT SIGNED

Subject Public Key of the Public Key Modulus
Subject Public Key 37 b 37 least significant bytes of the NOT SIGNED

Remainder Public Key Modulus
Subject Public Key Nb Public Key Exponent NOT SIGNED

Exponent
CA Self-Signed Certificate (Clear Data)

>> Appendix J: Self-Signed CA Public Key Format (MCI/EPI/JCB)

Format
Recovered Data Header 1b Hex value ‘6A’
ID of Subject Certificate 5b The scheme provider RID
Certificate Expiry Date 2 cn MMYY after which this certificate is invalid.
Certificate Serial 3b Inserted by scheme provider

Number
Hash Algorithm 1b Identifies the hash algorithm used to produce

Indicator the Hash Result.
Subject Public Key 1b Identifies the digital signature algorithm to be

Algorithm Indicator used with the Public Key (=“01” )
Subject Public Key 1b Length of the Public Key Modulus in bytes (NCA)
Length
Subject Public Key 1b Length of Issuer Public Key Exponent in bytes

Exponent Length (from 01 to 04)
Leftmost Digits of NCA-37 b Leftmost NCA-37 bytes of the Public Key

Subject Public Key Modulus
Hash Result 20 b Hash of Public Key and its associated

information.
Recovered Data Trailer 1b Hex value “BC”
CA Self-Signed Certificate (Self-Signed Certificate)

>> Appendix K: Self-Signed Issuer Public Key Format (MCI/EPI)
>> Appendix K: Self-Signed Issuer Public

Key Format (MCI/EPI)

Format
ID of Certificate Subject 4 cn Leftmost 3-8 digits from the NOT SIGNED

PAN, right padded with
hexadecimal F
Issuer Public Key Index 3b Number, chosen by the NOT SIGNED

Issuer, which uniquely
identifies the Public Key
Subject Public Key 1b Indicates the algorithm to be NOT SIGNED

Algorithm Indicator used with the Issuer Public
Key, set to “01” (hex)
Subject Public Key 1b Length of Issuer Public Key NOT SIGNED

Length Modulus (equal to NI)
Subject Public Key 1b Length of Issuer Public Key NOT SIGNED

Exponent Length Exponent (between 1 and
NI/4)
Leftmost Digits of NI-36 b NI-36 most significant bytes NOT SIGNED

Subject Public Key of the Issuer Public Key
Modulus
Subject Public Key 36 b 36 least significant bytes of NOT SIGNED

Remainder the Issuer Public Key
Modulus
Subject Public Key var b Issuer Public Key Exponent, NOT SIGNED
Exponent
e = (1 to NI/4)
Self-Signed Issuer Public Key Certificate (Clear Data)

>> Appendix K: Self-Signed Issuer Public Key Format (MCI/EPI)

Format
Recovered Data Header 1b Hex value ‘6A’
ID of Subject Certificate 4b Leftmost 3-8 digits from the PAN, right

padded with hex. ‘F’
Certificate Expiry Date 2 cn MMYY after which this certificate is invalid.
Certificate Serial 3b Chosen by the Issuer

Number
Hash Algorithm 1b Identifies the hash algorithm used to produce

Indicator the Hash Result.
Subject Public Key 1b Identifies the digital signature algorithm to be

Algorithm Indicator used with the Issuer’s Public Key (=“01” )
Subject Public Key 1b Length of the Issuer Public Key Modulus in

Length bytes (NI)
Subject Public Key 1b Length of the Issuer Public Key Exponent in

Exponent Length bytes
Leftmost Digits of NI-36 b Leftmost NI-36 bytes of Issuer’s Public Key

Subject Public Key Modulus
Hash Result 20 b Hash of Issuer Public Key and its associated

information.
Recovered Data Trailer 1b Hex value “BC”
Self-Signed Issuer Public Key Certificate (Self-Signed Certificate)

>> Appendix L: Issuer Public Key Certificate Format (MCI/EPI)
>> Appendix L: Issuer Public Key

Certificate Format (MCI/EPI)

Format
ID of Subject Certificate 4 cn Leftmost 3-8 digits of the NOT SIGNED

PAN, right padded with hex.
‘F’.
Issuer Public Key Index 3b Number, chosen by the NOT SIGNED

Issuer, which uniquely
identifies the Public Key.
Europay Public Key 1b The Europay Public Key NOT SIGNED

Index Index, uniquely identifies a
Europay Public Key.
Subject Public Key var b Field only present if NI > NCA NOT SIGNED
Remainder - 36, and consists of the NI-
NCA + 36 least significant
bytes of the Issuer Public
Key Modulus
Subject Public Key var b Exponent (e = 1 to Ni / 4). NOT SIGNED

Exponent
Issuer Certificate (Clear Data)

>> Appendix L: Issuer Public Key Certificate Format (MCI/EPI)

Format

Header
Certificate Format 1b Hex. value ‘02’
Issuer Identification 4 cn Leftmost 3-8 digits, starting with position 1,

Number from the PAN (padded to 8 digits as
required, on the right with hex. ‘F’s)
Certificate Expiry 2n MMYY after which this certificate is invalid

Date

Number assigned by the Certification Authority

signature scheme
Issuer Public Key 1b Identifies the digital signature algorithm to

Algorithm Indicator be used with the Issuer Public Key
Issuer Public Key 1b Identifies the length of the Issuer Public Key
Length Modulus in bytes
Issuer Public Key 1b Identifies the length of the Issuer Public Key
Exponent Length Exponent in bytes
Issuer Public Key var b If NI NCA 36, this field consists of the full
Modulus (N) or Issuer Public Key Modulus (N) right padded
Leftmost portion of with NCA – 36 – NI ‘BB’ bytes. If NI > NCA –
the Issuer Public Key 36, this field consists of the NCA – 36 most
Modulus (N) significant bytes of the Issuer Public Key
Modulus (N).
Hash Result 20 b Hash of the Issuer Public Key and its

related information

Trailer
Issuer Certificate (Issuer Public Key Certificate)

>> Appendix M: Encryption of Tag-Length-Value (TLV) Fields
>> Appendix M: Encryption of Tag-Length-

Value (TLV) Fields
Visa Cash parameters are transferred to the Personalisation System in Tag, Length,
Value (TLV) format. The Tag identifies the parameter type, the Length provides the
length in bytes of the Value field, and the Value is the parameter value itself. For Visa
Cash a Tag of 80 or greater signifies that the parameter is encrypted.
If the plain text parameter (which does not appear outside a security module) is:
T L V
the encrypted version becomes:
T L’ V’
Where:
T remains the same in plain text.
L’ is the new length of the new V’ field which will be a multiple of 8 bytes (not
encrypted).
V’ is the original L and V fields concatenated together and padded with zeros
to a multiple of 8 bytes and encrypted under the appropriate DES key. The
mode of encryption is Electronic Code Book (ECB), regardless of whether the
encryption key is a single or double length key.
To decrypt such an encrypted parameter, the steps are:

a) Decrypt the L’ bytes of the V’ field.
b) The first byte of the decrypted block will be the original L field. Extract L bytes
starting at the byte after the L byte. The remaining bytes in the block should all
be zeros.
c) We now have the original T, the recovered plaintext L and the recovered
plaintext V fields.
>> Appendix N: Multos Padding
>> Appendix N: Multos Padding
This padding method takes the supplied data in precisely the format submitted and
appends sufficient random data bytes to make the total block equal to the size of
the modulus of the private key. No padding is added if the data supplied is exactly
the size of the private key. It is up to the calling application to ensure that the
supplied data has the most significant bit cleared to ensure that the data to be
signed (supplied data || random padding) is numerically smaller than the modulus. If
the data to be signed is the result of the Multos asymmetric hash function, the
most significant bit will already have been cleared.

>> Appendix O: Triple DES CBC Mode of Encryption/Decryption
>> Appendix O: Triple DES CBC Mode of

Encryption/Decryption
For the purposes of this specification, the Triple DES CBC mode of
Encryption/Decryption is defined to be the same as the standard single DES CBC
mode except:
a) For Encryption, the single round of DES at each stage (8 bytes) is replaced with
an encrypt, decrypt, encrypt sequence where the left half of the double length
key is applied to both the encrypt stages and the right half of the key is applied
to the decrypt stage.
b) For Decryption, the single round of DES at each stage (8 bytes) is replaced with
a decrypt, encrypt, decrypt sequence where the left half of the double length key
is applied to both the decrypt stages and the right half of the key is applied to
the encrypt stage.
An IV, if used, is applied at the first stage as for the standard single DES CBC mode
>> Appendix P: Multos KTU Format
The standard Multos Key Transport Unit (KTU) and the modified version (KTU’) are
defined in this Appendix. The KTU and KTU’ may have different lengths, depending
on whether the system that generated the KTU’ has knowledge of the length of the
smart card public key modulus. The format of the plaintext KTU is as follows.
Data Field Description Length (in bytes)
header X’55 1
msm_controls_data_date 1
mcd_no 8
application_id 17
no_area_descriptors number (L) of protected 1

areas
area_descriptors L records 14 or 22 (per record)
padding random values variable - to ensure that the

total length of the KTU is
equal to the length of the
smart card public key
modulus
Each area_descriptor has the following format:
algorithm id algorithm used for data protection (X’01 = DES; 1

X’02 = 3-DES)
area start offset of start of protected area relative to start of 2

application load unit
area length length of protected area - must be a multiple of 8 2

bytes
key length length of key data 1
key data key used to protect the area 8 or 16
NB: The algorithm id will always be 02 (3-DES) when generated by the HSM

The format of the plaintext KTU’ will be as above, except that the
msm_controls_data_date and mcd_no fields will be filled with binary zeros and the
amount of padding may be less than required for a KTU.
The entire KTU or KTU’ is encrypted, either using a double length DES key (for the
KTU’) or an RSA public key (for the KTU).
When a plaintext KTU’ is validated (in the command specified in Generic Card
Issuing Commands for M/Chip Lite, M/Chip Select, & Generic MULTOS
Applications), the following checks will be carried out. Any validation failure will
result in the command being terminated and error code 02 being returned to the
host.
1) (byte 1) Header = X’55.
2) (bytes 2-10) msm_controls_data_date and mcd_no fields = 9 bytes of binary
zeros.
>> Appendix Q: Checksum Algorithm
>> Appendix Q: Checksum Algorithm
This process is used to calculate a 4 byte checksum over the input data. It is an
implementation of the 4 byte “two’s complement” checksum.
a) Assume length of data (in bytes) over which the checksum is to be calculated is
“length”
b) Assume data over which checksum is to be calculated is “data”
c) Initialise the 4 byte checksum to “initial.value”
d) Set i = 1
e) WHILE length >0 DO (steps f to l)
f) Perform a bytewise cascading addition of the bytes in the input data, starting
with the initial.value. Each addition is carried out modulo 256 (ie any carry is
ignored). Steps g to l below shows the steps to be carried out for each new byte
of input data.
g) Set checksum[1] = checksum[1] + ith byte of data
h) Set checksum[2] = checksum[2] + checksum[1]
i) Set checksum[3] = checksum[3] + checksum[2]
j) Set checksum[4] = checksum[4] + checksum[3]
k) Set i = i +1
l) Set length = length – 1
m) END DO
n) The 4 byte checksum is checksum[1] || checksum[2] || checksum[3] ||
checksum[4]
Example:
I/P Data checksum[1] checksum[2] checksum[3] checksum[4]
5A A5 5A A5 (Init value)
01 5B 00 5A FF
7F DA DA 34 33
1A F4 CE 02 35
97 8B 59 5B 90
A6 31 8A E5 75

>> Appendix R: Format of ICC Certificate
Description Length & Notes

Format
Certificate Format 1b ‘04’
Application PAN 20 cn PAN (padded on the right with hex F.)
Certificate Expiration 4n MMYY, after which this certificate is

date invalid

Number assigned by the issuer.

Indicator produce the Hash Result. ‘01’ means
SHA-1.
ICC Public Key 1b Identifies the digital signature algorithm

Algorithm indicator to be used with the ICC Public Key. ‘01’
means RSA.
ICC Public Key Modulus 1b Identifies the length of ICC Public Key
length Modulus in bytes
ICC Public Key Exponent 1b Identifies the length of the ICC Public Key
length Exponent in bytes
Leftmost bytes of the NI-42 b If NIC =<NI-42, this field consists of the
ICC Key Modulus full ICC Public Key padded to the right
with NI-42-NIC bytes of value hex ‘BB’ if
necessary.
If NIC>NI-42, this field consists of the NI-
42 most significant bytes of the ICC
Public Key Modulus.
ICC Public Key Modulus 0 or NC- This field only present if NIC>NI-42 and
Remainder NI+42 b consists of NC-NI+42 least significant
bytes of the ICC Public Key Modulus.
ICC Public Key Exponent 1 to NIC/4 b ICC Public Key Exponent
Static Data var b Static Data to be Authenticated.
ICC Public Key Data to be signed by the Issuer (ie input to hash algorithm)
Description Length & Notes

Format
Recovered Data Header 1b ‘6A’
Certificate Format 1b ‘04’
Application PAN 20 cn PAN (padded on the right with hex F)
Certificate Expiration 4n MMYY, after which this certificate is

date invalid

Number assigned by the issuer.

Indicator produce the Hash Result below. ‘01’
means SHA-1.
ICC Public Key 1b Identifies the digital signature algorithm

Algorithm indicator to be used with the ICC Public Key. ‘01’
means RSA
ICC Key Modulus length 1b Length of ICC Public Key Modulus in bytes
Length of ICC Public Key 1 b Identifies the length of the ICC Public Key
Exponent Exponent in bytes
ICC Public Key modulus NI-42 b If NIC =<NI-42, this field consists of the full
or leftmost bytes of the ICC Public Key padded to the right with
ICC Public Key modulus NI-42-NIC bytes of value hex ‘BB’ if
necessary.
If NIC>NI-42, this field consists of the NI-

42 most significant bytes of the ICC
Public Key Modulus.
Hash Result 20 b Hash of ICC Public Key and its related

information
Recovered data trailer 1b ‘BC’
Content of the ICC Certificate (Deciphered)

>> Appendix S: Mastercard PIN Block Format
>> Appendix S: Mastercard PIN Block

Format
The MasterCard PIN Block format is defined as:
Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 Byte 7 Byte 8
L L P P P P P/ P/ P/ P/ P/ P/ P/ P/ F F
F F F F F F F F
Byte 1 contains the BCD encoded length of the PIN (04 to 12)
P = PIN Digit
P/F = PIN Digit or Hex F
F = Hex F
This PIN Block Format is allocated Code 35

>> Appendix T: Multos Encryption Algorithm
>> Appendix T: Multos Encryption

Algorithm
This algorithm is required to encrypt the sensitive data inside a Multos ALU. It uses
ONLY DES decrypt rounds at every stage since the Multos card can only perform
DES encrypt rounds for the complementary operation.
It is structurally similar to the Triple DES CBC encryption algorithm defined in Error!
Reference source not found. but instead of using Encrypt/Decrypt/Encrypt at
every stage, the sequence Decrypt/Decrypt/Decrypt is used. This is shown in the
diagram below
Plain Text Plain Text Plain Text

Block 1 Block 2 Block n
XOR XOR
Key DES DES DES

Left dec dec dec
Key DES DES DES

Right dec dec dec
Key DES DES DES

Left dec dec dec
Cypher Text Cypher Text Cypher Text

Block 1 Block 2 Block n
Stage 1 Stage 2 Stage n
Note, the same sequence of Key Left and Key Right is used at every stage,

>> Appendix U: Alternative Output Formats for Private Key
>> Appendix U: Alternative Output

Formats for Private Key
The command in RSA Key Management Commands for EMV-type Schemes has the
ability to output a Private key in the form of 5 Chinese Remainder Theorem
components. These are p, q, d1, d2, q-1 mod p. It is possible to select either of
the conditions q>p or p>q.
Some applications may require that the 5th component (q-1 mod p) is provided in a
different form. This is the modular inverse of p (or p-1 mod q). It is possible to
obtain output in this form by observing the following rules:
1. If the condition that q>p is required:

- Select the condition p>q (ie the opposite of what is required)
- From the returned 5 components (p, q, d1, d2, q-1 mod p) rearrange them
according to the following table.
For new component Use returned

component
p q
q p
d1 d2
d2 d1
p-1 mod q q-1 mod p
2. If the condition that p>q is required:

- Select the condition q>p (ie the opposite of what is required)
- From the returned 5 components (p, q, d1, d2, q-1 mod p) rearrange them
according to the table above.
>> Appendix V: Encryption of Chinese Remainder Theory Components
>> Appendix V: Encryption of Chinese

Remainder Theory Components
When an RSA Public/Private Key set is generated using the command given in
Section 4.2 of this specification, there is an option to return the Private Key in the
form of 5 Chinese Remainder Theorem (CRT) components. This Appendix describes
how those components are encrypted.
The length in bits of each of the components is:
a) Exactly half the length of the modulus size requested when the modulus size
is an even number.
b) If the modulus size is odd then either p or q will be one bit longer than the
other depending on the selection made when the command is called. ( ie if
q>p is selected, q will be one bit longer than p and vice versa). In this
situation all 5 components will be the size of the longest of p and q.
The size of each component is then rounded up to the next integral multiple of 8
bits so that the components will each fit into an integral number of bytes. ( ie if the
component size is 509 bits, this is rounded up to 512 bits or 64 bytes). The
component is right justified in the appropriate number of whole bytes so any unused
bits at the most significant (left hand end) are set to zero. This block of bytes is
known as the plaintext component block.
To encrypt this block using DES requires that it must be an integral multiple of 8
bytes so some padding bytes may need to be appended to the right hand end of the
block. To allow the user of the components to know the original size of the
component, the following scheme is used (for each component):
a) Form a composite block consisting of a single length byte concatenated with
the plaintext component block. The length byte contains a binary
representation of the number of bytes in the plaintext component block.
b) If the resultant composite block is a exact multiple of 8 bytes long it is ready
for encryption.
c) If the resultant composite block is not an exact multiple of 8 bytes, append a
single byte containing hex 80, and then as many additional extra bytes
containing hex 00 as necessary to make the whole block up to a multiple of
8 bytes.
Thus anything from 1 to 7 additional bytes are appended to the plaintext component
block.
The length of this composite plaintext component block (length, component data,
and possibly some additional padding) becomes the value supplied back as the
Private Key Component Length parameter. The composite plaintext component
block is then encrypted using triple DES CBC as defined in Error! Reference source
not found..
To retrieve the components the user must:
a) Decrypt the block using triple DES CBC decryption.

>> Appendix V: Encryption of Chinese Remainder Theory Components
b) Examine the first byte of the plaintext block to determine the length in bytes
of the plaintext component. Extract from the plaintext block, starting at byte
2, the correct number of bytes for the component
>> Appendix W: ZS Command Output for PIN Block Format
>> Appendix W: ZS Command Output for

PIN Block Format
There are two forms of the ZS Command Output PIN Block Format
PIN Block Format Mode 0

The ZS Command Output PIN Block format (Mode 0) is defined as:
L L P P P P P/ P/ P/ P/ P/ P/ P/ P/ F F
F F F F F F F F
Byte 1 contains the binary encoded length of the PIN (04 to 0C)
P = PIN Digit
F = Hex F
PIN Block Format Mode 1

The ZS Command Output PIN Block format (Mode 1) is defined as:
C L P P P P P/ P/ P/ P/ P/ P/ P/ P/ F F
F F F F F F F F
C = Control field, 4 bit field set to 0010 (hex 2)

L = PIN Length, 4 bit field with permissible values of 0100 (hex 4) to 1100 (hex C)
P = PIN Digit
F = Hex F

>> Appendix X: RSA CRT Components Format Definition
>> Appendix X: RSA CRT Components

Format Definition
This Appendix describes how the 5 Chinese Remainder Theorem components

formatted before loading into the HSM memory block (Host Command ZO,
Subcommand 03, Ciphertext Type 03) i.e. this is the format of the plaintext
component.
The length in bits of each of the CRT components is:
a) Exactly half the length of the modulus size when the modulus size is an even
number.
b) If the modulus size is odd then either p or q will be one bit longer than the
other depending on the selection made when the command is called. ( i.e. if
q>p is selected, q will be one bit longer than p and vice versa). In this
situation all 5 components will be the size of the longest of p or q.
The size of each component will be equal to the next integral multiple of 8 bits so
that the components will each fit into an integral number of bytes. ( ie if the
component size is 509 bits, this is rounded up to 512 bits or 64 bytes). The
component is right justified in the appropriate number of whole bytes so any unused
bits at the most significant (left hand end) are set to zero. This block of bytes is
known as the plaintext component block.
The 5 plaintext component blocks are concatenated with no padding between them
in the order:
dp, dq, p, q, u
where:
dp = d mod (p-1)
dq = d mod (q-1)
p= prime p
q= prime q
u= q-1 mod p
Note: dp is referred to as d1, and dq as d2 in DSP module documentation

>> Appendix Y: Diversifying a Key from a Master Key
>> Appendix Y: Diversifying a Key from a

Master Key
The process of diversifying a key from a master key is given below:

a) 8 bytes of Diversification data are created. (For a KDP the diversification data
consists of the BIN (3 bytes) followed by the Card ID (5 bytes). For a KDD or a
KDE, when the algorithm code is ‘02’, the diversification data consists of the
leftmost bytes of the PAN, padded with ‘00’s as needed)
b) This data is triple DES encrypted using the master key resulting in eight bytes
that are the left half of the Diversified key. (For a KDP the Issuer Purchase Key
(KIP) is the master key. For a KDE the KME is the master key. For a KDD the
KMD is the master key)
c) The diversification data is then inverted (XOR with FF) and this new value is triple
DES encrypted using the master key. The resulting eight bytes are the right half
of the Diversified key. (For a KDP the Issuer Purchase Key (KIP) is the master
key. For a KDE the KME is the master key. For a KDD the KMD is the master
key)

>> Appendix Z: Commands & Responses for the P3SAM Card
>> Appendix Z: Commands & Responses

for the P3SAM Card
Get Key Version

Command Message:
Field Value Length (bytes)
CLA ‘EC’ 1
INS ‘22’ 1
P1` ‘00’ 1
P2 ‘00’ 1
Lc ‘03’ 1
PPIEP Purse Provider Identifier (BIN) 3
Le ‘01’ 1
Response Message
A successful response to the Get Key Version command shall have the following
format:
VKKMA Key Version for the KMA 1
SW1-SW2 Status Bytes 2
A rejected response to the Get Key Version command shall have the following
format:

Possible Status Byte return codes are given below
Status Meaning
Bytes
90 00 No Error
93 1B Key Not Present
Get Challenge
Command Message:
CLA ‘EC’ 1
INS ‘24’ 1
P1` ‘00’ 1
P2 ‘00’ 1
Le ‘04’ 1
Response Message
A successful response to the Get Challenge command shall have the following
format:
RNDP3SAM Random Number from the P3SAM 4
A rejected response to the Get Challenge command shall have the following format:

Mutual Authenticate A
Command Message:
CLA ‘EC’ 1
INS ‘14’ 1
P1` ‘00’ 1
P2 ‘00’ 1
Lc ‘10’ 1
T1 Authentication token 1 16
Le ‘08’ 1
Response Message
A successful response to the Mutual Authenticate A command shall have the
following format:
ALGPIEP Algorithm Identifier for Purchase 1

transactions
Validity Validity period for the IEP (No. of months) 1
T2 Authentication token 2 8
A rejected response to the Mutual Authenticate A command shall have the following
format:

Status Meaning
Bytes
90 00 No Error
93 1D Wrong random number
93 60 Card series data not available
93 61 Date mismatch
95 82 Key version not supported
Mutual Authenticate B
Command Message
CLA ‘EC’ 1
INS ‘16’ 1
P1` ‘00’ 1
P2 ‘00’ 1
Lc ‘18’ 1
[KEK]KSES KEK encrypted under KSES 16
S1 Signature (MAC) 8
Le Absent if ALGP < ‘05’ 1

’14’ if ALGP >= ‘05’
Response Message
A successful response to the Mutual Authenticate B command shall have the
following format when ALGP is less than 5:

A successful response to the Mutual Authenticate B command shall have the

following format when ALGP is greater than or equal to 5:
[KIP]KEK Encrypted Issuer Purchase Key 16
KCVKIP Key Check Value for the KIP 3
VKKIP Key Version for the KIP 1
A rejected response to the Mutual Authenticate B command shall have the following
format:
Status Meaning
Bytes
90 00 No Error
95 57 Invalid Signature
Get KDP
Command Message
CLA ‘EC’ 1
INS ‘20’ 1
P1` ‘00’ 1
P2 ‘00’ 1
Lc ‘0B’ 1
PPIEP Purse Provider Identifier (BIN) 3
IDIEP Card Serial Number 5
DEXPIEP Expiry Date for the card 3
Le ‘14’ 1
Response Message
A successful response to the Get KDP command shall have the following format:
[KDPIEP ]KEK Diversified card purchase key (encrypted 16

under the KEK)
KCVKDP Key Check Value for the KDP 3
VKKMP Key version number of the KMP 1
A rejected response to the Get KDP command shall have the following format:
Status Meaning
Bytes
90 00 No Error
93 1C Expiry Date out of range
95 83 BIN not found

>> Appendix AA: Encoding of a Private Key
ASN.1 encoding of a PRIVATE Key

An RSA Private Key has the following ASN.1 encoded format:
RSAPrivateKey::= SEQUENCE{
p BIT STRING,
q BIT STRING,
d1 BIT STRING,
d2 BIT STRING,
q-1 mod p BIT STRING}
When using ASN.1 encoding, the value 30 indicates a sequence and the value 03
indicates a bit string. As a result, a ASN.1 encoded private key will appear as
follows:
30 | Length of Complete Sequence | 03 | Bit String Length | p | 03 | Bit
String Length | q | 03 | Bit String Length | d1| 03 | Bit String Length | d2| 03
| Bit String Length | q-1 mod p |
When defining the length of the bit string, the length of the bit string in bytes is
given first, followed by the number of bits that are ignored in the last byte. For
example “101010” is encoded as 03 02 02 A8, where 03 is a bit string, 02 is the
length, 02 is the number of bits dropped from the end of the data, and A8 is the
zero padded data (note that the padding can be any value as it is ignored).
The following example shows the five data items that make up a key and then shows
the key ASN.1 encoded:
p:
FADD62A62492706C 5784790CDC40D76C
5CA0736FA0E07CAA EB1729C1C7FF18E1
70EFC25B7711C907 B515542ACFD80823
q:
EC43DD6A0F955408 09579E9A8D0DECC3
B4050712A28C97F0 6521505342D6E102
58F3BBBB845CBAB0 3B136EC6A7E1F6E9
dp (d1):
A73E41C41861A048 3A5850B33D808F9D
9315A24A6B40531C 9CBA1BD68554BB40
F5F52C3CFA0BDB5A 78B8E2C7353AB017
dq (d2):
9D82939C0A638D5A B0E5146708B3F32D
22AE04B71708654A EE16358CD739EB56
E5F7D27D02E87C75 7CB79F2F1A96A49B
U (q inverse mod p):
CEB3DA4206C267C1 1EF3DCCB77268707
09E735BED60E68D5 3C0E573FB64A634F
376B15CCC0219C5A 02F09B834048ECB9
ASN.1 encoded public key

In the following example, the bit string indicators have been underlined and the
length indicators are in italic to aid with clarity.
30 81 FF 03 31 00 FA DD 62 A6 24 92 70 6C 57 84
79 0C DC 40 D7 6C 5C A0 73 6F A0 E0 7C AA EB 17
29 C1 C7 FF 18 E1 70 EF C2 5B 77 11 C9 07 B5 15
54 2A CF D8 08 23 03 31 00 EC 43 DD 6A 0F 95 54
08 09 57 9E 9A 8D 0D EC C3 B4 05 07 12 A2 8C 97
F0 65 21 50 53 42 D6 E1 02 58 F3 BB BB 84 5C BA
B0 3B 13 6E C6 A7 E1 F6 E9 03 31 00 A7 3E 41 C4
18 61 A0 48 3A 58 50 B3 3D 80 8F 9D 93 15 A2 4A
6B 40 53 1C 9C BA 1B D6 85 54 BB 40 F5 F5 2C 3C
FA 0B DB 5A 78 B8 E2 C7 35 3A B0 17 03 31 00 9D
82 93 9C 0A 63 8D 5A B0 E5 14 67 08 B3 F3 2D 22
AE 04 B7 17 08 65 4A EE 16 35 8C D7 39 EB 56 E5
F7 D2 7D 02 E8 7C 75 7C B7 9F 2F 1A 96 A4 9B 03
31 00 CE B3 DA 42 06 C2 67 C1 1E F3 DC CB 77 26
87 07 09 E7 35 BE D6 0E 68 D5 3C 0E 57 3F B6 4A
63 4F 37 6B 15 CC C0 21 9C 5A 02 F0 9B 83 40 48
EC B9
Private Key Exponent/Modulus format

The private key exponent (d) and modulus (n) are given in the following format:
Length | Private Key Exponent (d) or Modulus (n) | Padding
The length is an n byte value (though usually 0 or 1) which indicates the length (in
bytes) of the following field, which may be the Private Key Exponent (d) or the
Modulus (n). This value is given in HEX E.g. 0x40 corresponds to a key size of 64.
The padding consists of zeros and pads so that the total length of all three
components is a multiple of eight bytes. If the number of bytes specified for the
length is zero then this field will be omitted, giving an output as follows:

Private Key Exponent (d) or Modulus (n) | Padding

The data block is encrypted using ECB or CBC under a KEK or a specified LMK pair
and variant.
>> Appendix BB: JCB PIN Block Format
>> Appendix BB: JCB PIN Block Format
The JCB PIN Block format is defined as:
C L P P P P P/ P/ P/ P/ P/ P/ P/ P/ F F
F F F F F F F F
C = Control field, 4 bit field set to 0010 (hex 2)

L = PIN Length, 4 bit field with permissible values of 0100 (hex 4) to 1100 (hex C)
P = PIN Digit
F = Hex F
This PIN Block Format is allocated Code 36

>> Appendix CC: Multos Version 3.0 Public Key Certificate
>> Appendix CC: Multos Version 3.0

Public Key Certificate
A smart card Multos v3.0 public key certificate (mkd_pk_c) is a total of 136 bytes,
comprising:
Certificate public key length (2 bytes)
Multos key header (38 bytes)
Multos key certificate (96 bytes).
The Multos key certificate is decrypted (signed) using the Multos CA secret key
(tkck_sk).
The plain value of the Multos key certificate comprises:
Hash result (16 bytes)
Smart card public key modulus (72 bytes)
Random values (8 bytes).
The 38 byte Multos key header has the following format:
Miscellaneous data 18 bytes
Public key exponent length 2 bytes
Public exponent 4 bytes
msm_controls_data_date 1 byte
mcd_no 8 bytes
Notes:
1. The 23 bytes of miscellaneous data will be ignored by the HSM.
2. The “public exponent” is left justified and padded with 00 to a total of 4 bytes.
3. The “public key exponent length” denotes (in bytes) the actual length of the public
exponent.
Examples:
If public exponent = 3 (decimal) then “public exponent” = 03 00 00 00 and “public
key exponent length” = 00 01
>> Appendix CC: Multos Version 3.0 Public Key Certificate
If public exponent = 65537 (decimal) then “public exponent” = 01 00 01 00 and

“public key exponent length” = 00 03
Extraction of Public Key from Certificate

1. Encrypt the rightmost 96 bytes (i.e. the Multos key certificate) of mkd_pk_c with
the Multos CA public key (tkck_pk). Extract the smart card public key modulus
(72 bytes) from the result. The HSM will perform no validity checks on the
extracted modulus.
2. Extract the “public exponent” from the Multos key header. The HSM will validate
that the “public exponent” and the “public key exponent length” are compatible. In
the event of an error the HSM will return error code 06 to the host.
3. The RSA public key comprises the modulus (from step 1) and the exponent (from
step 2).
Note:
The HSM will perfom no validity check of the certificate, except as described in step
2.

>> Appendix DD: Multos Version 4.0 Public Key Certificate
>> Appendix DD: Multos Version 4.0

Public Key Certificate
A Multos v4.0 smart card public key certificate (mkd_pk_c) can take one of two
forms, depending on the relative lengths of the smart card public key modulus and
the Multos CA public key modulus.
Notation
Let N = length (in bytes) of the Multos CA public key modulus and let M = length (in
bytes) of the smart card public key modulus.
Important Note
The case of N M+56 is not allowed. If the keys submitted in the command
specified in Generic Card Issuing Commands for M/Chip Lite, M/Chip
Select, & Generic MULTOS Applications of this document satisfy this
condition then error code 83 will be returned to the host and the command
terminated.
Case 1: (M+32) N < (M+56)

In this case the smart card public key certificate (mkd_pk_c) has the following
format:
Multos key certificate (N bytes).
(tkck_sk).
Padding (N-M-32 bytes)
Smart card public key modulus (M bytes)
Redundancy (16 bytes).
The 38 byte Multos key header has the following format:
Public key length 2 bytes
Certifying key length 2 bytes
Miscellaneous data 1 byte

Public key exponent length 2 bytes
Public exponent 4 bytes
msm_controls_data_date 1 byte
mcd_no 8 bytes
Notes:
1. The 19 bytes of miscellaneous data will be ignored by the HSM.
2. The “Public exponent” is left justified and padded with 00 to a total of 4 bytes.
3. The “Public key exponent length” denotes (in bytes) the actual length of the public
exponent.
Examples:
If public exponent = 3 (decimal) then “Public exponent” = 03 00 00 00 and “Public
key exponent length” = 00 01
If public exponent = 65537 (decimal) then “Public exponent” = 01 00 01 00 and
“Public key exponent length” = 00 03
If public exponent = 257 (decimal) then “Public exponent” = 01 01 00 00 and
“Public key exponent length” = 00 02
1. Encrypt the rightmost N bytes (i.e. the Multos key certificate) of mkd_pk_c with
the Multos CA public key (tkck_pk). Ascertain the length of the smart card public
key modulus (M) from the value of the “Public key length” field in the Multos key
header and extract the modulus from the plaintext Multos key certificate. The
HSM will perform no validity checks on the extracted modulus.
2. Extract the public exponent from the Multos key header. The HSM will validate
that the values of the “Public exponent” and the “Public key exponent length”
fields are compatible. In the event of an error the HSM will return error code 06
to the host.
3. The smart card RSA public key comprises the modulus (from step 1) and the
exponent (from step 2).
Note:
The HSM will perfom no validity check of the certificate, except as described in
step 2.
Case 2: N < (M+32)
In this case the smart card public key certificate (mkd_pk_c) has the following
format:
Smart card public key modulus, left part (M-N+32 bytes)
Multos key certificate (N bytes).

(tkck_sk).
Smart card public key modulus, right part (N-32 bytes)
Redundancy (16 bytes)
The 38 byte Multos key header has the same format as in Case 1.
1. Encrypt the rightmost N bytes (i.e. the Multos key certificate) of mkd_pk_c with
the Multos CA public key (tkck_pk) and extract the smart card public key modulus
(right part). Concatenate the smart card public key modulus (left part) and the
smart card public key (right part) to form the smart card public key modulus.
Validate that the length of the modulus (in bytes) is equal to the value of the
“Public key length” field in the Multos key header. In the event that the two
values are different then return error code 07 to the host and terminate
processing. The HSM will perform no additional validity checks on the extracted
modulus.
2. Extract the public exponent from the Multos key header. The HSM will validate
that the values of the “Public exponent” and the “Public key exponent length”
fields are compatible. In the event of an error the HSM will return error code 06
to the host.
3. The smart card RSA public key comprises the modulus (from step 1) and the
exponent (from step 2).
Note:
The HSM will perform no validity check of the certificate, except as described in
steps 1 and 2.
>> Appendix EE: Multos CA Public Key Format
>> Appendix EE: Multos CA Public Key

Format
The Multos CA Public Key (tkck_pk) has the following format, prior to being
reformatted into standard HSM format (ASN.1 DER encoded) - see the command
specified in Generic Card Issuing Commands for M/Chip Lite, M/Chip Select, &
Generic MULTOS Applications.
Length of Management Length of next field 1

Data
Management Data See below 8
Length of Modulus Length of next field 1
Modulus Multos CA Public Key Modulus as defined above
Length of Exponent Length of next field 1
Exponent Multos CA Public Key Exponent as defined above
The Management Data field has the following format:
Key Type Value X’01 1
Generation Date Date of key generation 4

(DDMMYYYY format)
Public Key Index Public key index 3

>> Appendix FF: Multos Version Public Key Format (Version 1)
>> Appendix FF: Multos Version Public Key

Format (Version 1)
The Multos CA Public Key (TKCK) may be supplied in the following format, prior to
being reformatted into standard HSM format (ASN.1 DER encoded) - see the
command specified in Generic Card Issuing Commands for M/Chip Lite, M/Chip
Select, & Generic MULTOS Applications. This format is as described in the
document “MULTOS CA File Interface Formats”, document number “maos-gkc-spc-
002”, Version 4.1 dated 15/06/2000.
Data Field Description Length

(in
bytes)
File_Type_Code ASCII, 4 Character. Set to “TKCK” 4
File_Protection _Method Binary. Set to 0x01 1
File_Structure_Method Binary. Set to 0x01 1
Consignment_File_ID ASCII. 8 Characters. Set to “TKCK”, followed by 4 8

characters presenting the identifier (in hex). This
will be the same as the MKD_Cert_Method_ID.
For example: “TKCK0113” would be version

19 (decimal) of a MULTOS 4 96 byte TKCK
Date Date, 4
Time Time 3
MKD_Cert_Method_ID Binary. Comprised of: 2

scheme ID, 1 byte +
key version number, 1 byte
Currently defined scheme IDs are:
0x00 for MULTOS 3 platforms with a 96 byte

TKCK
TKCK
TKCK
>> Appendix FF: Multos Version Public Key Format (Version 1)
Key_Length Binary. This should match the value inferred from 2

the scheme ID byte of the MKD_Cert_Method_ID
Key_Data Binary.The actual TKCK Public Key Key-

Length
Hash_Code Binary. A SHA-1 hash of the 20

MKD_Cert_Method_ID, Key_Length and Key_Data.
Key data contains the public key modulus. The exponent is always assumed to be
3.

>> Appendix GG: Multos Public Key Authentication
>> Appendix GG: Multos Public Key

Authentication
Authenticating the Multos Card Public Key is described in the Multos document
“Guide to Generating Application Load Units” V2.51. Sections 4.4.4 and 5.4.4
describe the process.
>> Appendix HH: EMV 2000 Session Key Calculation
>> Appendix HH: EMV 2000 Session Key

Calculation
Φ(x, y, j) = (DES3(x)[yL (j mod b)] || DES3(x)[yR (j mod b) ‘F0’] )

Where:
b = “branch factor” i.e. number of “child keys” that a parent derives, fixed value
of either 2 or 4.
j = a counter 0..b-1, per iteration bit or 2 bit value
x = a “parent” key (or the MK for first iteration of Φ)
y = a “grandparent” key (or IV for first iteration of Φ)
Note: Odd parity should be applied to the calculated intermediate keys and the final
session keys.
For further information see:
EMV2000 Book 2 Annex A1.3 “Session Key Deviation”.
M/Chip 4 Cryptography & Key Management v4.0 (May 2002) section 7-
4 “ICC Session Key Derivation for EMV 2000”.
Session Key (SK) computation for a branch factor of 2:
GP = MK GP=“grandparent”, MK=Master Key
P = Φ(MK, IV, a0) P=“parent”, a0= MSB of ATC
for (i=1; i<h-1; i++)
{
T=P T is just temp storage
P= Φ(P, GP, ai) ai = the ith bit of ATC
GP=T
}
SK= Φ(P, GP, ah-1) GP

IK0,0= MK
0 1
IK1,0 = Φ(MK, IV, 0)
IK1,1 = Φ(MK, IV, 1)
0 1
1 0
IK2,0 = Φ(IK1,0, MK, 0) IK2,1 = Φ(IK1,0, IK2,2 = Φ(IK1,1, MK, 0) IK2,1 = Φ(IK1,1, MK, 1)
MK, 1)
1
Intermediate
IK3,4 = Φ(IK2,1, IK1,0, 1)
keys
0
IK4,7 = Φ(IK3,4, IK2,1, 0)
0
IK5,12 = Φ(IK4,7, IK3,4, 0)
1
IK6,25 = Φ(IK5,12, IK4,7, 1)
1
IK7,47 = Φ(IK6,25, IK5,12, 1)
1
SK = Φ(IK7,47, IK6,25, 1) IK6,25
For ATC = 01100111:
Note: For the purposes of simplification an 8 bit ATC was used for this
example, in reality this is 16 bits.
Session Key (SK) computation for a branch factor of 4:
GP = MK GP=“grandparent”, MK=Master Key
P = Φ(MK, IV, a0) P=“parent”, a0= MSB & MSB-1of ATC
for (i=1; i<h-1; i+=2)
{
T=P T is just temp storage
P= Φ(P, GP, ai) ai = 0..3, the numeric value of bit(i) and bit(i-1) of ATC
GP=T
}
SK= Φ(P, GP, ah-1) GP
IK0,0= MK
0 3
1 2
Intermediate
IK1,0 = Φ(MK, IV, 0) IK1,1 = Φ(MK, IV, 1) IK1,2 = Φ(MK, IV, 2) IK1,3 = Φ(MK, IV, 3)
keys
IK2,2 = Φ(IK1,1, MK, 2)
3
IK3,3 = Φ(IK2,2, IK1,1, 3)
0
SK = Φ(IK3,3, IK2,2, 0) IK2,2
For ATC = 01 10 11 00:

↓ ↓ ↓ ↓
1 2
3 0
Note: For the purposes of simplification an 8 bit ATC was used for this
example, in reality this is 16 bits.

>> Appendix II: EMV 2000 Session Key Output Key Formats
>> Appendix II: EMV 2000 Session Key

Output Key Formats
The output for host command WM is a variable length block of keys. The
block of keys contains all the session keys for each of the input keys, of
which there can be 9, it is possible to have up to 16 session keys per input
key, therefore it is possible to have 144 keys (9 * 16), although typically only
3 session keys would be required per input key.
Output Key Block:
Key1 Data Key2 Data … Keyn-1 Data Keyn Data
Output Keyn Data:
nth Ancestor Key … Grandparent Parent Key Session Key

Key
Where:
Keyn Data equals the data create for the nth Input Key
Number of keys within each Keyn Data block is equal to ‘Levels Required’.
Each of these keys are ECB encrypted.

>> Appendix AAA: Application Specific Error Codes
>> Appendix AAA: Application Specific

Error Codes
This section defines any error codes that are specific to this application. The
application may return any of these error codes, or any of the standard payShield
9000 error codes (defined in the payShield 9000 Host Command Reference
Manual).
Note that error codes may have multiple meanings assigned.
Error Meaning
Code

>> Appendix BBB: List of Authorisable Activities
>> Appendix BBB: List of Authorisable

Activities
Command
Cat- Sub-Cat- Inter-
(H=Host, Description
egory egory face
C=Console)
SYMMETRIC KEY GENERATION
zmk kml
zpk pvk tpk
tmk tak
csck cvk
H – A0 Generate Key (Auth required as per key table) generate wwk zak host
bdk mk-ac
mk-smi mk-
smc mk-dak
mk-dn zek
zmk kml
zpk pvk tpk
tmk tak
csck cvk
C – KG Generate Key (Auth required as per key table) generate wwk zak console
bdk mk-ac
mk-smi mk-
smc mk-dak
mk-dn zek
zmk kml
zpk pvk tpk
H – A2 Generate and Print a Component
tmk tak
csck cvk
genprint wwk zak host
bdk mk-ac
mk-smi mk-
H – NE Generate and Print a Key as Split Components smc mk-dak
mk-dn zek
zmk kml
zpk pvk tpk
tmk tak
csck cvk
H – A4 Form a Key from Encrypted Components component wwk zak host
bdk mk-ac
mk-smi mk-
smc mk-dak
mk-dn zek
C – BK Form a Key from Components zmk kml

component zpk pvk tpk console
C – EC Encrypt Clear Component tmk tak
Command
Cat- Sub-Cat- Inter-
(H=Host, Description
egory egory face
C=Console)
C – FK Form Key from Component csck cvk

wwk zak
C – GS Generate Key Components and Write to a Smartcard bdk mk-ac
mk-smi mk-
smc mk-dak
C – GC Generate Key Component mk-dn zek
SYMMETRIC KEY IMPORT
zmk kml
zpk pvk tpk
tmk tak
csck cvk
H – A6 Import a Key (Auth required as per key table) import wwk zak host
bdk mk-ac
mk-smi mk-
smc mk-dak
mk-dn zek
zmk kml
zpk pvk tpk
tmk tak
csck cvk
C – IK Import Key (Auth required as per key table) import wwk zak console
bdk mk-ac
mk-smi mk-
smc mk-dak
mk-dn zek
SYMMETRIC KEY EXPORT
zmk kml
Generate Key (Auth required as per key table)
H – A0 zpk pvk tpk
(when requested to export generated key) tmk tak
csck cvk
export wwk zak host
bdk mk-ac
mk-smi mk-
H – A8 Export a Key (Auth required as per key table) smc mk-dak
mk-dn zek
zmk kml
Generate Key (Auth required as per key table)
C – KG zpk pvk tpk
(when requested to export generated key) tmk tak
csck cvk
export wwk zak console
bdk mk-ac
mk-smi mk-
C – KE Export Key (Auth required as per key table) smc mk-dak
mk-dn zek

V V V
Americas Asia Pacific Europe, Middle East, Africa

THALES e-SECURITY, INC. THALES TRANSPORT & SECURITY THALES e-SECURITY LTD.
2200 North Commerce Parkway (HONG KONG) LTD. Meadow View House
Suite 200 Unit 4101, 41/F Long Crendon
Weston 248 Queen's Road East Aylesbury
Florida Wanchai Buckinghamshire
33326. USA Hong Kong, PRC HP18 9EQ. UK
T: +1 888 744 4976

or +1 954 888 6200 T: +852 2815 8633 T: +44 (0)1844 201800
F: +1 954 888 6211 F: +852 2815 8141 F: +44 (0)1844 208550
E: sales@thalesesec.com E: asia.sales@thales-esecurity.com E: emea.sales@thales-esecurity.com
© Copyright 1987 - 2012 THALES e-SECURITY LTD
This document is issued by Thales e-Security Limited (hereinafter referred to as Thales) in confidence and is not to be reproduced in
whole or in part without the prior written approval of Thales. The information contained herein is the property of Thales and is to be
used only for the purpose for which it is submitted and is not to be released in whole or in part without the prior written p ermission
of Thales.

1270A622-001.1 Card Issuance Firmware 1119-0902 - CIP

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

1270A622-001.1 Card Issuance Firmware 1119-0902 - CIP

Uploaded by

Copyright:

Available Formats

payShield 9000

User Manual for

>> Revision Status

Document No. Software Version Built on Base … Publication Date

The following documents are referenced in this document:

1 payShield 9000 Installation Manual

2 payShield 9000 Console Reference Manual

3 payShield 9000 Security Operations Manual

4 payShield 9000 Host Command Reference Manual

5 payShield 9000 Host Programmers Manual

6 payShield 9000 General Information Manual

The following abbreviations are used in this document:

3DES Triple DES

ANSI American National Standard Institute

CBC Cipher Block Chaining

DES Data Encryption Standard

ECB Electronic Code Book

HSM Host Security Module

LMK Local Master Key

PIN Personal Identification Number

Thales e-Security iii

>> List of Chapters

>> Introduction ........................................................................................ 13

>> Console Commands ............................................................................. 17

>> Host Commands.................................................................................. 20

>> Appendix A: Local Master Key Variants ................................................ 110

>> Appendix B: Algorithm Identifiers ........................................................ 111

>> Appendix D: Public Key Encoding ......................................................... 114

>> Appendix E: Self-Signed CA Public Key Format (Visa) ............................. 115

>> Appendix G: Issuer Public Key Format (Visa) ......................................... 120

>> Appendix H: Format of Static Data Authentication Block ........................ 124

>> Appendix I: Format of Visa Cash Card Certificate .................................. 125

>> Appendix J: Self-Signed CA Public Key Format (MCI/EPI/JCB) ................ 128

>> Appendix M: Encryption of Tag-Length-Value (TLV) Fields ........................ 134

>> Appendix N: Multos Padding ............................................................... 135

>> Appendix O: Triple DES CBC Mode of Encryption/Decryption .................. 136

>> Appendix P: Multos KTU Format ......................................................... 137

>> Appendix Q: Checksum Algorithm ........................................................ 139

>> Appendix R: Format of ICC Certificate .................................................. 140

>> Appendix S: Mastercard PIN Block Format ........................................... 142

>> Appendix T: Multos Encryption Algorithm ............................................. 143

>> Appendix V: Encryption of Chinese Remainder Theory Components .......... 145

>> Appendix X: RSA CRT Components Format Definition............................. 148

>> Appendix Y: Diversifying a Key from a Master Key ................................. 149

>> Appendix AA: Encoding of a Private Key ............................................... 156

>> Appendix BB: JCB PIN Block Format ................................................... 159

>> Appendix EE: Multos CA Public Key Format .......................................... 165

>> Appendix GG: Multos Public Key Authentication .................................... 168

>> Appendix AAA: Application Specific Error Codes .................................... 173

>> Appendix BBB: List of Authorisable Activities ........................................ 174

>> Table of Contents

>> Revision Status ...................................................................................... ii

>> References ........................................................................................... iii

>> Abbreviations ........................................................................................ iii

>> List of Chapters .................................................................................... 4

>> Table of Contents .................................................................................. 6

>> End User License Agreement ................................................................ 10

>> Introduction ........................................................................................ 13

>> Console Commands ............................................................................. 17

>> Host Commands.................................................................................. 20

Generate Card Unique DES Keys ......................................................... 55

>> Appendix A: Local Master Key Variants................................................ 110

>> Appendix B: Algorithm Identifiers ........................................................ 111

>> Appendix D: Public Key Encoding ......................................................... 114