1270A542-033 Host Programmer v3.1

Thales e-Security
payShield 9000 v3.1
Host Programmer’s Manual

1270A542-033 30 March 2017
payShield 9000 Host Programmer’s Manual
Contents
CONTENTS .......................................................................................................... 2
END USER LICENSE AGREEMENT ......................................................................... 9
REVISION STATUS ............................................................................................ 13
REFERENCES ..................................................................................................... 14
CHAPTER 1 – INTRODUCTION........................................................................... 15
INTRODUCTION ................................................................................................... 15
PCI HSM CERTIFICATION AND COMPLIANCE ................................................................. 15
GENERAL........................................................................................................... 15
COMMAND MESSAGE FORMAT................................................................................... 16
Start of Text Character ................................................................................................................................ 16
Message Header .......................................................................................................................................... 16
Command Code ........................................................................................................................................... 16
Data ............................................................................................................................................................. 16
Message Trailer ........................................................................................................................................... 16
End of Text Character .................................................................................................................................. 17
RESPONSE MESSAGE FORMAT .................................................................................. 17
Start of Text Character ................................................................................................................................ 18
Message Header .......................................................................................................................................... 18
Response Code ............................................................................................................................................. 18
Error Code .................................................................................................................................................... 18
Data ............................................................................................................................................................. 18
Message Trailer ........................................................................................................................................... 18
End of Text Characters ................................................................................................................................. 18
DATA REPRESENTATION ......................................................................................... 18
ASCII Character Codes.................................................................................................................................. 19
EBCDIC Character Codes .............................................................................................................................. 19
INPUT/OUTPUT FLOW CONTROL ................................................................................ 20
ERROR HANDLING ................................................................................................ 21
ERROR LOG........................................................................................................ 21
USE OF MULTIPLE HSM UNITS ................................................................................. 22
USER STORAGE ................................................................................................... 22
CHAPTER 2 – HOST CONNECTIONS ................................................................... 23
GENERAL........................................................................................................... 23
ASYNCHRONOUS CONNECTED OPTION ......................................................................... 23
TRANSPARENT ASYNCHRONOUS CONNECTED OPTION ....................................................... 23
Sending Commands ..................................................................................................................................... 23
HSM Processing of Packets .......................................................................................................................... 24
TCP/IP PROTOCOL ............................................................................................... 24
Port Addresses ............................................................................................................................................. 24
Returning Responses ................................................................................................................................... 25
UDP PROTOCOL .................................................................................................. 26
Returning Responses ................................................................................................................................... 26
FICON............................................................................................................. 27
Connections ................................................................................................................................................. 27
Configuration Settings ................................................................................................................................. 27
CHAPTER 3 – PIN PRINTING AND SOLICITATION............................................. 28
INTRODUCTION ................................................................................................... 28
PIN MAILERS ..................................................................................................... 28
Overview ...................................................................................................................................................... 28
Setting up the PIN Mailer form at the payShield 9000 ................................................................................ 29

Generate an Encrypted PIN ......................................................................................................................... 31
Sending PIN Mailer data for printing at the HSM ........................................................................................ 31
PINs created outside of the payShield 9000 ................................................................................................ 32
Verify PIN data cryptography ...................................................................................................................... 32
PIN SOLICITATION ............................................................................................... 33
Overview ...................................................................................................................................................... 33
Validation Algorithm ................................................................................................................................... 33
Stages in PIN Solicitation ............................................................................................................................. 35
Setting up the PIN Solicitation Mailer form at the HSM .............................................................................. 35
Generating an Encrypted PIN ...................................................................................................................... 36
Sending PIN Solicitation Mailer data for printing at the HSM ..................................................................... 36
Verify PIN Solicitation data cryptography ................................................................................................... 36
Processing the selected PIN returned by the cardholder ............................................................................. 37
PRINTER SUPPORT ................................................................................................ 38
Impact printers ............................................................................................................................................ 38
Directly-attached laser or ink jet printers .................................................................................................... 38
High-volume "print factories" ...................................................................................................................... 40
CHAPTER 4 – TRANSACTION KEY SCHEMES ...................................................... 43
GENERAL........................................................................................................... 43
RACAL TRANSACTION KEY SCHEME (RTKS) ................................................................. 43
RTKS Functions............................................................................................................................................. 44
SIMULTANEOUS USE OF BOTH RACAL AND AUSTRALIAN TRANSACTION KEY SCHEMES .................. 45
DERIVED UNIQUE KEY PER TRANSACTION (DUKPT) ....................................................... 48
Overview ...................................................................................................................................................... 48
Single-DES and Triple-DES variants of DUKPT ............................................................................................. 49
DUKPT Keys .................................................................................................................................................. 49
The Base Derivation Key (BDK) .................................................................................................................... 49
The Initial Key (IKEY or IK) ............................................................................................................................ 50
Key Serial Number ....................................................................................................................................... 51
Transaction Keys .......................................................................................................................................... 51
Processing by the Acquirer .......................................................................................................................... 52
Summary of DUKPT Operations ................................................................................................................... 53
Variations on DUKPT ................................................................................................................................... 53
DUKPT for Point-to-Point Encryption and Mobile Acceptance .................................................................... 54
The role of the payShield 9000 in DUKPT..................................................................................................... 56
payShield 9000 Host Commands for DUKPT ................................................................................................ 57
Host Command Examples ............................................................................................................................ 61
GERMAN BANKING INDUSTRY COMMITTEE (GBIC) .......................................................... 62
CHAPTER 5 – THE RSA CRYPTOSYSTEM ............................................................ 63
GENERAL........................................................................................................... 63
HSM BUFFER SIZES ............................................................................................. 63
DATA FORMATS ................................................................................................... 63
EVEN PUBLIC EXPONENT......................................................................................... 63
RSA CRYPTOSYSTEM FUNCTIONS .............................................................................. 64
COMMON PARAMETERS .......................................................................................... 64
DES Key Type................................................................................................................................................ 64
Signature Algorithm .................................................................................................................................... 64
Encryption Identifier .................................................................................................................................... 64
Hash Identifier ............................................................................................................................................. 65
Pad Mode Identifier ..................................................................................................................................... 66
Key Block Type ............................................................................................................................................. 69
WORKED EXAMPLES .............................................................................................. 72
Sample Data Definitions (1024-bit RSA keys) .............................................................................................. 73
Sample Data Generation Procedure (1024-bit RSA keys) ............................................................................ 75
Sample Data Calculation (1024-bit RSA keys).............................................................................................. 76
Thales e-Security Page 3 30 March 2017

Sample Data Definitions (2048-bit RSA keys) .............................................................................................. 78

Sample Data Generation Procedure (2048-bit RSA keys) ............................................................................ 79
Sample Data Calculation (2048-bit RSA keys).............................................................................................. 81
CHAPTER 6 – LOCAL MASTER KEYS (LMKS) ...................................................... 84
INTRODUCTION ................................................................................................... 84
MULTIPLE LMKS .................................................................................................. 84
KEY BLOCK & VARIANT KEY COMPARISON TABLE ............................................................ 85
CONVERTING KEY NAMES ....................................................................................... 86
CHAPTER 7 – VARIANT LMK KEY SCHEME ......................................................... 87
INTRODUCTION ................................................................................................... 87
HOW THE VARIANT SCHEME WORKS ........................................................................... 87
LOCAL MASTER KEY (LMK) VARIANTS ........................................................................ 88
Double-length Variant LMK: ........................................................................................................................ 89
Triple-length Variant LMK: .......................................................................................................................... 90
LOCAL MASTER KEY TRIPLE DES VARIANT SCHEME ......................................................... 90
TEST VARIANT LMK .............................................................................................. 93
Double-length Variant Test LMK: ................................................................................................................ 94
Triple-length Variant Test LMK: ................................................................................................................... 95
VARIANT KEY TYPE CODES ...................................................................................... 95
KEY TYPE TABLE .................................................................................................. 98
Non PCI-HSM Compliant (for backwards compatibility) .............................................................................. 99
PCI Compliant ............................................................................................................................................ 100
Notes ......................................................................................................................................................... 100
CHAPTER 8 – KEY BLOCK LMK KEY SCHEME .................................................... 102
INTRODUCTION .................................................................................................. 102
RELATIONSHIP BETWEEN THALES KEY BLOCKS AND TR-31 KEY BLOCKS ............................... 102
SUPPORT FOR THALES KEY BLOCKS ........................................................................... 103
KEY BLOCK FORMAT............................................................................................. 103
KEY BLOCK HEADER............................................................................................. 104
Key Block Length (Bytes 1-4) ...................................................................................................................... 104
Key Usage (Bytes 5-6) ................................................................................................................................ 104
Algorithm (Byte 7) ..................................................................................................................................... 106
Mode of Use (Byte 8) ................................................................................................................................. 107
Key Version Number (Bytes 9-10) .............................................................................................................. 108
Exportability (Byte 11) ............................................................................................................................... 109
Number of Optional Blocks (Bytes 12-13) .................................................................................................. 109
LMK Identifier (Bytes 14-15) ...................................................................................................................... 109
Example ..................................................................................................................................................... 109
OPTIONAL HEADER .............................................................................................. 110
Optional Header Block Types ..................................................................................................................... 111
ENCRYPTED KEY DATA ........................................................................................... 112
AUTHENTICATOR ................................................................................................. 113
KEY BLOCK LOCAL MASTER KEYS (LMKS)................................................................... 113
3DES Key Block Test LMK ........................................................................................................................... 114
AES Key Block Test LMK ............................................................................................................................. 114
CONSOLE COMMAND EXAMPLES ............................................................................... 115
CK Console Command (Generate Check Value) ......................................................................................... 115
KG Console Command (Generate Key)....................................................................................................... 115
HOST COMMANDS ............................................................................................... 116
Host Command Examples .......................................................................................................................... 116
Error Codes ................................................................................................................................................ 116
CHAPTER 9 – MULTIPLE LMKS ........................................................................ 117
INTRODUCTION .................................................................................................. 117
THE NEED FOR MULTIPLE LMKS............................................................................... 117

About LMKs................................................................................................................................................ 117

Multiple LMKs ............................................................................................................................................ 117
MULTIPLE LMK LICENSING ..................................................................................... 118
MANAGING MULTIPLE LMKS ................................................................................... 118
LMK component generation ...................................................................................................................... 118
LMK Loading .............................................................................................................................................. 118
Migration from Old to New LMK ............................................................................................................... 119
AUTHORIZATION ................................................................................................. 119
LMK TABLE ....................................................................................................... 120
DELETING LMKS ................................................................................................ 120
IDENTIFYING THE REQUIRED LMK ............................................................................ 121
Console Commands ................................................................................................................................... 121
Host Commands......................................................................................................................................... 121
CHAPTER 10 – MIGRATING LMKS ................................................................... 124
INTRODUCTION .................................................................................................. 124
MULTIPLE LMKS ................................................................................................. 124
OVERVIEW OF THE LMK MIGRATION PROCESS .............................................................. 124
GENERATING NEW LMK COMPONENT SMARTCARDS ......................................................... 125
Types of LMK component cards ................................................................................................................. 126
FORMATTING LMK SMART CARDS ............................................................................. 126
HSM LMK Cards ......................................................................................................................................... 126
payShield Manager LMK Cards .................................................................................................................. 126
GENERATING LMK COMPONENT CARDS ....................................................................... 126
HSM LMK Cards ......................................................................................................................................... 126
payShield Manager RLMK Cards................................................................................................................ 127
CREATING COPIES OF LMK COMPONENT CARDS ............................................................ 127
HSM LMK cards .......................................................................................................................................... 127
payShield Manager RLMK card.................................................................................................................. 127
LOADING THE NEW LMK ........................................................................................ 127
Using the Console ...................................................................................................................................... 128
Using payShield Manager .......................................................................................................................... 128
Checking the LMK ...................................................................................................................................... 128
LOADING THE OLD LMK ........................................................................................ 128
Using the Console ...................................................................................................................................... 129
Using payShield Manager .......................................................................................................................... 129
MIGRATING KEYS BETWEEN VARIANT LMKS ................................................................. 129
The BW Host command ............................................................................................................................. 129
The BX Response to the Host ..................................................................................................................... 131
MIGRATING KEYS FROM VARIANT TO KEY BLOCK LMKS ................................................... 132
MIGRATING KEYS BETWEEN KEY BLOCK LMKS .............................................................. 135
MIGRATING KEYS FROM VARIANT TO KEY BLOCK LMKS ................................................... 137
MIGRATING KEYS FOR PCI HSM COMPLIANCE .............................................................. 137
RE-ENCRYPTING PINS .......................................................................................... 137
The BG Host Command. ............................................................................................................................. 137
The BH Response ....................................................................................................................................... 138
RE-ENCRYPTING DECIMALIZATION TABLES ................................................................... 139
SWITCHING TO THE NEW LMK ................................................................................. 140
TAKING ADVANTAGE OF MULTIPLE LMKS .................................................................... 141
TIDYING UP AFTER MIGRATION TO A NEW LMK .............................................................. 142
Deleting the Old LMK from Key Change Storage ....................................................................................... 142
Deleting the New LMK ............................................................................................................................... 143
CHAPTER 11 – TR-31 KEY BLOCKS .................................................................. 144

RELATIONSHIP BETWEEN THALES KEY BLOCKS AND TR-31 KEY BLOCKS ............................... 144
TR-31 KEY BLOCK STRUCTURE ............................................................................... 144
KEY BLOCK HEADER............................................................................................. 145
Key Block Length (Bytes 1-4) ...................................................................................................................... 145
Key Usage (Bytes 5-6) ................................................................................................................................ 146
Algorithm (Byte 7) ..................................................................................................................................... 147
Mode of Use (Byte 8) ................................................................................................................................. 147
Key Version Number (Bytes 9-10) .............................................................................................................. 147
Exportability (Byte 11) ............................................................................................................................... 148
Number of Optional Blocks (Bytes 12-13) .................................................................................................. 148
Example ..................................................................................................................................................... 148
OPTIONAL HEADER .............................................................................................. 149
USING TR-31 KEY BLOCKS .................................................................................... 149
Licensing .................................................................................................................................................... 150
Key Scheme Tags ....................................................................................................................................... 150
GISKE KEY BLOCK ............................................................................................. 150
CHAPTER 12 – DES KEY SUPPORT ................................................................... 151
DES KEYS ........................................................................................................ 151
KEY USAGE ....................................................................................................... 151
KEY ENCRYPTION SCHEMES .................................................................................... 151
ANSI X9.17 method .................................................................................................................................... 151
Variant method.......................................................................................................................................... 151
Thales Key Block Method ........................................................................................................................... 151
X9 TR-31 Method ....................................................................................................................................... 151
GISKE Method ............................................................................................................................................ 152
Key Generate, Import and Export .............................................................................................................. 152
REJECTION OF WEAK, SEMI-WEAK, & POSSIBLY WEAK KEYS ............................................ 152
DES Weak Keys .......................................................................................................................................... 153
DES Semi-Weak Keys ................................................................................................................................. 153
DES Possibly Weak Keys ............................................................................................................................. 153
CHAPTER 13 – AES KEY SUPPORT ................................................................... 155
OVERVIEW ........................................................................................................ 155
AES Keys ..................................................................................................................................................... 155
Key Management Keys .............................................................................................................................. 155
Data Authentication Keys .......................................................................................................................... 155
Data Encryption Keys ................................................................................................................................. 155
Key Encryption Schemes ............................................................................................................................ 156
SUPPORT FOR AES IN THE PAYSHIELD 9000................................................................ 156
IMPLEMENTING AES ON AN EXISTING PAYSHIELD 9000 ................................................... 158
Re-encrypting existing keys under an AES Key Block LMK ......................................................................... 158
Creating AES working keys ........................................................................................................................ 159
SUPPORT FOR AES IN HOST COMMANDS ..................................................................... 159
Processing data using AES keys ................................................................................................................. 159
AES Key Management ............................................................................................................................... 160
AES Key Block LMK support ....................................................................................................................... 161
SUPPORT FOR AES IN CONSOLE COMMANDS ................................................................. 167
Managing the HSM.................................................................................................................................... 167
AES Key Management ............................................................................................................................... 167
SUPPORT FOR AES IN PAYSHIELD MANAGER ................................................................ 169
Managing the HSM.................................................................................................................................... 169
CHAPTER 14 – PIN BLOCK FORMATS .............................................................. 171
GENERAL.......................................................................................................... 171
PCI HSM Compliance.................................................................................................................................. 171

DEFINITIONS OF THALES PIN BLOCK FORMATS ............................................................. 171

Format 01 .................................................................................................................................................. 172
Format 02 .................................................................................................................................................. 172
Format 03 .................................................................................................................................................. 172
Format 04 .................................................................................................................................................. 172
Format 05 .................................................................................................................................................. 173
Format 34 .................................................................................................................................................. 174
Format 35 .................................................................................................................................................. 174
Format 41 .................................................................................................................................................. 175
Format 42 .................................................................................................................................................. 176
Format 47 .................................................................................................................................................. 177
Format 48 .................................................................................................................................................. 178
CHAPTER 15 – USER STORAGE ........................................................................ 180
INTRODUCTION .................................................................................................. 180
PERFORMANCE ................................................................................................... 180
THE USER STORAGE AREA ..................................................................................... 180
DEFINING THE BLOCK SIZE .................................................................................... 181
USER STORAGE WHEN USING FIXED BLOCK SIZES ......................................................... 181
Loading Data into User Storage with fixed block sizes .............................................................................. 181
Reading Data from User Storage with fixed block sizes ............................................................................ 182
Storing and accessing Symmetric Keys in User Storage with fixed block sizes (Variant LMK) ................... 182
User storage and Key Block LMKs with fixed block sizes ........................................................................... 183
Storing general data with fixed block sizes................................................................................................ 183
PIN Solicitation Data with fixed block sizes ............................................................................................... 184
PIN Blocks with fixed block sizes ................................................................................................................ 184
Diebold Table with fixed block sizes .......................................................................................................... 184
Decimalization Tables with fixed block sizes ............................................................................................. 185
Storing a mix of data types with fixed block sizes ..................................................................................... 185
STORING RSA KEYS IN THE PAYSHIELD 9000 .............................................................. 186
Storing the RSA Private Key in the payShield 9000 .................................................................................... 186
Using RSA Private Keys held in the payShield 9000 ................................................................................... 186
USER STORAGE WHEN USING VARIABLE BLOCK SIZES ..................................................... 186
Enabling the Enhanced Functionality ........................................................................................................ 187
New Data Structure ................................................................................................................................... 187
Loading Data into user storage with variable block sizes .......................................................................... 187
Storing a Diebold table with variable block sizes....................................................................................... 187
Reading Data from User Storage with variable block sizes ....................................................................... 188
Referencing keys stored in user storage with variable block sizes ............................................................ 188
HOST COMMAND EXAMPLES .................................................................................... 189
CHAPTER 16 – SNMP....................................................................................... 190
INTRODUCTION .................................................................................................. 190
NETWORK CONNECTIVITY ...................................................................................... 190
SNMP VERSIONS ................................................................................................ 191
CONFIGURING TRAPS ........................................................................................... 191
INFORMATION PROVIDED BY THE PAYSHIELD 9000 THROUGH SNMP .................................... 191
TRAPS ISSUED BY THE PAYSHIELD 9000 ..................................................................... 196
Failure of a daily diagnostic self-test ......................................................................................................... 196
Tamper ...................................................................................................................................................... 196
Powering up ............................................................................................................................................... 196
Use of the Restart button .......................................................................................................................... 196
Use of the Erase button ............................................................................................................................. 197
Fraud Detection ......................................................................................................................................... 197
Installation of a new license ...................................................................................................................... 197
Installation of new software ...................................................................................................................... 197
Power Supply Unit (PSU) failure ................................................................................................................ 197
Abnormal fan speed .................................................................................................................................. 197

New Error Log entry ................................................................................................................................... 197

Invalid or unexpected data received at a host port ................................................................................... 197
Actual or impending battery problem ....................................................................................................... 198
CHAPTER 17 – KEY COMPONENT PRINTING .................................................... 199
INTRODUCTION .................................................................................................. 199
DESCRIPTION OF THE PROCESS ................................................................................ 199
Overview .................................................................................................................................................... 199
Directly Attached printers .......................................................................................................................... 200
Operation without a directly attached printer .......................................................................................... 201
Setting up Key Component print forms ...................................................................................................... 202
Generating and printing components........................................................................................................ 203
Security considerations .............................................................................................................................. 204
Forming the KEK at the issuer system ........................................................................................................ 205
Forming the KEK at the recipient system ................................................................................................... 205
FURTHER INFORMATION ........................................................................................ 206
CHAPTER 18 – MOVING TO PCI HSM COMPLIANCE ......................................... 207
INTRODUCTION .................................................................................................. 207
PIN BLOCKS ..................................................................................................... 207
Using PIN Block formats in a compliant manner ....................................................................................... 207
Permitted PIN Block Format Translations .................................................................................................. 208
PIN Block Format for Values Derived from PIN & PAN .............................................................................. 209
Summary of Actions required .................................................................................................................... 209
UPDATING KEY TYPE 002 IN HOST COMMANDS ............................................................. 209
Example ..................................................................................................................................................... 211
Interoperability with older HSMs ............................................................................................................... 212
Summary of actions required..................................................................................................................... 212
MIGRATING KEYS FROM KEY TYPE 002 ....................................................................... 212
Migrating keys without a change of LMK: ................................................................................................. 213
Migrating keys with a change of LMK: ...................................................................................................... 214
Making use of Disaster Recovery (DR) sites ............................................................................................... 215
Examples of using the BW Host Command................................................................................................ 215
Thales Professional Services ...................................................................................................................... 215
DIEBOLD TABLE RE-ENCRYPTION .............................................................................. 216
APPENDIX A – KEY SCHEME TABLE ................................................................. 217
APPENDIX B – REDUCED CHARACTER SETS .................................................... 218
APPENDIX C – THALES KEY BLOCK / TR-31 KEY USAGE CONVERSION ........... 219
APPENDIX D – PRINT FORMATTING SYMBOLS ............................................... 220
PRINTER FORMATTING........................................................................................... 220
PRINTING PINS IN WORD FORMAT ........................................................................... 221
PRINTING PINS IN COLUMNS .................................................................................. 221
APPENDIX E – EXAMPLE LASER PRINTER FORMATTING CONTROL CODES ...... 223
APPENDIX F – SNMP MIB................................................................................ 225

End User License Agreement

Please read this Agreement carefully.
THALES E-SECURITY IS WILLING TO LICENSE SOFTWARE TO THE ENTITY THAT HAS PURCHASED A THALES E-
SECURITY HARDWARE DEVICE UPON THE CONDITION THAT ALL OF THE TERMS CONTAINED IN THIS END
USER LICENSE AGREEMENT ("AGREEMENT") ARE ACCEPTED AND AGREED. PLEASE READ THIS AGREEMENT
CAREFULLY. THE TERMS OF THIS AGREEMENT WILL BE DEEMED TO HAVE BEEN AGREED TO BY THE ENTITY
OR END USER CUSTOMER THAT HAS PURCHASED A THALES E-SECURITY HARDWARE DEVICE IF SOFTWARE IS
DOWNLOADED OR IF SOFTWARE IS USED OR IF A SECURITY SEAL ON THE MEDIA PACKAGE CONTAINING
SOFTWARE IS BROKEN OR IF CONSENT IS MANIFESTED BY CLICKING ON AN ACCEPTANCE KEY.
This document is a legal agreement between Thales e-Security, Inc., ("Thales e-Security"), 900 South Pine
Island Road, Suite 710, Plantation, FL 33324 U.S.A. and the end user customer that has purchased a Thales e-
Security hardware device, (hereafter referred to as the "End User Customer"). Any person who manifests their
agreement to this Agreement represents that they have the requisite and appropriate legal authority to bind
the End User Customer.
1. Definitions
(a) "Affiliates" means Thales Transport & Security (Hong Kong) Ltd. and Thales UK Limited.
(b) "Software" means machine readable instructions and all modifications and customizations thereof in
binary form and any other machine readable materials (including, but not limited to, libraries, source files,
header files, and data files), any updates or error corrections provided by Thales e-Security or its corporate
Affiliates that direct a computer’s processor to perform specific operations.
2. Ownership
Software consists of a combination of proprietary components that are owned by or licensed to Thales e-
Security or its Affiliates together with free or open source 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 PURSUANT TO ITS
APPLICABLE GOVERNING LICENSE SHALL BE APPLICABLE TO SUCH FREE SOFTWARE COMPONENT. Each Free
Software Component is the copyright of its respective copyright owner. Software is licensed to End User
Customer and is not sold. End User Customer has no ownership rights in the Software. Rather, End User
Customer is hereby granted a license to use the Software. The Software is copyrighted by Thales e-Security or
its Affiliates or its suppliers. End User Customer hereby agrees to respect and not to remove or conceal from
view any copyright or trademark notice appearing on the Software or documentation, and to reproduce all
copyright or trademark notices on any copy of the Software and documentation or any portion thereof and on
all portions contained in or merged into other programs and documentation.
3. License to Use
Subject to the terms and conditions of this Agreement Thales e-Security grants to End User Customer a non-
exclusive, limited license to use Software unmodified for the sole purpose of running or operating Software on
or with a Thales e-Security hardware device and to copy such Software provided that such copies are made in
machine readable form for backup purposes.
4. Restrictions
Software is confidential and copyrighted. Unless enforcement is prohibited by applicable law, End User
Customer may not modify, decompile, or reverse engineer Software. End User Customer shall not permit any
other person to do any of the same. End User Customer may not rent, lease or sublicense the Software. Any
rights not expressly granted by Thales e-Security to End User Customer hereunder are reserved by Thales e-
Security 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 Agreement. The Software and any accompanying written
materials are protected by international copyright and patent laws and international trade provisions. No right,
title or interest is granted under this Agreement in or to any trademark, service mark, logo or trade name of
Thales, S.A., Thales e-Security or its licensors or corporate Affiliates. End User Customer may not disassemble
the Thales e-Security owned or licensed components of the Software. End User Customer may not create
derivative works based on the Software except as may be necessary to permit integration with other
technology.
5. Limited Warranty
(a) Thales e-Security warrants that a Thales e-Security hardware device and the accompanying Software
will function substantially as detailed in their respective and applicable specifications. The warranty period for a

Thales e-Security hardware device is one year from the date of delivery and the warranty period for Software is
ninety (90) days from the date of delivery. If either a Thales e-Security hardware device or Software fails to
materially conform to their applicable specifications, Thales e-Security or its Affiliates will repair or replace the
affected hardware device or Software provided that End User Customer provides Thales e-Security with a
written notice of a claim or a defect under this warranty within the warranty period herein described. FOR THE
AVOIDANCE OF DOUBT, THALES E-SECURITY NEITHER WARRANTS, NOR CAN BE EXPECTED TO WARRANT
THAT A THALES E-SECURITY HARDWARE DEVICE OR SOFTWARE IS WHOLLY FREE FROM DEFECT, OR THAT
ANY PARTICULAR DEFECT CAN BE REMEDIED, OR THAT A REMEDY CAN BE PROVIDED IN ANY PARTICULAR
TIMEFRAME. THE FOREGOING WARRANTY SHALL NOT APPLY IF THE NONCONFORMITY ISSUE IS CAUSED BY
ANY MODIFICATION OR REPAIRS TO A THALES E-SECURITY HARDWARE DEVICE OR SOFTWARE PERFORMED
BY ANYONE OTHER THAN THALES E-SECURITY OR TO ANY ASSOCIATED OR COMPLEMENTARY EQUIPMENT OR
SOFTWARE NOT FURNISHED BY THALES E-SECURITY OR ITS CORPORATE AFFILIATES, OR BY ANY HARDWARE
DEVICE OR SOFTWARE MISUSE OR NEGLECT.
(b) NOTWITHSTANDING THE FOREGOING, TO THE MAXIMUM EXTENT PERMITTED BY LAW, THALES E-
SECURITY, ON BEHALF OF ITSELF, ITS AFFILIATES AND ITS THIRD PARTY SUPPLIERS, HEREBY DISCLAIMS
ANY AND ALL WARRANTIES OF ANY OTHER KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, WITHOUT
LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTABILITY, SATISFACTORY QUALITY, NON-
INFRINGEMENT AND FITNESS FOR A PARTICULAR PURPOSE. THALES E-SECURITY DOES NOT WARRANT THAT
THE FUNCTIONS CONTAINED IN THE HARDWARE DEVICE OR SOFTWARE WILL MEET ANY REQUIREMENTS OR
NEEDS THAT END USER CUSTOMER MAY HAVE, OR THAT A THALES E-SECURITY HARDWARE DEVICE OR
SOFTWARE WILL OPERATE ERROR FREE, OR IN AN UNINTERRUPTED FASHION, OR THAT ANY DEFECTS OR
ERRORS WILL BE CORRECTED, OR THAT THE SOFTWARE OR HARDWARE DEVICE 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 HARDWARE DEVICE OR
SOFTWARE, AND NO WARRANTIES SHALL APPLY AFTER THAT PERIOD.
6. Intellectual Property Indemnification
Thales e-Security shall defend or, at its option, settle, any claim, action or proceeding brought against End User
Customer alleging that a Thales e-Security hardware device or Software infringes upon a trademark, patent,
copyright or trade secret or other intellectual property right in a country that is a signatory to the Berne
Convention, and shall indemnify End User Customer from and against all damages and costs finally awarded
against End User Customer in any such action or proceeding, provided that End User Customer (a) promptly
notifies Thales e-Security in writing of the claim, (b) gives Thales e-Security full authority, information and
assistance to defend such claim and (c) gives Thales e-Security sole control of the defense of such claim and all
negotiations for the compromise or settlement thereof. If a Thales e-Security hardware device or Software or
any part thereof becomes, or in the opinion of Thales e-Security is likely to become the subject of a valid claim
of infringement or the like under any trademark, patent, copyright or trade secret or other intellectual property
right law, Thales e-Security shall have the right, at its option and expense, either to obtain for End User
Customer a license permitting the continued use of the Thales hardware device or Software or such part, or to
replace or modify it so that it becomes non-infringing. Thales e-Security shall have no liability hereunder for
any costs incurred or settlement entered into without its prior written consent. Thales e-Security shall have no
liability hereunder with respect to any claim based upon (i) the combination of a Thales hardware device or
Software with other equipment not furnished by Thales e-Security (except if the infringement occurs due to the
use of the Thales e-Security hardware device or Software itself as originally provided by Thales e-Security or its
Affiliates); (ii) any addition to or modification of a Thales e-Security hardware device or Software by any person
or entity other than Thales e-Security or its Affiliates; or (iii) use of a superseded or altered release of the
Software. THE FOREGOING STATES THE SOLE AND EXCLUSIVE LIABILITY OF THALES E-SECURITY AND ITS
LICENSORS AND THE SOLE AND EXCLUSIVE REMEDY OF END USER CUSTOMER WITH RESPECT TO ANY CLAIM
OF PATENT, COPYRIGHT, TRADEMARK, TRADE SECRET OR OTHER INTELLECTUAL PROPERTY RIGHTS
INFRINGEMENT BY A THALES E-SECURITY HARDWARE DEVICE OR SOFTWARE, ANY SERVICE, ANY PART
THEREOF OR THE USE THEREOF, AND IS IN LIEU OF ALL OTHER WARRANTIES, EXPRESS OR IMPLIED OR
ARISING BY CUSTOM OR TRADE USAGE, AND INDEMNITIES WITH RESPECT THERETO. NOTWITHSTANDING
THE FOREGOING, ALL OPEN SOURCE SOFTWARE OR FREEWARE INCLUDED WITH THE SOFTWARE IS
PROVIDED WITHOUT ANY RIGHTS TO INDEMNIFICATION.
7. Limited Liability
TO THE EXTENT ALLOWED BY LAW, IN NO EVENT WILL THALES E-SECURITY OR ITS CORPORATE AFFILIATES
OR ITS LICENSORS BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR ANY SPECIAL, INDIRECT,
CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, HOWEVER CAUSED REGARDLESS OF THE THEORY OF
LIABILITY, ARISING OUT OF OR RELATED TO THE USE OF OR INABILITY TO USE SOFTWARE, EVEN IF THALES
E-SECURITY OR ANY OF ITS CORPORATE AFFILIATES HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH

DAMAGES. In no event will Thales e-Security or its corporate affiliate's liability, whether in contract, tort
(including negligence), or otherwise, exceed the amount paid by End User Customer for the Thales e-Security
hardware device or Software under this Agreement. The foregoing limitations will apply even if the above
stated warranty fails of its essential purpose.
8. Export Restrictions.
Thales e-Security hardware devices and Software are subject to the restrictions imposed by the United States
Export Administration Regulations and the United Kingdom Export Control Order 2008 and may be subject to
export or import regulations in other countries. End User Customer agrees to comply strictly with all such laws
and regulations and acknowledges that it has the responsibility to obtain such licenses to export, re-export, or
import as may be required.
9. Transfer Rights
End User Customer may transfer a Thales e-Security hardware device together with the Software, and this
license to another party if the other party agrees to accept the terms and conditions of this Agreement and
notice of such transfer and acceptance is provided to Thales e-Security in writing. FOR THE AVOIDANCE OF
DOUBT, IF END USER CUSTOMER TRANSFERS POSSESSION OF ANY COPY OF THE SOFTWARE TO ANOTHER
PARTY, EXCEPT AS PROVIDED IN THIS SECTION 9, THE LICENSE GRANT PROVIDED HEREIN IS
AUTOMATICALLY REVOKED, CANCELLED AND TERMINATED.
10. Termination
This Agreement is effective until terminated. End User Customer may terminate this Agreement at any time by
destroying or erasing all copies of the Software and accompanying written materials in its possession or control.
This license will terminate automatically, without notice from Thales e-Security if End User Customer fails to
comply with the terms and conditions of this Agreement. Upon such termination, End User 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 its possession or control.
11. U.S. Government Acquisitions
Software and Documentation acquired by the U.S. Government or on its behalf is furnished with "RESTRICTED
RIGHTS," as defined in Federal Acquisition Regulation ("FAR") 52.227-19(b)(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(b)(1)
and (2) or DFAR 252.227-7013 to 7019, as applicable.
12. Governing Law and Dispute Resolution
(a) If an End User Customer is located in Anguilla, Antigua and Barbuda, Argentina, Aruba, Bahamas,
Barbados, Belize, Bermuda, Bolivia, Bonaire, Sint Eustatius and Saba, Brazil, British Virgin Islands, Canada,
Cayman Islands, Chile, Colombia, Costa Rica, Cuba, Curaçao, Dominica, Dominican Republic, Ecuador, El
Salvador, Falkland Islands (Malvinas), French Guiana, Greenland, Grenada, Guadeloupe, Guatemala, Guyana,
Haiti, Honduras, Jamaica, Martinique, Mexico, Monserrat, Nicaragua, Panama, Paraguay, Peru, Puerto Rico,
Saint-Barthélemy, St. Kitts and Nevis, Saint Lucia, Saint Martin, Saint Vincent and the Grenadines, Saint Pierre
and Miquelon, Sint Maarten, Suriname, Trinidad and Tobago, Turks and Caicos Islands, United States, United
States Virgin Islands, Uruguay or Venezuela, this End User License Agreement shall be construed, interpreted
and governed by the laws of the State of Florida, United States of America without regard to conflicts of laws
and all disputes shall be submitted to the State or Federal courts located in Florida.
(c) If an End User Customer is located in Algeria, Angola, Afghanistan, Albania, Andorra, Armenia, Austria,
Azerbaijan, Bahrain, Bangladesh, Belarus, Belgium, Benin, Bhutan, Bosnia-Herzegovina, Botswana, Bulgaria,
Burkina Faso, Burundi, Cameroon, Cape Verde, Central African Republic, Chad, Comoros, Congo, Cote d'Ivoire,
Croatia, Cyprus, Czech Republic, Denmark, Democratic Republic of the Congo, Djibouti, Egypt, Equatorial
Guinea, Eritrea, Estonia, Ethiopia, Finland, Faroe Islands, France, Gabon, Gambia, Germany, Gibraltar, Georgia,
Greece, Ghana, Guerney and Alderney, Guinea, Guinea-Bissau, Hungary, Iceland, India, Iran, Iraq, Ireland,
Island of Man, Israel, Italy, Jersey, Jordan, Kazakhstan, Kenya, Kosovo, Kyrgyzstan, Kuwait, Latvia, Lesotho,
Liberia, Libya, Liechtenstein, Lithuania, Lebanon, Luxembourg, Macedonia, Madagascar, Malawi, Maldives, Mali,
Malta, Mauritania, Mauritius, Moldova, Monaco, Montenegro, Morocco, Mozambique, Namibia, Nepal,
Netherlands, Niger, Nigeria, Norway, Oman, Palestine, Pakistan, Poland, Portugal, Qatar, Romania, Russia,
Rwanda, San Marino, Sao Tome & Principe, Saudi Arabia, Senegal, Serbia, Seychelles, Sierra Leone Slovakia,
Slovenia, Somalia, South Africa, South Sudan, Sudan, Spain, Sri Lanka, Swaziland, Sweden, Svalbard and Jan
Mayen Islands, Switzerland, Syria, Tajikistan, Tanzania, Togo, Tunisia, Turkey, Turkmenistan, Uganda, Ukraine,
United Arab Emirates, United Kingdom, Uzbekistan, Vatican City State (Holy See), Yemen, Zambia, or
Zimbabwe, this End User License Agreement will be governed by the laws of England and Wales and all
disputes shall be submitted to the courts of England.

(c) If an End User Customer is located in American Samoa, Australia, Brunei Darussalam, Cambodia,
China, Cook Islands, Fiji, Guam, Hong Kong, Indonesia, Japan, Kiribati, Laos, Macao, Malaysia, Marshall
Islands, Micronesia, Mongolia, Myanmar (ex-Burma), New Caledonia, New Zealand, Papua New Guinea,
Philippines, Samoa, Singapore, Solomon, Islands, South Korea, Taiwan, Thailand, Timor Leste, Tonga, Tuvalu,
Vanuatu, Vietnam or Western Samoa, this End User License Agreement will be governed by the Law of the
Hong Kong Special Administrative Region of the People’s Republic of China and all disputes shall be submitted
to arbitration in Hong Kong.
13. Elliptic Curve Cryptography Activation
If End User Customer elects to purchase a Thales e-Security hardware device containing elliptic curve
cryptography software (ECC) it agrees that its use of ECC is limited to storing cryptographic keys and the
performance of cryptographic operations in a hardware environment together with the management and
issuance of digital certificates by a registration authority or certificate authority provided such certificates are
either (i) solely for the internal use of the registration authority or (ii) are solely for the internal use of an
enterprise that is hosted by a registration authority or certificate authority. No right or license is provided or
granted to use ECC as part of a third party service provider for the purpose of acting as a commercial
registration authority or certificate authority as part of a commercial service offered by an enterprise, either as
a vendor of digital certificates or in the provisioning of certificates for use in a commercial service.

Revision Status
Document No. Manual Set Software Version Release Date
1270A542-033 Issue 33 payShield 9000 v3.1 March 2017

References
The following documents are referenced in this document:
1 payShield 9000 Console Reference Manual

Document Number: 1270A544
2 payShield 9000 Host Command Reference Manual
Document Number: 1270A546
3 PKCS#1: RSA Encryption Standard - Version 1.5 – Revised November
1993 (www.rsalabs.com)
4 PKCS#1: RSA Cryptography Standard – Version 2.0 – October 1998
(www.rsalabs.com)
5 Visa Integrated Circuit Card Specification, Version 1.4.0 – April 2001, plus
August 2002 Corrections
(www.visa.com)
6 MasterCard M/Chip 4 Cryptography and Key Management v4.0 – May 2002
(www.mastercardinternational.com/)
7 ASC X9 TR-31, Interoperable Secure Key Exchange Key Block Specification
for Symmetric Algorithms, 2005.
8 Global Interoperable Secure Key Exchange Key Block Specification, version
2.3, written by ACI Worldwide, HP Atalla, Diebold, Thales e-Security and
VeriFone Inc. 2002.
9 Visa Integrated Circuit Card Specification. Version 1.4.0 – April 2001, plus
August 2002 corrections.

Chapter 1 – Introduction
Introduction
The payShield 9000 hardware security module (HSM) acts as a peripheral to the Host
computer. It performs cryptographic processing in a physically secure environment on
behalf of the Host. The processing is performed by a payShield 9000 HSM in response to
commands, which it receives via a data link.
Typically an HSM is used in a real-time, online environment performing key

management, PIN and MAC related functions as required by the system.
This manual contains programming notes to assist the application programmer. A

complete command reference can be found in the Host Command Reference Manual.
For commands that are entered manually at a Console terminal attached to an HSM, see
the Console Reference Manual. A glossary of terms can be found in the payShield 9000
General Information Manual.
PCI HSM Certification and Compliance

Information about PCI HSM certification of the payShield 9000 can be found in Chapter
10 of the payShield 9000 General Information Manual.
General
The application program sends commands to an HSM, and receives responses from it.
Each command and response consists of a variable number of fields.
Versions of the payShield 9000 HSM can be configured to support asynchronous, TCP/IP,
and UDP communications protocols. The HSM has no flow control support so the
programmer must ensure that the HSM input buffer is not exceeded.
The HSM returns an error code to the Host as part of the response message. The
programmer must ensure that a suitable response is made to each type of error.
In a typical system, a minimum of two HSMs are connected to the Host via separate Host
ports. The HSM units are independent, and the programmer should make maximum use
of all the HSM units to increase throughput, using one HSM if another is already
processing data or is faulty. Also, it is useful to ensure that the program allows for
additional HSM units to be subsequently added as throughput requirements increase.
Each HSM has a user storage area reserved for use by the programmer to store data
required during processing. Typically it is used to store keys and tables. Instructing an
HSM to access data from user storage reduces the amount of data necessary in each
command, and thus reduces the communications time.
There is a facility to print data (e.g., account holder PINs) at a printer connected to a
payShield 9000 HSM. The HSM must have format information for the data before sending
it to the printer. The program must send a print format command to an HSM before print
commands can be issued.

Command Message Format

To give an HSM an instruction, the Host application must assemble a message containing
all the necessary information and send it to an HSM as a sequence of characters on the
communications link. In general, each command consists of the following fields:
 Start of Text Character
 Message Header
 Command Code
 Data
 Message Trailer
 End of Text Character
Start of Text Character

The Start of Text (STX) character indicates the start of a valid message. The ASCII and
EBCDIC value is X'02. The STX character is not used in TCP/IP environments.
Message Header
The message header field can be any length from 1 to 255 characters and it is configured
at installation. It can contain any printable characters and an HSM returns them
unmodified in the response message.
It can be used to label commands and their responses for systems that implement batch
queues or which multi-thread commands.
Command Code
Every command has a unique two-character command code. The command codes are
detailed in the Host Command Reference Manual.
Data
Most HSM commands require data, often including cryptographic keys. Details of the data
for each command can be found in the Host Command Reference Manual.
Message Trailer
The message trailer is an additional variable-length field (to a maximum of 32
characters), which can be used to pass additional details required by the Host for further

processing. The field should always be preceded by the EM control character; ASCII and
EBCDIC value is X'19.
The data in this field can be any printable character, and it is returned in the response
message unchanged for error codes 00 and 02. (The trailer is not returned for other error
codes.)
End of Text Character

The End of Text (ETX) character indicates the end of command data. The HSM ignores
any data received after the ETX and before the next STX. The ETX character is not used
in TCP/IP environments.
The ASCII and EBCDIC value is X'03.
Response Message Format

To inform the Host of the results of processing, an HSM sends a message containing all
the necessary information as a sequence of characters on the communications link. A
response message is generated for each of the following:
 In response to a command.
 As a second response to a print command after an HSM has finished sending the
print data to the printer.
 In response to the entry of PIN solicitation data at the Console (but only after the
Host has enabled this function).
Each response from an HSM consists of the following:
 Start of Text Character (if applicable)

 Message Header
 Response Code
 Error Code
 Data
 Message Trailer
 End of Text Character (if applicable)
End of Text Character
Data Message Trailer
Error Code
Response Code
Message Header


The Start of Text (STX) character indicates the start of a valid message. The ASCII and
EBCDIC value is X'02. The STX character is not used in TCP/IP environments.
Message Header
The message header field is a copy of the field received in the command message from
the Host. The data is returned to the Host unchanged.
It can be used to label commands and their responses for systems that implement batch
queues or which multi-thread commands.
Response Code
Every response has a unique two-character code. Normally this code has the same first
character as the command to which it is a response, and the second character is one
greater than the second character of the command (e.g., if the command code is AA, the
response code is AB). The value of each code is detailed in the Host Command Reference
Manual.
Error Code
The two-character error code field is used by an HSM to report errors detected during
processing. The values are alphanumeric and the value 00 indicates that no errors have
been found. If an error (other than 00) is returned, subsequent fields, with the exception
of the end of text character, are not returned by an HSM. Error codes specific to a
command or frequently returned with a command are listed with the command code in
the Host Command Reference Manual. A list of global errors is also included in the Host
Command Reference Manual.
Data
Many payShield 9000 HSM commands return data as a result of the processing. Details
of the contents of the returned data are given in the Host Command Reference Manual.
Generally, data is not returned for error codes other than 00. There are some exceptions
to this rule, for example the Key Import command (A6) returns error code 01 to advise
that the key being imported does not have odd parity.
Message Trailer
The message trailer field is present only if it was present in the command message, and
it is returned unchanged. It is not returned for error codes other than 00 or 02.
End of Text Characters

The End of Text (ETX) field indicates the end of the response message from an HSM. In a
bisynchronous system its ASCII and EBCDIC value is X'03. The End of Text field is not
used in TCP/IP environments.
In an asynchronous system it can be configured to be one or two characters in length,

and the value of each of the characters is configurable (normally at installation time).
Data Representation
For asynchronous serial communications, the HSM expects all data to be encoded as
either ASCII or EBCDIC characters with the exception of the STX (X'02), ETX (X'03) and

EM (X'19) control characters. Where an HSM does not try and interpret the data (e.g., in
the message header and message trailer fields), it is possible to include other control
characters, but this is not good practice.
When sending data to an HSM, other than data that is already in character format,
encode each digit (0-9, A-F) as a character (e.g., to send the hexadecimal value
1234ABCD to an HSM requires 8 characters).
For Ethernet communications, the HSM accepts certain fields in binary format. Refer to
individual host commands for full details.
Note: The payShield 9000 HSM automatically detects whether an incoming command
message uses ASCII or EBCDIC characters, and process the command accordingly,
returning the result in the same format.
ASCII Character Codes

The table shows the ASCII characters and their hexadecimal values.
ASCII HEX ASCII HEX ASCII HEX ASCII HEX

NUL 00 SP 20 @ 40 ` 60
SOH 01 ! 21 A 41 a 61
STX 02 " 22 B 42 b 62
ETX 03 # 23 C 43 c 63
EOT 04 $ 24 D 44 d 64
ENQ 05 % 25 E 45 e 65
ACK 06 & 26 F 46 f 66
BEL 07 ' 27 G 47 g 67
BS 08 ( 28 H 48 h 68
HT 09 ) 29 I 49 i 69
LF OA * 2A J 4A j 6A
VT OB + 2B K 4B k 6B
FF OC , 2C L 4C l 6C
CR OD - 2D M 4D m 6D
SO OE . 2E N 4E n 6E
SI OF / 2F O 4F o 6F
DLE 10 0 30 P 50 p 70
DC1 11 1 31 Q 51 q 71
DC2 12 2 32 R 52 r 72
DC3 13 3 33 S 53 s 73
DC4 14 4 34 T 54 t 74
NAK 15 5 35 U 55 u 75
SYN 16 6 36 V 56 v 76
ETB 17 7 37 W 57 w 77
CAN 18 8 38 X 58 x 78
EM 19 9 39 Y 59 y 79
SUB 1A : 3A Z 5A z 7A
ESC 1B ; 3B [ 5B { 7B
FS 1C < 3C \ 5C | 7C
GS 1D = 3D ] 5D } 7D
RS 1E > 3E ^ 5E ~ 7E
US 1F ? 3F = 5F DEL 7F
EBCDIC Character Codes

The table shows the EBCDIC characters and their hexadecimal values.

EBCDIC HEX EBCDIC HEX EBCDIC HEX EBCDIC HEX

NUL 00 SP 40 80 C0
SOH 01 41 a 81 A C1
STX 02 42 b 82 B C2
ETX 03 43 c 83 C C3
04 44 d 84 D C4
HT 05 45 e 85 E C5
06 46 f 86 F C6
DEL 07 47 g 87 G C7
08 48 h 88 H C8
09 49 i 89 I C9
0A 4A 8A CA
VT 0B .(period) 4B { 8B CB
FF 0C < 4C 8C CC
CR 0D ( 4D 8D CD
SO 0E + 4E 8E CE
SI 0F | 4F 8F CF
DLE 10 & 50 90 D0
DC1 11 51 j 91 J D1
DC2 12 52 k 92 K D2
DC3 13 53 l 93 L D3
14 54 m 94 M D4
15 55 n 95 N D5
BS 16 56 o 96 O D6
17 57 p 97 P D7
CAN 18 58 q 98 Q D8
EM 19 59 r 99 R D9
1A ! 5A 9A DA
1B $ 5B } 9B DB
1C * 5C 9C DC
1D ) 5D 9D DD
1E ; 5E 9E DE
1F 5F 9F DF
20 - (minus) 60 A0 \ E0
21 / 61 ~ (tilde) A1 E1
FS 22 62 s A2 S E2
23 63 t A3 T E3
24 64 u A4 U E4
LF 25 65 v A5 V E5
ETB 26 66 w A6 W E6
ESC 27 67 x A7 X E7
28 68 y A8 Y E8
29 69 z A9 Z E9
2A 6A AA EA
2B ,(comma) 6B AB EB
2C % 6C AC EC
ENQ 2D _(underscore) 6D [ AD ED
ACK 2E > 6E AE EE
BEL 2F ? 6F AF EF
30 70 B0 0 F0
31 71 B1 1 F1
SYN 32 72 B2 2 F2
33 73 B3 3 F3
34 74 B4 4 F4
35 75 B5 5 F5
36 76 B6 6 F6
EOT 37 77 B7 7 F7
38 78 B8 8 F8
39 `(grave) 79 B9 9 F9
3A : 7A BA FA
3B # 7B BB FB
DC4 3C @ 7C BC FC
NAK 3D ' 7D ] BD FD
3E = 7E BE FE
SUB 3F " 7F BF FF
Input/Output Flow Control

There is no flow control provided by a payShield 9000 HSM. It is the responsibility of the
application to ensure that the input buffer in the HSM, which is 32K bytes per connection,
is not exceeded.
No single command contains more than 32Kbytes, including any STX and ETX characters.
Where an Async connected HSM operates in half duplex the response to a command
must be received before a new command request is sent.

Error Handling
There are four types of errors generated by a payShield 9000 HSM:
 Fatal errors.
 Non-recoverable errors.
 Recoverable errors.
 Programming errors.
Fatal errors indicate a hardware fault in the equipment. Such an error should be logged
and reported for user action to be taken (e.g., report to supervisor). Fatal errors are
normally reported on the console and are not seen by the host application. The host
application usually times out if a fatal error occurs.
Non-recoverable errors cannot be rectified by the program and need user intervention
(e.g., with an HSM set into the Authorized state). Such errors should also be logged and
reported for user action to be taken (e.g., report to supervisor). This type of error does
not mean that an HSM cannot action other types of commands.
Recoverable errors may be the result of data corruption or indicate that an HSM cannot
process a command because some other action is required first. The application should
attempt to recover by re-issuing the command, attempting to clear the corruption or by
implementing the missing action (e.g., an HSM reports that the print format definition is
not loaded, so the program should load it and re-issue the failed command).
Programming errors are normally found during testing, but if they occur at other times,
they are probably non-recoverable.
Additionally the application should monitor an HSM for timeouts on the interface.
In any of the above events, the application should try to continue processing by using
another HSM to action the command. Continued failure may indicate a catastrophic
failure of all HSM units (unlikely), a power failure or a program error.
The application should monitor usage of all HSM units and mark any unit as "out of
service" if it has given a fatal error, or where a unit repeatedly reports non-recoverable
errors.
Error Log
Hardware failures, software errors and alarm events are recorded in the Error Log. This
has 100 slots, with fields for error code, sub-code, date, time and severity level. There
are four severity levels: informative, recoverable, major and catastrophic (needing a
reboot). When an error is recorded for a particular error code, any subsequent error with
the same code updates the date and time for that code., thus each error type remains in
the log until it is cleared.
Error log maintenance is performed from the console using the command ERRLOG to
retrieve the log and CLEARERR to clear the log. Once the log has been read, the flashing
Error LED changes to a steady illumination. If the log is cleared, the Error LED is
extinguished. It is possible to configure the payShield 9000 security settings such that
the Error LED is extinguished after the error log has been viewed.

Use of Multiple HSM units

A typical system has two or more HSM units connected as ‘live’ units. This provides
increased capability where the processing requires more than one HSM, and provision for
backup in the event of an HSM failure.
Each HSM is normally connected to the Host via a separate Host port, although a port-
sharing unit can be used if the number of Host ports available is limited. The sharing
configuration is not capable of providing backup if the port or the port-sharing unit
becomes faulty.
Optionally it is possible to have a backup unit not connected to the Host but ready for
connection in place of a faulty unit. This is not the preferred practice because the unit
may remain idle for a long time and may itself have developed a fault.
In addition to the ‘live’ units, a typical system contains at least one HSM connected to a
test or development computer system. This allows changes in the environment to be
tested, without disturbing the live system.
User Storage
It is possible to store keys and other data securely inside the payShield 9000 using the
User Storage facility. This is described in Chapter 13.

Chapter 2 – Host Connections

General
The following communication connections are possible between the payShield 9000 HSM
and the host computer:
 Asynchronous RS232 (via a USB-to-serial cable)

 Transparent asynchronous RS232 (via a USB-to-serial cable)
 Ethernet TCP/IP
 Ethernet UDP
Asynchronous Connected Option

The HSM Asynchronous Connected mode operates as a communications attached device.
It responds only to messages bracketed with STX and ETX (X’02 and X’03).
Transparent Asynchronous Connected Option

In the standard asynchronous mode of communication, codes like STX (X'02) and ETX
(X'03) have a special meaning, but they can sometimes occur in a stream of binary data,
where that special meaning does not apply. To avoid ambiguity, Transparent
Asynchronous Communications mode is used.
Sending Commands
The Host port of the payShield 9000 HSM must be configured for Transparent Async
Communications and 8-bit data transfers. The message format for Transparent Async
Communications is:
STX COUNT COMMAND/DATA LRC ETX
Where:
 STX is the Start of Text character (X'02).
 COUNT is a two-byte hexadecimal value in the range X'0003 to X'7FFB inclusive,
representing the number of bytes in the COMMAND/DATA field. The count
excludes the STX, COUNT, LRC and ETX.
 LRC is a single-byte Longitudinal Redundancy Check character. It is calculated by
performing an exclusive-OR on each byte of the data sent over the
communications link excluding the STX, COUNT, LRC and the ETX.
 ETX is the End of Text character (X'03).

HSM Processing of Packets

When the HSM receives a Transparent Async packet it:
 Checks the LRC value with that computed over the input data and returns a
response message with Error 91 if a match is not obtained.
 Checks that the Count value is between limits. If this check fails, the HSM
responds in one of two ways:
- If Count > X'7FFB, it returns a response message with Error 92;
- otherwise it responds with the following error message:
Message Header : 0000
Response Code : ZZ
Error Code : 92
e.g., for Message Header length 4, the response is 0000ZZ92.
 Checks that the number of characters received between the Count characters and
the LRC matches the value in Count. If this check fails, it returns a response
message with Error 92.
lf no errors are discovered in the Transparent Async packet, the HSM processes
the command and responds accordingly.
If the HSM discovers both errors (Error 91 and Error 92), it reports Error 92.
If the HSM reports Error 90 there is a Data Parity Error. Check the payShield 9000 Host
port settings using the QH (Query Host) console command and ensure that the correct
parity is in use.
TCP/IP Protocol
IP addresses can be configured manually or obtained automatically by using DHCP. DNS
is also supported to allow the HSM to be addressed by name rather than by its IP
address.
The HSM employs TCP for the transfer of data (see Chapter 1). It acts as a TCP server
supporting multiple TCP clients configurable via the CH command. The maximum number
of TCP sockets that can be supported is 64. If a TCP client attempts to establish a
connection with an HSM that already has the maximum number of configured sockets
active, the TCP client’s request is rejected.
The HSM supports the TCP Push function. To improve the efficiency of data transfer the
TCP protocol software can buffer data into larger blocks, or divide the data into smaller
blocks. This is useful for time-critical applications, such as transaction processing
systems, where response time is more important than Ethernet utilization efficiency.
The HSM always returns a response to a command using the Push function.
The payShield 9000 Secure Host Communications facility supports the use of SSL and
TLS to protect the TCP/IP link between the HSM and the host. This facility is described in
Chapter 14 of the payShield 9000 General Information Manual.
The payShield 9000 also allows whitelists of acceptable host IP addresses to be
configured using its Access Control Lists (ACL) facility. See the payShield 9000 Console
Reference Manual and the payShield Manager User Guide for information on setting up
ACLs.
Port Addresses
When the port is configured using the Console or payShield Manager, a well-known port
address is assigned (default value 1500). See Chapter 1 of the payShield 9000 Host

Command Reference Manual for information on how port addressing can be used to
specify which LMK a Host Command requires to be used.
Sending Commands
The HSM expects a command to be sent in the form defined in the table.
Field Size Format Description

LENGTH 2 Byte Length of the COMMAND field
COMMAND n Byte HSM command
Note: The field COMMAND should not be bracketed by X’02 - X’03 as used with
the Async protocol.
Multiple commands can be sent to an HSM within one TCP transmission. Each should be
of the form defined in the table.
Example:
The command format for a diagnostics command (NC) is:

X’00 X’06 X’31 X’32 X’33 X’34 X’4E X’43
where the HSM message header length is set to 04, a message header of 1234 is used,
and character representation is ASCII.
Returning Responses
When an HSM receives a command from a TCP client, the command is processed and the
response returned to the TCP client. The response is of the form defined in the table.

LENGTH 2 Byte Length of the RESPONSE field
RESPONSE n Byte HSM response
Note: The field RESPONSE is not bracketed by X’02 - X’03 (or alternative value)
as used with the Async protocol.
The result of each command sent to an HSM is returned as a separate response to the
TCP client. This also operates when multiple commands are sent to an HSM in a single
TCP transmission.
All HSM responses are returned to the TCP client using the TCP Push function.
Example:
The response format from a diagnostics command (NC) is:
X’00 X’21 X’31 X’32 X’33 X’34 X’4E X’43 X’30 X’30 X’32 X’36
X’38 X’36 X’30 X’34 X’37 X’34 X’34 X’34 X’39 X’31 X’32 X’34
X’32 X’32 X’30 X’30 X’30 X’37 X’2D X’45 X’30 X’30 X’30
and the character representation is ASCII.
The example shows the error code returned was 00 and the LMK check value returned
was 2686047444912422 and the firmware installed is 0007-E000.

UDP Protocol
The HSM client expects all UDP connections to be made on the Well-Known-Port at the IP
address (see Chapter 1). The IP address and Well-Known-Port address are defined to the
HSM when configuring the software settings with the Console CH command.
All UDP host clients sending data to an HSM send the datagrams to the Well-Known-Port
at the IP address. The HSM (UDP server) processes the datagram and returns a
datagram response to the originating UDP host client.
UDP is a connection-less protocol. If an HSM detects an error in a received datagram it is

discarded. The UDP host client should support a time-out mechanism whereby if a
response is not received within the time-out period the original request is re-sent.
Sending Commands
The payShield 9000 HSM expects a command to be sent in the form defined in the table.

LENGTH 2 Byte Length of the COMMAND field
COMMAND n Byte HSM command
Note: The field COMMAND should not bracketed by X’02 - X’03 as used with the
Async protocol.
Only a single command can be sent to an HSM in one UDP transmission (packet).
Example:
The command format for a diagnostics command (NC) is:

X’00 X’06 X’31 X’32 X’33 X’34 X’4E X’43
and character representation is ASCII.
Returning Responses
When an HSM receives a command from a UDP client the command is processed and the
response returned to the UDP client. The response is of the form defined in the table.

LENGTH 2 Byte Length of the RESPONSE field
RESPONSE n Byte HSM response
Note: The field RESPONSE is not bracketed by X’02 - X’03 (or alternative value)
as used with the Async protocol.
The result of each command sent to an HSM is returned as a separate response to the
UDP client.
Example:
The response format from a diagnostics command (NC) is:
X’00 X’21 X’31 X’32 X’33 X’34 X’4E X’43 X’30 X’30 X’32 X’36
X’38 X’36 X’30 X’34 X’37 X’34 X’34 X’34 X’39 X’31 X’32 X’34
X’32 X’32 X’30 X’30 X’30 X’37 X’2D X’45 X’30 X’30 X’30

where the HSM message header length in set to 04, a message header of 1234 is used,
and the character representation is ASCII.
The example shows the error code returned was 00 and the LMK check value returned
was 2686047444912422 and the firmware installed is 0007-E000.
FICON
FICON is the system for fiber-optic connections to IBM mainframes, and replaces the
older ESCON system. The payShield 9000 Installation Manual gives extensive information
about setting up FICON on the payShield 9000.
Connections
To achieve maximum throughput on the HSM, the FICON interface needs to be driven by
the host with multiple connections. Optimum performance is normally achieved with 4 - 8
connections (depending on the payShield 9000 performance model and the commands
being processed), although for FICON on the 1500 tps model the performance improves
right up to the maximum of 16 connections. Running with only a single connection can
significantly reduce the throughput of the payShield 9000, and means that you will not
be able to reach the rated throughput for the machine.
Configuration Settings
The FICON interface is configured using the CH console command or using Configuration
/ Host Settings / FICON in payShield Manager. The following FICON-specific settings can
be specified:
 Control Unit Image:

 Valid Range: 0-255; Default=0
 This is the actual control unit image defined in the mainframe I/O gens.
 Unit Address:
 The unit address for this control unit.
 Missing Interrupt Handler (mih) Minutes
 This specifies the missing interrupt handler value to be used in the read
device characteristics CCW for the mainframe. If set to 0, the mainframe
setting is used.

Chapter 3 – PIN Printing and

Solicitation
Introduction
This chapter describes how the HSM can:
 use directly-attached impact printers to print PIN mailers which are used to notify
cardholders of their PINs when new cards are issued, or
 use directly-attached impact printers to print PIN Solicitation mailers which invite
users to submit their desired PINs, and how to process the PIN submitted by the
user.
 Use directly-attached laser printers for PIN mailers or PIN Solicitation mailers.
 Support PIN mailer or PIN Solicitation mailer printing in high-volume "print
factories".
The focus here is on the role of the payShield 9000 in the use of printed matter to
engage with cardholders when setting up PINs. Some organizations are moving to using
electronic means (in particular, the telephone system or the Internet) to set up PINs:
chapter 3 of Applications Using the payShield 9000 describes one way that this can be
achieved by using the payShield 9000.
PIN Mailers
Overview
The principle of PIN mailer printing is straightforward – the card issuer’s computer
systems generate a PIN when a new card is issued or a PIN change is requested, print it
in tamper-evident PIN mailer stationery through which the PIN cannot be viewed, and
post it to the cardholder separately from the card itself.
The need for security, to prevent the PIN being disclosed within the card issuer’s data
centre, means that an HSM should be used to prevent the PIN being available in the
clear. Using the methodology described in this chapter, the PIN is in the clear only on the
cable connecting the printer to the HSM (and, of course, inside the PIN mailer).
The stages in providing a secure method of printing PIN mailers are as follows:
 Set up the PIN Mailer form at the HSM

 Generate an Encrypted PIN
 Send PIN Mailer data for printing into the mailer at the HSM
 Verify PIN data cryptography
The following sections assume use of an impact printer directly attached to the HSM and
the use of specialized multi-part stationery requiring the use of impact printers.

PINs in the clear
Commands,
format,
encrypted PINs,
& data
Host
Computer
Impact
printer
HSM
Setting up the PIN Mailer form at the payShield 9000

Forms for conveying and protecting PINs can be produced on a printer attached to a
payShield 9000 HSM. The documents are printed at the terminal in response to a
command from the Host.
A form definition needs to be loaded into the payShield 9000 so that it can format the
output sent to the printer. The HSM can hold a single form definition at a time: this
definition formats the printed output. Form definitions may be used for other purposes
such as key component printing, and so a PIN Mailer form may need to be loaded before
each PIN mailer print run. The form definition data is loaded onto the HSM as text
strings. This data consists of:
 Formatting symbols to format the data: these are described at Appendix D.

 Constants (text strings)
 Variable print field markers, which will be populated with data when the PIN
mailers are to be printed.
The maximum length of a form definition is 299 symbols and characters of constant data.
This form definition is loaded onto the HSM using payShield 9000 Host commands. The
definition data is stored in an HSM until power is removed, or until a reset is performed.
The form definition allows for PIN digits to be printed as words (using the ^V and ^W
symbols). Where words other than the standard English words for numerals ("ZERO",
"ONE", "TWO", …) are to be used, these can also be loaded to the HSM by using a Host
command. The required host commands are as follows - see the payShield 9000 Host
Command Reference Manual for full details:

payShield 9000 Host Command

ID Command Description
PA Load Formatting Data to HSM - to load the first part of the set of symbols
and constant characters.
PC Load Additional Formatting Data to HSM - to load any continuation of the
symbols and constant characters. (PC is a continuation of PA, and must be
preceded by a PA command.)
LI Load a PIN Text String (to allow PIN digits to be printed as words in
languages other than English).
It is possible to format PIN mailers to be "one-up" (i.e. the PIN mailers are printed one
after another on the PIN mailer stationery) or "two-up" (i.e. the PIN mailers are printed
in side-by-side pairs).
Example of a two-up formatting string:

Desired result:
1 THOMAS M SMITH JOHN R JONES

2 APT 4B 1782 427 WEST 9TH ST 3690
3 39 ELM DR WAYNE PA 19132
4 MEDIA PA 19063
5
6 NEVER DISCLOSE YOUR PIN NEVER DISCLOSE YOUR PIN
7
The formatting string required to generate the above form is:
>L>003^0>033^4>L>003^1>023^P>033^5>053^Q>L>003^2>033^6>L>003^3>033^7>
L>L>003NEVER DISCLOSE YOUR PIN>033 NEVER DISCLOSE YOUR PIN >L>F
In this example, the following print formatting symbols are used:
 >L means carriage return + line feed (CR/LF)

 >nnn means skip to output column nnn
 ^n means insert variable print field n – the actual value will be provided at print
time
 ^P means insert clear PIN for mailer 1 of the side-by-side pair.
 ^Q means insert clear PIN for mailer 2 of the side-by-side pair.
 >F means Form Feed (FF).
The full set of print formatting symbols is defined at Appendix D.
Note that the PAN is not printed on the mailer, although the last 6 digits can be printed
for the cardholder’s convenience.

Example of a one-up formatting string:

Desired result:
1 THOMAS M SMITH
2 APT 4B 1782
3 39 ELM DR
4 MEDIA PA 19063
5 YOUR FULL SERVICE BANK
6
1 JOHN R JONES
2 427 WEST 9TH ST 3690
3 WAYNE PA 19132
4
5 YOUR FULL SERVICE BANK
6
The formatting string required to generate the above form is:
>L>013^0>L>013^1>041^P>L>013^2>L>013^3>L>013 YOUR FULL SERVICE
BANK>L>F>
See the previous example to understand the meanings of the formatting codes.
Generate an Encrypted PIN

A PIN must be generated at the time that the card data is created in preparation for the
issuing of the card. For security, this PIN must be encrypted whenever it is associated
with the card data, such that no individual or application has access to both the card’s
PAN and clear-text PIN.
The payShield 9000 offers various host commands for generating a PIN and returning it,
encrypted using the HSM’s LMK, to the Host application:

JA Generate a random PIN. This command can prevent the generation of PINs
considered to be weak.
EE Derive a PIN from the PAN, using the IBM method.
GA Derive a PIN from the PAN using the Diebold method.
The PIN is stored encrypted under the LMK, and is passed to the HSM in this encrypted
form at print time. Therefore the PIN is never available in plain text to the host
computer.
Sending PIN Mailer data for printing at the HSM

When it is required to print the PIN Mailer, the following Host command is used to send
the variable PIN mailer data to the HSM.

PE Print PIN/PIN and Solicitation Data
A PE command is issued for each PIN mailer record. The parameters for this command
include:

 Whether this record is for one-up printing, or whether it is record 1 or 2 for two-up
printing.
 The PAN
 The PIN, encrypted under the LMK.
 The values for the Print Fields identified in the form definition.
The HSM will decrypt the PIN, and then output the record in the defined format to the
printer. The only time the PIN is in the clear is on the cable linking the HSM to the
printer.
PINs created outside of the payShield 9000

The process described above assumes that the PIN was originally created using the
payShield 9000 and is encrypted using the payShield 9000 LMK.
It may be, however, that the PIN derives from a different source, which cannot encrypt
the PIN under the payShield 9000 LMK. In this case, the PIN will be available as a PIN
Block encrypted using a Zone PIN Key (ZPK) and the following payShield 9000 host
command should be used to obtain the LMK-encrypted PIN which is required by the PE
command:

JE Translate PIN from ZPK to LMK
Verify PIN data cryptography

The Host application cannot "see" the data that the HSM has sent to the printer, and
therefore a mechanism is required to enable the Host application to verify that the
cryptographic processing for the PIN mailer printing was performed correctly.
After the HSM has processed the PE Host command, it sends 2 responses to the Host
application:
payShield 9000 Responses

PF Before the PIN mailer is printed. This includes a cryptographic PIN check
value calculated using the LMK.
PZ After the PIN mailer is printed. This confirms that the physical printing
activity completed successfully.
The Host application should confirm the check value returned in the PF response. It does
this by sending the following Host command - preferably to a different HSM from the one
that printed the mailer (but which is using the same LMK).

PG Verify PIN/PIN and Solicitation Mailer Cryptography
This command contains the same PAN and encrypted PIN as was used in the PE Host
command, and the check value contained in the PF response.
The PH response to the PG Host command will indicate whether there is a mismatch
between the encrypted PIN and the check value.

PIN solicitation
Overview
The objective of PIN solicitation is to send a mailer to the cardholder to invite them to:
 select their desired PIN when a new card is about to be issued and return the
desired PIN to the card issuer.
 select a new PIN for a previously issued card.
The PIN may be returned by various methods depending on how the card issuer’s
applications have been designed, such as:
 Returning all or part of the PIN Solicitation mailer onto which the PIN has been
entered;
 Entry at an ATM
 Entry via the Internet
 Entry by telephone (Interactive Voice Recognition)
Once the PIN is returned, it is then associated with the card data in the card issuer’s
application.
The crucial factor in making this secure is that the mailer and returned data do not
include the PAN. Instead they include a reference number which is a cryptographic
representation of the last 10 digits of the account number (excluding the account number
check digit). This reference number is a 10-digit number, followed by two check digits.
Knowledge of the PIN and reference number is of no value to a fraudster. The

relationship between PAN and reference number is determined only within the HSM, and
the PAN and PIN are never presented together.
Because the reference number is the only link to the cardholder’s PIN, there must be a
means of validating the data that is manually entered. There is no way to validate the
PIN except through dual entry procedures or through the visual comparison of the value
entered and the value recorded on the mailer form.
The 12-digit reference number, unlike the PIN, can be validated by a Host program – see
the next sub-section. The check digits can be validated during or after data entry.
PIN solicitation data is batch processed using Host commands. The number of records
entered must be greater than or equal to the minimum batch size specified in the
payShield 9000’s security settings. Each batch consists of at least one logical record.
Each logical record contains the 12-digit reference number in the returned solicitation
mailer and the cardholder-selected PIN.
When the batch has been loaded to the payShield 9000 internal memory, the HSM
encrypts the PINs under LMK pair 02-03, and decrypts the reference numbers, yielding a
value which contains the 10 right-most digits of the account number (excluding the check
digit). The encrypted PIN and 10 digits of the account number are returned to the Host.
The Host can match the account number digits and store the encrypted PIN for
subsequent processing (for verification purposes or the creation of PIN offsets etc.).
Validation Algorithm
The algorithm for validating the two check digits of a reference number is as follows:
First Check Digit:

The first of the two check digits is calculated as:

MOD 10 [10 - MOD 10 (Y)]
where Y is the sum of the products obtained by multiplying the 3rd to the 10th digits of
the reference number by the following weights:
Digit Weight
3 9
4 7
5 8
6 6
7 7
8 9
9 6
10 8
Second Check Digit:

The second check digit is calculated as:
MOD 10 [10 - MOD 10 (Z)]
where Z is the sum of the following:

f(digit 1) + digit 2 + f(digit 3) + digit 4 +f(digit 5) + digit 6 + f(digit
7) + digit 8 + f(digit 9) + digit 10 + f(first check digit)
The value of f(digit n) is determined as follows:
Digit f(digit n)
0 0
1 2
2 4
3 6
4 8
5 1
6 3
7 5
8 7
9 9
The MOD 10 (n) operation yields a value that is the remainder after dividing n by 10.
This remainder is the same as the low-order digit on n.
Example:
The following example illustrates the validation of the reference number 936125183702,
where 0 is the first check digit and 2 is the second check digit.

10-digit reference check digits
9 3 6 1 2 5 1 8 3 7 0 2
Stages in PIN Solicitation

The stages in providing a secure method of PIN Solicitation are as follows:
 Set up PIN Solicitation Mailer form at the HSM

 Generate an Encrypted PIN (optional)
 Send PIN Solicitation Mailer data to the HSM for printing on a printer directly
attached to the HSM.
 Verify the PIN data cryptography
 Processing the selected PIN returned by the cardholder.
As for PIN printing, this section assumes use of an impact printer directly attached to the
HSM and the use of specialized multi-part stationery requiring the use of impact printers.
Setting up the PIN Solicitation Mailer form at the HSM

This is the same process as described earlier for setting up the PIN Mailer form.
The available symbols to control printing (sent to the HSM using the PA and PC Host
commands) include:
 ^R for Reference Number 1

 ^Q for Reference Number 2.
See Appendix D for the full set of printing control symbols.

The mailer can be designed to print the Reference Number but not the PIN in situations
where the cardholder is required to provide a PIN. Alternatively both the reference
Number and the PIN can be printed for situations where the cardholder is invited to
change the default PIN that the issuer has provided and will use in the absence of a
customer-specified PIN.
Note that the PAN is not printed on the mailer, although the last 6 digits can be printed
for the cardholder’s convenience.
Generating an Encrypted PIN

An encrypted PIN is required only where the card issuer is providing a default PIN which
the cardholder is invited to change. This is not necessary where the card issuer always
requires the cardholder to select their own PIN.
Where an encrypted PIN is required, the same Host commands are used as described
previously.
Sending PIN Solicitation Mailer data for printing at the HSM

Where the mailer is to include both the PIN and the Reference Number, the same PE
Host command as described earlier should be used.
Where only the Reference Number (without the PIN) is to be printed on the mailer, the
OA Host command should be used.

OA Print a PIN Solicitation Mailer
This provides the same information as the PE Host command, except that it does not
provide an encrypted PIN.
The Reference Number is not part of the PE or OA command, but is calculated by the
HSM from the last 10 digits of the PAN (excluding the check digit) prior to printing the
mailer.
Verify PIN Solicitation data cryptography

The Host application cannot "see" the data that the HSM has sent to the printer, and
therefore a mechanism is required to enable the Host application to verify that the
cryptographic processing for the PIN Solicitation mailer printing was performed correctly.
After the HSM has processed the PE or OA Host command, it sends 2 responses to the
Host application:
payShield 9000 Responses to PE Command

PF Before the PIN mailer is printed. This includes a cryptographic PIN check
value calculated using the LMK.
PZ After the PIN mailer is printed. This confirms that the physical printing
activity completed successfully.

payShield 9000 Responses to OA Command

OB Before the PIN Solicitation mailer is printed. This includes a cryptographic
Reference Number check value calculated using the LMK.
OZ After the PIN Solicitation mailer is printed. This confirms that the physical
printing activity completed successfully.
The Host application should confirm the check value returned in the PF or OB response. It
does this by sending the following Host commands - preferably to a different HSM (but
with the same LMK).

PG Verify PIN/PIN and Solicitation Mailer Cryptography (for a PF response)
RC Verify Solicitation Mailer Cryptography (for an OB response)
These commands contain the same PAN and encrypted PIN as was used in the PE or OA
Host command, and the check value contained in the PF or OB response.
The PH or RD response to the PG or RC Host command will indicate whether there is a

mismatch between the encrypted PIN and the check value.
Processing the selected PIN returned by the cardholder

The cardholder will return their selected PIN together with the Reference Number. This
data needs to be processed as follows prior to the card being issued.
Entry of PIN and Reference Number into a Host application

The PIN and Reference Number need to be entered into a host application. The reference
Number consists of 10 digits of data plus 2 check digits. The Host application should
confirm that the Reference Number has been entered correctly by validating the check
digits. This should be done in the host application, using the algorithm documented
elsewhere in this manual.
Recovery of PAN and Encrypted PIN

The Reference Number and plain-text selected PIN must now be converted into a plain-
text PAN and encrypted PIN, which can be passed to the card issuing system. This is
accomplished using the HSM.
Up to 2,520 records (consisting of Reference Number + Selected PIN) can be loaded into
the HSM at a time. This data goes into the HSM’s user storage area, and overwrites any
data that is already there: any user storage area data that is overwritten in this way will
need to be reloaded after this process is completed.
These records are loaded using the following Host commands:

QC Final Load of Solicitation Data to User Storage - one QC command is
required for the batch, and can contain up to 1,260 records.

QA Load Solicitation Data to User Storage - if more than 1,260 records is

needed for the batch. Each QA command can contain 25 records. Any QA
command(s) must precede the QC command.
The QB responses to the QA command are simple acknowledgements. The actual

returned data for all the QA and QC commands is returned in one or two QD responses to
the QC command. (If it is required to ensure that only a single QD response is returned,
the batch size must not exceed 1,260 records.)
For each of these records, the QD response(s) provide(s) the 10 rightmost digits of the
PAN in plain-text and the PIN encrypted under the LMK. This data will then be used by
the host applications to generate the data for the card to be issued.
In order to prevent the plain text PIN in the QA/QC commands from being matched with
the account number in the QD response(s), the order of the records in the QD
response(s) is randomized. To provide additional security, the minimum batch size (as
defined in the CS Console command or in the payShield Manager Configuration / Security
Settings / Initial dialogue box) should be made as large as possible.
Printer Support
Impact printers
The payShield 9000 allows direct attachment of printers with the following interfaces:
 Serial
 Parallel - D25 connectors
 Parallel – Centronics
 USB
These printers are connected to one of the USB ports on the payShield 9000. Serial and
parallel printers are attached using the appropriate serial or parallel adapter cable from
Thales: these adapter cables are intelligent and include microprocessors, the drivers for
which are included with the HSM software. (USB adapters from other sources should not
be used as these may not work with the drivers installed on the HSM.)
Cable length limitations conform to appropriate standards. (Note that for serial printers,
the maximum cable lengths are dependent on the baud rate of the interface and the
physical characteristics of the type of cable used.)
Printers must support the ASCII character set.
Directly-attached laser or ink jet printers

Overview
There is a gradual move away from character-based impact printers to laser (or ink-jet)
printers for the production of PIN or PIN Solicitation mailers. These offer benefits in
terms of performance, quality of output, and use of a wider range of stationery.
A PC application (e.g. Thales PINman) is required to manage and drive the laser printer,
providing very accurate positioning of printing. Additional fonts are required, and the
laser printer may require additional memory to accommodate these.
As with the use of directly-attached impact printers, this arrangement offers a high
degree of security because the clear PINs are only present on the printer cable and in the
printer.

For convenience, this document will refer just to laser printers. However, ink-jet printers
can also be used.
PINs in the clear

Encrypted PINs & data
Commands,
format,
encrypted PINs,
PC Application & data
Host
Computer
Laser
or ink-jet
printer
HSM
Stationery for laser-printed mailers

Mailer printing using laser printers cannot use the traditional multi-part stationery, which
requires an impact printer to cause the secret data to be printed inside the envelope.
Instead specialised laser printer stationery is used, with a plastic panel where the PIN (or
secret data) will be printed. The panel has a printed mask on it such that the PIN printed
on the panel cannot be read unless the panel is removed and held up to the light or the
mask is rubbed off: if these actions are performed, it is evident that the panel has been
tampered with.
Special fonts, provided by the stationery manufacturer, are required to allow the PIN to
be printed over the mask. Accurate positioning is essential to align the mask and printed
PIN.
Examples of stationery made for this purpose are:
 Bastione PIN-TAB
 Hyadalam Laser pin
 Page International ICS V3
Caution
The use of laser printers for printing of mailers is growing in popularity because of the
benefits in terms of performance, reduced noise, and quality of output. However, some
concern has been expressed about the security of this approach - for example at:
http://www.cl.cam.ac.uk/~mkb23/research/PIN-Mailer.pdf
Anyone contemplating implementing laser printing technology should research the

concerns and implement any additional security measures that they feel are appropriate.

Modifications for this solution

The principles described previously relating to the use of character impact printers apply
equally to the use of laser printers, but there are some additional considerations.
Fonts
The laser printer must be capable of allowing the specialized fonts needed for the
stationery to be loaded. This may require additional memory to be installed in the
printer.
PC Application
A PC application is necessary to enable this approach to work. This must be able to:
 Communicate with the payShield 9000 - sending the appropriate host commands
and data (including encrypted keys) and processing responses.
 Design output forms.
 Pass printer control data to the HSM, using the PA and PC host commands as
described previously. Particularly important is the ability to accurately position the
(notional) print head - the standard column/row positioning provided by the
standard PA/PC formatting commands is not precise enough, and the laser printer
chosen must allow print head positioning by user-defined data. In the PA/PC
command the control string required by the printer to do this would be passed by
the application to the HSM using the "|" Symbol (‘6A’ in EBCDIC, ‘7C’ in ASCII).
See Appendix E for an example.
High-volume "print factories"

Overview
Where high-volume PIN Mailer printing is required, greater throughput can be achieved
by using a print server driving one or more high-volume laser printers, possibly providing
other functions such as collating, stapling, stuffing into envelopes, and so on.
In this case, the printer is not directly connected to the HSM but is connected to the print
server. The print server can make use of one or more HSMs to decrypt the PINs provided
by the host application. It then incorporates the clear PINs returned by the HSM in the
data sent to the printer.

Print Server
Printer data,
Encrypted PINs Inc. clear PINs
& data
High-volume
Encrypted Clear printer
Host PINs PINs
Computer
PINs in the clear

HSM
Commercial products implementing this architecture are available from various vendors
such as Red Titan and Phalanx e-Solutions.
Security Considerations
Whereas in the previously discussed cases of directly attached printers the clear PINs are
only present in the printer and the cable connecting the printer to the HSM, in the print
factory scenario the PINs are also in the clear in the print server and on the network
connecting the print server to the HSM. Furthermore, the print server is also connected
to the host system and potentially to the institution’s network.
There is therefore a wider range of attack opportunities than with directly attached
printers. Organizations implementing this printing architecture should satisfy themselves
that they have implemented suitable security and system design measures - which might
include:
 physical access controls

 network isolation
 software design preventing PINs returned by the HSM from being accessed more
than once
 use of different print engines used for sensitive and non-sensitive data
 Automatic memory flushing.
Solutions of this type will use similar stationery to that used with directly attached laser
or ink-jet printers, and so the Caution described in that section also applies here.
However, the Phalanx PIN Production System using PIN-TAB mailers meets the UK Cards
Association Standard 71, Security level 4 (Formerly APACS PIN standard).
Relevant payShield 9000 Commands

The following payShield 9000 host commands allow:
 a PIN encrypted under the LMK to be decrypted, and

 a PIN encrypted under a ZPK to be translated to encryption under the LMK (so that
it can then be decrypted).

NG Decrypt a PIN encrypted with LMK
JE Translate a PIN from ZPK to LMK Encryption
The response to the NG command includes both the clear PIN for PIN Mailer printing and
a Reference Number that can be used for PIN Solicitation Mailer printing.

Chapter 4 – Transaction Key Schemes

General
The transaction key scheme is a technique in which data-encrypting keys change with
each transaction in a manner that cannot be followed by a third party. This is typically of
use in Electronic Fund Transfer at Point Of Sale (EFTPOS) systems where fund transfer
requests and responses are exchanged between a retailer (EFTPOS terminal) and an
acquirer, and then, optionally, between the acquirer and the card issuer.
The payShield 9000 HSM supports three techniques:
 Racal (or APACS) Transaction Key Scheme (RTKS). Discussed in this chapter.
Detailed descriptions of the host commands are included in 1270A546 payShield
9000 Host Command Reference Manual.
 Derived Unique Key Per Transaction (DUKPT). Discussed in this chapter. Detailed
descriptions of the host commands are included in 1270A546 payShield 9000 Host
 Australian (AS 2805) Transaction Key Scheme. This requires optional license
HSM9-LIC003 to be installed on the payShield 9000. The Scheme is described
in1270A547 payShield 9000 Australian Standards Reference Manual.
The payShield 9000 also provides functionality to enable it to participate in systems
meeting the requirements of GBIC/ZKA: this is discussed later in this chapter.
Racal Transaction Key Scheme (RTKS)

The Racal Transaction Key Scheme (RTKS) is a key management technique that is closely
coupled with message authentication. The functions provided by an HSM include key
management in addition to MAC generation and verification.
In the Racal Transaction Key Scheme the TPK and the TAK are updated after each EFT
transaction using an algorithm that depends on the current key and the details of the
transaction (which are known to both communicating parties but do not form part of the
transmitted message, and so would not be known to a third party).
This affords a very high degree of protection for the cryptographic keys. Even if a third
party were able to discover the value of the cryptographic key in use at a particular time,
this would not facilitate discovery of the keys used on previous transactions (i.e., the
scheme has good break-backward protection). Also, if some card data were not
transmitted, the third party would not be able to discover the new value of the keys for
the subsequent transaction (break-forward protection).

T r a n s a c tio n K e y
R e qu est M e ssag e D a ta MAC
K ey Req MR R e sp M R
D e riv e d M A C K e y K ey
D a ta
R e sp on se M essa ge D a ta MAC
OWF
P IN
D a ta
D e riv e d P IN K e y K ey E n c r y p te d P IN
N e w T r a n s a c tio n K e y
Racal Transaction Key Scheme
The key update algorithm used in the Racal Transaction Key Scheme is based on a One-
Way Function (OWF) involving the current key value and the Message Authentication
Code (MAC) residues from the request and response messages from the transaction. The
use of the MAC residues is important, as they are not part of the transmitted data.
In this scheme, the MACs are calculated using a key derived from the transaction key,
and not the transaction key itself. This also applies to the PIN encrypting key.
For more details of the Racal Transaction Key Scheme see Racal-Transcom Publication
RRL4 Secure Key Management for Pin Encryption and Message Authentication.
RTKS Functions
The following functions are all for use at an acquirer site:
 Transaction request with PIN (T/AQ key). Used to receive a cardholder request
message from a terminal with a PIN encrypted under the T/AQ key.
 Transaction request without PIN. Used to receive a cardholder request message
from a terminal with no PIN.
 Transaction request with PIN (T/CI key). Used to receive the request from the
terminal when the PIN key cannot be determined by the acquirer.
 KEYVAL translation. Used to pass KEYVAL to the card issuer (required to derive
the PIN key) when the PIN key cannot be determined by the acquirer.
 Administration request. Used to receive an administration request message (such
as a reconciliation request).
 Transaction response originating at the card issuer. Used when authorization is
generated at the card issuer.
 Transaction response originating at the acquirer. Used when authorization is
generated by the acquirer.
 Verify confirmation message from terminal. Used to verify the MAC on a
confirmation message from the terminal.
The commands RI, RK, RM, RO, RQ, RS and RU are only available when Racal
Transaction Key Scheme is selected in the payShield 9000 security settings.

The existing Racal Transaction key commands have been modified to support longer
messages. The new commands are backward compatible with existing systems.
The details of the modifications are as follows:
Old style: Pointer (not all functions) 2H
Message Length 2H
Message Text nA
New style: Pointer (if required) 2H
Message Length 2H
Message Text nA
Delimiter 1C Optional, only if original length is 0
Extended Message Pointer(s) 4H Optional, only if original length is 0 and
function requires one or two pointers
Extended Message Length 4H Optional, only if original length is 0
Extended Message nA Optional, only if above field is non zero
To use the extended message length option, the calling application has to set the
Message Length field to zero, whereupon the Message Text field will be of zero length,
i.e. not present. The zero Message Length enables an HSM to check for the optional
Delimiter, any Extended Message Pointer(s), and the Extended Message Length field
which defines the length of the Extended Message.
Some of the functions do not include a pointer to items included in the message, whilst
other functions include either one or two pointers. If a function does include one or two
pointers, one or two Extended Message Pointers are included after the Delimiter as
appropriate. The original pointer(s) in the function are ignored when extended messages
are used, however the 2 hex digit placeholder(s) for the original pointer(s) must still be
supplied.
Whilst the extended commands allow for message sizes up to 65537 characters long (hex
FFFF), in practice the limit is imposed by the maximum size of the HSM input buffer. The
HSM has a much larger input buffer (32K) per connection although the interface option in
use may impose limits which are smaller than this. The HSM will check that the message
lengths (and the pointers) are within sensible limits for an HSM platform executing the
function.
Users may, if they wish, use the Extended Message Length scheme for small messages
(i.e. less than 160 bytes).
Simultaneous use of both Racal and Australian

Transaction Key Schemes
The original design of the payShield assumed that only one (or none) of these schemes
would be used on any one HSM. The desired TKS was selected using a security setting –
e.g. in the CS Console command:
Transaction Key Scheme: Racal, Australian or None [R/A/N]:
Because the two TKSs were mutually exclusive, the same Host command code was used
to identify two different commands, one applicable to the Racal TKS and the other
applicable to the Australian TKS. The command codes affected by this are:
Code  ø
Racal TKS Australian TKS
RI Transaction Request With a PIN Verify a Transaction Request, with PIN,

(T/AQ Key) when CD Field not Available

RK Transaction Request Without a PIN Generate Transaction Response, with
Auth Para Generated by Acquirer
RM Administration Request Message Generate Transaction Response with
Auth Para Generated by Card Issuer
RO Transaction Response with Auth Para Translate a PIN from PEK to ZPK
from Card Issuer Encryption
RQ Generate Auth Para and Transaction Verify a Transaction Completion
Response Confirmation
RS Confirmation Generate a Transaction Completion
Response
RU Transaction Request With a PIN Generate Auth Para at the Card Issuer
(T/CI Key)
RW Translate KEYVAL Generate an Initial Terminal Key

Access to these commands requires Optional License HSM9-LIC025 which is
available in HSM9-PAC301 and HSM9-PAC303. Full details of the commands can
be found in the payShield 9000 Host Command Reference Manual.
ø
Access to these commands requires installation of Optional License LIC003 on
the payShield 9000. Full details of the commands can be found in the payShield
9000 Australian Standards Reference Manual.
The functionality delivered when any of these Host commands was used was dependent
on the security setting mentioned above.
More recently, the need has arisen for both TKSs to be used on the same payShield
9000, and therefore to have access to both versions of these R* commands. In order to
allow users to have access to both versions of the commands, the R* commands have
been "aliased" as H* commands - e.g. for each of the two RI commands there is an HI
command which is identical to the RI command except for the Command code (HI
instead of RI) and Response code (HJ instead of RJ).
Where the user wishes to use the version of the command that is appropriate to the TKS
selected in the security setting they should use the R* variant of the command. For
example:
 if the TKS is set to "Racal" and the user wants the"Transaction Request Without a
PIN" functionality then they would use the RK command.
 if the TKS is set to "Australian" and the user wants the "Generate Transaction
Response, with Auth Para Generated by Acquirer" functionality then they would
use the RK command.
This is exactly as for earlier versions of payShield 9000 software, and so provides
backwards compatibility for existing applications.
On the other hand, if the user wishes to use the version of the command that is not
appropriate to the selected TKS, they should use the H* variant of the command. For
example:
 if the TKS is set to "Australian" and the user wants the "Transaction Request
Without a PIN" functionality then they would use the HK command.
 if the TKS is set to "Racal" and the user wants the "Generate Transaction
Response, with Auth Para Generated by Acquirer" functionality then they would
use the HK command.

In summary:
If Transaction Key If Transaction Key

Scheme = Racal Scheme = Australian
You want to process Racal Use the R* variant of the Use the H* variant of the
Transaction Key commands command command
You want to process Australian Use the H* variant of the Use the R* variant of the
Transaction Key commands command command

Derived Unique Key Per Transaction (DUKPT)

Overview
DUKPT (Derived Unique Key Per Transaction) is a scheme to manage TDES (Tripe-DES)
encryption keys in a card payment environment. It has traditionally been used with POS
(Point of Sale) terminals in North America, but adoption is growing in other regions and
for other applications - and so DUKPT is becoming increasingly important in the
payments space.The DUKPT scheme is specified in ANSI X9.24-1:2009.
DUKPT is used for encrypting PIN blocks, encrypting other data, and message
authentication (MACing). DUKPT is typically used between merchants and their Acquirer.
The Acquirer will repackage the transaction data for passage through the payments
network (which uses Master/Session key management) before passing it to a payments
switch.
Acquirer Domain Payments network
Merchant’s
POS Terminal
Acquirer Switch Issuer
DUKPT Data formatted for payments network
The strength of DUKPT lies in the fact that a new, unique key is generated for each
transaction, such that if a transaction key is compromised this cannot be used to attack
previous at that terminal or transactions at any other terminal. In addition, key
management in the DUKPT environment is simplified by having a single master key
which can manage an entire estate of terminals.
This technique involves the use of a non-secret "key serial number" and a secret "Base
Derivation Key", or BDK. On each transaction, the PIN pad uses a unique key based on a
previous key and the key serial number, which contains a transaction counter. It
encrypts the PIN with this key, then returns both the encrypted PIN and the key serial
number to the acquirer. In an HSM, the key generated by the PIN pad is derived
dynamically and independently of the PIN pad, using the original BDK together with the
key serial number supplied by the PIN pad.
The same BDK can be used by thousands of PIN pads because each PIN pad has a unique
serial number. Therefore each PIN pad produces a unique key for every transaction and a
successful cryptographic attack on one PIN pad will have no effect on any other. The
acquirer only has to manage a relatively small number of BDKs, and the algorithm to

derive a given transaction key is designed in such a way as to require very little
overhead in an HSM.
The Host has the responsibility for maintaining the BDKs. For each transaction, the Host
verifies that the serial number supplied by the PIN pad is valid and extracts from internal
storage the appropriate encrypted BDK identified by the left-most portion of the serial
number. The Host controls BDK generation.
Single-DES and Triple-DES variants of DUKPT

The payShield 9000 HSM supports both single DES and Triple-DES variants of DUKPT.
DUKPT Keys
Three levels of keys are employed in DUKPT:
 Base Derivation Key (BDK) - a TDES master key owned by the acquirer. The BDK
is used for a large number of terminals - perhaps all the terminals that the
provider ships, or to a model of terminals, or to a serial number range.
 Initial Key (IKEY, IK, or IPEK) - a TDES key that is unique to a terminal. The IKEY
is used to initiate the sequence of transaction keys, and is then discarded by the
terminal.
 Transaction key - generated within the terminal. Keys for PIN encryption, data
encryption, and MACing are derived from the transaction key. Each transaction is
provided with a unique key to protect its data. When the encrypted data is
received by the Acquirer, the Acquirer will derive the same transaction key using
the same process that the terminal used to derive the encryption key.
These are described in the following sections.
It can be seen from this process that there is no requirement for the Acquirer and
terminal to exchange keys - except in the unlikely event of a terminal generating a
million transaction keys and therefore requiring a new IKEY.
It is expected that DUKPT will be able to manage AES keys in the future.
The Base Derivation Key (BDK)

The BDK is a double-length TDES key which is usually generated and owned by the
acquirer, and is used for a large number of terminals. (If the BDK is owned by an
organization other than the Acquirer, it will need to be distributed to the Acquirer to
enable them to process transactions. It will also need to be distributed to any other
organization involved in generating IKEYs.) Multiple BDKs will generally be held to allow
for different terminal families or groups. BDK distribution can be done:
 electronically, with the BDK protected by a Zone Master Key (ZMK), or

 in the form of printed components, with separate component holders coming
together to enable the BDK to be formed from their components.
A stored BDK must be protected by encryption using an appropriate Key Encryption Key
(KEK) whenever it exists outside of a Tamper Resistant Security Module (TRSM). Where
Thales payment HSMs are used, BDKs are protected by the HSM's Local Master Key
(LMK).
Base Derivation Key (BDK) Support in the payShield 9000

The following host commands are available to manage BDKs:

Code Description
A0 Generate a random BDK and return it to the Host encrypted under the
Local Master Key (LMK)
A6 Accept a BDK encrypted under a Zone Master Key (ZMK) and translate
it to encryption under the LMK
A8 Translate a BDK from LMK to ZMK encryption
The latest revision of the DUKPT standard (X9.24-1:2009) defines two different methods
for deriving data authentication & encryption keys:
 The bidirectional method uses a single key to protect terminal-to-host data and
host-to-terminal data. BDK types 1 and 3 support the bidirectional method. (Note
that a BDK type 3 uses the 'PIN encryption' variant to derive the data encryption
key, and therefore can only be used to perform data encryption operations. A
BDK-3 cannot be used to perform PIN-related operations.)
 The unidirectional method uses two keys: one key to protect terminal-to-host
data, and another key to protect host-to-terminal data. BDK types 2 and 4
support the unidirectional method.
Further information about the usage of the various BDK types is provided later in this
chapter on the section on Thales Key Types for DUKPT.
Zone Master Key (ZMK) Support

The payShield 9000 HSM supports single-length Zone Master Keys (ZMKs), 16
hexadecimal characters (64 bits); and double-length Zone Master Keys (ZMKs), 32
hexadecimal characters (128 bits). The DUKPT command set ignores the S/D
(single/double length) parameter set in the payShield 9000 security settings (e.g. by the
CS (Configure Security) command).
The Initial Key (IKEY or IK)

The IKEY (originally referred to as an IPEK - Initial PIN Encryption Key) is unique to its
terminal. The IKEY is calculated from:
 the BDK
 the Key Serial Number (KSN) which is unique to the terminal – see below.
The payShield 9000 A0 host command can generate an IKEY and export it under a TMK
(Terminal Master Key) or ZMK (Zone Master Key).
Once created, the IKEY is installed into the terminal. (The IKEY is also recreated
transiently by the Acquirer when processing transactions from the terminal in order to
derive the same transaction key that the terminal used to encrypt its data.)

Key Serial Number

The KSN has a maximum length of 80 bits, and has the following structure:
Element Length Description

Key Set Identifier 5-9 Hex chars. Identifies the BDK to be used for this
(20-36 bits) terminal.
Sub-key Identifier 1 Hex char. Currently set to 0
(4 bits)
Device Identifier 2-5 Hex chars. Unique identifier (i.e. serial number) for
(8-20 bits) this terminal (always even).
Transaction 1 bit + 5 Hex chars. Counter of the number of PIN encryptions
Counter (21 bits) since terminal was initialized.
The first 3 elements in the table above form the Initial Key Serial Number, and do not
change during the life of the terminal (unless a new IKEY is loaded for any reason).
Often only 64 bits of the KSN are used, with the KSN padded with "F" Hex characters to
the left. In this scheme, the KSN would have the following structure:
 Padding - 4 "F" Hex characters, 16 bits.

 Key set identifier - 6 Hex characters, 24 bits. This allows for about 16 million
different BDKs.
 Device Identifier - 5 Hex characters, 20 bits. This includes one bit of the
Transaction Counter, leaving 19 bits for the actual Device Identifier. This means
that about half a million different devices can be managed by the Device
Identifier. No two terminals with the same base derivation key and sub-
key identifiers may be given the same device identifier. Because the
terminal packs the left-most bit of the transaction counter as the right-most bit of
the device identifier, this field is always even (the right-most bit is set to zero).
 Transaction Counter - 5 Hex characters, 20 bits (plus the bit included in the
Device Identifier). The transaction counter is supplied by the terminal to identify a
particular transaction. It is used by an HSM to compute the actual PIN key. The
left-most bit is supplied as the right-most bit of the device identifier, so the length
of this field is 20 bits (5 hex digits). This allows for about 1 million transactions
before a new IKEY would be required - a limit which is unlikely to be reached.
The terminal cannot accept a serial number longer than 20 characters, so the Host
ensures that the total length of the first three fields does not exceed 15 characters.
The Host also supplies to an HSM a three-character KSN descriptor, which defines the
length (in characters) of each of the first 3 fields. It is included with the KSN in Host
storage, and is used by the Host to identify the base derivation key. The KSN descriptor
consists of:
 Left character: base derivation key identifier length.

 Middle character: sub-key identifier key length (currently always 0).
 Right character: device identifier length.
Transaction Keys
When the IKEY is installed in the terminal, it calculates up to 21 "Future Keys". These
Transaction Keys are the keys that will be used in the encryption of future transactions.
The calculation of these keys involves the value of the transaction counter, which
increments for each transaction.

When the initial batch of Future Keys has been derived, the IKEY is no longer required,
and is deleted by the terminal.
When a transaction is being processed, the next available Transaction Key is used. The
keys used for PIN block encryption, MACing, and data encryption are derived from this
transaction key.
The KSN is also modified by incrementing the Transaction Counter.
The DUKPT terminal sends its encrypted data and the KSN, together with other
transaction data, to the Acquirer.
As each Transaction Key is used, it is deleted by the terminal and replaced by a new
Future Transaction Key. This means that even if the security of the terminal is
compromised in any way and its keys extracted, they cannot be used to attack a
previous transaction from this or any other terminal because the key for that transaction
has already been deleted and each terminal generates different keys.
Processing by the Acquirer

When the encrypted data is sent by the terminal to the Acquirer, the KSN (including the
transaction counter) is also sent. The Acquirer can reconstruct the Transaction Key used
by the terminal from the KSN and the appropriate BDK (as identified in the KSN's Key
Set Identifier).
The Acquirer needs to re-package the data received from the terminal into the standard
formats used by the payments network. This will include actions such as:
 Translating a DUKPT PIN Block encrypted with the DUKPT transaction key into one
of the standard PIN Block formats that the payments network uses encrypted with
a Zone PIN Key (ZPK).
 Verifying and translating MACs.

Summary of DUKPT Operations
Terminal Payments
Terminal Acquirer
Vendor Network
Generate BDK
Generate Initial KSN KSN0 BDK
Generate IKEY from

IKEY + BDK & KSN0
KSN0
Generate Future Trans’n

Keys & delete IPEK
FTKs +
KSN0
Initialization
Transaction Use next FTK to derive
keys for transaction
Increment Trans’n Counter

& form KSNT
Send encrypted data & Use BDK & KSNT to derive

KSNT to Acquirer keys for transaction
Delete keys used in Decrypt data & trans-

transaction & create a new late to payment network Process transaction in
FTK formats normal way
Notes:
1. KSN0 = Initial Key Serial Number (with Transaction Counter = 0). May be
modified by Acquirer before generating IKEY.
2. KSNT = Key Serial Number for the transaction, with Transaction Counter
incremented)
3. The BDKs held by the acquirer will be protected using an HSM.
4. The Acquirer operations shown here will involve the use of an HSM for various
cryptographic functions.
Variations on DUKPT
Data Encryption using a PIN Encryption Key Variant
The traditional method of implementing DUKPT X9.24-1:2004 is where the terminal is
initially loaded with an IKEY, and thereafter derives a new PIN encryption key (and
optionally a new MAC key) for each transaction it performs. Since this method does not
support the derivation of data encryption keys, some terminal vendors have implemented
the following hybrid method, using two BDKs: one of which is used to derive the PIN
encryption keys and MAC keys, and a second BDK which is used to derive the data
encryption keys.
In this case, the terminal is initially loaded with IKEYa and IKEYb (which have been
derived from BDKa and BDKb respectively). During each transaction, the terminal derives
two keys, TransactionKeya and TransactionKeyb. The PIN encryption key (and optionally
the MAC key) is derived from TransactionKeya using X9.24-1:2004 compliant methods.
The data encryption key is derived from TransactionKeyb using the PIN encryption key
derivation method described in X9.24-1:2004.

BDKa is a BDK Type 1 and BDKb is a BDK Type 3 - see the section on Thales Key Types
for DUKPT.
Data Translation to DUKPT

In the diagram above, the data flow is from the POS terminal to the Acquirer and then
into the standard payments network. As mentioned already, this will involve translating
DUKPT data to formats used by the payments network.
However, consider the following environment:
Acquirer Domain Payments network
Merchant’s
POS Terminal
Payment Acquirer Switch Issuer

Gateway
Master/Session DUKPT Data formatted for payments network
Here we have an additional link in the chain - the Payment Gateway. This is an
intermediary between the merchant and the Acquirer. The Payment Gateway provides
various services to the Merchant, and might be needed because the merchant is too
small to have a direct relationship with an Acquirer. For the present discussion we shall
assume that the Payment Gateway is required because the Acquirer provides support for
only DUKPT terminals, but the merchant does not support DUKPT.
In such an environment, the Payment Gateway will implement master/session key

management with the merchant POS terminals, using the same data and PIN Block
formats as the payments network. However, because the Acquirer supports only DUKPT
key management and data formats on the terminal side, the Payment Gateway must
have the capability to translate data to DUKPT formats.
DUKPT for Point-to-Point Encryption and Mobile Acceptance

Point-to-Point Encryption (P2PE)
Traditionally in card payment processing, only the PIN is encrypted (in the form of a PIN
Block) - other data such as the PAN has generally not been encrypted: PCI DSS covers
the Acquirer domain and requires encryption of cardholder data such as the PAN when
the data passes over a public network, but not where the data is on a secure private
network.

Encrypting cardholder data at the merchant, at the Acquirer, and on the network
connecting them - whether this is a private network or not - takes the data out of scope
of PCI DSS compliance and audit. This is very attractive to merchants and Acquirers
because of the cost of PCI DSS compliance and audits, and so there is a growing interest
in encrypting all cardholder data in the Acquirer domain - this is referred to as P2PE.
A wide variety of P2PE implementations are available, with proprietary designs by their
vendors. These implementations may involve a Payment Gateway.
DUKPT is often used as the key management method for a P2PE solution, because it
provides a standardised way of exchanging encrypted data (not just PINs) and high
levels of security.
Mobile Acceptance (or Mobile Point of Sale - mPOS)

Traditional card payment terminals are beyond the reach of small merchants or mobile
merchants (such as market stall operators or plumbers) because of the cost of the
terminals and the fixed-line communications infrastructure needed to support them.
Mobile Acceptance is a technology that addresses this issue, and is enjoying a rapid rate
of adoption.
With Mobile Acceptance, the terminal consists of low-cost, secure card readers and PIN
entry devices attached to intelligent mobile communications devices (such as tablets or
standard smartphones). This brings the technology within financial reach of any
merchant or service provider and removes the dependence on a fixed communications
infrastructure.
P2PE must be employed between the mobile terminal and the Acquirer (or a Payment
Gateway providing a mobile transaction service to merchants and passing the
transactions to an Acquirer).
Again, DUKPT is often employed as the key management scheme in this environment.

The role of the payShield 9000 in DUKPT

The payShield 9000 provides a secure platform for performing cryptographic functions,
protecting secret data against attackers either within or outside of the organization. It
can undertake tasks such as:
 Generating keys
 Protecting keys by encrypting with an LMK
 Encrypting/decrypting data
 Importing/exporting keys
 Translating PINs from encryption under the base derivation key to encryption
under the appropriate interchange key shared between the acquirer and the issuer
or switch.
 Verifying the PINs received from a terminal using base derivation keys. All four
HSM verification methods (IBM, Diebold, VISA PVV and Encrypted PIN) are
supported.
 Calculating and verifying various types of check values.
 Verifying MACs on messages received from a POS terminal, and generates MACs
on messages to be sent to a POS terminal.
The card schemes require that organizations (Acquirers, Switches, and Issuers) who are
processing their cards’ transactions use HSMs such as the payShield 9000 for certain
cryptographic functions. Even for functions not covered by these mandates, use of HSMs
is best security practise for these organizations.
Systems and products used by these organizations must comply with standards
developed by PCI - a body set up by the card schemes. Acquirers’ systems are audited
against the PCI DSS standard. Payments products must comply with a number of
standards and are certified against various PCI standards. For instance, payment
terminals, including DUKPT-capable devices, must be certified against the PCI PED (PIN
Entry Device) standard. In the case of HSMs, PCI introduced the PCI HSM standard fairly
recently. Although this standard is not yet mandated by the card schemes, PCI in their
standard for P2PE specify that the HSMs used by the acquirer are certified to either FIPS
140-2 or the PCI HSM standard.

payShield 9000 Host Commands for DUKPT

Thales Key Types for DUKPT
The host commands in the next sub-section use the following Thales key types relating to
DUKPT:
Thales Key Key Description

Key Type Type Usage
Code (Key
(Variant Block
LMKs) LMKs)
BDK Type 1 009 B0 This type of BDK is used to secure transactions
("BDK-1") sent between a terminal and an acquirer.
Three types of bidirectional keys may be
derived from a BDK-1:
 PIN encryption keys
 Data authentication (MAC) keys
 Data encryption keys
The same key is used in both terminal-to-
acquirer messages and acquirer-to-terminal
messages.
This type of BDK meets the requirements of
ANSI X9.24-1:2009.
BDK Type 2 609 41 This type of BDK is used to secure transactions
("BDK-2") sent between a terminal and an acquirer.
Five types of unidirectional keys may be derived
from a BDK-2:
 PIN encryption keys (for terminal-to-
acquirer messages)
 Data authentication (MAC) keys (for
terminal-to-acquirer messages)
acquirer-to-terminal messages)
 Data encryption keys (for terminal-to-
acquirer messages)
 Data encryption keys (for acquirer-to-
terminal messages)
Different keys are used for terminal-to-acquirer
messages and acquirer-to-terminal messages.
ANSI X9.24-1:2009.

Thales Key Key Description

Key Type Type Usage
Code (Key
(Variant Block
LMKs) LMKs)
BDK Type 3 809 42 This type of BDK is used to secure data portions
("BDK-3") (not PINs or MACs) of transactions sent
between a terminal and an acquirer.
One type of bidirectional key may be derived
from a BDK-3:
 Data encryption key
Note: The data encryption key is derived from
the BDK-3 using the "PIN verification" variant,
but can be used only for data encryption /
decryption purposes.
The same key is used in both terminal-to-
acquirer messages and acquirer-to-terminal
messages.
This type of BDK does not meet the
requirements of ANSI X9.24-1, but is used in
some proprietary terminal solutions.
See the section on Data Encryption using a PIN
Encryption Key Variant.
Note: this method cannot be used to derive a
PIN encryption key, or a data authentication
(MAC) key.
BDK Type 4 909 43 This type of BDK is used to secure transactions
("BDK-4") between a Payment Service Provider (PSP)
emulating a DUKPT terminal, and an upstream
acquirer.
Five types of unidirectional keys may be derived
from a BDK-4:
 PIN encryption keys (for PSP-to-acquirer
messages)
PSP-to-acquirer messages)
acquirer-to-PSP messages)
 Data encryption keys (for PSP-to-
acquirer messages)
 Data encryption keys (for acquirer-to-
PSP messages)
Different keys are used for PSP-to-acquirer
messages and acquirer-to-PSP messages.
ANSI X9.24-1:2009.
IKEY 302 B1 Initial key injected into POS terminal from
which future transaction keys are generated.

DUKPT Key Management

ID Command Use
A0 Generate a BDK.
Use Mode = 0 where the key is to be used only by the HSM at this time, or
Mode = 1 if it is also required to be exported to another device, encrypted
under a ZMK. The key type is specified in the command as being the
appropriate type of BDK.
See Appendix C for an example of the A0 command being used to generate a
BDK.
A0 Generate an IKEY.
Use Mode = A where the key is to be used only by the HSM at this time, or
Mode = B if it is also required to be exported to another device, encrypted
under a ZMK or TMK. The key type is specified in the command as being the
appropriate type of BDK.
See Appendix C for an example of the A0 command being used to generate an
IKEY.
A6 Import a BDK encrypted under a ZMK. This command would only be used by
the Acquirer if for any reason the BDK was generated by a third party and
passed to the Acquirer.
A8 Export a BDK or IKEY encrypted under a ZMK. This command may be used by
a third party that generates the BDK and passes it to the Acquirer.
PIN Processing

ID Command Use
CA From payShield 9000 software v2.3, the CA command can translate a PIN
Block from encryption under a Terminal PIN Key (TPK) to encryption under
DUKPT.
This allows non-DUKPT terminals to work with a DUKPT-enabled Acquirer.
G0 Translate a DUKPT PIN Block to encryption under a ZPK. This allows the PIN to
be passed into the payments network. The host provides the appropriate BDK-
1, BDK-2, or BDK-4 as identified in the KSN sent by the terminal.
From v2.3 software, G0 can also translate PINs between 2 DUKPT schemes –
for example, where a DUKPT-enabled service provider exists between DUKPT
terminals and a DUKPT-enabled Acquirer.
See Appendix C for an example of the G0 command.
GO Verify a PIN Using the IBM Method, with optional MAC verification. The host
provides the appropriate BDK-1 or BDK-2 as identified in the KSN sent by the
terminal. This command would only be used where the Acquirer is the issuing
bank, and the transaction is not being passed through the payments network.
GQ Verify a PIN Using the VISA PVV Method, with optional MAC verification. The
host provides the appropriate BDK-1 or BDK-2 as identified in the KSN sent by
the terminal. This command would only be used where the Acquirer is the
issuing bank, and the transaction is not being passed through the payments
network.


ID Command Use
GS Verify a PIN Using the Diebold Method, with optional MAC verification. The host
provides the appropriate BDK-1 or BDK-2 as identified in the KSN sent by the
terminal. This command would only be used where the Acquirer is the issuing
bank, and the transaction is not being passed through the payments network.
GU Verify a PIN Using the Encrypted PIN Method, with optional MAC verification.
The host provides the appropriate BDK-1 or BDK-2 as identified in the KSN
sent by the terminal. This command would only be used where the Acquirer is
the issuing bank, and the transaction is not being passed through the
payments network.
MACing

ID Command Use
GW Generate a MAC on a message to be sent to a DUKPT terminal. The host
provides the appropriate BDK-1, BDK-2, or BDK-4 and the KSN for the
terminal. Use modes 4-6 (for BDK-1), D-F (for BDK-2), or J-L (forBDK-4):
Mode 4 or D: Generate an 8-byte MAC
Mode 5 or E: Generate Approval MAC (4 leftmost bytes of MAC)
Mode 6 or F: Generate Decline MAC (4 rightmost bytes of MAC)
GW Verify a MAC on a message sent from a DUKPT terminal. The host provides the
appropriate BDK-1, BDK-2, or BDK-4 and the KSN for the terminal. Use modes
1-3 (for BDK-1), A-C (for BDK-2), or G-I (for BDK-4):
Mode 1 or A: Verify an 8-byte MAC
Mode 2 or B: Verify Approval MAC (4 leftmost bytes of MAC)
Mode 3 or C: Verify Decline MAC (4 rightmost bytes of MAC)
Data Encryption and Decryption

ID Command Use
M0 Encrypt a block of data to be sent to a DUKPT terminal. The host provides to
the HSM the appropriate BDK-1, BDK-2, BDK-3, of BDK-4 and the KSN for the
terminal.
M2 Decrypt a block of data sent from a DUKPT terminal. The host provides to the
HSM the appropriate BDK-1, BDK-2, BDK-3, or BDK-4 and the KSN for the
terminal.
See Appendix C for an example of the M2 command.
M4 Translate a block of data from encryption under a BDK-1, BDK-2, or BDK-3 to
encryption under a ZEK, DEK, or TEK. The host provides to the HSM the
appropriate BDK-1, BDK-2, or BDK-3 and the KSN for the terminal. This allows
data from a DUKPT terminal to be passed into the payments network or used
for other purposes.
M4 Translate a block of data from encryption under a ZEK, DEK, or TEK to
encryption under a BDK-1, BDK-2, or BDK-3. The host provides to the HSM the
appropriate BDK-1, BDK-2, or BDK-3 and the KSN for the terminal. This allows
data from payments network or other sources to be passed to a DUKPT
terminal.

Host Command Examples

Examples of the host commands used for DUKPT are available in the document payShield
9000 Host Command Examples.

German Banking Industry Committee (GBIC)

GBIC (or DK - Die Deutsche Kreditwirtschaft – in German) sets security standards for
German domestic card payments. GBIC was known until 2011 as ZKA - Zentraler
Kreditausschuss – and this name is still in widespread use.
Authorised evaluation labs. evaluate complete systems against the security standard and
recommend approval by GBIC. Each system has to be individually approved and there is
no product certification for HSMs. However, the HSMs used in a system are evaluated as
part of the approval process for that system: this evaluation is specific to the use of the
HSM in that particular system, and the HSM has to undergo evaluation again when used
as part of another system going through the approval process. The payShield 9000 has
been successfully evaluated in several system approvals by GBIC.
GBIC/ZKA PIN Authentication, Message Authentication, and Data Encryption keys are
derived from ZKA Master Keys. The payShield 9000 A0 host command supports the
generation of these working keys: the required random number input can be provided as
one of the A0 command input parameters or generated by the command.

Chapter 5 – The RSA Cryptosystem

General
The RSA cryptosystem is available as an optional feature and the commands described in
this section are activated by the purchase of an additional license.
The RSA public key algorithm was devised in 1979 by Rivest, Shamir and Adleman
(hence the name). It is an asymmetric cryptographic algorithm, which means that the
encryption and decryption keys are different, and that it is computationally infeasible to
deduce the decryption key from the encryption key. The encryption key may be made
public and distributed in clear without compromising the security of the decryption key,
hence the term Public Key Cryptography.
RSA public-key cryptography is usually used in two ways:

 To digitally sign electronic messages to provide proof of the identity of the sender,
and to protect the integrity of the contents of the messages.
 To automate and simplify the difficult problem of secret key distribution and
management in large distributed networks, such as the Internet.
The RSA algorithm is implemented in all variants of a payShield 9000, and can be
activated by installing optional license HSM9-LIC002. RSA performance can be enhanced
in a cost-effective manner by adding optional license HSM9-LIC033.
Functions are provided for:
 Generation of variable-length RSA keys.

 Validation of public key certificates.
 Generation and validation of digital signatures.
 Secure DES key management using RSA public master keys.
 Generation of hash values.
The length of the RSA keys used can be selected from 320 to 4096 bits. NOTE: RSA keys
longer than 2048 bits can only be used with AES key block LMKs: TDES LMKs have
insufficient strength to protect these keys.
HSM Buffer Sizes

The payShield 9000 HSM has a 32K-byte input buffer per connection and it is the
responsibility of the host application to ensure that that the total amount of data sent in
an HSM command does not cause a buffer overflow.
Data Formats
Certificates, signatures, encrypted key blocks and message data supplied in commands
specified in this document are binary fields, with the leftmost byte being the most
significant and the rightmost byte being the least significant. Note that the binary data
may be right justified and padded to the left with zeros, if necessary, in order to make
the data length (in bits) an exact multiple of eight.
Even Public Exponent

There is a variant of RSA (known as the "Rabin" variant) which utilizes an even Public
Exponent. This variant cannot be used for unique encryption/decryption unless the
associated data contains some redundant information which can be used to determine

the correct result. Although the commands specified in this document, which use a
Public Key, could be used with an even Exponent, there is no guarantee that the results
produced by these commands will be correct. It is strongly recommended that the
commands in this document are used only with odd Public Exponents. Note that it is not
possible to use an HSM to generate an RSA Key Set that has an even Public Exponent.
RSA Cryptosystem Functions

The RSA cryptosystem provides the following functions:
 Generation of variable-length RSA keys.

 Validation of public key certificates.
 Generation and validation of digital signatures.
 Secure DES key management using RSA public master keys.
 Generation of hash values.
These functions are implemented by the following host commands:
 Generate an RSA Key Set (EI)
 Load a Secret Key (EK)
 Translate a Secret Key from the Old LMK to a New LMK (EM)
 Generate a MAC on a Public Key (EO)
 Verify a MAC on a Public Key (EQ)
 Validate a Certificate and Generate a MAC on its Public Key (ES)
 Translate a MAC on a Public Key (EU)
 Generate a Signature (EW)
 Validate a Signature (EY)
 Import a DES Key (GI)
 Export a DES Key (GK)
 Hash a Block of Data (GM)
Details of these commands can be found in the payShield 9000 Host Command
Reference Manual.
Common Parameters
Within these functions certain common parameters are defined as follows:
DES Key Type

The DES Key Type field is 4 digits. The first two digits indicate the LMK pair used to
encrypt the key, the last two digits indicate the LMK variant. For example:
 If the DES Key Type is 0600, LMK pair 06-07 is used (no variant).
 If the DES Key Type is 3007, variant 7 of LMK pair 30-31 is used.
Signature Algorithm
01 = RSA
Encryption Identifier
01 = RSA

Hash Identifier
01 = SHA-1, produces a 20 byte result.
02 = MD5, produces a 16 byte result.
03 = ISO 10118-2, produces a 16 byte result.
04 = No hash.
05 = SHA-224
06 = SHA-256
07 = SHA-384
08 = SHA-512
01 = SHA-1 hashing algorithm

The ASN.1 DER object identifier for this hashing function is:
{iso(1) identified-organization(3) oiw(14) secsig(3) 2 26}
which encodes as:

2B 0E 03 02 1A
02 = MD5 hashing algorithm

{iso(1) member-body(2) US(840) rsadsi(113549) digest Algorithm(2) 5 }
which encodes as:

2A 86 48 86 F7 0D 02 05
03 = ISO 10118-2 hashing algorithm

{2 10 67 4}
which encodes as:

5A 43 04
04 = No hash
The no-hash option can be used when an HSM provides signature generation or
validation, or certificate validation, on data that is hashed outside an HSM.
If the no-hash option is chosen, the data that is provided in the Validate a Certificate,
Generate a Signature and Validate a Signature commands is not modified in any way by
an HSM, so it must be precisely the data in the plain signature block (which depends on
the pad mode selected by the Pad Mode Identifier). It is the responsibility of the Host
application to ensure that the precise data to be included in the signature block is
supplied in the command.

The ASN1.DER object identifier for this hashing function is:
id-SHA224 OBJECT IDENTIFIER ::=
{joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3)

nistalgorithm(4) hashalgs(2) sha224(4) }
which encodes as:

60 86 48 01 65 03 04 02 04

which encodes as:

60 86 48 01 65 03 04 02 01

which encodes as:

60 86 48 01 65 03 04 02 02

which encodes as:

60 86 48 01 65 03 04 02 03
Example:
If the SHA-1 algorithm is used to hash the data and the resultant hash value is:
0123456789ABCDEF0123456789ABCDEF01234567
and if the PKCS#1 pad mode is used, the data to be provided must be the complete
ASN.1 DER encoded DigestInfo, which is:
30 21 300906052B0E03021A0500 04140123456789ABCDEF0123456789ABCDEF01234567.
Note that when using the no-hash mode, the HSM checks that the DER encoded
DigestInfo syntax is correct. If there is a digest info syntax error, the HSM returns error
code 74.
Pad Mode Identifier

01 = PKCS#1 v1.5
02 = OAEP

The PKCS#1 standard (see References 3 and 4 at the beginning of this manual) defines
the padding method to be used before operating with a public or secret RSA key.
01 = PKCS#1 v1.5
This simple padding scheme was introduced in the original PKCS#1 specification. The
data to be encrypted or decrypted is padded as follows:
00 BT PS 00 D
where:
 BT is a single byte indicating the block type. BT is 01 for a secret key operation;
02 for a public key operation.
 PS is a padding string consisting of bytes FF....FF for block type 01, random non-
zero bytes for block type 02. PS must contain at least 8 bytes.
 D is the data block.
 The total length of the padded block is equal to the length (in bytes) of the RSA
key modulus
The data block D is the ASN.1 encoded message digest, or AES/DES key (depending on
the command used), as follows:
DigestInfo :: SEQUENCE {
digestAlgorithm DigestAlgorithmldentifier,
digest OCTET STRING
}
DigestAlgorithmldentifier :: SEQUENCE {
algorithm OBJECT IDENTIFIER,
parameters NULL
}
Key block :: SEQUENCE {

key OCTET STRING,
iv OCTET STRING
}
Example 1:
Assume that the SHA-1 algorithm is used to produce the 20-byte digest:
0123456789ABCDEF0123456789ABCDEF01234567.
The DigestAlgorithmldentifier for SHA-1 is:
30 09 06 05 2B0E03021A 05 00.
Thus, the ASN.1 DER encoded DigestInfo is:
30 21 300906052B0E03021A0500
04140123456789ABCDEF0123456789ABCDEF01234567
Example 2:

If a single-length DES key 0123456789ABCDEF and IV = 9999999999999999 are

used, the ASN.1 DER encoding of Key block is:
30 14 04080123456789ABCDEF 04089999999999999999.
When the PKCS#1 pad mode is used, the following validity checks are carried out:
For a validation operation (Validate a Certificate, Validate a 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, error code 76 is
returned.
 The first byte of the clear data block is 00. If not, error code 77 is returned.
 The second byte of the clear data block is 01. If not, error code 77 is returned.
 Subsequent bytes consist of at least 8 bytes of binary 1s, followed by a zero byte.
If not, error code 77 is returned.
 The hash algorithm object identifier corresponds to that of the identifier of the
hash algorithm supplied in the command message. If not, error code 79 is
returned.
 The digest is compared with the hash of the supplied data. If the two values are
not equal, error code 02 is returned.
For a generation operation (Generate a Signature):
 The length (in bytes) of the data block D is at most m-11 (where m is the length,
in bytes, of the modulus of the key to be used). If not, error code 76 is returned.
For an import key operation (Import a DES Key):
 The length of the imported key block is equal to the length (in bytes) of the
modulus of the secret key to be used to decrypt the block. If not, error code 76 is
returned.
 The first byte of the clear data block is 00 and the second byte is 02. If not, error
code 77 is returned.
 Subsequent bytes consist of at least 8 bytes of random non-zero bytes, followed
by a zero byte. If not, error code 77 is returned.
 The data block D conforms to the ASN.1 encoding rules. If not, error code 77 is
returned.
For an export key operation (Export a DES Key):
 The length (in bytes) of the data block D is at most m-11 (where m is the length,
in bytes, of the modulus of the key to be used). If not, error code 76 is returned.
02 = OAEP
Optimal Asymmetric Encryption Padding (OAEP) was introduced in PKCS#1 v2.0, as an
improvement on the original, simple PKCS#1 v 1.5 method described above. OAEP
requires four additional parameters:
 Mask Generation Function
01 = MGF1
 MGF Hash Function
01 = SHA1
 OAEP Encoding Parameters Length
Specifies the length of the encoding parameters.
 OAEP Encoding Parameters
The host may optionally supply a set of OAEP encoding parameters. If OAEP

padding is used, but no Encoding Parameters are required, then OAEP Encoding
Parameters Length should be "00", and this field will be empty.
The OEAP fields are encoded according to PKCS#1 version 2.0 section 11.2.1 (see
Reference 3 at the beginning of this manual). The HSM does not interpret or validate the
contents of this field, it applies the Hash Algorithm to it and feeds the result into the
OAEP process.
Key Block Type

01 = Standard Key Block Type
02 = Key Block Template
03 = Unformatted Key Block
This parameter specifies the type of data structure used to carry a DES key.
01 = Standard Key Block Type

This is the standard key block format as supported in the Model 7 HSM. The format is as
shown in the PKCS#1 v1.5 padding scheme above, i.e.:
Key block :: SEQUENCE {
key OCTET STRING,
iv OCTET STRING
}
Note: For a DES/3DES key, the ‘key’ may be 8, 16 or 24 bytes, and the ‘iv’ is 8 bytes; for
an AES key, the ‘key’ may be 16, 24 or 32 bytes, and the ‘iv’ is 16 bytes.
02 = Key Block Template

This method supports any valid ASN.1 DER encoded Key Block format, which may consist
of arbitrary encoded data with a Key Block field containing a plain-text DES Key of single,
double or triple length.
The Host must supply a block of data, which conforms to ASN.1 DER encoding, with an
indication of the position in which the key is located (DES Key Offset). The key data area
of the template must be zero filled.
For key export, an HSM overlays the zero filled data with a DES or Triple DES key as
appropriate.
For key import, an HSM verifies that the decrypted data conforms to the specified
padding, then checks that the supplied template matches the decoded data. It then
extracts the data at the position indicated by the DES Key Offset, and use this as the key
for import.
An example Key Block structure and template is shown below. This structure is used for
Diebold Remote Key Transport.
Example Key Block Structure
RecipientInfo ::= SEQUENCE {
version Version,
issuerAndSerialNumber IssuerAndSerialNumber,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
keyOrKey block KeyOrKey block

KeyOrKey block ::= CHOICE {

encryptedKey EncryptedKey,
EncryptedKey block encryptedKey block
}
EncryptedKey ::= OCTET STRING
EncryptedKey block ::= ENCRYPTED Key block – a BIT STRING
Key block ::= SEQUENCE {

version Version, -- 0
originatorIssuerAndSerialNumber IssuerAndSerialNumber,
keyId KeyId,
key Key,
keyUsage [0] KeyUsage OPTIONAL
}
Example Key Block Template

A key block template corresponding to the above structure is shown below:
30 61 Key block
02 01 00 version = 0
30 47 originatorIssuerAndSerialNumber
30 42 issuer
31 10
30 0E
06 03 55 04 03 attributeType = commonName
13 07 52 6F 6F 74 20 43 41 attributeValue = "Root CA"
31 2E
30 2C
06 03 55 04 0A attributeType = organizationName
13 25 attributeValue = "Initial Certificate
Authority Company"
49 6E 69 74 69 61 6C 20 43 65 72 74 69
66 69 63 61 74 65 20 41 75 74 68 6F 72
69 74 79 20 43 6F 6D 70 61 6E 79
02 01 02 serialNumber = 2
02 01 00 keyIdentifier = 0, A key
04 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 key
The Key Block Template requires four additional parameters:
 Key Block Template Length

The length of the key block data
 Key Block Template
The actual template, as shown in the example above
 DES Key Length
The length of the DES key within the key block.
 DES Key Offset
Offset to the location of the DES key within the key block. In the example above
this points to the beginning of the block of zeros shown in bold italics and the
offset is 83 (decimal) bytes.

Another two optional parameters support a check value. The Check Value is not required
for the Diebold implementation, but provides flexibility to support applications that
require a check value in the key block.
 Check Value Length
Length in bytes of the check value field. This field should be 0 if no check value is
used.
 Check Value Offset
Offset to the location of the check value within the key block.
03 = Unformatted Key Block

This is the format required for remote ATM key loading for NCR ATMs. It consists of only
8, 16 or 24 bytes of key data (for a single, double or triple length DES key), with no
encoding or additional information.
Public Key Encoding
01 = DER encoding for ASN.1 public key (INTEGER uses unsigned representation)
02 = DER encoding for ASN.1 public key (INTEGER uses 2’s complement
representation)
An ASN.1 RSAPublicKey has the following definition:

RSAPublicKey :: = SEQUENCE {
modulus INTEGER, -- n
publicExponent INTEGER -- e
}
payShield 9000 HSM base software supports two different representations for INTEGER
values in the RSAPublicKey - unsigned INTEGER (Public Key Encoding 01) and 2's
complement INTEGER (Public Key Encoding 02).
A public key Modulus represented in 2’s complement form will always have a leading 00
byte, the most significant bit of the second byte will always be ‘1’. A public key modulus
represented in unsigned form will never begin with a 00 byte, the most significant bit of
the modulus will always be ‘1’.
To avoid interoperability problems with non-Thales host security modules, it is

recommended to use Public Key Encoding 02.
Examples:
1024 bit modulus with an exponent of 03 using Public Key Encoding 01:
Sequence Byte Integer Modulus Integer Exponent

Modulus Exponent
Identifier Length Identifier length Identifier length
X'30 X'81 X'86 X'02 X'81 X'80 128 bytes X'02 X'01 X'03
Where:
 X'30 is the identifier specifying the start of a sequence.

 X'81 X'86 specifies the length of the following field in bytes:
- If value is between X'01 and X'7F then this directly specifies length of following
field in bytes (1byte to 127 bytes).
- If value is greater than X'80 it defines the number of bytes to define the length
of the next field in the above example X'81 therefore length i.e. 1 byte (X'86 -
134 bytes).
 X'02 is the identifier specifying the start of the integer.

 X'81 X'80 specifies the length of the following field in bytes using the same
definition as above (128 Bytes).
 The modulus in this example is 1024 bits. For Public Key Encoding 01 this is
represented in unsigned form. The resulting field is 128 bytes.
 X'02 is the identifier specifying the start of the second integer.
 X'01 specifies the length of the following field in bytes using the same definition
as above (1 Byte).
 X'03 is the value of the exponent.
1024 bit modulus with an exponent of 03 using Public Key Encoding 02:
Sequence Byte Integer Modulus Modulus Integer Exponent Exponent

Identifier Length Identifier length Identifier length
X'30 X'81 X'87 X'02 X'81 X'81 129 bytes X'02 X'01 X'03
Where:
 X'30 is the identifier specifying the start of a sequence.

 X'81 X'87 specifies the length of the following field in bytes. Using the same
definition as described in example above, X'87 - 135 bytes.
 X'02 is the identifier specifying the start of the integer.
 X'81 X'81 specifies the length of the following field in bytes using the same
definition as above (129 Bytes).
 The modulus in this example is 1024 bits. For Public Key Encoding 02 this is
represented in 2’s complement form. The resulting field is 129 bytes. The first
byte will always be X’00.
 X'02 is the identifier specifying the start of the second integer.
 X'01 specifies the length of the following field in bytes using the same definition
as above (1 Byte).
 X'03 is the value of the exponent.
Worked Examples
This section demonstrates the typical use of the GK (Export Key under RSA Public Key)
host command, whereby a ZPK is securely transported from the local system (an HSM) to
a trusted external system (X).
External Local
System System
ZPK
(X) (HSM)
Both systems must previously have generated RSA key pairs. Additionally, both systems
must trust each other's public keys. For the local system, this can be achieved using the
EO (Generate a MAC on a Public Key) command, which requires Authorized State. How
the external system achieves this is outside the scope of this example.
The ZPK is encrypted using X’s public key, positioned within a block containing additional
data, and then signed using an HSM’s private key.

The examples provide values for all input and (anticipated) output parameters to the GK
(Export Key under RSA Public Key) command when using both 1024-bit and 2048-bit
RSA keys.
The first section defines a number of values that are used in producing the encrypted &
signed ZPK (using 1024-bit RSA keys).
The second section Sample Data Generation Procedure (1024-bit RSA keys) shows the
intermediate steps to producing the encrypted & signed ZPK (using 1024-bit RSA keys).
The third section Sample Data Calculation (1024-bit RSA keys) consists of a complete
command message / response message sequence for this example (using 1024-bit RSA
keys).
The fourth section Sample Data Definitions (2048-bit RSA keys) defines a number of
values that are used in producing the encrypted & signed ZPK (using 2048-bit RSA keys).
The fifth section Sample Data Generation Procedure (2048-bit RSA keys) shows the
intermediate steps to producing the encrypted & signed ZPK (using 2048-bit RSA keys).
The sixth and final section Sample Data Calculation (2048-bit RSA keys) consists of a
complete command message / response message sequence for this example (using
2048-bit RSA keys).
Sample Data Definitions (1024-bit RSA keys)

DES KEY TO EXPORT = 7C 7C 7C 7C 7C 7C 7C 7C 7C 7C 7C 7C 7C 7C 7C 7C
DES KEY TYPE = ZPK
DES KEY CHECK VALUE = 8B 15 36 D4 D6 0F EC 19
LMK ENCRYPTED DES KEY (AS ZPK) IN KEY SCHEME U = U 51 3E CF 7E 7D 0A 55 54 90 0F A7 09 B9 A5

F7 21
ENCRYPTION PADDING MODE = OAEP (MGF1, SHA-1, OAEP PARAMS = "09 08 07 06")
ENCRYPTION PUBLIC KEY (ASN.1 DER ENCODED) =
0000: 30 81 89 02 81 81 00 40 CE 04 F8 5B 70 30 49 C8 0•‰.••.@Î.ø[p0IÈ
0010: 48 6C 84 C8 EB 40 54 EC B2 2A FD 6B 78 96 7D A2 Hl„Èë@Tì²*ýkx–}¢
0020: D8 CD F7 5E 5E B9 63 94 95 43 C6 8F 54 31 88 11 ØÍ÷^^¹c"•CÆ•T1ˆ.
0030: B3 A9 91 27 A8 C1 D0 9C B1 3C CD 70 05 80 8E 91 ³©‘'¨ÁÐœ±<Íp.€Ž‘
0040: 80 80 B0 AF 5A 58 C7 11 8B 44 3F C7 CD AE E4 D5 €€°¯ZXÇ.‹D?ÇÍ®äÕ
0050: A7 F6 3C C0 F3 59 6C 98 E3 7B 9F 97 9D 53 C4 4B §ö<ÀóYl˜ã{Ÿ—•SÄK
0060: E1 0E C4 06 8F DD 7A 38 24 BD 20 34 F0 E5 EA 19 á.Ä.•Ýz8$½ 4ðåê.
0070: 8E FF 9B 36 B0 EF 65 90 BF D0 50 99 E2 8A E0 4D Žÿ›6°ïe•¿ÐP™âŠàM
0080: 09 96 D2 E1 36 21 E9 02 03 01 00 01 .–Òá6!é.....
ENCRYPTION PUBLIC KEY MAC = 0E FA 9C 3A
ENCRYPTION PUBLIC KEY AUTHENTICATION DATA = "ABCDEFG"
ENCRYPTION PRIVATE KEY (D) =
0000: 03 36 B4 44 64 B4 71 90 97 20 10 51 9D 6D 1D 29 .6´Dd´q•— .Q•m.)

0010: 98 FB 54 EA 70 53 F0 92 96 6A CD FC 00 70 0E 1D ˜ûTêpSð’–jÍü.p..
0020: 84 16 CA DF A3 E7 F6 F4 DA 7B E0 62 D4 66 A8 05 „.Êß£çöôÚ{àbÔf¨.
0030: E2 5F 5F B6 88 61 9D 78 74 7A BC E7 06 2B 22 CF â__¶â•xtz¼ç.+"Ï
0040: DF A6 7B 5B A5 4D 72 BD E4 69 10 03 60 D2 06 37 ß¦{[¥Mr½äi..`Ò.7
0050: EC E7 09 A6 19 0C BF 33 D3 CE C7 F9 89 94 31 41 ìç.¦..¿3ÓÎÇù‰"1A
0060: 42 11 2F 5E 48 FA 05 C6 70 22 D6 05 7E 6D 10 78 B./^Hú.Æp"Ö.~m.x
0070: 78 BA 9C D4 F2 A2 63 9B A8 71 A4 4D F7 EE 8A 21 xºœÔò¢c›¨q¤M÷îŠ!
SIGNATURE PUBLIC KEY (ASN.1 DER ENCODED) =
0000: 30 81 89 02 81 81 00 40 85 8A 70 C8 7F 3E AB 9E 0‰..@…ŠpÈ•>«ž
0010: 13 6D 2C 0C A3 B6 CC 47 ED 68 6E 3C 6F 31 46 C5 .m,.£¶ÌGíhn<o1FÅ
0020: FE 05 64 3B 4F EE F9 B6 9A 1C ED 6A EB D3 B9 15 þ.d;Oîù¶š.íjëÓ¹.
0030: 31 3C 8C D1 5C BF 26 FB AB D4 8C 6E 08 2A D0 F0 1<ŒÑ\¿&û«ÔŒn.*Ðð
0040: D5 FD 03 64 56 B6 CE A5 91 DF B7 F5 A4 30 B2 6B Õý.dV¶Î¥‘ß·õ¤0²k

0050: EA 3A 8C E4 15 2C DC 50 DE AF 9D DF EF D8 AC 10 ê:Œä.,ÜPÞ¯•ßïØ¬.
0060: DB FF 2B 92 F1 97 C7 D6 D0 CF BC 1A 6D 85 06 CB Ûÿ+’ñ—ÇÖÐÏ¼.m….Ë
0070: F8 1B 76 F1 5D 32 AC D0 72 ED 34 72 30 A9 24 F0 ø.vñ]2¬Ðrí4r0©$ð
0080: 6D B2 E3 8D 55 33 33 02 03 01 00 01 m²ã•U33.....
SIGNATURE PRIVATE KEY (D) =
0000: 01 9F 3E 65 05 75 57 C0 B5 08 7F B4 D3 EE 3B 6B .Ÿ>e.uWÀµ.•´Óî;k
0010: 39 4C 42 79 B1 D7 89 33 BD DA C9 B1 E9 3C 62 33 9LBy±×‰3½ÚÉ±é<b3
0020: C3 7B 00 A6 4F E6 87 45 15 76 4E 6A 62 26 2D C0 Ã{.¦Oæ‡E.vNjb&-À
0030: 9D 90 86 72 AF 9E 9A 5F 3D 7A 2A 92 53 66 B8 F6 †r¯žš_=z*’Sf¸ö
0040: 0D A9 89 E5 24 1D 38 B8 1B 01 0D 55 A6 59 C4 E5 .©‰å$.8¸...U¦YÄå
0050: 53 2F 2A A9 53 CF 68 CF 20 AE 4B CD 9E 26 F1 60 S/*©SÏhÏ ®KÍž&ñ`
0060: 05 4A 58 29 7A C8 43 7F D1 46 C8 E9 E0 66 EE FF .JX)zÈC•ÑFÈéàfîÿ
0070: 64 93 6C 3D 12 CF 3B 78 42 3D 39 77 3E EF 42 E9 d"l=.Ï;xB=9w>ïBé
SIGNATURE PRIVATE KEY (ENCRYPTED UNDER LMK) =
0000: B9 02 C5 03 07 7E E3 DF FF 12 DC 4F 35 A9 96 22 ¹.Å..~ãßÿ.ÜO5©–"
0010: 11 58 A5 59 72 A7 CB 93 0C 39 93 C9 FD 70 07 6D .X¥Yr§Ë".9"Éýp.m
0020: F6 3D 62 C1 BF 00 65 86 42 84 72 9B DE AD 89 8A ö=bÁ¿.e†B„r›Þ‰Š
0030: 3F 58 94 CE B2 7E 66 E5 15 D7 E1 6A 91 6F F1 96 ?X"Î²~få.×áj‘oñ–
0040: 89 BF AC 5F 97 54 B1 EF 4A 36 2A 1A 53 6F 3F 82 ‰¿¬_—T±ïJ6*.So?‚
0050: AA 31 F9 F7 1A 95 EC E9 DD 70 76 CE 7E E5 1C B4 ª1ù÷.•ìéÝpvÎ~å.´
0060: 70 FE A8 A8 6D CC E8 25 E8 6E 4E D7 7A 0A 71 22 pþ¨¨mÌè%ènN×z.q"
0070: 25 5D 11 1C D2 DA EE DA FC 5A 92 93 39 39 2C 77 %]..ÒÚîÚüZ’"99,w
0080: 93 A2 C9 47 ED 0A F1 7C 4F 15 A6 0F C7 F4 36 E4 "¢ÉGí.ñ|O.¦.Çô6ä
0090: 60 D0 38 4F 5F B2 43 3C 01 13 57 44 9A BA 8D 94 `Ð8O_²C<..WDšº•"
00A0: 95 98 E0 A5 EE D3 8C D8 8F 29 93 AF 62 E0 0B E2 •˜à¥îÓŒØ•)"¯bà.â
00B0: 12 B7 07 76 05 BC BB 0D D2 EB 87 B1 DC D8 B8 12 .·.v.¼».Òë‡±ÜØ¸.
00C0: 26 B3 EA 58 58 D1 1F 3B C1 66 DC 75 68 7C EF 64 &³êXXÑ.;ÁfÜuh|ïd
00D0: 4D 46 61 F8 C3 74 AC 76 B4 42 D1 9B D7 D4 63 DC MFaøÃt¬v´BÑ›×ÔcÜ
00E0: C2 A0 E7 CA 7C 4E 7A 09 57 DA FA 3E A6 C8 50 4E Â çÊ|Nz.WÚú>¦ÈPN
00F0: BC 49 37 97 C1 89 67 26 07 2C 3C 1C 1B 8A 53 A4 ¼I7—Á‰g&.,<..ŠS¤
0100: AB F1 63 F1 9D 9E ED 59 EF 62 E3 75 22 13 BD 46 «ñcñžíYïbãu".½F
0110: 10 BC ED CE 38 78 03 72 F5 D1 2D 1C DF 62 42 73 .¼íÎ8x.rõÑ-.ßbBs
0120: 52 53 2C 67 84 AE 7B A7 3B B3 AD 1C 33 EE 6E E4 RS,g„®{§;³.3înä
0130: A0 F2 62 AE 82 DE F1 80 7A 69 8C 68 27 FA 4A 45 òb®‚Þñ€ziŒh'úJE
0140: 73 E2 B4 7C 12 13 9C D3 BC 23 72 9A C3 42 91 20 sâ´|..œÓ¼#ršÃB‘
0150: 8B 1B 9A F3 1F 7D 37 9D ‹.šó.}7•

Sample Data Generation Procedure (1024-bit RSA keys)

1. DER encode ASN.1 format DES Key
30 12
03 10
7C 7C 7C 7C 7C 7C 7C 7C 7C 7C 7C 7C 7C 7C 7C 7C
2. Pad #1 using PKCS#1 OAEP

0000: 00 D8 BF 0E 30 FB 8A E3 98 9E 6D 47 CE A8 05 A9 .Ø¿.0ûŠã˜žmGÎ¨.©
0010: 22 D9 19 4A 2C 3B AC 74 11 CA DE CD C8 7F 78 A6 "Ù.J,;¬t.ÊÞÍÈ•x¦
0020: 64 E5 DC 33 CE 37 72 85 A7 62 7A 37 FE C8 8E 8C dåÜ3Î7r…§bz7þÈŽŒ
0030: 21 21 E0 F9 64 73 24 9C B2 07 7A A3 60 B4 DB ED !!àùds$œ².z£`´Ûí
0040: 52 EF 02 89 3B C8 E9 A9 C3 E6 E8 AB 29 EC 20 D1 Rï.‰;Èé©Ãæè«)ì Ñ
0050: F0 CA 0B AF 7D 6A D3 C7 90 D3 F3 73 75 63 AC A6 ðÊ.¯}jÓÇ•Óósuc¬¦
0060: D4 D4 91 FA D8 5F 23 6B 7C 2A 07 E1 09 C9 5D AC ÔÔ‘úØ_#k|*.á.É]¬
0070: 16 2C C9 70 12 B0 65 F0 40 A1 02 A2 8A 6A 4C 45 .,Ép.°eð@¡.¢ŠjLE
3. Encrypt #2 using Encryption Public Key

0000: 0F 7B 55 85 C7 26 FB 5F 81 45 9F CC 7C 2A CD FC .{U…Ç&û_EŸÌ|*Íü
0010: B2 D4 62 8F CB 86 00 5C 62 47 F9 25 B0 7F FF 05 ²ÔbË†.\bGù%°•ÿ.
0020: 2F D0 03 7A B6 8C 24 DF 98 BB 65 78 D3 40 1B 8B /Ð.z¶Œ$ß˜»exÓ@.‹
0030: 19 17 9F 5E 92 32 BB D0 87 C5 5F 52 A3 BF 3F E8 ..Ÿ^’2»Ð‡Å_R£¿?è
0040: 81 6A 75 C7 19 2D 5F 0D 74 39 23 DA 81 0B 96 FC •juÇ.-_.t9#Ú•.–ü
0050: 43 B8 55 B2 FB 60 F3 E8 B3 45 3E 89 43 4E 40 17 ÇU²û`óè³E>‰CN@.
0060: DC 03 66 C8 8D C6 9E 17 A4 C5 89 54 0B 91 11 9A Ü.fÈÆž.¤Å‰T.‘.š
0070: 1D 0B 04 22 BC B3 55 29 8D BF 0B 80 AC C9 BD 1C ..."¼³U)¿.€¬É½.
4. Insert #3 into data block for signing

0000: 59 59 59 59 59 59 59 59 59 59 59 59 0F 7B 55 85 YYYYYYYYYYYY.{U…
0010: C7 26 FB 5F 81 45 9F CC 7C 2A CD FC B2 D4 62 8F Ç&û_EŸÌ|*Íü²Ôb
0020: CB 86 00 5C 62 47 F9 25 B0 7F FF 05 2F D0 03 7A Ë†.\bGù%°•ÿ./Ð.z
0030: B6 8C 24 DF 98 BB 65 78 D3 40 1B 8B 19 17 9F 5E ¶Œ$ß˜»exÓ@.‹..Ÿ^
0040: 92 32 BB D0 87 C5 5F 52 A3 BF 3F E8 81 6A 75 C7 ’2»Ð‡Å_R£¿?è•juÇ
0050: 19 2D 5F 0D 74 39 23 DA 81 0B 96 FC 43 B8 55 B2 .-_.t9#Ú•.–üÇU²
0060: FB 60 F3 E8 B3 45 3E 89 43 4E 40 17 DC 03 66 C8 û`óè³E>‰CN@.Ü.fÈ
0070: 8D C6 9E 17 A4 C5 89 54 0B 91 11 9A 1D 0B 04 22 Æž.¤Å‰T.‘.š..."
0080: BC B3 55 29 8D BF 0B 80 AC C9 BD 1C 5A 5A 5A 5A ¼³U)¿.€¬É½.ZZZZ
0090: 5A 5A 5A 5A 5A 5A 5A 5A 5A 5A 5A ZZZZZZZZZZZ
5. Generate hash over #4

0000: 91 6C E5 4D EB 72 0C 65 DE E0 32 3F 62 01 61 32 ‘låMër.eÞà2?b.a2
0010: E5 49 DC A4 åIÜ¤
6. DER encode ASN.1 format #5

30 21
30 09
06 05
2B 0E 03 02 1A
05 00
04 14
91 6C E5 4D EB 72 0C 65 DE E0 32 3F 62 01 61 32 E5 49 DC A4
7. Pad #6 using PKCS#1 v1.5

0000: 00 01 FF FF FF FF FF FF FF FF FF FF FF FF FF FF ..ÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
0010: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
0050: FF FF FF FF FF FF FF FF FF FF FF FF 00 30 21 30 ÿÿÿÿÿÿÿÿÿÿÿÿ.0!0
0060: 09 06 05 2B 0E 03 02 1A 05 00 04 14 91 6C E5 4D ...+........‘låM
0070: EB 72 0C 65 DE E0 32 3F 62 01 61 32 E5 49 DC A4 ër.eÞà2?b.a2åIÜ¤
8. Encrypt #7 using Signature Private Key:

0000: 08 60 4D 82 4C B2 A7 3F 9F E7 9A 73 5B AB 66 AC .`M‚L²§?Ÿçšs[«f¬
0010: 3C A0 85 33 BB F7 77 31 AD 36 C0 01 88 2D 2C 27 < …3»÷w16À.ˆ-,'
0020: D6 5D 2C 52 D1 B6 27 CF 92 FF 67 64 4C E4 3A A6 Ö],RÑ¶'Ï’ÿgdLä:¦
0030: 43 22 E6 D6 92 93 C3 D0 C6 2C B6 B2 E5 2D 41 E1 C"æÖ’"ÃÐÆ,¶²å-Aá
0040: 90 77 F8 D8 AB 5F D8 2C 4C C9 CC F5 E8 48 7E 08 •wøØ«_Ø,LÉÌõèH~.
0050: 4B 2B BA E5 F8 A8 EF 19 76 A5 3D 53 6E 00 8A 88 K+ºåø¨ï.v¥=Sn.Šˆ
0060: 33 75 7B B5 66 0D D3 40 CB A2 EE 49 CB 5D 44 C4 3u{µf.Ó@Ë¢îIË]DÄ

0070: 1D 01 13 08 42 2E 2F A6 67 22 6E 84 D7 8D 0D DC ....B./¦g"n„×•.Ü
Sample Data Calculation (1024-bit RSA keys)

Field Length & Type Value
COMMAND MESSAGE
Message Header mA
Command Code 2A "GK" – Export Key under RSA Public Key
Encryption Identifier 2N "01" – RSA Encryption
Pad Mode Identifier 2N "02" – OAEP (EME-OAEP-ENCODE)
Mask Generation Function 2N "01" – MGF1 as defined in PKCS#1 v2.0
MGF Hash Function 2N "01" – SHA-1
OAEP Encoding Parameters 2N "04"
Length
OAEP Encoding Parameters NB "09080706"
OAEP Encoding Parameters 1A ";"
Delimiter
DES Key Type 4N "0600"
Signature Indicator 1A "="
Signature Hash Identifier 2N "01" – SHA-1
Signature Identifier 2N "01" – RSA
Signature Pad Mode 2N "01" – PKCS#1 v1.5 padding
Identifier
Header Data Block Length 4N "0012"
Header Data Block nB "YYYYYYYYYYYY"
Delimiter 1A ";"
Footer Data Block Length 4N "0015"
Footer Data Block nB "ZZZZZZZZZZZZZZZ"
Delimiter 1A ";"
Private Key Flag 2N "99"
Private Key Length 4N "0344"
Private Key nB b902c503077ee3dfff12dc4f35a996221158a55972a7c
b930c3993c9fd70076df63d62c1bf0065864284729bd
ead898a3f5894ceb27e66e515d7e16a916ff19689bfac
5f9754b1ef4a362a1a536f3f82aa31f9f71a95ece9dd7
076ce7ee51cb470fea8a86dcce825e86e4ed77a0a712
2255d111cd2daeedafc5a929339392c7793a2c947ed0
af17c4f15a60fc7f436e460d0384f5fb2433c01135744
9aba8d949598e0a5eed38cd88f2993af62e00be212b7
077605bcbb0dd2eb87b1dcd8b81226b3ea5858d11f3
bc166dc75687cef644d4661f8c374ac76b442d19bd7d
463dcc2a0e7ca7c4e7a0957dafa3ea6c8504ebc49379
7c1896726072c3c1c1b8a53a4abf163f19d9eed59ef6
2e3752213bd4610bcedce38780372f5d12d1cdf62427
352532c6784ae7ba73bb3ad1c33ee6ee4a0f262ae82d
ef1807a698c6827fa4a4573e2b47c12139cd3bc23729
ac34291208b1b9af31f7d379d
DES Key Flag 1N "1"
DES Key (LMK) 1A+32H "U513ECF7E7D0A5554900FA709B9A5F721"
Check Value 16 H "8B1536D4D60FEC19"
MAC 4B 0EFA9C3A
Public Key nB 3081890281810040CE04F85B703049C8486C84C8EB
4054ECB22AFD6B78967DA2D8CDF75E5EB96394954
3C68F54318811B3A99127A8C1D09CB13CCD700580
8E918080B0AF5A58C7118B443FC7CDAEE4D5A7F63
CC0F3596C98E37B9F979D53C44BE10EC4068FDD7A
3824BD2034F0E5EA198EFF9B36B0EF6590BFD05099
E28AE04D0996D2E13621E90203010001
Authentication Data nA "ABCDEFG"


Delimiter 1A ";"
Key Block Type 2N "02" – Key Block Template
Key Block Template Length 4N "0020"
Key Block Template nH "3012031000000000000000000000000000000000"
Delimiter 1A ";"
DES Key Offset 4N "0004"
Check Value Length 2N "00"
Check Value Offset 4N "0000"
End Message Delimiter 1C
Message Trailer nA
RESPONSE MESSAGE
Message Header mA
Response Code 2A GL
Error Code 2A "00" – No error
Initialization Value 16 H "????????????????"
DES Key Length 4N "0128"
DES Key (PK) nB 0f7b5585c726fb5f81459fcc7c2acdfcb2d4628fcb8600
5c6247f925b07fff052fd0037ab68c24df98bb6578d34
01b8b19179f5e9232bbd087c55f52a3bf3fe8816a75c
7192d5f0d743923da810b96fc43b855b2fb60f3e8b34
53e89434e4017dc0366c88dc69e17a4c589540b9111
9a1d0b0422bcb355298dbf0b80acc9bd1c
Signature Length 4N "0128"
Signature nB 08604d824cb2a73f9fe79a735bab66ac3ca08533bbf7
7731ad36c001882d2c27d65d2c52d1b627cf92ff6764
4ce43aa64322e6d69293c3d0c62cb6b2e52d41e1907
7f8d8ab5fd82c4cc9ccf5e8487e084b2bbae5f8a8ef197
6a53d536e008a8833757bb5660dd340cba2ee49cb5d
44c41d011308422e2fa667226e84d78d0ddc
Message Trailer nA
Note: PKCS#1’s OAEP padding involves a random input, and therefore is not predictable.
The value of an encrypted DES key and its signature will be different each time this
command is run, even if the DES key and RSA keys remain the same. The values in the
table above should only be used to indicate how an HSM’s internal processing works: do
not expect to get the same encrypted key and signature as shown above!

Sample Data Definitions (2048-bit RSA keys)

DES KEY TO EXPORT = 7C 7C 7C 7C 7C 7C 7C 7C 7C 7C 7C 7C 7C 7C 7C 7C
DES KEY TYPE = ZPK
DES KEY CHECK VALUE = 8B 15 36 D4 D6 0F EC 19
LMK ENCRYPTED DES KEY (AS ZPK) IN KEY SCHEME U = U 51 3E CF 7E 7D 0A 55 54 90 0F A7 09 B9 A5

F7 21
ENCRYPTION PADDING MODE = OAEP (MGF1, SHA-1, OAEP PARAMS = "09 08 07 06")
ENCRYPTION PUBLIC KEY (ASN.1 DER ENCODED) =
0000: 30 82 01 0A 02 82 01 01 00 40 F5 B5 3A 32 47 50 0‚...‚...@õµ:2GP
0010: 90 AD DE 8A 33 EF 6F 9F 95 EE 58 41 84 F1 FE 7D ÞŠ3ïoŸ•îXA„ñþ}
0020: 31 AE 58 C6 CA E2 A0 62 DA B0 39 E7 45 03 9F 7A 1®XÆÊâ bÚ°9çE.Ÿz
0030: A4 3A 23 6A 45 40 AD 0A 3F 36 1F 90 5F 29 B1 A0 ¤:#jE@-.?6.•_)±
0040: E9 C1 65 B0 A6 56 D9 F8 18 C5 7E 05 D7 87 F1 F8 éÁe°¦VÙø.Å~.×‡ñø
0050: EE 0C 6B E9 B4 2A 83 2C FD BD 35 74 A5 E7 EF 86 î.ké´*ƒ,ý½5t¥çï†
0060: 3B 11 FF 3F 95 DC AC BB DC FD D9 0E A9 C7 D5 52 ;.ÿ?•Ü¬»ÜýÙ.©ÇÕR
0070: CF 0D 1B E4 71 53 2C F6 4E 02 9C CD D7 D9 AE C9 Ï..äqS,öN.œÍ×Ù®É
0080: 2F 90 C3 9D 1B E9 63 AE E6 F5 78 E6 A3 D8 3A C6 /•Ã•.éc®æõxæ£Ø:Æ
0090: 57 2E B5 52 5D 0A 81 79 BC BA 02 63 D8 2E BB 5D W.µR].•y¼º.cØ.»]
00A0: 77 C3 35 56 16 06 B3 27 01 75 3A ED C4 2A AA E1 wÃ5V..³'.u:íÄ*ªá
00B0: 20 D9 23 3C B3 B9 EF 4D DE 0C 7B 07 02 25 3E 25 Ù#<³¹ïMÞ.{..%>%
00C0: 5C 1E DE 05 2D 9C 4F 7A 6C 7A FB F4 E4 08 BB 18 \.Þ.-œOzlzûôä.».
00D0: D9 53 54 C4 44 62 FF 35 2B FF 31 1E 8E 07 A3 83 ÙSTÄDbÿ5+ÿ1.Ž.£ƒ
00E0: 49 A7 88 08 16 4A 24 A0 8F D9 D3 54 9B C3 3D 58 I§ˆ..J$ ÙÓT›Ã=X
00F0: DE C5 25 E9 7F FB FB F8 A6 D4 12 05 12 0A E8 D4 ÞÅ%é•ûûø¦Ô....èÔ
0100: AC 75 6F 3E 85 80 91 8D CB 02 03 01 00 01 ¬uo>…€‘•Ë.....
ENCRYPTION PUBLIC KEY MAC = AA 5E 41 CC
ENCRYPTION PUBLIC KEY AUTHENTICATION DATA = "ABCDEFG"
ENCRYPTION PRIVATE KEY (D) =
0000: 07 B7 88 C7 78 98 9B 3C 0C C3 AE A4 5B D1 E5 61 .·ˆÇx˜›<.Ã®¤[Ñåa
0010: F0 D6 20 36 74 6F 18 9D 51 CA 6F 17 44 13 EC 9A ðÖ 6to.QÊo.D.ìš
0020: 71 2B F7 CA ED 92 C1 05 88 78 93 93 D5 8A 98 F8 q+÷Êí’Á.ˆx""ÕŠ˜ø
0030: 88 6B F8 81 2D 99 51 F5 E3 09 3B 12 8F A7 C6 3E ˆkø•-™Qõã.;.•§Æ>
0040: DF 1B 49 03 61 3D 80 26 7B 68 48 73 A4 47 40 0D ß.I.a=€&{hHs¤G@.
0050: 86 B0 36 82 CD 0A 59 E6 63 8D 70 96 D3 87 DB AB †°6‚Í.Yæc•p–Ó‡Û«
0060: 75 A6 97 04 D9 5E 00 BF E3 1D 48 A6 A3 CC 68 18 u¦—.Ù^.¿ã.H¦£Ìh.
0070: 3D 5C 36 61 E9 94 C7 86 B4 8A 60 7C 23 DE 39 35 =\6aé"Ç†´Š`|#Þ95
0080: 4D 19 5D DA 82 71 06 4F C7 73 82 A0 F9 AB 9F 10 M.]Ú‚q.OÇs‚ ù«Ÿ.
0090: 25 3B 43 74 B6 5B 29 79 0C 34 C2 FF 82 2C D9 62 %;Ct¶[)y.4Âÿ‚,Ùb
00A0: 45 1B 66 0E 43 67 56 A1 E1 9E 04 E8 D1 FD 23 72 E.f.CgV¡áž.èÑý#r
00B0: 4D 81 1D 61 54 22 95 2B 66 05 A5 A2 CD 20 6F 74 M.aT"•+f.¥¢Í ot
00C0: 18 18 FA E4 BD 0F 6E D9 24 64 F6 A7 C6 16 5E 89 ..úä½.nÙ$dö§Æ.^‰
00D0: 46 85 00 12 9F 45 50 CA 6F C9 A9 3B AC E4 2F 39 F…..ŸEPÊoÉ©;¬ä/9
00E0: BA B7 63 7E 8B BB 97 4C D7 A3 90 C8 39 62 85 AE º·c~‹»—L×£È9b…®
00F0: B1 AC 82 E0 70 F8 84 05 53 99 F6 7E 33 EA 76 F1 ±¬‚àpø„.S™ö~3êvñ
SIGNATURE PUBLIC KEY (ASN.1 DER ENCODED) =
0000: 30 82 01 0A 02 82 01 01 00 40 BD C2 92 8D CF A2 0‚...‚...@½Â’•Ï¢
0010: 96 A7 B3 F2 FE 3E 78 C7 24 21 F3 B2 89 A0 CA 5D –§³òþ>xÇ$!ó²‰ Ê]
0020: 6E E5 9F 4F 14 76 59 95 64 32 D2 30 31 42 8D 9B nåŸO.vY•d2Ò01B›
0030: 83 99 99 1A DB E3 B7 10 17 4C 12 87 1F 53 49 05 ƒ™™.Ûã·..L.‡.SI.
0040: 82 46 F3 94 22 32 D2 2F 02 B5 AF D3 C0 E9 1A 28 ‚Fó""2Ò/.µ¯ÓÀé.(
0050: 51 13 96 3A 66 05 98 D9 00 40 E8 CB 48 71 C4 48 Q.–:f.˜Ù.@èËHqÄH
0060: BA FA 17 46 38 DB 3C 35 BA F5 CA 5D C5 6D B9 3D ºú.F8Û<5ºõÊ]Åm¹=
0070: E2 5A C2 A5 C3 D7 49 1F 5B A7 02 98 F0 42 3A DE âZÂ¥Ã×I.[§.˜ðB:Þ
0080: 55 06 9B 0B 40 B4 38 78 E0 55 76 B0 8F 71 A8 EE U.›.@´8xàUv°•q¨î
0090: 10 B1 F7 52 4D A7 DF 52 C4 4B 23 0E 31 E0 B1 E4 .±÷RM§ßRÄK#.1à±ä
00A0: B5 A1 E4 B4 7C 94 E9 E5 30 F6 DB 57 70 7E 53 5A µ¡ä´|"éå0öÛWp~SZ
00B0: 5F BF B0 32 21 44 B5 04 B2 8D 22 B7 21 E4 D5 98 _¿°2!Dµ.²"·!äÕ˜
00C0: 10 17 3B 2B 71 4A 70 3B B3 6F FC B8 9A D5 33 32 ..;+qJp;³oü¸šÕ32
00D0: 60 91 FB 41 A6 D4 FB 71 F4 12 5E 80 33 1D BC E7 `‘ûA¦Ôûqô.^€3.¼ç
00E0: 53 EC 13 4F 9B 3D A9 E7 77 FF 89 54 CC 25 A8 FF Sì.O›=©çwÿ‰TÌ%¨ÿ
00F0: C7 D3 E0 2F C7 03 F0 CF 0F 18 C8 8D 1F 5D 35 32 ÇÓà/Ç.ðÏ..È•.]52
0100: BB 17 DB 94 63 03 77 34 73 02 03 01 00 01 ».Û"c.w4s.....
SIGNATURE PRIVATE KEY (D) =
0000: 01 A1 65 CD 90 11 BB 1C 05 34 34 79 EF B3 D5 FC .¡eÍ•.»..44yï³Õü

0010: 14 78 D1 35 C3 1D 65 95 FD E5 71 B5 E7 B7 20 DA .xÑ5Ã.e•ýåqµç· Ú
0020: 89 A7 1E 7C 97 1A FE E0 25 15 A4 86 06 29 9D 97 ‰§.|—.þà%.¤†.)•—
0030: A0 9C 54 D7 D6 9E 9F AB 64 C3 0C A7 81 D5 26 46 œT×ÖžŸ«dÃ.§•Õ&F
0040: F0 B1 71 69 49 D5 95 4F 59 69 6E A6 14 1D 01 D6 ð±qiIÕ•OYin¦...Ö
0050: 0E 4C 6E 96 2F FB 4C 03 9D 79 C9 94 73 FD 03 B3 .Ln–/ûL.•yÉ"sý.³
0060: 66 2E 47 07 4A 58 A0 74 DB 69 4C 88 6E 9B 12 55 f.G.JX tÛiLˆn›.U
0070: 9A 12 A8 2C 60 D6 9F B3 CF 7B 47 20 C5 89 28 8E š.¨,`ÖŸ³Ï{G Å‰(Ž
0080: 23 4C D6 97 21 D0 19 DF 7E A3 05 AC F2 2E 0C E9 #LÖ—!Ð.ß~£.¬ò..é
0090: 59 7C 98 1B DF AA D7 09 69 D3 04 CA 09 87 4E 52 Y|˜.ßª×.iÓ.Ê.‡NR
00A0: C5 62 CE 85 39 2B 45 8E 6E E3 AA DD E1 85 BD 62 ÅbÎ…9+EŽnãªÝá…½b
00B0: 4F 0A 0F 75 29 32 30 4A 4B 07 7C AA 4A C8 50 48 O..u)20JK.|ªJÈPH
00C0: 0A EE 65 55 89 6B 2D 98 40 33 61 1D DA 24 F4 E8 .îeU‰k-˜@3a.Ú$ôè
00D0: 08 79 D5 AA 5F 4B F8 EB FB 98 DC B9 CB CD 09 AC .yÕª_Køëû˜Ü¹ËÍ.¬
00E0: 78 A0 10 A0 96 5A 63 59 D5 03 2C F3 68 64 D8 B0 x . –ZcYÕ.,óhdØ°
00F0: 05 D2 74 6B 18 A5 0A FB F9 AF 84 31 DB 5B 41 39 .Òtk.¥.ûù¯„1Û[A9
SIGNATURE PRIVATE KEY (ENCRYPTED UNDER LMK) =
0000: 14 F7 B6 45 05 43 83 DA 0C 52 C6 5F 91 86 ED 10 .÷¶E.CƒÚ.RÆ_‘†í.
0010: F6 88 11 F2 8D 0F 69 98 00 3F A6 48 A7 5C E5 12 öˆ.ò.i˜.?¦H§\å.
0020: 34 59 53 EB 41 5B B1 DE C9 21 F5 DD B3 E1 5D 47 4YSëA[±ÞÉ!õÝ³á]G
0030: 5D 8A 27 E4 C8 A9 48 CC 36 F8 C2 5D 84 7B 42 BA ]Š'äÈ©HÌ6øÂ]„{Bº
0040: 66 55 1F 66 DA 86 02 B1 8C B0 F9 F0 B4 90 0E 1C fU.fÚ†.±Œ°ùð´•..
0050: 40 DB BA 12 D3 E2 E7 D1 44 AF 02 97 70 38 8A F9 @Ûº.ÓâçÑD¯.—p8Šù
0060: BC 88 D9 FC 29 6B 1F A8 88 44 47 6D 5E B8 FC 70 ¼ˆÙü)k.¨ˆDGm^¸üp
0070: 90 8D F0 FC B8 18 B7 BB 48 67 67 D1 CB E4 BA 92 ðü¸.·»HggÑËäº’
0080: 77 D7 50 08 84 4E EB FE 38 E6 39 1C DB C8 D4 1C w×P.„Nëþ8æ9.ÛÈÔ.
0090: F2 F6 5C C4 B8 1A BD A0 6D 37 13 75 06 85 A3 0A òö\Ä¸.½ m7.u.…£.
00A0: 24 62 99 72 02 E0 F5 FE D5 BF 2A 3A 0C 25 0E 3D $B™R.ÀÕÞÕ¿*:.%.=
00B0: 64 09 2E 7D 2A 1B 72 3B D1 57 1A 71 92 68 C3 F0 D..}*.R;ÑW.Q’HÃÐ
00C0: DF E6 24 8A 8F 3D D9 34 43 7B 34 25 3D 06 1C 40 ßæ$Š•=Ù4C{4%=..@
00D0: 14 2E B0 F3 83 25 DE 14 3C 6F 3A E3 56 15 FC 61 ..°óƒ%Þ.<o:ãV.üa
00E0: A4 A7 A2 0D E4 F6 BF 38 66 CC 6E 80 6B DD 28 C2 ¤§¢.äö¿8fÌn€kÝ(Â
00F0: AD 96 BE F3 B3 AE 81 EE 49 5D 0E 25 90 A3 32 34 -–¾ó³®•îI].%•£24
0100: 73 5F 48 A8 53 57 00 DF 51 71 E3 9B 1D 6B 35 B7 s_H¨SW.ßQqã›.k5·
0110: 28 AD FC E9 4D B6 95 DC 8D 26 9B 86 40 82 30 AA (üéM¶•Ü&›†@‚0ª
0120: 26 B6 C1 CC 72 48 B3 36 D5 65 18 A2 AF 09 C4 D2 &¶ÁÌrH³6Õe.¢¯.ÄÒ
0130: EB 1A FB F5 4B 91 C6 C0 BD 13 AD 0A F8 D4 EA B2 ë.ûõK‘ÆÀ½..øÔê²
0140: 3F A2 AD 0F 8C CE 1E 4B BE 2F D8 52 4E ED E0 76 ?¢.ŒÎ.K¾/ØRNíàv
0150: 90 D9 B0 C3 67 0F 71 51 3B 78 BE 32 B0 DC 28 56 •Ù°Ãg.qQ;x¾2°Ü(V
0160: 71 70 49 C0 55 1F 4E FD 5F AC 8A 46 F8 E6 02 DC qpIÀU.Ný_¬ŠFøæ.Ü
0170: A6 55 A8 2A F9 18 2D E3 90 7D F7 6F E4 8B B9 65 ¦U¨*ù.-ã}÷oä‹¹e
0180: 85 F6 9B FE B0 D4 37 4A 36 E0 C3 D6 D5 2D 9F 61 …ö›þ°Ô7J6àÃÖÕ-Ÿa
0190: E9 A2 5E 5E 4A A1 E4 C3 CC 74 4C B4 9E 86 4D 8B é¢^^J¡äÃÌtL´ž†M‹
01A0: 23 6B E5 15 B2 42 5D 6F 28 0C 74 3F 4B CF B0 64 #kå.²B]o(.t?KÏ°d
01B0: 95 82 E9 9A 06 FB 78 ED F7 5D AE 1F D9 D3 FA 66 •‚éš.ûxí÷]®.ÙÓúf
01C0: B9 40 7C F2 B4 4A 6F 6E 3F AB 21 49 0A 30 91 92 ¹@|ò´Jon?«!I.0‘’
01D0: 5B 0D DF F0 98 9D 62 58 9A 4F 23 06 1A 2C DB 41 [.ßð˜bXšO#..,ÛA
01E0: CF 34 3D 89 46 EB 39 02 81 9A 81 57 AC B2 B2 BF Ï4=‰Fë9.šW¬²²¿
01F0: 58 7F 84 CF D6 7B FE 91 DB 9A FB BF A3 01 FC B5 X•„ÏÖ{þ‘Ûšû¿£.üµ
0200: 7B C5 12 64 BC 3A 75 8E DF 57 04 B6 A1 69 18 A6 {Å.d¼:uŽßW.¶¡i.¦
0210: 6F E4 E8 67 78 42 B9 08 0E 5C D1 CF 7E E2 FD 7A oäègxB¹..\ÑÏ~âýz
0220: A7 AC 3B 4E 41 39 3F A2 D5 14 B9 76 1A 22 A5 FD §¬;NA9?¢Õ.¹v."¥ý
0230: 80 9A 21 06 D9 9B 40 6A 1C 5B E7 A7 F9 97 7A 98 €š!.Ù›@j.[ç§ù—z˜
0240: 8B AA 1A 37 54 1C D7 D3 8D B0 64 88 AE C8 0E 0A ‹ª.7T.×Ó°dˆ®È..
0250: 9C D3 18 17 7B C1 09 DB 87 68 EA 57 1F 38 4E 45 œÓ..{Á.Û‡hêW.8NE
0260: 7F 80 08 B8 05 5A 6B 4B 82 98 F8 83 B5 1D 72 40 •€.¸.ZkK‚˜øƒµ.r@
0270: 12 A8 F5 DD 87 8D 58 50 40 BF E5 2C 5C 00 61 22 .¨õÝ‡•XP@¿å,\.a"
0280: B4 8B 14 E9 13 2E B2 61 75 77 7B 9F 74 B8 F7 3F ´‹.é..²auw{Ÿt¸÷?
Sample Data Generation Procedure (2048-bit RSA keys)

1. DER encode ASN.1 format DES Key
30 12
03 10
7C 7C 7C 7C 7C 7C 7C 7C 7C 7C 7C 7C 7C 7C 7C 7C
2. Pad #1 using PKCS#1 OAEP

0000: 00 DF F6 83 6C EA D3 47 BE C2 3C 06 6D 66 19 9E .ßöƒlêÓG¾Â<.mf.ž
0010: 14 83 36 95 7B 3B AC 74 11 CA DE CD C8 7F 78 A6 .ƒ6•{;¬t.ÊÞÍÈ•x¦
0020: 64 E5 DC 33 CE 37 72 85 A7 62 7A 37 FE C8 8E 8C dåÜ3Î7r…§bz7þÈŽŒ
0030: 21 21 E0 F9 64 73 24 9C B2 07 7A A3 60 B4 DB ED !!àùds$œ².z£`´Ûí
0040: 52 EF 02 89 3B C8 E9 A9 C3 E6 E8 AB 29 EC 20 D1 Rï.‰;Èé©Ãæè«)ì Ñ
0050: F0 CA 0B AF 7D 6A D3 C7 90 D3 F3 73 75 63 AC A6 ðÊ.¯}jÓÇ•Óósuc¬¦
0060: D4 D4 91 FA D8 5F 23 6B 7C 2A 07 E0 39 DB 5E BC ÔÔ‘úØ_#k|*.à9Û^¼
0070: 6A 50 B5 0C 6E CC 19 8C 3C DD 7E DE F6 16 30 39 jPµ.nÌ.Œ<Ý~Þö.09
0080: 25 5A DD 34 C9 BF 2B 53 98 43 9D B8 1E 0C AF E8 %ZÝ4É¿+S˜C•¸..¯è

0090: E0 38 6F F8 31 CE 18 5B 17 BA F0 47 83 EE D7 7C à8oø1Î.[.ºðGƒî×|
00A0: F9 CD 37 C9 9A AD D1 FF 12 8D 27 9F 03 7D F4 41 ùÍ7ÉšÑÿ.'Ÿ.}ôA
00B0: A8 3B 9C F8 C4 5E 80 F3 2D AF 6F 20 F1 81 7E 07 ¨;œøÄ^€ó-¯o ñ•~.
00C0: 74 E4 0C E8 C0 2A FA D7 BD 22 18 FF BA DB F1 E1 tä.èÀ*ú×½".ÿºÛñá
00D0: 5D AB 8A 0A CC A1 6C 72 FB 8A 5E 8A 13 5B EC 2F ]«Š.Ì¡lrûŠ^Š.[ì/
00E0: A8 8A 55 93 F4 56 CF A4 2E 84 23 1D 7B 8E 4F 54 ¨ŠU"ôVÏ¤.„#.{ŽOT
00F0: 4D AF 58 F9 FF FA 1F 9C 9D F4 A8 5D 2B 2E FA 12 M¯Xùÿú.œ•ô¨]+.ú.
3. Encrypt #2 using Encryption Public Key

0000: 32 27 D3 03 4C 27 B6 48 B7 AE 68 53 77 17 50 62 2'Ó.L'¶H·®hSw.Pb
0010: AF 19 22 24 71 72 E1 E7 51 5C 11 43 81 09 54 FC ¯."$qráçQ\.C•.Tü
0020: D4 46 38 AC 96 98 DE 90 AC EC 0E 0A 97 77 93 CA ÔF8¬–˜Þ•¬ì..—w"Ê
0030: 8C 35 41 7E 0C C9 2B 6A 32 AB C6 60 C7 34 AA 7D Œ5A~.É+j2«Æ`Ç4ª}
0040: FA F8 29 91 71 20 4F 13 7C F9 98 10 91 2B 34 44 úø)‘q O.|ù˜.‘+4D
0050: 9D 7A 39 30 E6 04 13 5D 12 64 D7 0E C5 68 78 E1 •z90æ..].d×.Åhxá
0060: C2 1F 42 C8 EF DE 21 1C CC 78 1D 84 97 96 72 65 Â.BÈïÞ!.Ìx.„—–re
0070: 85 9C 3B E9 3A DF F0 B5 DC A7 9D 53 EF E8 6E A6 …œ;é:ßðµÜ§•Sïèn¦
0080: 14 61 9A FB C0 6A AD FF 66 C5 D6 BD E3 E0 A4 C0 .ašûÀjÿfÅÖ½ãà¤À
0090: B2 08 4D 30 2B 28 96 65 4E F9 36 40 46 45 22 70 ².M0+(–eNù6@FE"p
00A0: C5 11 AE 6B 03 B1 1B 94 4C 8E FC BE 12 40 E5 95 Å.®k.±."LŽü¾.@å•
00B0: E4 32 AE 8C 9B A7 BE 13 5E 6A 29 60 F9 65 77 F9 ä2®Œ›§¾.^j)`ùewù
00C0: 76 34 AC B1 C7 42 C6 28 35 58 BB 68 1A 61 2D FF v4¬±ÇBÆ(5X»h.a-ÿ
00D0: 90 82 48 F6 C9 D4 E8 04 76 B5 94 C7 2A E1 47 F0 ‚HöÉÔè.vµ"Ç*áGð
00E0: 02 2C CD FB 9B 63 63 1B 74 D1 99 AF B3 85 26 7C .,Íû›cc.tÑ™¯³…&|
00F0: 22 3C EF FD 7C EA E8 D1 E0 4A 9E A1 27 FD CB 58 "<ïý|êèÑàJž¡'ýËX
4. Insert #3 into data block for signing

0000: 59 59 59 59 59 59 59 59 59 59 59 59 32 27 D3 03 YYYYYYYYYYYY2'Ó.
0010: 4C 27 B6 48 B7 AE 68 53 77 17 50 62 AF 19 22 24 L'¶H·®hSw.Pb¯."$
0020: 71 72 E1 E7 51 5C 11 43 81 09 54 FC D4 46 38 AC qráçQ\.C•.TüÔF8¬
0030: 96 98 DE 90 AC EC 0E 0A 97 77 93 CA 8C 35 41 7E –˜Þ•¬ì..—w"ÊŒ5A~
0040: 0C C9 2B 6A 32 AB C6 60 C7 34 AA 7D FA F8 29 91 .É+j2«Æ`Ç4ª}úø)‘
0050: 71 20 4F 13 7C F9 98 10 91 2B 34 44 9D 7A 39 30 q O.|ù˜.‘+4D•z90
0060: E6 04 13 5D 12 64 D7 0E C5 68 78 E1 C2 1F 42 C8 æ..].d×.ÅhxáÂ.BÈ
0070: EF DE 21 1C CC 78 1D 84 97 96 72 65 85 9C 3B E9 ïÞ!.Ìx.„—–re…œ;é
0080: 3A DF F0 B5 DC A7 9D 53 EF E8 6E A6 14 61 9A FB :ßðµÜ§Sïèn¦.ašû
0090: C0 6A AD FF 66 C5 D6 BD E3 E0 A4 C0 B2 08 4D 30 Àj-ÿfÅÖ½ãà¤À².M0
00A0: 2B 28 96 65 4E F9 36 40 46 45 22 70 C5 11 AE 6B +(–eNù6@FE"pÅ.®k
00B0: 03 B1 1B 94 4C 8E FC BE 12 40 E5 95 E4 32 AE 8C .±."LŽü¾.@å•ä2®Œ
00C0: 9B A7 BE 13 5E 6A 29 60 F9 65 77 F9 76 34 AC B1 ›§¾.^j)`ùewùv4¬±
00D0: C7 42 C6 28 35 58 BB 68 1A 61 2D FF 90 82 48 F6 ÇBÆ(5X»h.a-ÿ‚Hö
00E0: C9 D4 E8 04 76 B5 94 C7 2A E1 47 F0 02 2C CD FB ÉÔè.vµ"Ç*áGð.,Íû
00F0: 9B 63 63 1B 74 D1 99 AF B3 85 26 7C 22 3C EF FD ›cc.tÑ™¯³…&|"<ïý
0100: 7C EA E8 D1 E0 4A 9E A1 27 FD CB 58 5A 5A 5A 5A |êèÑàJž¡'ýËXZZZZ
0110: 5A 5A 5A 5A 5A 5A 5A 5A 5A 5A 5A ZZZZZZZZZZZ
5. Generate hash over #4

0000: 27 E2 34 FF D1 99 2F 8A A8 56 F0 54 B5 A7 6D 81 'â4ÿÑ™/Š¨VðTµ§m•
0010: A5 80 FA 42 ¥€úB
6. DER encode ASN.1 format #5

30 21
30 09
06 05
2B 0E 03 02 1A
05 00
04 14
27 E2 34 FF D1 99 2F 8A A8 56 F0 54 B5 A7 6D 81 A5 80 FA 42
7. Pad #6 using PKCS#1 v1.5

0000: 00 01 FF FF FF FF FF FF FF FF FF FF FF FF FF FF ..ÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
00A0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
00B0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
00C0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
00D0: FF FF FF FF FF FF FF FF FF FF FF FF 00 30 21 30 ÿÿÿÿÿÿÿÿÿÿÿÿ.0!0

00E0: 09 06 05 2B 0E 03 02 1A 05 00 04 14 27 E2 34 FF ...+........'â4ÿ
00F0: D1 99 2F 8A A8 56 F0 54 B5 A7 6D 81 A5 80 FA 42 Ñ™/Š¨VðTµ§m¥€úB
8. Encrypt #7 using Signature Private Key:

0000: 19 5F 27 EF 10 CA F3 8D 81 98 30 06 38 B1 B4 7C ._'ï.Êó˜0.8±´|
0010: 53 DA 8C E1 96 31 0A A3 0C 43 2A EB 87 F9 4A CE SÚŒá–1.£.C*ë‡ùJÎ
0020: 67 E1 5B 0F 1E 6D 88 DB 59 05 EC AE F9 A0 35 61 gá[..mˆÛY.ì®ù 5a
0030: 8B D8 C4 AC C6 37 36 03 2B 6E C2 5A D7 87 5B 12 ‹ØÄ¬Æ76.+nÂZ×‡[.
0040: 89 B0 35 A5 F9 FD 77 46 BD CB 69 D2 15 4A C5 99 ‰°5¥ùýwF½ËiÒ.JÅ™
0050: DD A5 EE 91 DB B3 22 CD D2 83 FB 38 E8 F8 0E 37 Ý¥î‘Û³"ÍÒƒû8èø.7
0060: 83 C3 BE 3B 90 7B C6 49 59 EC 82 1B D2 9E 63 A8 ƒÃ¾;{ÆIYì‚.Òžc¨
0070: FD 49 0D 4B 1B ED 2E 29 71 C8 EA 87 3D EC 40 3A ýI.K.í.)qÈê‡=ì@:
0080: B1 6C 1F 2B 83 AD 54 8E 81 5A CE EA 26 1B AB 6E ±l.+ƒTŽ•ZÎê&.«n
0090: FC FA 8C B0 79 17 6C D7 10 4A 1E 97 11 4C B6 30 üúŒ°y.l×.J.—.L¶0
00A0: 06 E7 1C B2 C0 5C AD B2 7B 8B 79 31 F7 7D 20 75 .ç.²À\²{‹y1÷} u
00B0: 6B 8C 85 07 6D E3 D5 66 95 24 18 95 6A D8 62 66 kŒ….mãÕf•$.•jØbf
00C0: 26 68 37 E9 66 8D E1 E6 58 63 BD 95 B1 2F 1D F7 &h7éfáæXc½•±/.÷
00D0: E9 B9 41 CC DD E6 55 6F 22 DF 21 14 65 5E 29 0E é¹AÌÝæUo"ß!.e^).
00E0: 89 06 54 B1 11 EF 9A D8 8E 80 67 78 73 F5 73 84 ‰.T±.ïšØŽ€gxsõs„
00F0: 5C DE A5 23 52 8A C8 99 97 07 5B 8C 00 68 F7 A1 \Þ¥#RŠÈ™—.[Œ.h÷¡
Sample Data Calculation (2048-bit RSA keys)

COMMAND MESSAGE
Message Header mA
Command Code 2A "GK" – Export DES Key
Encryption Identifier 2N "01" – RSA Encryption
Pad Mode Identifier 2N "02" – OAEP (EME-OAEP-ENCODE)
Mask Generation 2N "01" – MGF1 as defined in PKCS#1 v2.0
Function
MGF Hash Function 2N "01" – SHA-1
OAEP Encoding 2N "04"
Parameters Length
OAEP Encoding NB "09080706"
Parameters
OAEP Encoding 1A ";"
Parameters Delimiter
DES Key Type 4N "0600"
Signature Indicator 1A "="
Signature Hash Identifier 2N "01" – SHA-1
Signature Identifier 2N "01" – RSA
Signature Pad Mode 2N "01" – PKCS#1 v1.5 padding
Identifier
Header Data Block 4N "0012"
Length
Header Data Block nB "YYYYYYYYYYYY"
Delimiter 1A ";"
Footer Data Block Length 4N "0015"
Footer Data Block nB "ZZZZZZZZZZZZZZZ"
Delimiter 1A ";"
Private Key Flag 2N "99"
Private Key Length 4N "0656"
Private Key nB 14F7B645054383DA0C52C65F9186ED10F68811F28D0F
6998003FA648A75CE512345953EB415BB1DEC921F5DD
B3E15D475D8A27E4C8A948CC36F8C25D847B42BA665
51F66DA8602B18CB0F9F0B4900E1C40DBBA12D3E2E7
D144AF029770388AF9BC88D9FC296B1FA88844476D5E
B8FC70908DF0FCB818B7BB486767D1CBE4BA9277D750
08844EEBFE38E6391CDBC8D41CF2F65CC4B81ABDA06
D3713750685A30A2462997202E0F5FED5BF2A3A0C250
E3D64092E7D2A1B723BD1571A719268C3F0DFE6248A8
F3DD934437B34253D061C40142EB0F38325DE143C6F3


AE35615FC61A4A7A20DE4F6BF3866CC6E806BDD28C2A
D96BEF3B3AE81EE495D0E2590A33234735F48A853570
0DF5171E39B1D6B35B728ADFCE94DB695DC8D269B86
408230AA26B6C1CC7248B336D56518A2AF09C4D2EB1
AFBF54B91C6C0BD13AD0AF8D4EAB23FA2AD0F8CCE1E
4BBE2FD8524EEDE07690D9B0C3670F71513B78BE32B0
DC2856717049C0551F4EFD5FAC8A46F8E602DCA655A8
2AF9182DE3907DF76FE48BB96585F69BFEB0D4374A36
E0C3D6D52D9F61E9A25E5E4AA1E4C3CC744CB49E864
D8B236BE515B2425D6F280C743F4BCFB0649582E99A0
6FB78EDF75DAE1FD9D3FA66B9407CF2B44A6F6E3FAB2
1490A3091925B0DDFF0989D62589A4F23061A2CDB41C
F343D8946EB3902819A8157ACB2B2BF587F84CFD67BF
E91DB9AFBBFA301FCB57BC51264BC3A758EDF5704B6A
16918A66FE4E8677842B9080E5CD1CF7EE2FD7AA7AC3
B4E41393FA2D514B9761A22A5FD809A2106D99B406A1
C5BE7A7F9977A988BAA1A37541CD7D38DB06488AEC8
0E0A9CD318177BC109DB8768EA571F384E457F8008B8
055A6B4B8298F883B51D724012A8F5DD878D585040BF
E52C5C006122B48B14E9132EB26175777B9F74B8F73F
DES Key Flag 1N "1"
DES Key (LMK) 1A+32H "U513ECF7E7D0A5554900FA709B9A5F721"
Check Value 16 H "8B1536D4D60FEC19"
MAC 4B AA 5E 41 CC
Public Key nB 3082010A028201010040F5B53A32475090ADDE8A33EF
6F9F95EE584184F1FE7D31AE58C6CAE2A062DAB039E7
45039F7AA43A236A4540AD0A3F361F905F29B1A0E9C1
65B0A656D9F818C57E05D787F1F8EE0C6BE9B42A832C
FDBD3574A5E7EF863B11FF3F95DCACBBDCFDD90EA9C
7D552CF0D1BE471532CF64E029CCDD7D9AEC92F90C3
9D1BE963AEE6F578E6A3D83AC6572EB5525D0A8179BC
BA0263D82EBB5D77C335561606B32701753AEDC42AA
AE120D9233CB3B9EF4DDE0C7B0702253E255C1EDE05
2D9C4F7A6C7AFBF4E408BB18D95354C44462FF352BFF
311E8E07A38349A78808164A24A08FD9D3549BC33D58
DEC525E97FFBFBF8A6D41205120AE8D4AC756F3E8580
918DCB0203010001
Authentication Data nA "ABCDEFG"
Delimiter 1A ";"
Key Block Type 2N "02" – Key Block Template
Key Block Template 4N "0020"
Length
Key Block Template nH "3012031000000000000000000000000000000000"
Delimiter 1A ";"
DES Key Offset 4N "0004"
Check Value Length 2N "00"
Check Value Offset 4N "0000"
Message Trailer nA
RESPONSE MESSAGE
Message Header mA
Response Code 2A GL
Error Code 2A "00" – No error
Initialisation Value 16 H "????????????????"
DES Key Length 4N "0256"
DES Key (PK) nB 3227D3034C27B648B7AE685377175062AF1922247172
E1E7515C1143810954FCD44638AC9698DE90ACEC0E0A
977793CA8C35417E0CC92B6A32ABC660C734AA7DFAF8
299171204F137CF99810912B34449D7A3930E604135D
1264D70EC56878E1C21F42C8EFDE211CCC781D849796
7265859C3BE93ADFF0B5DCA79D53EFE86EA614619AFB
C06AADFF66C5D6BDE3E0A4C0B2084D302B2896654EF


9364046452270C511AE6B03B11B944C8EFCBE1240E59
5E432AE8C9BA7BE135E6A2960F96577F97634ACB1C74
2C6283558BB681A612DFF908248F6C9D4E80476B594C
72AE147F0022CCDFB9B63631B74D199AFB385267C223
CEFFD7CEAE8D1E04A9EA127FDCB58
Signature Length 4N "0256"
Signature nB 195F27EF10CAF38D8198300638B1B47C53DA8CE19631
0AA30C432AEB87F94ACE67E15B0F1E6D88DB5905ECAE
F9A035618BD8C4ACC63736032B6EC25AD7875B1289B0
35A5F9FD7746BDCB69D2154AC599DDA5EE91DBB322C
DD283FB38E8F80E3783C3BE3B907BC64959EC821BD29
E63A8FD490D4B1BED2E2971C8EA873DEC403AB16C1F
2B83AD548E815ACEEA261BAB6EFCFA8CB079176CD71
04A1E97114CB63006E71CB2C05CADB27B8B7931F77D2
0756B8C85076DE3D566952418956AD86266266837E96
68DE1E65863BD95B12F1DF7E9B941CCDDE6556F22DF
2114655E29E890654B111EF9AD88E80677873F573845C
DEA523528AC89997075B8C0068F7A1
Message Trailer nA

Chapter 6 – Local Master Keys (LMKs)

Introduction
LMKs are used to encrypt operational keys used for encryption, MACing, digital signing,
etc. LMKs are secret, internal to the HSM, and do not exist outside of the HSM except as
components or shares held in smartcards. Each HSM can have a unique LMK, or an
organization can install the same LMKs on multiple HSMs within a logical system.
LMKs provide separation between different types of keys to ensure that keys can be used
only for their intended purpose. Thales payment HSMs support two types of LMK, both of
which provide key separation:
 Variant LMKs. These are double- or triple-length Triple-DES keys and provide
key separation by encrypting different types of key with different variants of the
LMK. Double-length Variant LMKs have been in use for many years, and are the
most widely used type of LMK. Triple-length Variant LMKs were introduced for
later versions of the payShield 9000. Chapter 7 – Variant LMK Key Scheme
describes Variant LMKs in more detail.
 Key Block LMKs. These are either triple-length Triple-DES keys, or 256-bit AES
keys, and key separation is provided by parameters in the key block which govern
characteristics such as usage and exportability of the protected key. Key Block
LMKs are newer technology than Variant LMKs and so are still less widely used,
but provide security benefits. Chapter 8 – Key Block LMK Key Scheme describes
Key Block LMKs in more detail.
Multiple LMKs
It is possible to install multiple LMKs within a single payShield 9000. For more
information see Chapter 9.
See Chapter 1 of the payShield 9000 Host Command Reference Manual for information
on how the required LMK can be specified in Host commands.

Key Block & Variant Key Comparison Table

The table below shows the possible values in the key block header fields when creating
the standard HSM keys. (This table uses the same pink/blue shading as is used in the
payShield 9000 Host Command Reference Manual to distinguish between information
relating to key block and variant keys.)
Variant Key Block

Key Name Key
LMK Key Usage Algorithm Mode of Use
Type
BDK-1 009 28-29/0 "B0" "T" "X", ‘N’
BDK-2 609 28-29/6 "41" "T" "X", ‘N’
BDK-3 809 28-29/8 "42" "T" "X", ‘N’
BDK-4 909 28-29/9 "43" "T" "X", ‘N’
CSCK 402 14-15/4 "C0", "11" "D", "T" "C", "G", ‘N’, "V"
CVK 402 14-15/4 "C0", "12", "13" "D", "T" "C", "G", ‘N’, "V"
DEK 00B 32-33/0 "D0", "21" "D", "T", "A" "B", "D", "E", ‘N’
HMAC 10C 34-35/1 "61", "62", "63", "64", "65" "H" "C", "G", ‘N’, "V"
IKEY 302 14-15/3 "B1" "T" "X", ‘N’
KML 200 04-05/2 "E6", "31" "T" ‘N’
MK-AC 109 28-29/1 "E0" "T" ‘N’
MK-CVC3 709 28-29/7 "E6", "32" "T" ‘N’
MK-DAC 409 28-29/4 "E3" "T" ‘N’
MK-DN 509 28-29/5 "E4" "T" ‘N’
MK-SMC 309 28-29/3 "E1" "T" ‘N’
MK-SMI 209 28-29/2 "E2" "T" ‘N’
PVK 002 14-15/0 "V0", "V1", "V2" "D", "T" "C", "G", ‘N’, "V"
RSA Private Key 00C 34-35/0 "03" "R" "B", "D", ‘N’, "S"
RSA Public Key 00D 36-37/0 "02" "R" "B", "E", ‘N’, "S"
TAK 003 16-17/0 "M0", "M1", "M3", "M5", "M6" "D", "T", "A" "C", "G", ‘N’, "V"
TEK 30B 32-33/3 "D0", "23" "D", "T", "A" "B", "D", "E", ‘N’
002 14-15/0
TKR or or "P0", "73" "D", "T" ‘N’
90D 36-37/9
002 14-15/0
TMK or or "K0", "51" "D", "T", "A" "B", "D", "E", ‘N’
80D 36-37/8
002 14-15/0
TPK or or "P0", "71" "D", "T" "B", "D", "E", ‘N’
70D 36-37/7
WWK 006 22-23/0 "01" "D", "T" "C", "G", ‘N’, "V"
ZAK 008 26-27/0 "M0", "M1", "M3", "M5", "M6" "D", "T", "A" "C", "G", ‘N’, "V"
ZEK 00A 30-31/0 "D0", "22" "D", "T", "A" "B", "D", "E", ‘N’
ZMK 000 04-05/0 "K0", "52" "D", "T", "A" "B", "D", "E", ‘N’
ZPK 001 06-07/0 "P0", "72" "D", "T" "B", "D", "E", ‘N’

IKEY is also known as IPEK.

Converting Key Names

The table below shows some of the conversions between Thales and other organizations'
key names.
Organization Key Description Thales Key Description Thales

Key Name
Mastercard Issuer MK Master Key for Authentication Cryptograms MK-AC
Master Key for Secure messaging Integrity MK-SMI
Master Key for Secure Message MK-SMC
Confidentiality
Master Key for Data Authentication Codes MK-DAC
Master Key for Dynamic Numbers MK-DN
Mastercard ICC MK Derived Key for Authentication Cryptograms DK-AC
Derived Key for Secure Messaging Integrity DK-SMI
Derived Key for Secure Messaging DK-SMC
Confidentiality
Derived Key for Dynamic Numbers DK-DN
Visa AWK Zone PIN Key ZPK
(Acquirer Working Key)
Visa C2KA CVKA (1st half of double-length CVK) CVK

(Card Verification Key for
generation of CVV2)
Visa C2KB CVKA (2nd half of double-length CVK) CVK

(Card Verification Key for
generation of CVV2)
Visa CAKA CVKA (1st half of double-length CVK) CVK

(Card Verification Key (for
generation of CAVV)
Visa CAKB CVKA (2nd half of double-length CVK) CVK

(Card Verification Key (for
generation of CAVV)
Visa DMK-AC Master Key for Authentication Cryptograms MK-AC
Visa DMK-MAC Master Key for Secure messaging Integrity MK-SMI
Visa DMK-ENC Master Key for Secure Message MK-SMC

Confidentiality
Visa IWK (Issuer Working Key) Zone PIN Key ZPK

Chapter 7 – Variant LMK Key Scheme

Introduction
A Variant LMK is a set of 20 double- or triple-length TDES keys, with different "pairs"
(and variants of those pairs) being used to encrypt different types of keys. The Double-
length Variant LMK is the original LMK format supported in all versions of Racal/Thales
payment HSM firmware.
Note:
 The term "Variant LMK" refers to the 'variant' method of encrypting keys; a
Variant LMK is not itself a variant of any other key.
Keys encrypted under a Variant LMK have an associated (3-digit) Key Type Code, which
is used to enforce key separation between different types of keys. The different types of
symmetric keys available are included in the table below.
NOTE: Variant LMKs cannot be used to protect AES keys or RSA keys longer than 2048
bits.
The tables below use the same pink shading as in the payShield 9000 Host Command
Reference Manual to indicate information relating to variant keys.
How the Variant scheme works

Each key of a double- or triple-length TDES key set is encrypted separately using the
ECB mode of encryption. For the second key, a variant is applied to the encryption key.
There are five variants to enable the encryption of each key distinctly. This application of
variants enforces the key use as a double- or triple-length key and the key order. This
scheme is available for encryption of keys under the Local Master Key and for import and
export of keys.
Variant Local Master Keys can be either:

 Double-length TDES keys, consisting of a left and right half. Each half consists of
16 hexadecimal characters.
 Triple-length TDES keys, consisting of a left, middle and right part. Each part, as
for double-length keys, consists of 16 hexadecimal characters.
Other key encryption keys, such as ZMKs, can be double- or triple-length TDES keys.
The variant is applied to the right half of double-length encrypting keys, and to the
middle part of triple-length encrypting keys.
The tags for this scheme are as follows:
U – Double-length DES keys.

T – Triple-length DES keys.
The following variants are used for this purpose:
 Double-length key:
Left part – A6
Right part – 5A
 Triple-length key:

Left part – 6A
Middle part – DE
Right part– 2B
Example 1:
Given a double-length encrypting key of: XXXX XXXX XXXX XXXX YYYY YYYY YYYY YYYY, and
a double-length key of: AAAA AAAA AAAA AAAA BBBB BBBB BBBB BBBB:
 The variant A6 is applied to the first two hex characters of Y to encrypt A.

 The variant 5A is applied to the first two hex characters of Y to encrypt B.
Example 2:
Given a double-length encrypting key of: XXXX XXXX XXXX XXXX YYYY YYYY YYYY YYYY, and
a triple-length key of: AAAA AAAA AAAA AAAA BBBB BBBB BBBB BBBB CCCC CCCC CCCC CCCC:
 The variant 6A is applied to the first two hex characters of Y to encrypt A.

 The variant DE is applied to the first two hex characters of Y to encrypt B
 The variant 2B is applied to the first two hex characters of Y to encrypt C
Variants are applied by "Exclusive ORing" (XOR) the first two characters of Y with the
Variant.
Local Master Key (LMK) Variants

To protect key usage, variants of the Local Master Key are used for encryption of defined
keys or key components. The Key Type Table (see later in this chapter) defines the LMK
pairs and variants that are used to protect various types of keys. For example, an MK-
SMI is encrypted using LMK 28-29 variant 2.
In order to create an LMK variant, a non-secret fixed value (known as a variant) is

XOR'ed with the first byte of the LMK. The variants used by the HSM are:
 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
The example below demonstrates how a Local Master Key variant is calculated for key
type MK-SMI:
1. Refer to the Key Type Table to select the appropriate LMK pair for the type of key
that you wish to encrypt. For example, for key type MK-SMI, LMK 28-29 is used:
Test LMK 28-29: 1A1A 1A1A 1A1A 1A1A 1C1C 1C1C 1C1C 1C1C
2. Identify from the Key Type Table which Variant of the LMK is required. For key
type MK-SMI variant 2 is used:
Variant 2: 5A
3. Exclusive-OR the selected variant with the first byte of the LMK pair :
1A XOR 5A = 40

Replace the left-most byte of the LMK pair with the result of Step 3 and use the
resulting key to encrypt the MK-SMI:
LMK Variant 2 = 401A 1A1A 1A1A 1A1A 1C1C 1C1C 1C1C 1C1C
When the Variants are applied to the standard Double-length Variant Test LMK or Triple-
length Variant Test LMK (see later in this chapter), the left-most bytes of the sets are as
follows:
Double-length Variant LMK:

LMK First byte of LMK
Pair 1 2 3 4 5 6 7 8 9
00-01 A7 5B 6B DF 2A 51 75 9D FB
02-03 86 7A 4A FE 0B 70 54 BC DA
04-05 E6 1A 2A 9E 6B 10 34 DC BA
06-07 C7 3B 0B BF 4A 31 15 FD 9B
08-09 26 DA EA 5E AB D0 F4 1C 7A
10-11 07 FB CB 7F 8A F1 D5 3D 5B
12-13 67 9B AB 1F EA 91 B5 5D 3B
14-15 46 BA 8A 3E CB B0 94 7C 1A
16-17 BA 46 76 C2 37 4C 68 80 E6
18-19 A7 5B 6B DF 2A 51 75 9D FB
20-21 A4 58 68 DC 29 52 76 9E F8
22-23 A1 5D 6D D9 2C 57 73 9B FD
24-25 B5 49 79 CD 38 43 67 8F E9
26-27 B0 4C 7C C8 3D 46 62 8A EC
28-29 BC 40 70 C4 31 4A 6E 86 E0
30-31 85 79 49 FD 08 73 57 BF D9
32-33 80 7C 4C F8 0D 76 52 BA DC
34-35 8C 70 40 F4 01 7A 5E B6 D0
36-37 89 75 45 F1 04 7F 5B B3 D5
38-39 A7 5B 6B DF 2A 51 75 9D FB

Triple-length Variant LMK:

LMK First byte of LMK
Pair 1 2 3 4 5 6 7 8 9
00-01 75 89 B9 0D F8 83 A7 4F 29
02-03 2C D0 E0 54 A1 DA FE 16 70
04-05 9B 67 57 E3 16 6D 49 A1 C7
06-07 A7 5B 6B DF 2A 51 75 9D FB
08-09 13 EF DF 6B 9E E5 C1 29 4F
10-11 CD 31 01 B5 40 3B 1F F7 91
12-13 F7 0B 3B 8F 7A 01 25 CD AB
14-15 2F D3 E3 57 A2 D9 FD 15 73
16-17 15 E9 D9 6D 98 E3 C7 2F 49
18-19 6E 92 A2 16 E3 98 BC 54 32
20-21 29 D5 E5 51 A4 DF FB 13 75
22-23 6B 97 A7 13 E6 9D B9 51 37
24-25 BC 40 70 C4 31 4A 6E 86 E0
26-27 C1 3D 0D B9 4C 37 13 FB 9D
28-29 68 94 A4 10 E5 9E BA 52 34
30-31 58 A4 94 20 D5 AE 8A 62 04
32-33 32 CE FE 4A BF C4 E0 08 6E
34-35 26 DA EA 5E AB D0 F4 1C 7A
36-37 1A E6 D6 62 97 EC C8 20 46
38-39 CE 32 02 B6 43 38 1C F4 92
Note: the term "LMK Pair" and the associated numbering scheme is retained for historical
reasons, even though for triple-length LMKs each key is actually a triplet.
Local Master Key Triple DES Variant scheme

The Local Master Key Variants described in the previous section are used only to protect
key usage. The HSM can also use the variant technique to provide additional protection
to Triple-DES keys:
 To ensure that the Left and Right parts of a double-length Triple-DES key can only
be used as such.
 To ensure that the Left, Middle and Right parts of a triple-length Triple-DES key
can only be used as such.
The following variants are used for this purpose:
 Double-length key:
Left part – A6
Right part – 5A
 Triple-length key:
Left part – 6A
Middle part – DE
Right part– 2B
Key Scheme tags are used to identify the technique used to encrypt keys.

 'U' is used to identify double-length Triple DES keys that are encrypted using the
Triple-DES variant Scheme
 'T' is used to identify triple-length Triple DES keys that are encrypted using the
Triple-DES variant scheme.
The example below demonstrates how a double-length MK-SMI is encrypted using this
method. The test key to be encrypted is:
Test MK-SMI = F1F1 F1F1 F1F1 F1F1 C1C1 C1C1 C1C1 C1C1
 Refer to the Key Type Table to select the appropriate LMK pair and variant for the
type of key that you wish to encrypt. For example, for key type MK-SMI, LMK 28-
29 Variant 2 is used (this is the LMK variant that was calculated in the example in
section 15):
LMK 28-29 Variant 2 = 401A 1A1A 1A1A 1A1A 1C1C 1C1C 1C1C 1C1C
 Select the appropriate variants to be applied to the encrypting key. In this case
the MK-SMI is a double-length Triple-DES key, so the following variants should be
used:
To encrypt the left part of the MK-SMI – A6
To encrypt the right part of the MK-SMI – 5A
 To create the key with which to encrypt the left part of MK-SMI, Exclusive-OR A6
with the first byte of the right part of the LMK pair:
1C XOR A6 = BA
Key with which to encrypt left part of MK-SMI
= 401A 1A1A 1A1A 1A1A BA1C 1C1C 1C1C 1C1C
 Use the key calculated in step 3 to encrypt the left part of the MK-SMI:
= 401A 1A1A 1A1A 1A1A BA1C 1C1C 1C1C 1C1C
Left part of MK-SMI = F1F1 F1F1 F1F1 F1F1
Result of Triple-DES encryption is: 5178 C9D3 D105 2B15
 To create the key with which to encrypt the right part of MK-SMI, Exclusive-OR
5A with the first byte of the right part of the LMK pair
1C XOR 5A = 46

= 401A 1A1A 1A1A 1A1A 461C 1C1C 1C1C 1C1C
 Use the key calculated in step 5 to encrypt the right part of the MK-SMI:
Key with which to encrypt right part of MK-SMI
= 401A 1A1A 1A1A 1A1A 461C 1C1C 1C1C 1C1C
Right part of MK-SMI = C1C1 C1C1 C1C1 C1C1
Result of Triple-DES encryption is:
BF6A EC45 8B4A 4564

 The encrypted MK-SMI is the result of step 4 concatenated with the result of step
6:
5178 C9D3 D105 2B15 BF6A EC45 8B4A 4564

The example above can be demonstrated on an HSM by using the FK console command,
with inputs as follows:
Offline-AUTH> FK <Return>
Enter key length [1,2,3]: 2 <Return>
Enter key type: 209 <Return>
Enter key scheme: U <Return>
Enter component type [X,H,T,E,S]: X <Return>
Enter number of components [1-9]: 2 <Return>
Enter component 1: 50505050505050505050505050505050 <Return>
Enter component 2: A1A1A1A1A1A1A1A19090909090909090 <Return>
Encrypted key: U 5178 C9D3 D105 2B15 BF6A EC45 8B4A 4564
Key check value: 8357D9
When the Variants are applied to the standard test LMK set (see next section), the first
bytes of the second key are as follows:
Double-length Variant LMK:
First byte of second key of the LMK

Double-length Key Triple-length Key
LMK Pair
Scheme Tag "U" Scheme Tag "T"
1 of 2 2 of 2 1 of 3 2 of 3 3 of 3
04-05 F7 0B 3B 8F 7A
06–07 D6 2A 1A AE 5B
14–15 57 AB 9B 2F DA
16–17 A7 5B 6B DF 2A
18-19 A7 5B 6B DF 2A
20–21 A2 5E 6E DA 2F
22-23 B6 4A 7A CE 3B
24–25 B3 4F 7F CB 3E
26–27 BF 43 73 C7 32
28–29 BA 46 76 C2 37
30-31 83 7F 4F FB 0E
32–33 8F 73 43 F7 02
34-35 8A 76 46 F2 07
36–37 97 6B 5B EF 1A
38-39 A7 5B 6B DF 2A

Triple-length Variant LMK:
First byte of second key of the LMK

Double-length Key Triple-length Key
LMK Pair
Scheme Tag "U" Scheme Tag "T"
1 of 2 2 of 2 1 of 3 2 of 3 3 of 3
04-05 CE 32 02 B6 43
06–07 68 94 A4 10 E5
14–15 BC 40 70 C4 31
16–17 94 68 58 EC 19
18-19 DA 26 16 A2 57
20–21 B6 4A 7A CE 3B
22-23 07 FB CB 7F 8A
24–25 0E F2 C2 76 83
26–27 F8 04 34 80 75
28–29 A8 54 64 D0 25
30-31 79 85 B5 01 F4
32–33 6B 97 A7 13 E6
34-35 29 D5 E5 51 A4
36–37 7A 86 B6 02 F7
38-39 43 BF 8F 3B CE
When the HSM encrypts a key component under a variant of the LMK, an additional
variant (0xFF) is applied to the first byte of the LMK. This is to prevent a single encrypted
component from masquerading as an encrypted key.
Test Variant LMK

The values of the LMK pairs contained in the "Test LMK" Smartcard are shown in the
table below. The two Passwords are also held in this device, and their values are also
shown below.
The PIN for each Test LMK Smartcard is: 1 2 3 4

Double-length Variant Test LMK:

LMK Key
00-01 01 01 01 01 01 01 01 01 79 02 CD 1F D3 6E F8 BA
02-03 20 20 20 20 20 20 20 20 31 31 31 31 31 31 31 31
04-05 40 40 40 40 40 40 40 40 51 51 51 51 51 51 51 51
06-07 61 61 61 61 61 61 61 61 70 70 70 70 70 70 70 70
08-09 80 80 80 80 80 80 80 80 91 91 91 91 91 91 91 91
10-11 A1 A1 A1 A1 A1 A1 A1 A1 B0 B0 B0 B0 B0 B0 B0 B0
12-13 C1 C1 01 01 01 01 01 01 D0 D0 01 01 01 01 01 01
14-15 E0 E0 01 01 01 01 01 01 F1 F1 01 01 01 01 01 01
16-17 1C 58 7F 1C 13 92 4F EF 01 01 01 01 01 01 01 01
18-19 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
20-21 02 02 02 02 02 02 02 02 04 04 04 04 04 04 04 04
22-23 07 07 07 07 07 07 07 07 10 10 10 10 10 10 10 10
24-25 13 13 13 13 13 13 13 13 15 15 15 15 15 15 15 15
26-27 16 16 16 16 16 16 16 16 19 19 19 19 19 19 19 19
28-29 1A 1A 1A 1A 1A 1A 1A 1A 1C 1C 1C 1C 1C 1C 1C 1C
30-31 23 23 23 23 23 23 23 23 25 25 25 25 25 25 25 25
32-33 26 26 26 26 26 26 26 26 29 29 29 29 29 29 29 29
34-35 2A 2A 2A 2A 2A 2A 2A 2A 2C 2C 2C 2C 2C 2C 2C 2C
36-37 2F 2F 2F 2F 2F 2F 2F 2F 31 31 31 31 31 31 31 31
38-39 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
Password 1 01 01 01 01 01 01 01 01
Password 2 NOWISTHETIMEFORA
The check value for the Double-length Variant Test LMK is: 268604

Triple-length Variant Test LMK:

LMK Key
00-01 D3 CB 07 68 76 A2 07 04 01 01 01 01 01 01 01 01 32 B9 7F 73 34 AE B6 5E
02-03 8A CD 34 CE F4 91 79 9D F1 19 94 8F E5 E6 B6 9B 61 97 8A 40 D0 83 04 32
04-05 3D 80 AD C8 6D 83 97 2F 68 EC 6B 7A 23 25 DA 98 A2 23 6D 1A 89 9B 07 32
06-07 01 34 76 B6 F4 08 BA 6B CE 45 4C 2C 6D A8 B3 5E BA C2 4A E6 1F 43 70 49
08-09 B5 7A E3 58 A2 1A DA 89 19 C2 5E 9E F4 8A B3 01 61 C1 23 1A 8F C4 2A 38
10-11 6B F7 10 C1 DF 13 7C EC 7F B3 7F E9 38 F2 A7 3D BA F2 C4 B5 9B FD 1C 54
12-13 51 DC F1 58 D6 CD 0E CE A2 E9 BC 0B 1F 85 EF 8C EA C8 10 A8 1A C8 A7 EA
14-15 89 B5 CB BA 43 80 C8 91 1A 6E 1A D6 61 1C 1C DA 94 68 E3 CB 1A 26 9E FB
16-17 B3 FB D3 4A 5E 51 EC 52 32 AD FE BA 32 0D 68 7C 7A 68 31 EF 25 58 C4 A7
18-19 C8 B9 49 D6 2C 57 9E A7 7C CD CE A1 D0 3D 9E 6B F4 A1 E6 3B E5 85 8A 83
20-21 8F 32 B9 10 E9 D5 6E DF 10 02 FB B5 57 AB 8F 73 0D 34 4A B3 89 38 F2 FD
22-23 CD 34 89 FB 38 54 97 61 A1 31 1F CB 92 AE 54 B3 16 76 13 16 76 A8 76 DF
24-25 1A CB 8C C1 26 1F FE EA A8 E9 EA 58 80 1A A7 85 46 20 91 85 AB 3D 89 37
26-27 67 AB EC 46 16 23 D3 70 5E 85 F8 2F 15 26 62 68 02 15 D3 2F 8A CE D5 91
28-29 CE 23 B0 98 B0 34 B6 CD 0E 08 CD FE 3D 08 B5 0D 4F 80 D3 83 9D 73 85 BF
30-31 FE 3E 64 3E 92 C1 23 D3 DF 89 B6 83 43 A2 61 6D AB 61 10 C4 A7 9E EA AB
32-33 94 DF 13 58 3B B5 E3 1F CD B6 B5 32 AE 6D A8 DC 0D A8 6B EF 34 C7 51 8A
34-35 80 76 7F FD 76 F1 CE 57 8F 1F EC 15 AE 3E 7F 10 16 38 80 D6 29 58 08 CD
36-37 BC FB D6 89 FE 86 15 E0 DC AD 8F 8F 49 F8 0D 61 3D EA 73 F2 EC C2 F2 7C
38-39 68 B6 3D 1A F8 73 D5 92 E5 1C 1F D5 80 C1 D3 A1 2C 85 32 2A 1F 07 D9 08
Password 1 D3 CB 07 68 76 A2 07 04
Password 2 01 01 01 01 01 01 01 01
The check value for the Triple-length Variant Test LMK is: 665641
Variant Key Type Codes

Each key has a Key Type as defined in the following table. The relationship between Key
Type and LMK Variant is shown in the Key Type Table in the next section.
Key Key
Type Type
Key Type Code 1 Code 2 Description
ZMK 000 000 Zone Master Key (also known as ZCMK)
ZMK (Comp) 100 100 Zone Master Key Component (legacy commands only)
KML 200 200 Master Load Key (Visa Cash)
KEKr 300 300 (AS 2805) Key Encryption Key of Recipient
KEKs 400 400 (AS 2805) Key Encryption Key of Sender
ZPK 001 001 Zone PIN Key
PVK 002 002 PIN Verification Key
PVVK 002 002 (OBKM) P V V Key
TPK 002 70D Terminal PIN Key
PEK 002 70D (AS 2805) PIN Encipherment Key

Key Key
Type Type
PEK 002 70D (LIC031) PIN Encryption Key
TMK 002 80D Terminal Master Key
KT 002 80D (AS 2805) Transaction Key
TK 002 80D (AS 2805) Terminal Key
KI 002 80D (AS 2805) Initial Transport Key
KCA 002 80D (AS 2805) Sponsor Cross Acquirer Key
KMA 002 80D (AS 2805) Acquirer Master Key Encrypting Key
TKR 002 90D Terminal Key Register
TMK1 102 102 (AS 2805) Terminal Master Key
TMK2 202 202 (AS 2805) Terminal Master Key

IKEY 302 302 Initial Key (DUKPT)
CK-ENK 30D 30D (Issuing) Card Key for Cryptograms
CVK 402 402 Card Verification Key
CSCK 402 402 Card Security Code Key
CK-MAC 40D 40D (Issuing) Card Key for Authentication
CK-DEK 50D 50D (Issuing) Card Key for Authentication
KIA 602 602 (AS 2805) Acquirer Initialization Key
TAK 003 003 Terminal Authentication Key
TAKr 103 103 (AS 2805) Terminal Authentication Key of Recipient
TAKs 103 103 (AS 2805) Terminal Authentication Key of Sender
KML 105 105 (OBKM) Master Load Key
KMLISS 105 105 (OBKM) Master Load Key for Issuer
KMX 205 205 (OBKM) Master Currency Exchange Key
KMXISS 205 205 (OBKM) Master Currency Exchange Key for Issuer
KMP 305 305 (OBKM) Master Purchase Key
KMPISS 305 305 (OBKM) Master Purchase Key for Issuer
KIS.5 405 405 (OBKM) S5 Issuer Key
KM3L 505 505 (OBKM) Master Key for Load & Unload Verification
KM3LISS 505 505 (OBKM) Master Key for Load & Unload Verification for Issuer
KM3X 605 605 (OBKM) Master Key for Currency Exchange Verification
(OBKM) Master Key for Currency Exchange Verification for
KM3XISS 605 605
Issuer
KMACS4 705 705 (OBKM)
KMACS5 805 805 (OBKM)
KMACACQ 905 905 (OBKM)
KMACACX 905 905 (OBKM)
WWK 006 006 Watchword Key
KMACUPD 106 106 (OBKM)
KMACMA 206 206 (OBKM)
KMACCI 306 306 (OBKM)
KMACISS 306 306 (OBKM)
KMSCISS 406 406 (OBKM) Secure Messaging Master Key
BKEM 506 506 (OBKM) Transport key for key encryption
BKAM 606 606 (OBKM) Transport key for message authentication

Key Key
Type Type
KEK 107 107 (Issuing) Key Encryption Key
KMC 207 207 (Issuing) Master Personalization Key
(Issuing) Session Key for cryptograms and encrypting card
SK-ENC 307 307
messages
SK-MAC 407 407 (Issuing) Session Key for authenticating card messages
SK-DEK 507 507 (Issuing) Session Key for encrypting secret card data
KD-PERSO 507 507 (Issuing) KD Personalization Key
ZKA MK 607 607 Master key for GBIC/ZKA key derivation
MK-KE 807 807 (Issuing) Master KTU Encipherment key
MK-AS 907 907 (Issuing) Master Application Signature (MAC) key
ZAK 008 008 Zone Authentication Key
ZAKs 108 108 (AS 2805) Zone Authentication Key of Sender
ZAKr 208 208 (AS 2805) Zone Authentication Key of Recipient
BDK-1 009 009 Base Derivation Key (type 1)
MK-AC 109 109 Master Key for Application Cryptograms
MK-SMI 209 209 Master Key for Secure Messaging (for Integrity)
MK-SMC 309 309 Master Key for Secure Messaging (for Confidentiality)
MK-DAC 409 409 Master Key for Data Authentication Codes
MK-DN 509 509 Master Key for Dynamic Numbers
MK-CVC3 709 709 Master Key for CVC3 (Contactless)
ZEK 00A 00A Zone Encryption Key
ZEKs 10A 10A (AS 2805) Zone Encryption Key of Sender
ZEKr 20A 20A (AS 2805) Zone Encryption Key of Recipient
DEK 00B 00B Data Encryption Key
TEK 00B 00B (AS 2805) Terminal Encryption Key
TEKs 10B 10B (AS 2805) Terminal Encryption Key of Sender
TEKr 10B 10B (AS 2805) Terminal Encryption Key of recipient
TEK 30B 30B Terminal Encryption Key
RSA-SK 00C 00C RSA Private Key
HMAC 10C 10C HMAC key
RSA-PK 00D 00D RSA Public Key
TPK 002 70D Terminal PIN Key
PEK 002 70D (AS 2805) PIN Encipherment Key
TMK 002 80D Terminal Master Key
KT 002 80D (AS 2805) Transaction Key
TK 002 80D (AS 2805) Terminal Key
KI 002 80D (AS 2805) Initial Transport Key
KCA 002 80D (AS 2805) Sponsor Cross Acquirer Key
KMA 002 80D (AS 2805) Acquirer Master Key Encrypting Key
TKR 002 90D Terminal Key Register


Notes:
1 This Key Type Code column applies when the security setting "Enforce key
type 002 separation for PCI HSM compliance" has a value of ‘N’ – i.e. key
separation is not PCI HSM complaint.
2 This Key Type Code column applies when the security setting "Enforce key
type 002 separation for PCI HSM compliance" has a value of ‘Y’ – i.e. key
separation is PCI HSM complaint.
(OBKM) For use with Optional License HSM9-LIC004
(AS 2805) For use with Optional License HSM9-LIC003
(Issuing) For use with Optional Licenses HSM9-LIC016, HSM9-LIC018, HSM9-LIC023.
(LIC031) For use with Optional License HSM9-LIC031.
For a list of permissions associated with these key types, see the Key Type Table below.
Key Type Table

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, for sending to another party. Import is the reverse, for
receiving keys and translating to local storage. The Key Type Table (see below) controls
'permitted actions' for the console and host commands used to generate, import and
export keys.
Errors are reported when an action breaks the rules imposed by the table. For example:
29 : Key function not permitted
The Key Type table is automatically modified dependent on the value of the Security
Setting "Enforce key type 002 separation for PCI HSM compliance": a setting of 'N'
indicates non-compliance with the requirements of PCI HSM, and a setting of 'Y' indicates
compliance with the key separation requirements of PCI HSM.

Non PCI-HSM Compliant (for backwards compatibility)

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 KML KEKr1 KEKs1
04 – 05 00 (Comp)
A U A U U A U U A U U A U
ZPK PEK4a Auth
06 – 07 01 ZKA MK Para1
U A U
PVK
TPK
KEYVAL
TMK
TKR
PEK4b
KT1
CVK
DbTAB5 TMK11 TMK21 IKEY KIA1 PPASN1
14 – 15 02 CSCK
KCA1
KMA1
KI1
PEK1
TK1
PVVK2
ZKA MK
U A U U A U U A U U A U U A U U A U
TAK TAKs1 TAKr1
16 – 17 03
U A U U A U U A U
DTAB5 IPB
18 – 19 04
KML2 KMX2 KMP2 KM3L2 KM3X2 KMACACQ2

KIS,5'2 KMACS42 KMACS52
20 – 21 05 KMLISS2 KMXISS2 KMPISS2 KM3LISS2 KM3XISS2 KMACACK2
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
KMACCI2
WWK KMACUPD2 KMACMA2 KMSCISS2 BKEM2 BKAM2
22 – 23 06 KMACISS2
U A U U A U U A U U A U U A U U A U U A U
SK-DEK3
KEK3 KMC3 SK-ENC3 SK-MAC3 KD- ZKA MK MK-KE3 MK-AS3
24 – 25 07
PERSO3
U A A U A A U U U A U U A U
1 1
ZAK ZAKs ZAKr
26 – 27 08
U A U U A U U A U
MK-
CVC3
BDK-1 MK-AC MK-SMI MK-SMC MK-DAC MK-DN BDK-2 BDK-3 BDK-4
28 – 29 09 MK-
DCVV3
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
ZEK ZEKs1 ZEKr1
30 – 31 0A
U A A/U6 U U
DEK TEK1 TEKs1 TEKr1 TEK

32 – 33 0B
U U U U A
RSA-SK HMAC
34 – 35 0C
A U A U
RSA-PK CK-ENC3 CK-MAC3 CK-DEK3 Note 7 Note 7 Note 7
36 – 37 0D
A A U A U U A U U A U U A U U A U U A U
Reserved Reserved Reserved Reserved Reserved Reserved Reserved Reserved Reserved Reserved
38 – 39 0E
Key Type Table 1 - "Enforce key type 002 separation for PCI HSM compliance" set to ‘N’
(i.e. key separation is not PCI HSM compliant)


PCI Compliant
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 KML KEKr1 KEKs1
04 – 05 00 (Comp)
A U A U U A U U A U U A U
ZPK PEK4a Auth
06 – 07 01 ZKA MK Para1
U A U
PVK
CVK
PVVK2 TMK11 TMK21 IKEY KIA1 PPASN1
14 – 15 02 CSCK
ZKA MK
U A U U A U U A U U A U U A U U A U
1 1
TAK TAKs TAKr
16 – 17 03
U A U U A U U A U
DTAB IPB
18 – 19 04
KML2 KMX2 KMP2 KIS,5'2 KM3L2 KM3X2 KMACS42 KMACS52 KMACACQ2

20 – 21 05 KMLISS2 KMXISS2 KMPISS2 KM3LISS2 KM3XISS2 KMACACK2
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
KMACUPD2 KMACMA2 KMACCI2 KMSCISS2 BKEM2 BKAM2
WWK
22 – 23 06 KMACISS2
U A U U A U U A U U A U U A U U A U U A U
SK-DEK3
KEK3 KMC3 SK-ENC3 SK-MAC3 KD- ZKA MK MK-KE3 MK-AS3
24 – 25 07
PERSO3
U A A U A A U U U A U U A U
1 1
ZAK ZAKs ZAKr
26 – 27 08
U A U U A U U A U
MK-
CVC3
BDK-1 MK-AC MK-SMI MK-SMC MK-DAC MK-DN BDK-2 BDK-3 BDK-4
28 – 29 09 MK-
DCVV3
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
ZEK ZEKs1 ZEKr1
30 – 31 0A
U A A/U6 U U
1 1
DEK TEK TEKs TEKr1 TEK
32 – 33 0B
U U U U A
RSA-SK HMAC
34 – 35 0C
A U A U
TPK TMK KT1
3 3 3 KEYVAL KCA1
RSA-PK CK-ENC CK-MAC CK-DEK DbTAB 5
TKR
36 – 37 0D PEK1 KMA1 KI1
PEK4b TK1
A A U A U U A U U A U U A U U A U U A U
Reserved Reserved Reserved Reserved Reserved Reserved Reserved Reserved Reserved Reserved
38 – 39 0E
Key Type Table 2 - "Enforce key type 002 separation for PCI HSM compliance" set to ‘Y’
(i.e. key separation is PCI HSM compliant)

Notes
1. For optional AS2805 License (HSM9-LIC003)
2. For optional Europay Security Platform (OBKM) License (HSM9-LIC004)
3. For optional EMV-based Card data Preparation License (HSM9-LIC016), General
Purpose Card Personalization License (HSM9-LIC018), MULTOS Card Data
Preparation License (HSM9-LIC023)
4. For use with Optional License HSM9-LIC031
a. Where Source PEK Type = 0

b. Where Source PEK Type = 1

5. DTAB = Decimalization Table; DbTAB = Diebold Table
6. Authorization requirements for Import are dependent on the security setting
"Enable ZEK encryption of ASCII data or Binary data or None".
7. Keys of this key type can be generated/imported/exported, but may only be used
for other operations when the security setting "Enforce key type 002 separation
for PCI HSM compliance" is set to ‘Y’. This allows users to pre-generate their keys
before migrating to a PCI-compliant environment.
8. The term "LMK pair" and the associated numbering scheme is retained for
historical reasons, even though for triple-length LMKs each key is actually a
triplet.
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.
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.

Chapter 8 – Key Block LMK Key Scheme

Introduction
A Key Block LMK is a more recent type of local master key, and is used to encrypt keys in
a key block format. It is not compatible with a Variant LMK, and it can only be used to
encrypt keys in key block form.
When using a Key Block LMK, working keys are encrypted as a Thales key Block.
Two types of Thales Key Block LMKs are supported in the payShield 9000:
 DES Key Block LMK – based on a triple-length 3-DES key. This key provides a
security strength of 112-bits, and can be used to protect subordinate DES, TDES,
RSA (up to 2048 bits), and HMAC keys.
 AES Key Block LMK – based on a 256-bit AES key. This key provides a security
strength of 256-bits, and can be used to protect subordinate AES, DES, TDES,
RSA & HMAC keys.
Notes:
 The term "Key Block LMK" refers to the 'key block' method of encrypting keys; a
Key Block LMK is not itself stored in key block form.
 AES key block LMKs must be used to protect AES keys and RSA keys longer than
2048 bits.
 The tables in this chapter use the same blue shading as in the payShield 9000
Host Reference Manual to indicate information relating to keys encrypted using
key blocks LMKs.
Relationship between Thales Key Blocks and TR-31 Key

Blocks
Thales Key Blocks are similar to the Key Blocks as defined by the ANSI X9 committee in
Technical Report 31 (TR-31), which are offered as a way of meeting the requirements of
ANSI X9.24 when exporting keys between products from different vendors. However
there are differences between Thales Key Blocks and TR-31 Key Blocks and the ways in
which they are used.
The main difference between the Thales and TR-31 Key Blocks is that the TR-31 Key
Block is less flexible in terms of Header values and supports only a small number of types
of Optional Header blocks.
The TR-31 Key Block allows key exchange between HSMs from multiple vendors which
have implemented the TR-31 specification
The Thales Key Block is a superset of the TR-31 Key Block, and can also be used for the
secure exchange of keys between HSMs. However, because the Thales Key Block
includes proprietary extensions it can be used to transfer keys only between Thales
payment HSMs (i.e. the payShield 9000 and HSM 8000).
The Thales and TR-31 Key Blocks can be supported and utilized independently of one
another. The combination of Thales and TR-31 Key Blocks defines a "trusted" HSM
environment, in which key manipulation is practically infeasible.
This chapter discusses Thales Key Blocks: further information on TR-31 key blocks can be
found in Chapter 11.

Support for Thales Key Blocks

Not all console commands and host commands can be used with Key Block LMKs. Most
commands that do not support the use of a Key Block LMK have a newer, alternative
command that should be used in their place, or relate to functionality in optional licenses.
You should check for Key Block support in the descriptions of all commands you intend to
use in the appropriate documentation, i.e.:
 payShield 9000 Console Reference Manual
 payShield 9000 Host Command Reference Manual
 the appropriate Host Command Reference Manual Addendum (for some host
commands requiring optional licenses).
Key Block Format

The Thales Key Block is denoted by key scheme "S" and has the following format:
Key Scheme Key Block Optional Encrypted

Authenticator
Tag ("S") Header Header Key Data (8 or 16 ASCII
(1 byte) (16 ASCII (ASCII characters, (variable length, characters)
characters) variable length) ASCII encoded)
a 16-byte (clear) Key Block Header, which defines the key usage (e.g. Visa PVV) and mode of use (e.g.
verification only), the algorithm with which the key is used (e.g. AES 256-bit) and the limitations on the
exportability of the key (e.g. no export permitted); the Header also identifies the LMK used to encrypt
the key in the Key Block;
a (clear) Optional Header block, which can be used (for example) to define the period of validity of the
key contained in the Key Block;
the Encrypted Key Data, which includes the actual key itself, encrypted under the "encryption variant"
of the identified LMK;
a Key Block Authenticator, calculated using the "authentication variant" of the identified LMK; the use
of the Authenticator prevents unauthorized modification to the Key Block.
The entire key block will be ASCII encoded.
The next 4 sections describe Key Block Headers, Optional Headers, Encrypted Key Data,
and Authenticators.

Key Block Header

The Thales Key Block Header is 16 (ASCII) bytes in length and has the following format:
Byte(s) Field Comments

value = "0" (X'30) for 3-DES Key Block LMK
0 Version ID
value = "1" (X'31) for AES Key Block LMK
1-4 Key Block Length total length of key block
5-6 Key Usage e.g. key encryption, data encryption
7 Algorithm e.g. DES, 3-DES, AES
8 Mode of Use e.g. encrypt only
e.g. version of key in the key block or used to indicate
9-10 Key Version Number
that the key is a key component
11 Exportability e.g. exportable under a trusted key
Number of optional
12-13 number of Optional Header Blocks
blocks
LMK identifier (to support multiple LMKs); numeric
14-15 LMK ID
values "00" - "19" (X'3030 - X'3139)
Key Block Length (Bytes 1-4)

Bytes 1-4 of the Header contain the length of the entire key block, namely Header,
Optional Header Blocks, encrypted Key Data and the Authenticator. The length of the
key block is calculated after encoding and is represented as 4 numeric (ASCII) digits.
For example, if the total key block length is 112 characters (bytes) then the value in byte
1 will be "0", the value in bytes 2 and 3 will be "1" and the value in byte 4 will be "2"
(i.e. X'30313132).
Key Usage (Bytes 5-6)

Bytes 5-6 of the Header define the primary usage of the key contained in the key block.
The following table defines the usage code. The table also indicates whether the usages
applies to TR-31 Key Blocks:
 A blank entry means the usage is not appropriate to TR-31.
 An entry of ‘Y’ means that the usage is appropriate to TR-31.
 An entry of the form ("XX") means that the usage is not appropriate to TR-31 Key
Blocks, but that when exporting from Thales Key Block format to TR-31 format
the usage code is converted to the code in brackets.
TR-31
Value Hex Algorithm Description
KB
01 X'3031 DES/3DES WatchWord Key (WWK)
02 X'3032 RSA RSA Public Key
03 X'3033 RSA RSA Private Key
B0 X'4230 Y 3DES Base Derivation Key (BDK-1)
41 X'3431 ("B0") 3DES Base Derivation Key (BDK-2)
B1 X'4231 Y 3DES DUKPT Initial Key (IKEY)
C0 X'4330 Y DES/3DES Card Verification Key

TR-31
KB
11 X'3131 ("C0") DES/3DES Card Verification Key (American

Express CSC)
12 X'3132 ("C0") DES/3DES Card Verification Key (MasterCard

CVC)
13 X'3133 ("C0") DES/3DES Card Verification Key (Visa CVV)
D0 X'4430 Y AES/DES/3DES Data Encryption Key (Generic)
21 X'3231 ("D0") AES/DES/3DES Data Encryption Key (DEK)
22 X'3232 ("D0") AES/DES/3DES Data Encryption Key (ZEK)
23 X'3233 ("D0") AES/DES/3DES Data Encryption Key (TEK)
E0 X'4530 Y DES/3DES EMV/Chip card Master Key: Application

Cryptogram (MKAC)
E1 X'4531 Y DES/3DES EMV/Chip card Master Key: Secure

Messaging for Confidentiality (MKSMC)
E2 X'4532 Y DES/3DES EMV/Chip card Master Key: Secure

Messaging for Integrity (MKSMI)
E3 X'4533 Y DES/3DES EMV/Chip card Master Key: Data

Authentication Code (MKDAC)
E4 X'4534 Y DES/3DES EMV/Chip card Master Key: Dynamic

Numbers (MKDN)
E5 X'4535 Y DES/3DES EMV/Chip card Master Key: Card

Personalization
E6 X'4536 Y DES/3DES EMV/chip card Master Key: Other
31 X'3331 ("E6") DES/3DES Visa Cash Master Load Key (KML)
32 X'3332 ("E6") DES/3DES Dynamic CVV Master Key (MK-CVC3)
I0 X'4930 Y - Initialization Value
K0 X4B30 Y AES/DES/3DES Key Encryption / Wrapping Key

(Generic)
51 X'3531 ("K0") AES/DES/3DES Terminal Key Encryption (TMK)
52 X'3532 ("K0") AES/DES/3DES Zone Key Encryption (ZMK)
M0 X'4D30 Y 3DES ISO 16609 MAC algorithm 1 (using 3-

DES)
M1 X'4D31 Y DES ISO 9797-1 MAC algorithm 1
M2 X'4D33 Y DES/3DES ISO 9797-1 MAC algorithm 2
M3 X'4D33 Y 3DES ISO 9797-1 MAC algorithm 3
M4 X'4D34 Y DES/3DES ISO 9797-1 MAC algorithm 4
M5 X'4D35 AES AES CBC MAC
M6 X'4D36 ("M5") AES AES CMAC
61 X'3631 HMAC HMAC key (using SHA-1)

TR-31
KB
P0 X'5030 Y DES/3DES PIN Encryption Key (Generic)
71 X'3731 ("P0") DES/3DES Terminal PIN Encryption Key (TPK)
72 X'3732 ("P0") DES/3DES Zone PIN Encryption Key (ZPK)
73 X'3733 ("P0") DES/3DES Transaction Key Scheme Terminal Key

Register (TKR)
V0 X'5630 Y DES/3DES PIN Verification Key (Generic)
V1 X'5631 Y DES/3DES PIN Verification Key (IBM 3624

algorithm)
V2 X'5632 Y DES/3DES PIN Verification Key (Visa PVV

algorithm)

Algorithm (Byte 7)
Byte 7 of the Header defines the cryptographic algorithm with which the key contained in
the key block will be used. The following values are defined, although only four of these
values are currently supported:
Value Hex Algorithm

A X'41 AES
D X'44 DES
E X'45 Elliptic curve (included for future reference)
H X'48 HMAC
R X'52 RSA
S X'53 DSA (included for future reference)
T X'54 3-DES

Mode of Use (Byte 8)

Byte 8 of the Header defines the operation that the key contained in the key block can
perform.
Value Hex Description
B X'42 The key may be used to perform both encrypt and decrypt
operations.
C X'43 The key may be used to perform MAC calculation (both generate &
verify) operations.
D X'44 The key may only be used to perform decrypt operations.
E X'45 The key may only be used to perform encrypt operations.
G X'47 The key may only be used to perform MAC generate operations.
N X'4E No special restrictions apply.
S X'53 The key may only be used to perform digital signature generation
operations.
V X'56 The key may only be used to perform digital signature verification
operations.
X X'58 The key may only be used to derive other keys.
The "C", "G" and "V" field values will apply to HMAC keys, as well as "ordinary" MAC
keys.
The mode of use corresponding to the above values will be extended to include other key
usage, as follows:
Value Hex Mode of Use Key Usage

B X'42 Both encryption "K0", "51", "52" – key import or export
and decryption "P0", "71", "72" – PIN encryption or decryption
"D0", "21", "22", "23" – data encryption or
decryption
C X'43 Both generate "C0", "11", "12", "13" – card value generation or
and verify verification
"V0", "V1", "V2" – PIN or Offset generation or
verification
"01" – WatchWord response generation or
verification
D X'44 Decrypt only "K0", "51", "52" – key import only
"P0", "71", "72" – PIN decryption only
"D0", "21", 22", "23" – data decryption only
E X'45 Encrypt only "K0", "51", "52" – key export only
"P0", "71", "72" – PIN encryption only
"D0", "21". 22", "23" – data encryption only
G X'47 Generate only "C0", "11", "12", "13" – card value generation only
"V0", "V1", "V2" – PIN or Offset generation only
"01" – WatchWord response generation only

Value Hex Mode of Use Key Usage

‘N’ X'4E No special "C0", "11", "12", "13" – card value generation or
restrictions or verification
not applicable "D0", "21", "22", "23" – data encryption or
decryption
"K0", "51", "52" – key import or export
"M0", "M1", "M3", "M5", "M6" – MAC generation or
verification
"V0", "V1", "V2" – PIN or Offset generation or
verification
"01" – WatchWord response generation or
verification
"61" - "65" – HMAC generation or verification
"B0", "41", "42", "43" – DUKPT Base Derivation Key
"E0", "E1", "E2", "E3", "E4", "E5", "E6" – EMV
Master Keys
"P0", "71", "72" – PIN encryption
V X'56 Verify only "C0", "11", "12", "13" – card value verification only
"V0", "V1", "V2" – PIN or Offset verification only
"01" – WatchWord response verification only
X X'58 Derivation only "B0", "41", "42", "43" – DUKPT Base Derivation Key
For example, if, in a particular key block, bytes 5-8 have the values "11TV", this
indicates that the key in the key block is a 3-DES key that can only be used for the
verification of American Express CSCs. Similarly, if bytes 5-8 have the values "52TE"
then the key in the key block is a 3-DES ZMK that can only be used for key export and if
bytes 5-8 have the values "01DN" then the key is a single-length WatchWord key that
can be used for both response generation and verification.
Key Version Number (Bytes 9-10)

Bytes 9-10 of the Header define the version number of the key contained in the key
block or that the key is actually a key component. The following values will be
supported:
Value
Hex Key Version Number
(byte 9) (byte 10)
0 0 X'3030 Key versioning is not used for this key
A "c" in byte 9 indicates that the key carried in
c Any X'6300
the key block is a key component.
Any other combination of The version of the key or key component carried
printable characters in the key block
Note:
 If byte 9 is set to "c" then byte 10 will be used to indicate the component number.
For example, if bytes 9-10 = "c2" (X'6332) then this indicates that the key in the
key block is the second component of a key. Note, however, that this gives no
information regarding the total number of key components.

Exportability (Byte 11)

Byte 11 of the Header defines the conditions under which the key contained in the key
block can be exported outside the cryptographic domain in which the key is found. A key
is defined to be trusted if it is in either Thales Key Block or TR-31 Key Block format.
Any other format key is said to be untrusted. The following values will be supported.
Value Hex Exportability

May only be exported in a trusted key block, provided the wrapping
E X'45
key itself is in a trusted format.
N X'4E No export permitted.
Sensitive; all other export possibilities are permitted, provided such
S X'53 export has been enabled (existing Authorized State requirements
remain).
"Sensitive" export includes, for example, when a Key Block LMK is used and the key is
exported in ANSI X9.17 format. Export in X9.17 format is disabled by default in the
payShield 9000 security settings and must be specifically enabled (e.g. via the CS
console command) if required.
Note: When a key block is exported in a Thales or TR-31 Key Block format, byte 11 in
the exported key block dictates how further export must be handled by the recipient of
the key block. Hence, if the received byte 11 has value "E" then further "trusted" export
is permitted, but if byte 11 has value "N" then no further export will be permitted. Such
considerations must be taken into account when the key is initially generated. It will be
possible to change the value of byte 11 from "E" or "S" to "N" (so that no further export
will be permitted), via an optional field at the end of the command message.
Number of Optional Blocks (Bytes 12-13)

The Thales Key Block format allows a key block to contain up to 99 Optional Header
Blocks which can be used to include additional (optional) data within a Thales Key Block.
Optional Header Blocks are described below.
Bytes 12-13 of the Header specify the number of Optional Header Blocks in the key
block. A value of "00" (X'3030) indicates there are no optional blocks. A value of "12"
(X'3132) indicates that there are 12 optional blocks.
LMK Identifier (Bytes 14-15)

Bytes 14-15 of the Header identify the LMK used to encrypt and authenticate the key
block. Such identification is required to support multiple LMKs. The LMK Identifier field
may take numeric values "00" to "19". The number of LMKs that can be loaded into the
HSM is determined by the HSM's license file.
Example
As an example, a Key Block Header of
00072V2TG22N0033
indicates:
 a Key Block of 72 bytes,

 that the key contained in the Key Block may only be used with the Visa PVV
algorithm (the "V2" field),
 that it is a 3-DES key (the "T" field),

 that it may only be used for PVV generation ("G"),

 The key version number is "22",
 the key may not be exported (the "N" field),
 there are no Optional Header blocks in the Key Block, and
 the Key Block has been encrypted/authenticated using the LMK with identifier
"33".
With this example, the use of the Key Block is highly restricted. It cannot even be used
to verify PVVs. Users must take considerable care when generating Key Blocks to ensure
that the correct Header fields are created. The CS host command allows some
modifications to Header fields - but only modifications that further restrict the use of the
Key Block.
Carrying on with the above example, the Key Block may have been originally generated
with the Mode of Use field (byte 8) set to "N", meaning that the key could be used for
PVV generation or verification, and the Exportability field (byte 11) set to "E", meaning
that "trusted" export of the key was permitted. Following export of the key, it would exist
in two places, namely the PVV generation system and the PVV verification system. Once
there, byte 8 could be changed to "G" or "V", respectively, and byte 11 set to "N".
Thereafter the Header values cannot be changed any further.
Optional Header
An Optional Header Block has the following structure:

0-1 Identifier Optional Header Block identifier.
Optional Header Block length; this field contains the length in
bytes of the complete Optional Header Block, represented as a
hexadecimal value and ASCII encoded; for example, if the
2-3 Length overall length is 24 (decimal), then this is represented as X'18
and encoded as X'3138; if an Optional Header Block contains
no data then the length field contains the value X'04 (encoded
as X'3034).
4-n Optional Header Block data
Data
(n  251)
Thus the maximum length of an Optional Header block is 255 bytes (and the minimum
length is 4 bytes). The overall length of all the Optional Header Blocks must be a multiple
of the encryption block length (8 bytes in the case of 3-DES), which is achieved (if
necessary) by the inclusion of a "Padding" block that must be the last Optional Header
Block.
Note: In theory, a Key Block may have a maximum of 99 optional blocks. In practice,
however, a Key Block may not possess more than one optional block with the same
identifier. If a key block (Thales or TR-31) contains more than one Optional Header Block
with the same identifier then the HSM will return an error:
BC – Repeated optional block
This error will be returned if any attempt is made to use a host command to generate,
import or export such a key block.

Optional Header Block Types

The following Optional Header Blocks will be supported in the Thales Key Block. The first
three Optional Header Blocks are also supported by TR-31:
Optional
Header
Hex Field Name Comments
Block
ID
KS X'4B53 Key Set Identifier See examples in Annex E of ANSI X9.24-1
Used to define the version of the set of key
block field values and that the key block
KV X'4B56 Key Block version contains provisional values not yet
approved by ANSI. This field must contain
4 printable ASCII characters.
Used to ensure that the overall length of
the Optional Header Blocks is a multiple of
the encryption block length; the data field
PB X'5042 Padding block
is filled with readable (random) ASCII
characters; if used, the Padding block must
be the last Optional Header Block.
Key status; permitted values:
"E" (Expired)
"L" (Live)
"P" (Pending)
00 X'3030 Key Status
"R" (Revoked)
"T" (Test)
See notes below on permitted Key Status
transitions.
Algorithm and mode used to encrypt the
Key Data in the key block; only permitted
01 X'3031 Key Block Encryption
value:
"00" (current mechanism).
Algorithm and mode used to authenticate
Key Block
02 X'3032 the key block; only permitted value:
Authentication
"00" (current mechanism).
Date and time from which the key block is
03 X'3033 Start Date/Time valid; format:
YYYY:MM:DD:HH
Date and time after which the key block is
04 X'3034 End Date/Time invalid; format:
YYYY:MM:DD:HH
Any combination of printable characters; a
05 X'3035 Text
zero length data field will not be permitted
The "KS", "KV" and "PB" optional blocks are inherited from the TR-31 standard, but the
remaining optional block types are proprietary to the Thales key block. The "01" and "02"
optional blocks are for future-proofing, in the event that the LMK is changed to another
algorithm (as happened with AES).
For example, a key block that contains a "live" key could have an Optional Header Block
structure as follows (the space is to aid readability and is not part of the Optional Header
Block):

0005L PB0Brrrrrrr
In this case, the "Number of Optional Blocks" field in the key block header (bytes 12-13)
will contain the value "02" (X'3032).
The Padding block (containing 7 random padding characters in this case) is required to
ensure that the total length of the Optional Header Block is a multiple of 8 bytes. Note
that any optional block must be at least 4 bytes in length.
Notes:
 The order in which optional blocks appear in a key block is immaterial, except that
"PB" Padding block must be the last optional block.
 Optional Header Blocks with identifiers "01" and "02" will not normally be used,
but are included in the event that multiple encryption and authentication modes
may be required in the future. If they are used then they must have data value
"00".
Permitted Key Status transitions

The following transitions (only) will be permitted for Key Status:
Pending Live Expired
Revoked
Notes:
 The host command CS may be used to modify the status of a key.

 The HSM will not permit the use of a key that is marked as "Pending", "Expired"
or "Revoked".
 Keys with status "Test" or "Live" may be used as normal by an HSM.
Encrypted key data

The only part of the key block that is encrypted is the Key Data, which contains the
actual key stored in the key block. The key types that may be protected in a Thales Key
Block are DES and TDES keys, HMAC keys, AES keys, and RSA public and private keys.
Note that an RSA public key is not encrypted, but the key block is still authenticated.
The encryption algorithm used to protect the Key Data depends on the specific Key Block
scheme being used:
 When using a DES Key Block LMK, the Key Data portion of the key block is
encrypted using 3-DES Cipher Block Chaining (CBC), using bytes 0-7 of the
Header as the Initialization Vector (IV). The encryption key will be a variant of
the LMK.
 When using an AES Key Block LMK, the Key Data portion of the key block is
encrypted using AES Cipher Block Chaining (CBC), using bytes 0-15 of the Header
as the Initialization Vector (IV). The encryption key will be cryptographically
derived from the LMK.
Note:
 An Optional Header Block will be reserved so that other encryption algorithms and
modes of encryption can be supported in the future.

The Key Data block has the following format:
Field Length Notes

Key 2 bytes Contains the length in bits of the key that is to be
Length encrypted (see next field); the length is written as a
16-bit binary number; for example, if the key is a
192-bit (triple-length) 3-DES key then this field
contains the value X'00C0.
Key variable, Contains the key data, in binary format; for example,
depending on key a 192-bit (triple-length) 3-DES key would be
that is being represented as 24 bytes.
encrypted
Padding Variable Contains random padding, used to ensure that the
length of the entire Key Data block is a multiple of the
block length of the encrypting key; for example, if a
3-DES key is used as the encryption key then the Key
Data block must be a multiple of 8 bytes, so with the
examples above the padding field could contain 6, 14,
22,.. bytes; the padding field can be used to disguise
the true length of the key in the key block, if required.
A security setting (e.g. in the CS console command) allows users to ensure that all
double-length keys in Thales Key Blocks are padded with an additional 8 bytes of random
values to disguise the length of the key. If this option is not selected then the minimum
padding necessary will be applied in all cases.
Note:
 The minimum padding necessary for AES, RSA and HMAC keys will always be
applied, regardless of this security setting.
Authenticator
The key block Authenticator ensures the integrity of the key block, and is calculated over
the Header, Optional Header Blocks and the Key Data. The authentication algorithm
used depends on the specific Key Block LMK being used:
 When using a DES Key Block LMK, the key block Authenticator is calculated using
a 3-DES CBC-MAC, with a zero IV. (No padding is required, as the data to be
authenticated is always a multiple of 8 bytes in length.) The leftmost 4 bytes of
the result will be used as the Authenticator. The authentication key will be a
variant of the LMK.
 When using an AES Key Block LMK, the key block Authenticator is calculated using
an AES CMAC over the clear key block. The leftmost 8 bytes of the result will be
used as the Authenticator. The authentication key will be cryptographically
derived from the LMK.
Note: The Key Scheme Tag "S" is not included in the authenticated data.
Key Block Local Master Keys (LMKs)

A Key Block LMK is a either a triple-length DES key, or a 256-bit AES key, and is used to
encrypt keys in a key block format. It is not compatible with a Variant LMK, and it can
only be used to encrypt keys in key block form.
Note:
 The term "Key Block LMK" refers to the 'key block' method of encrypting keys; a
Key Block LMK is not itself stored in key block form.

3DES Key Block Test LMK

The value of the LMK contained in the 3DES Key Block Test LMK smartcard is shown in
the table below. The two Passwords are also held in this device, and their values are also
shown below.
The PIN for the Test Key Smartcard is: 1 2 3 4
LMK 01 23 45 67 89 AB CD EF 80 80 80 80 80 80 80 80 FE DC BA 98 76 54 32 10
Password 1 89 89 89 89 89 89 89 89
Password 2 THEQUICKBROWNFOX
The check value is 165126.
AES Key Block Test LMK

The value of the LMK contained in the AES Key Block Test LMK smartcards is shown in
the table below. The AES Key Block Test LMK can only be used in smartcard
authentication mode, so password authentication is not supported.
LMK 9B 71 33 3A13 F9 FA E7 2F 9D 0E 2D AB 4A D6 78 47 18 01 2F 92 44 03 3F
3F 26 A2 DE 0C 8A A1 1A
The check value is 9D04A0.

Console Command examples

CK Console Command (Generate Check Value)
In this first example, the CK console command is used to generate a check value for a
key contained in a Key Block. No additional fields are required.
Online> CK <Return>
Enter LMK id: 33 <Return>
Enter Key Block: S 00072V2TG22N0033xx………xxxxx <Return>
Key check value: cccccc
Online>
KG Console Command (Generate Key)

In this example, the console KG command is used to generate a non-exportable, double
length Base Derivation Key (BDK) used in the DUKPT scheme. The Key Block will contain
start and end date/time optional blocks.
Online> KG <Return>
Enter key length [1,2,3]: 2 <Return>
Enter key scheme (LMK): S <Return>
Enter key scheme (ZMK): <Return>
Enter ZMK: <Return>
Enter key usage: B0 <Return>
Enter mode of use: N <Return>
Enter key version number: 00 <Return>
Enter exportability: N <Return>
Enter optional blocks? [Y/N]: Y <Return>
Enter optional block identifier: 03 <Return>
Enter optional block data: 2005:12:21:00 <Return>
Enter more optional blocks? [Y/N]: Y <Return>
Enter optional block identifier: 04 <Return>
Enter optional block data: 2007:12:21:00 <Return>
Enter more optional blocks? [Y/N]: N <Return>
Key under LMK:

S 00112B0TN00N030703112005:12:21:0004112007:12:21:00PB06rrxx……xxxxx
Key check value: cccccc
Online>
In the above example, the Key Usage value "B0" indicates that the key is a BDK and the
Mode of Use value "N" means that there are no specific restrictions on the use of the key.

Host Commands
The document payShield 9000 Host Command Examples includes examples of Host
Commands and Responses when key block LMKs are being used.
Error Codes
Implementation of Key Blocks is a complex matter, so a large number of error codes are
provided to aid development and testing. For example:
 in an A6 command where a Key Usage of 72 has been specified, if a Mode of Use

value other than "N" was input an error code would be generated (as "N" is the
only permitted value when the Key Usage is "72").
 Similarly, if an Exportability value "E" was supplied then an error would be
generated (since the imported key is untrusted).
Some of the more obvious (generic) key block error conditions include key block
authentication failure, the use of incompatible key schemes or LMK identifiers, the
attempted use of an expired or revoked key and the attempted use of an exportability
mode that is not permitted. In addition, when used with specific commands only certain
Header values are allowed; an invalid Header will cause an error code or error message
to be returned.

Chapter 9 – Multiple LMKs

Introduction
The LMK (Local Master Key) on the payShield 9000 is used to protect (by encryption) all
of the operational keys plus some additional sensitive data that are processed by the
HSM.
The payShield has the capability of Multiple LMKs, such that up to 20 LMKs of different
types can be in use at any one time. Each LMK can be managed by a separate security
team, allowing a single payShield 9000 to be used for multiple purposes – such as
different applications or different clients.
The Need for Multiple LMKs

About LMKs
The LMK is stored in the tamper-resistant memory of the HSM. All other cryptographic
keys used in the system are encrypted under the LMK and are usually stored externally
to the HSM (but see also the chapter on User Storage), usually in a key database on the
host system that is accessible by host applications. The LMK may be common to a
number of HSMs, so that applications do not need to concern themselves with the
particular HSM used for cryptographic processing. Since there is only a single key stored
in the HSM, in the event of a problem with the device, recovery can be effected quickly
and with minimal disruption to operations.
There are two types of LMK:
 Variant LMK (see Chapter 7), and

 Key Block LMK (see Chapter 8)
Multiple LMKs
The LMK mechanism is simple, easy to understand and secure, but it does have some
limitations. In particular, the use of a single LMK within an HSM (or cluster of HSMs)
means that it is not possible to achieve cryptographic isolation of applications that are
calling the HSM. This may breach the requirements of some PCI security standards and
may be a cause for other concerns. For example:
 In a bureau situation, there is generally a need to support keys from many different
clients, yet maintain cryptographic isolation of such keys; the use of multiple LMKs is
one way to achieve this;
 Some users may wish to use the HSM in both a live operational environment and a
test or development environment (not recommended, but may be a necessity in some
cases).
The availability of Multiple LMKs also makes it easier to migrate operational keys from an
old LMK to a new one. Such LMK migration should be performed every few years for
security purposes, but may also be necessary for operational reasons – for example
when upgrading from double- to triple-length Variant LMKs or from Variant LMKs to Key
Block LMKs.
Although the payShield 9000 allows for changing the LMK, it means that all operational
keys need to be translated from encryption under the old LMK to encryption under the

new LMK before they can be used. A "big bang" approach typically requires very careful
planning and coordination, with possible downtime or need for additional HSM capacity.
As a consequence, some HSM users are reluctant to change the LMK.
The use of multiple LMKs allows users to adopt a phased approach to LMK change. LMK
migration is described in Chapter 10.
Multiple LMK Licensing

All payShield 9000 HSMs are delivered with the capability to support 2 LMKs – one
Variant LMK plus one Key Block LMK.
Additional optional licenses can be added to the payShield 9000 to enable use of up to 20
LMKs, of any mix of Variant and Key Block LMKs, on a single payShield 9000.
Managing Multiple LMKs

LMK component generation
LMK components are generated using the GK console command.
Secure> GK <Return>
Variant scheme or key block scheme? [V/K]: K <Return>
Key status? [L/T]: L <Return>
LMK component set [1-9]: 1 <Return>
Enter secret value A: <Return>
Enter secret value B: <Return>
Enter secret value C: <Return>
Insert blank card and enter PIN: ******** <Return>
Writing key
Checking key
Device write complete, check: 012345
Make another copy? [Y/N]: Y <Return>
…
Secure>
Equivalent functionality when using payShield Manager is found under Operational / Local
Master Keys.
LMK Loading
When the LMK is loaded into the HSM by forming it from components (e.g. using the
console LK console command), the LMK identifier is entered so that the LMK can be
stored in the correct "slot" in secure memory. It is important to note that the identifier is
only defined when the LMK is loaded.
Secure> LK <Return>
Enter comments: Live LMK for PQR Bank <Return>
LMK in selected location must be erased before proceeding.
Erase LMK? Y <Return>
Load LMK from components
Insert card and enter PIN: ******** <Return>
Check: 012345
Load more components? [Y/N]: Y <Return>
…
…
Check: 396723
Load more components? [Y/N]: N <Return>
LMK id: 02
LMK key scheme: Key block
LMK algorithm: 3DES (3key)
LMK status: Live
Comments: Live LMK for PQR Bank
Confirm details? [Y/N]: Y <Return>
…
Secure>

Master Keys.
Migration from Old to New LMK

Once the LMK has been loaded, an "old" LMK can be loaded into key change storage (e.g.
using the console LO command) and operational keys migrated from encryption under
the old LMK to encryption under the new. Keys can be migrated from variant  variant
LMK, variant  key block LMK or key block  key block LMK, but not from key block 
variant LMK.
Secure-AUTH> LO <Return>
Enter comments: Old LMK for PQR Bank <Return>
Load old LMK from components
Insert card and enter PIN: ******** <Return>
Check: 678901
Load more components? [Y/N]: Y <Return>
…
Check: 085392
Load more components? [Y/N]: N <Return>
LMK id: 02
LMK key scheme: Key block
LMK algorithm: 3DES (3key)
LMK status: Live
Comments: Old LMK for PQR Bank
Confirm details? [Y/N]: Y <Return>
…
Secure-AUTH>
Master Keys.
Once the old and new LMKs are loaded in the correct locations, migration of keys from
old to new LMK (and from variant to key block, if required) can take place. The same
mechanism can be used to provide a phased migration of keys from one LMK to another.
In this case, the "old" key may continue to be used as an operational LMK at the same
time as keys are migrated to encryption under a new LMK. This mechanism allows, for
example, existing keys for different applications to be cryptographically isolated from
each other. For more detail, see Chapter 10.
Authorization
Authorization is required to enable certain console and host commands to be executed.
Either the whole HSM can be put into Authorized State, which enables all commands
requiring authorization to be executed. Alternatively, the HSM can be configured to
support Multiple Authorized Activities: in this mode, authorization can be applied to
individual activities or groups of activities.
In order to set authorization, two smartcard holders must authenticate themselves to the
HSM by presenting the smartcards and entering the smartcards’ PINs. These PINs are set
up when the smartcards are formatted (e.g. by using the FC console command).
With multiple LMKs, each LMK will have its own authorizing smartcards and PINs. This
means that commands can be authorized for a specific LMK. So, for example, in the
previous section when using the LO command for loading an "old" LMK in key change
storage, LMK with identifier=02 has been specified: authorization requires the use of the
authorization smartcards and PINs used when setting up LMK 02 and so only permits the
old LMK to be loaded in key change storage slot 02.
This technique provides for highly granular control over sensitive LMK operations. The A
console command can be used to see which activities have been authorized:

Online> A <Return>
No activities are authorized for LMK id 03
List of authorizable activities:
…
…
The following activities are pending authorization for LMK id 03:
pin.mailer
First Officer:
Insert card for Security Officer and enter the PIN: ******** <Return>
Second Officer:
Insert card for Security Officer and enter the PIN: ******** <Return>
The following activities are authorized for LMK id 03:
pin.mailer
Online-AUTH>
In this example, only PIN mailer printing is authorized and then only for the LMK with
identifier 03. Equivalent functionality when using payShield Manager is found under
Operational / Local Master Keys.
LMK table
From a management perspective, it is important to know which LMKs have been loaded
into the HSM (and in which locations). This information can be displayed using the VT
console command:
Online> VT <Return>
LMK table:
ID Authorized Scheme Algorithm Status Check Comments
00 Yes(1H,1C) Variant 3DES(2key) Test 268604 For RST Bank
01 No Key block 3DES(3key) Test 999999 For XYZ Bank
02 Yes(4H,0C) Key block AES-256 Live 324365 For PQR Bank
03 Yes(0H,1C) Key block AES-256 Live 963272 Mngmnt LMK
Key change storage table:

ID Scheme Algorithm Status Check Comments
01 Variant 3DES(2key) Test 876543 For XYZ Bank
02 Key block 3DES(3key) Live 085392 For PQR Bank
Online>
As can be seen, details of operational LMKs and any LMKs that have been loaded into key
change storage are displayed. The second column of the LMK table indicates whether any
activities are authorized for that LMK and, if so, how many ("H" = Host commands, "C" =
Console commands).
Master Keys.
Deleting LMKs
With multiple LMKs in the HSM, it is necessary to be able to delete individual LMKs from
the HSM’s memory without deleting any other LMK. This is achieved using the DM
console command:

Secure-AUTH> DM <Return>
LMK table entry:

ID Scheme Algorithm Status Check Comments Auth
01 Key Block 3DES(3key) Test 999999 Test LMK for XYZ Bank Yes (1)
Key change storage table entry:

ID Scheme Algorithm Status Check Comments
01 Variant 3DES(2key) Test 876543 Old test LMK for XYZ Bank
Confirm LMK deletion [Y/N]: Y <Return>

LMK deleted from main memory and key change storage
Secure>
As can be seen from the above example, if an LMK is deleted then any LMK in the
corresponding "slot" in key change storage is also deleted.
Similarly, individual LMKs that have been loaded into key change storage may be deleted
without deleting the live LMK by using the DO console command.
Master Keys.
Identifying the Required LMK

Clearly, operational commands need to know which LMK should be used for processing.
Console Commands
For console commands, the user will simply be required to enter the LMK identifier. For
example:
Online> CK <Return>
Enter key block: S 0xxxxxxxxxxxxx03xx………xxxxx <Return>
Key check value: CCCCCC

Online>
In the above example, the LMK with identifier 03 is a key block LMK and the command
returns the check value for the key contained within the key block. Note that the key
block itself also includes the identifier of the LMK used to encrypt and authenticate the
key block, in bytes 14-15. If this value does not agree with the value entered by the user
then an error message will be displayed.
Host Commands
For host commands, the situation is somewhat more complicated and a number of
mechanisms can be used to indicate which LMK to use in the processing of the command.
Default LMK
One particular LMK is identified as the "default" LMK and, in the absence of any other
indication in the command message, it is assumed that the default LMK is being used.
The principal benefit of this mechanism is that it provides a backwards-compatibly for
host applications written without consideration of the multiple LMK capability.
The identifier for the default LMK (which may be the same as the management LMK – see
below) is defined using the CS console command ("Configure Security") or Configuration
/ Security Settings / General in payShield Manager.

Management LMK
One LMK is designated as the "management" LMK and is required for a small number of
host commands, mainly associated with the HSM’s audit functions.
The identifier for the management LMK (which may be the same as the default LMK
discussed above) is defined using the CS console command ("Configure Security") or
Configuration / Security Settings / General in payShield Manager.
Key Block LMKs

One of the fields in a key block identifies the LMK used to encrypt and authenticate the
key block (see bytes 14-15 of the key block in the earlier example) and so if key blocks
are presented in a host command, the LMK identified in the key blocks will be used. If
key blocks with different LMK identifiers are presented in the same command then the
HSM will return an error.
Explicit LMK Identifier in Host Commands

An explicit mechanism that can be used is simply to include optional fields at the end of
the command message to identify the correct LMK to use when processing the command.
This technique can be used if there are no other fields in the command message that
identify the LMK – for example, when using the A0 command to generate a key or when
using a variant LMK, which is neither the default LMK nor the management LMK. The
optional fields are a delimiter ("%") and the LMK identifier:
Field Length Details

& Type
Delimiter 1A Optional; if present the following field must be present;
value "%"
LMK 2N LMK identifier; permitted values "00" to "99"; must be
Identifier present if the above Delimiter is present
If there is a "mis-match" between the LMK identifiers in a command then the HSM will
return an error. This could happen, for example, if:
 no LMK is loaded in the identified location, or

 key blocks contain different identifiers, or
 the optional fields are present at the end of the command message and indicate an
LMK that is different from the LMK identified elsewhere in the command message.
The identification of the required LMK by explicit identification in the host command
normally overrides LMK identification using the TCP Port number (see below). However,
the payShield 9000 security settings can specify that the TCP port number can override
LMK identifiers in host commands (e.g. the Enforce host port override for LMK use?
setting in the CA console command).
Ethernet TCP Port

An additional mechanism is available for Ethernet-attached host computers. The HSM can
infer the LMK Identifier to use for a particular command from the TCP port on which the
command is received.
When configuring the payShield 9000’s host ports, a "Well-Known Port" is specified for
host command traffic arriving from the host: by default this is 1500 (or 2500 if Secure
Host Communications is being used). In the absence of any other indicator of the LMK to
be used:

 host commands directed to the Well-Known Port will use the Default LMK;
 host commands directed to [Well-Known Port +1] will automatically use LMK Id
00;
 host commands directed to [Well-Known Port +2] will automatically use LMK Id
01;
 more generally, host commands directed to [Well-Known Port + n, where n1] will
automatically use LMK Id [n-1].
The situation for an HSM using the default Well-Known Port value of 1500 is summarized
in the table below:
Command received LMK Used

on TCP Port
1500 Default LMK Id
1501 LMK Id 00
1502 LMK Id 01
1503 LMK Id 02
… …
The identification of the required LMK by using the TCP Port number is normally
overridden by LMK identifiers explicitly specified in host commands or key blocks.
However, the payShield 9000 security settings can specify that the TCP port number can
override LMK identifiers in host commands (e.g. the Enforce host port override for LMK
use? setting in the CA console command).

Chapter 10 – Migrating LMKs

Introduction
Thales payment HSMs have always provided a facility to migrate between LMKs - i.e. to
re-encrypt operational keys and other data from encryption under one (old) LMK to
encryption under another (new) LMK. The need to do this is more important than in the
past because:
 Card schemes are requesting that customers change their master keys every 2
years.
 Adoption of Key Block LMKs, with their added security, requires a migration from
Variant LMKs.
This chapter outlines the migration process.
Multiple LMKs
By default, the payShield 9000 is delivered with the ability to install 1 or 2 LMKs. If 2
LMKs are installed, one must be a Variant type and one must be a Key Block type (see
below).
It is also possible to purchase optional licenses for the payShield 9000 to allow up to 20
LMKs to be installed at the same time:
License Description
HSM9-LIC001 Two concurrent LMKs can be installed; however, one
(standard license) must be a Variant LMK, and the other a Key Block LMK.
HSM9-LIC012 LMK x 2 Two concurrent LMKs can be installed; they can be any
(optional license) combination of Variant and Key Block LMKs.
HSM9-LIC013 LMK x 5 Five concurrent LMKs can be installed; they can be any
HSM9-LIC021 LMK x 10 Ten concurrent LMKs can be installed; they can be any
HSM9-LIC022 LMK x 20 Twenty concurrent LMKs can be installed; they can be
(optional license) any combination of Variant and Key Block LMKs.
Each LMK can be managed by its own team of security officers.

The multiple LMK facility can be used to provide separation between multiple clients,
applications, or purposes serviced on the same HSM – and they also make the process of
migrating LMKs easier. The Multiple LMK facility is described in Chapter 9.
Overview of the LMK Migration Process

The LMK Migration process takes keys which are encrypted under an old LMK and re-
encrypts them under a new LMK. Both the old and the new LMKs must be installed in the
payShield 9000. There are two types of LMK storage:
 LMK Live storage. Transaction processing and other LMK functions can make use
only of LMKs in Live storage.
 Key Change storage. LMKs in Key Change storage cannot be used for any purpose
other than as part of the LMK migration process. Where multiple LMKs are
deployed, there is one Key Change storage "slot" for each LMK in the Main
storage.

There are 2 ways of allocating old/new keys to Main/Key Change storage:
 The new LMK (which has not yet been deployed for live operation) is loaded into
Live storage, and the old LMK (which is still being used for live processing) is
loaded into Key Change storage using the LO console command (as described
later). This is the original method that was available on the payShield 9000. It
means that the payShield 9000 being used for migration cannot be used to
process transactions until the LMK migration process is completed and the new
LMK comes into operational use, but it is then immediately ready to process
transactions because the new LMK is already loaded in Live storage.
 The old LMK (still being used for live operation but about to be obsoleted) is left in
Main Live, and the new LMK (which has not yet been deployed for live operation)
is loaded into Key Change storage using the LN console command (as described
later). This is a more recent option and means that the payShield 9000 can
continue processing transactions using the current LMK at the same time as it is
used for migrating keys to the new LMK. On the other hand, when the new LMK is
ready to go live, the new LMK must be loaded into Live storage before any
transactions can be processed.
The steps needed to migrate from an old LMK to a new LMK are:
1. Create smartcards with components for the new LMK.
2. Load the new LMK (from components cards) into either LMK Live storage or LMK
Key Change storage.
3. Either:
 leave the old LMK in LMK Live storage and load the new LMK (from
component cards) into LMK Key Change storage, or
 load the new LMK (from component cards) into LMK Live storage and load
the old LMK (from components cards) into LMK Key Change storage in the
same HSM.
4. Re-encrypt the operational keys from the old LMK to the new LMK and hold these
in a pending new key database.
5. Re-encrypt PINs from the old LMK to the new LMK and hold these in a pending
new PIN database.
6. Re-encrypt decimalization tables from the old LMK to the new LMK and hold these
in a pending new decimalization table database.
7. If the new LMKs have been loaded into Key Change storage, re-load them into
Live storage.
8. Make the pending key/PIN/decimalization table databases the live databases.
The following sections describe each of these options.

Subsequent sections look at the following associated considerations:
 Migrating from Variant to Key Block LMKs

 Key type changes for PCI HSM compliance.
 The Multiple LMK capability
Generating new LMK component smartcards

LMKs are set up in the payShield 9000 by loading a number (typically 3) of components
which are then combined within the HSM to form the LMK. (The formed LMK is never
available outside of the HSM.) The LMK components are loaded from LMK smartcards.

The first stage, therefore, is to create smartcards which have the components for the
new LMK. These components have completely random values, and are created on any
payShield 9000.
Each component must be held by a different security officer, and access to the
component cards must be securely controlled (e.g. by storing the card securely and
requiring security officers to check the cards out and in).
All component cards are required to load (or form) an LMK, and so loss of any card or
absence of a card holder prevents the LMK being loaded (or re-loaded at a later date if
necessary). Therefore at least one backup should be made of each component card.
Note that the terms "LMK card" and "LMK component card" are interchangeable. Only
LMK components are ever written to cards - the whole LMK is never written to a card.
Types of LMK component cards

There are two types of LMK component cards:
 HSM LMK cards - using the card reader built into the HSM. This type of card is
created and used by operators using a console and the HSM card reader.
 payShield Manager RLMK cards - created by operators using payShield Manager
and the card reader attached to the remote management PC.
The principles are the same for both types of card, although the detail of the processes is
different. The two types of card are incompatible, although either type of card can be
created from the other.
Formatting LMK smart cards

HSM LMK Cards
Before they can be written to, smart cards must be formatted.
Cards which have been used previously and are no longer required can be re-formatted
to enable the new components to be written to them. Do not re-format the
component cards for the old LMK that you are about to migrate from - you will
be needing them !
Each component holder should format their own card plus at least one backup per
component.
HSM LMK smartcards are formatted using the FC console command (described in the
payShield 9000 Console Reference Manual).
payShield Manager LMK Cards

With payShield Manager, the LMK components are written to RLMK cards which are
provided by Thales. RLMK cards do not require formatting.
Generating LMK component cards

HSM LMK Cards
Each component holder should now generate a component and write it to their smart
card and backup card(s). This is done using the GK console command (described in the
payShield 9000 Console Reference Manual).

Various warnings and errors may be reported during this process. These are easy to
understand, and appropriate responses should be made.
payShield Manager RLMK Cards

LMK components for use with payShield Manager are written to RLMK cards using the
Generate button in payShield Manager’s Operational / LMK Operations / Local Master
Keys tab. These cards use a quorum (i.e. "m of n") approach to define how many of the
cards must be used when loading an LMK. The operator provides the following
information when generating the LMK:
 Number of LMK shares, i.e. "n" (Default: 2)

 Number of shares to rebuild, i.e. "m" (Default: 2)
 Key scheme (Variant or Key Block)
 Algorithm
 Status (Live or Test)
For more detailed information see the payShield Manager User Guide.
Creating Copies of LMK Component Cards

Because all component cards are needed when the LMK is loaded, copies of each LMK
card should be made to allow for misplacement or for issuing to deputies. There are
several ways of doing this.
HSM LMK cards

During LMK card generation
As mentioned above in the section on Generating HSM LMK cards, multiple copies may
be made at the time of generating the LMK card.
Copying an existing HSM LMK card

It is possible at any time to copy an existing HSM LMK card using the DC console
command.
payShield Manager RLMK card

Duplicating a payShield Manager RLMK card
a copy of an existing RLMK component card can be made using the Duplicate button in
payShield Manager’s Operational / LMK Operations / Local Master Keys tab.
Loading the new LMK

In the previous section we explained how to create a set of cards containing the
components for the new LMK. Each component is "owned" by a different security officer,
with no one security officer having access to more than one component. One holder of
each of the required number of components must be present to allow the LMK to be
loaded onto the payShield 9000 using the component smart cards.
The new LMK now needs to be installed into either LMK Live storage or LMK Key Change
storage depending on the approach being taken – see the section on Overview of the
LMK Migration Process.
The new LMK can be loaded using a Console or payShield Manager.

Using the Console

Loading (or forming) the LMK
The LMK is loaded using either:
 the LK console command if the new LMK is to be loaded into LMK Live storage, or
 the LN console command if the new LMK is to be loaded into LMK Key Change
storage.
The payShield 9000 must be in Secure state. In addition, if the LN console command is
being used then the HSM must be in Authorized state. If multiple authorized states is
enabled, the activity category is admin (with no sub-category), and the console interface
should be selected.
The smart cards used must be HSM cards - not cards created for payShield Manager.
Checking the LMK

It is recommended that a check is made that the new LMK has been properly loaded.
This can be done using the A console command, to put the HSM into authorized state
(followed by the C command to cancel the authorized state). The A command can be run
in any HSM state. The operation of this command depends on whether multiple
authorized activities has been enabled in the security settings (e.g. by using the CS
console command) – see the payShield 9000 Console Reference Manual for full details.
Using payShield Manager

Installing the LMK
The new LMK is loaded using the Install button in the appropriate payShield Manager
tab:
 Operational / LMK Operations / Local Master Keys where the new LMK is to be
loaded into LMK Live storage, or
 Operational / LMK Operations /Key Change Storage where the new LMK is to be
loaded into LMK Key Change storage.
The LMK ID will need to be specified. See the payShield Manager User Guide for more
detailed information.
Checking the LMK

The installed LMK can be checked by viewing the LMK list displayed at Operational / LMK
Operations / Local Master Keys or Operational / LMK Operations / Key Change Storage.
Loading the old LMK

So far we have created a set of cards containing the components for the new LMK, and
used them to load into the HSM the "new" LMK that keys and data to be re-encrypted to.
To migrate keys from encryption under an old (current) LMK to encryption under the new
LMK, we also need to have the old LMK into the HSM. The old LMK can be left in LMK
Lives storage or loaded into LMK Key Change Storage, depending on the approach being
taken – see the section on Overview of the LMK Migration Process.
If the old LMK is to be loaded into Key Change Storage, this can be done using a Console
or payShield Manager.

Using the Console

The old LMK is loaded into Key Change Storage using the LO (where "O" is the alphabetic
"O for Oscar") console command.
The payShield 9000 must be in Secure state. In addition, the HSM must be in Authorized
state. If multiple authorized states is enabled, the activity category is admin (with no
sub-category), and the console interface should be selected.
The use of the LO console command is the same as for the LK console command
mentioned previously, except that no existing LMK needs to be erased and so you will
not be prompted to confirm an erasure.
After loading the old LMK, the HSM should be returned to Online state by turning the
physical keys.

The old LMK is loaded using the Install button in payShield Manager’s Operational / LMK
Operations / Key Change Storage tab. This can only be done if there is an LMK with the
same ID in the LMK table. See the payShield Manager User Guide for more detailed
information.
Migrating keys between Variant LMKs

We now have installed in the HSM both the old LMK that the operational keys are
currently encrypted under and the new LMK that they need to be encrypted under for the
future. We now need to take each existing operational key in the old key database
(encrypted under the old LMK), re-encrypt it using the new LMK, and put it in a new key
database.
In order to do this, an application needs to be set up at the host that:
 takes each operational key (encrypted under the old LMK) from the old key
database
 sends the encrypted key to the HSM using the BW host command.
 Receives the BX response from the HSM containing the operational key encrypted
under the new LMK.
 Puts the operational key encrypted under the new LMK into the new key database.
The BW Host command

Here we will look at the BW host command as it is used to convert an operational key
encrypted under an old LMK of the Variant type to encryption under a new LMK of the
Variant type. Other ways of using the BW command are discussed later in this document.
The BW host command automatically adapts its processing depending on where the old
and new LMKs are stored:
 If the old LMK was loaded into Key Change storage (e.g. the LO console command
was used), then keys and data are re-encrypted from encryption under the (old)
LMK in Key Change storage to encryption under the (new) LMK in Live storage.
 If the new LMK was loaded into Key Change storage (e.g. the LN console
command was used), then keys and data are re-encrypted from encryption under
the (old) LMK in Live storage to encryption under the (new) LMK in Key Change
storage.

The table below indicates the structure of the BW host command when it is used in this
way.
Length &
Field Type Notes
Message Header mA This field contains whatever the user wants. The
length of the field is defined using the CH console
command or Configuration / Host Settings in
payShield Manager. It is subsequently returned
unchanged in the response to the host.
Command Code 2A Must have the value 'BW'.
Key Type code 2H Indicates the LMK under which the key is encrypted:
'00' : LMK pair 04-05 (Key Type 000)
'01' : LMK pair 06-07 (Key Type 001)
'02' : LMK pair 14-15 (Key Type 002)
'03' : LMK pair 16-17 (Key Type 003)
'04' : LMK pair 18-19 (Key Type 004)
'05' : LMK pair 20-21 (Key Type 005)
'06' : LMK pair 22-23 (Key Type 006)
'07' : LMK pair 24-25 (Key Type 007)
'08' : LMK pair 26-27 (Key Type 008)
'09' : LMK pair 28-29 (Key Type 009)
'0A' : LMK pair 30-31 (Key Type 00A)
'0B' : LMK pair 32-33 (Key Type 00B)
'10' : Variant 1 of LMK pair 04-05 (Key Type 100)
'42' : Variant 4 of LMK pair 14-15 (Key Type 402)
'FF' : Use this value where the key type is specified
after the first ‘;’ delimiter below. This allows key
types other than those listed above to be specified.
Key length flag 1N '0' : for single-length key

'1' : for double-length key
'2' : for triple-length key.
Key 16/32 H The operational key to be translated, encrypted

or under the old LMK.
1A+
32/48 H
Delimiter 1A Optional. Only present if ‘FF’ was supplied above for

the Key Type code and the following field is present.
Value ';'.
Key Type 3H Where ‘FF’ was entered for Key Type Code, this is
the 3-digit key type code of the key being translated.
For a list of key type codes, see the appropriate table
of Key Type Codes in Chapter 4 of the payShield
9000 General Information Manual.
Delimiter 1A Optional. If present the following three fields must be

present. Value ';'.

Length &
Field Type Notes
Reserved 1A Optional. If present must be '0' (zero).
Key Scheme 1A Optional. Key scheme for encrypting key under LMK
(LMK) (or '0' (zero) ). For a list of key schemes, see the
Key Scheme Table at Appendix C of the payShield
9000 General Information Manual.
Reserved 1A Optional. If present must be '0’ (zero).
Delimiter 1A Value '%'. Optional; if present, the following field

must be present.
LMK Identifier 2N Where the user is using multiple LMKs on the same
HSM, this allows the ID of the LMK being migrated to
be selected. Minimum value = '00'; maximum value
is defined by licence. This field must be present if the
above Delimiter is present. If the field is not present,
then the default LMK will be used.
End Message 1C Must be present if a message trailer is present. Value

Delimiter X’19’.
Message Trailer nA Optional. The contents of the trailer is as required by

the user, and is returned unchanged in the response.
Maximum length 32 characters.
The BX Response to the Host

In response to the BW host command, the payShield 9000 will return the following BX
response to the host:
Length &
Field Type Notes
Message Header mA This is a play-back of the header provided in the BW

command.
Response Code 2A Has the value 'BX'.

Length &
Field Type Notes
Error code 2N Indicating the general outcome of the BW command:

'00' : No error
'04' : Invalid key type code
'05' : Invalid key length flag
'10' : Key parity error
‘44’ : migration not allowed: key migration requested
when the security setting "Enforce key type 002
separation for PCI HSM compliance" has the value
"Y".
‘45’ : Invalid key migration destination key type.
'68' : Command disabled
or any standard error code (see Chapter 4 of the

payShield 9000 Host Command Reference Manual).
Key 16/32 H The resulting key, re-encrypted under the new LMK.
or
1A+
32/48 H
End Message 1C Present only if a message trailer is present. Value

Delimiter X'19’.
Message Trailer nA This is simply a play-back of any trailer included in

the BW command.
Migrating keys from Variant to Key Block LMKs

Key Block LMKs provide additional security compared to Variant LMKs - see Chapter 8 for
further information.
The BW host command already described for Variant LMK  Variant LMK migration can
also be used for Variant LMK  Key Block LMK migration. When used for this purpose,
the BW command and BX response are modified as indicated below.
Note that it is not possible to migrate from:
 Key Block LMKs to Variant LMKs.

 AES Key Block LMKs to TDES Key Block LMKs.
The BW Host command

The table below indicates the structure of the BW host command when it is used to
migrate from Variant-type LMKs to Key Block-type LMKs. Only the differences compared
to Variant LMK  Variant LMK migration are described.
Full details on the use of the BW host command can be found in the payShield 9000 Host

Length &
Field Type Notes
Message Header mA (As for Variant LMK  Variant LMK)
Key Type code 2H (As for Variant LMK  Variant LMK)
Key length flag 1N (As for Variant LMK  Variant LMK)
Key 16/32 H (As for Variant LMK  Variant LMK)

or
1A+
32/48 H
Delimiter 1A (As for Variant LMK  Variant LMK)
Key Type 3H (As for Variant LMK  Variant LMK)
Reserved 1A (As for Variant LMK  Variant LMK)
Key Scheme 1A (As for Variant LMK  Variant LMK)

(LMK)
Reserved 1A (As for Variant LMK  Variant LMK)
LMK Identifier 2N (As for Variant LMK  Variant LMK)
Delimiter 1A Must have value ‘#’
Key Usage 2A The required key usage for the key encrypted under
the Key Bock LMK. This information is included in the
Key Block header and should be determined using the
Key Usage Table in Chapter 5 of the payShield 9000
General Information Manual. This field determines
type of the operational key (e.g. RSA private key,
BDK, ZEK), and enforces key separation.
Mode of Use 1A The required mode of use for the key encrypted under
the Key Bock LMK. This information is included in the
Key Block header, and should be determined using
the Mode of Use Table in Chapter 5 of the payShield
9000 General Information Manual. This field
determines how the operational key can be used (e.g.
encryption, decryption, MACing).
Key Version 2N A value from ‘00’ to ‘99’, for inclusion in the Key Block
Number header. Determined by the user. ‘00’ denotes that
key versioning is not in use for this key.

Length &
Field Type Notes
Exportability 1A The required exportability for the key encrypted

under the Key Bock LMK. This information is included
in the Key Block header, and should be determined
using the Exportability Table in Chapter 5 of the
payShield 9000 General Information Manual. This
field determines how the operational key can be
exported (e.g. no export allowed, may only be
exported as a Key Block).
Number of 2N A value from ‘00’ to ‘08’, identifying how many

Optional Blocks optional data blocks the user wants to add into the
Key Block Header. Optional data blocks are used to
identify parameters (such as key validity dates, key
status, algorithm). Optional header blocks are
described in Chapter 5 of the payShield 9000 General
Information Manual. For a value greater than 0, the
following three fields must be repeated for each
optional block.
Optional 2A The available Optional Block Identifiers (or

Block Types) are described in Chapter 5 of the
Identifier payShield 9000 General Information Manual.
Note that the value ‘PB’ may not be used.
Optional 2H The length in bytes of the optional block

Block (including the Identifier and Length). A value of
Length X’04’ indicates that the block contains only the
identifier and length, and so the next field would
not be present.
Optional NA The payload of the optional data block - see

Data Block Chapter 5 of the payShield 9000 General
Information Manual.
End Message 1C (As for Variant LMK  Variant LMK)

Delimiter
Message Trailer nA (As for Variant LMK  Variant LMK)

Length
Field & Type Notes
Message mA (As for Variant LMK  Variant LMK)

Header
Response 2A Has the value 'BX'. (As for Variant LMK  Variant
Code LMK)
Error code 2N (As for Variant LMK  Variant LMK)

Length
Field & Type Notes
Key 1A+ The operational key, encrypted under the new Key
nA Block LMK.
End Message 1C (As for Variant LMK  Variant LMK)

Delimiter
Message nA (As for Variant LMK  Variant LMK)

Trailer
Migrating keys between Key Block LMKs

Migration of operational keys between Key Block LMKs is supported in addition to the
Variant LMK  Variant LMK and Variant LMK  Key Block LMK migrations already
described. This section describes the BW host command when used for this purpose.
Note that it is not possible to migrate from:
 Key Block LMKs to Variant LMKs.

 AES Key Block LMKs to TDES Key Block LMKs.
The BW Host command

The table below indicates the structure of the BW host command when it is used to
migrate between Key Block-type LMKs. Only the differences compared to Variant LMK 
Key Block LMK migration are described.
Length &
Field Type Notes
Message Header mA (As for Variant LMK  Key Block LMK)
Key Type code 2H Must be set to ‘FF’.
Key length flag 1H Must be set to ‘F’.
Key 1A+nA The operational key to be translated, encrypted

under the old Key Block LMK.
Delimiter 1A Must have value ';'.
Key Type 3H Must be set to ‘FFF’.
Delimiter 1A (As for Variant LMK  Key Block LMK)
Reserved 1A (As for Variant LMK  Key Block LMK)
Key Scheme 1A (As for Variant LMK  Key Block LMK)

(LMK)
Reserved 1A (As for Variant LMK  Key Block LMK)

Length &
Field Type Notes
LMK Identifier 2N (As for Variant LMK  Key Block LMK)
Key Usage 2A (As for Variant LMK  Key Block LMK)
Mode of Use 1A (As for Variant LMK  Key Block LMK)
Key Version 2N (As for Variant LMK  Key Block LMK)

Number
Exportability 1A (As for Variant LMK  Key Block LMK)
Number of 2N (As for Variant LMK  Key Block LMK)

Optional Blocks
Optional 2A (As for Variant LMK  Key Block LMK)

Block
Identifier
Optional 2H (As for Variant LMK  Key Block LMK)

Block
Length
Optional NA (As for Variant LMK  Key Block LMK)

Data Block
End Message 1C (As for Variant LMK  Key Block LMK)

Delimiter
Message Trailer nA (As for Variant LMK  Key Block LMK)

Length
Field & Type Notes
Message mA (As for Variant LMK  Key Block LMK)

Header
Response 2A Has the value 'BX'. (As for Variant LMK  Key Block
Code LMK)
Error code 2N (As for Variant LMK  Key Block LMK)
Key 1A+ (As for Variant LMK  Key Block LMK)

nA

Length
Field & Type Notes
End Message 1C (As for Variant LMK  Key Block LMK)

Delimiter
Message nA (As for Variant LMK  Key Block LMK)

Trailer
Migrating keys from Variant to Key Block LMKs

This migration is not permitted because Variant LMKs are not as strong as key block
LMKs.
Migrating keys for PCI HSM compliance

When it is required to make a payShield 9000 compliant with the requirements of the PCI
PTS HSM security standard, it may be necessary to move some keys from Variant key
type 002 (LMK pair 14-15, Variant 0) to other key types.
Although this can be done as a separate operation, it can be achieved at the same time
as migrating between LMKs using the BW host command by entering ‘F2’ as the Key
Type Code, and the desired destination key type in the Key Type field: see the payShield
9000 Host Command Reference Manual for further details.
For an overview of the PCI HSM standard and its relevance to payShield 9000, see
Chapter 10 of the payShield 9000 General Information Manual.
Re-encrypting PINs
Where PINs have been stored encrypted under the old LMK (in LMK Live storage or LMK
Key Change storage) these will need to be re-encrypted using the new LMK (in LMK Key
Change storage or LMK Live storage). This can be done by using the BG host command.
A host application will be required that takes each PIN from the old PIN database, re-
encrypts it using the BG host command, and stores the re-encrypted PIN into the new
PIN database.
The BG Host Command.

The structure of the BG host command is given in the following table:
Length &
Field Type Notes
Command Code 2A Has the value 'BG'.
Account 12 N The 12 right-most digits of the account number,

Number excluding the check digit.

Length &
Field Type Notes
PIN L1 N The PIN encrypted under the old LMK, where L1 is

Or the old encrypted PIN length.
L1 H L1 N applies where PIN encryption algorithm A (Visa
method) is specified in the security settings, and L1 H
applies where PIN encryption algorithm B (Racal
method) is specified.

must be present.
HSM, this allows the required LMK to be selected.
Minimum value = '00'; maximum value is defined by
licence. This field must be present if the above
Delimiter (%) is present. If the field is not present,


The BH Response
The HSM will return the following BH response to the host’s BG command:
Length &
Field Type Notes
Message Header mA This is a play-back of the header provided in the BG

command.
Response Code 2A Has the value 'BH'.
Error code 2N Indicating the general outcome of the BG command:

'00' : No error

PIN L2 N The PIN encrypted under the new LMK, where L 2 is

Or the new encrypted PIN length.
L2 H L2 N applies where PIN encryption algorithm A (Visa
method) is specified in the security settings, and L2 H
applies where PIN encryption algorithm B (Racal
method) is specified.


Length &
Field Type Notes

the BW command.
Re-encrypting decimalization tables

For security, it is recommended that decimalization tables are encrypted. They are
encrypted under the LMK, and so will need to be re-encrypted when migrating to a new
LMK.
This is achieved by having a host application which takes each decimalization table from
the old decimalization table database and re-encrypting it under the new LMK using the
LO (where "O" is the alphabetic "O for Oscar") host command (not to be confused with
the LO console command discussed earlier!) and then storing it in a new decimalization
table database. The new LMK can be in either Key Change storage or Live storage.
The structure of the LO host command is as follows:
Length &
Field Type Notes
Command Code 2A Most have the value 'LO'.
Decimalization 16 H A decimalization table encrypted under the old LMK.

Table (old LMK)

must be present.
HSM, this allows the required LMK to be selected.
Minimum value = '00'; maximum value is defined by
licence. This field must be present if the above
Delimiter (%) is present. If the field is not present,


The payShield 9000 will return the following LP response to the host:

Length &
Field Type Notes
Message Header mA This is a play-back of the header provided in the LO

command.
Response Code 2A Has the value 'LP'.
Error code 2N Indicating the general outcome of the LO command:

'00' : No error

Decimalisation 16 H The decimalisation table encrypted under the new

Table (new LMK.
LMK)


the BW command.
Switching to the new LMK

Following the activities described above, the system is now in the following state:
 Old databases of operational keys, PINs, and decimalization tables, encrypted

under the old LMK, are still being used for production.
 New databases of operational keys, PINs, and decimalization tables, encrypted
under the new LMK are pending but not yet being used for production.
 One or more HSMs may have been taken out of service in order to re-encrypt the
operational keys, PINs, and decimalization tables.
 These would be HSMs that have the old (current) LMK (which is still being
used on other HSMs for production) loaded in Key Change Storage (e.g. by
using the LO console command), and the new LMK (not yet in use for
production work) in their Live storage.
 In this case there are other HSMs with the old LMK in their Live storage,
which are doing production work using keys, PINs, and decimalization
tables in the old versions of the databases.
 Production host applications are still using the old databases of operational keys,
PINs, and decimalization tables.
In order to start using the new LMK, the following changes must be synchronized:
 Host production applications start using the new databases of operational keys,
PINs, and decimalization tables.
 If the re-encryption of keys was done on an HSM with the new LMK in Live
storage, then this HSM is immediately ready to start processing transactions using
the new LMK. However, the new LMK needs to be loaded into LMK Live storage on
those HSMs that were processing transactions using the old LMK.

 On the other hand, if the re-encryption of keys was done on an HSM with the new
LMK in Key Change storage, then the new LMK needs to be loaded into LMK Live
storage on all the HSMs in the system.
A total interruption of service can be avoided by a gradual switchover from the old LMK
to the new - but in this case the host applications must know whether an HSM is using
the old or new LMK and must retrieve the key or data from the appropriate database.
The use of the Multiple LMK feature of the payShield 9000 offers additional options, and
is described in the following section.
Taking advantage of Multiple LMKs

The payShield 9000 supports multiple concurrent LMKs, as described in Chapter 9. The
base product allows the user to implement one Variant-type LMK and one Key Block-type
LMK, and optional licenses are available to provide up to 20 LMKs in any combination of
types.
The multiple LMK feature offers a number of valuable benefits, and provides additional
flexibility to simplify the process.
Here is an example of how the multiple LMK feature can be used where the old (still Live)
LMK is in LMK Key Change storage and the new (future) LMK is in LMK Live storage:
 let us take as a starting point a production system which has the live LMK at LMK
00.
 LMK 00 is set up as the default LMK. This means that it is the LMK that is used by
default in host commands where no LMK is identified: this provides backwards
compatibility to applications developed before the multiple LMK facility was
introduced.
 The future, new LMK is loaded as LMK 01 in LMK Live storage (see Loading the
new LMK).
 The existing, "old" LMK, which is LMK 00 and is being used for production, is also
loaded into LMK Key Change Storage for LMK 01 (see Loading the old LMK.)
 The BW, BG, and LO host commands can now be used to re-encrypt operational
keys, PINs, and decimalization tables from the old LMK (which is in Key Change
Storage, and also still in LMK 00 and therefore available for production) to the new
LMK, which is loaded as LMK 01. This is achieved by setting the LMK Identifier in
the host commands to a value of "01" : this must be preceded by a delimiter of
"%".
 When all of the operational keys, PINs, and decimalization tables have been re-
encrypted under the new LMK, the host application can start using the new key
database when one of the following actions have been taken:
 The new LMK is re-loaded on the payShield 9000 as LMK 00. Or
 Host commands sent to the payShield 9000 are amended to use LMK 01 by
either:
 Specifying the value "01" for the LMK identifier in host commands
(see the structure of commands in the payShield 9000 Host
Command Reference Manual). Or
 Directing commands to the relevant TCP port (see the section on
Multiple LMKs in Chapter 1 of the payShield 9000 Host Command
Reference Manual).
The benefit of this approach is that there is no need to take one or more HSMs out of
productive use while the LMK migration is being performed, and therefore the key
migration using the BW host command can be spread over as many HSMs as desired.

Multiple LMKs could also be used to avoid a "big bang" switchover from old to new LMKs:
with the old LMK in one Live storage slot and the new LMK in a second Live storage slot,
individual elements of the system can be moved to the new LMK one at a time.
Tidying up after migration to a new LMK

Deleting the Old LMK from Key Change Storage
The LMK in Key Change Storage should be deleted once it is no longer needed. There are
multiple ways of doing this.
Using the console

The LMK can be deleted from Key Change Storage using the DO (where O is the
alphabetic "O for Oscar") console command. The payShield 9000 must be in Secure
state.
The LMK is deleted using the button displayed against the LMK in payShield Manager’s
Operational / LMK Operations / Key Change Storage tab. This can only be done in Secure
state. See the payShield Manager User Guide for more detailed information.
Using a Host Command

The BS host command allows the host to erase the LMK in Key Change Storage. The
structure of the command is given in the following table:
Length &
Field Type Notes
Command Code 2A Must have the value 'BS'.

must be present.
HSM, this allows the host to select which Old LMK is
to be deleted. Minimum value = '00'; maximum
value is defined by licence. This field must be present
if the above Delimiter (%) is present. If the field is
not present, then the default LMK will be used.


The BT response has the following structure:

Length &
Field Type Notes
Message Header mA This is a play-back of the header provided in the BS

command.
Response Code 2A Has the value 'BT'.
Error code 2N Indicating the general outcome of the BS command:

'00' : No error



the BW command.
Deleting the New LMK

In the section Taking advantage of Multiple LMKs, one suggested approach requires the
new LMK to be unloaded from a temporary LMK Identifier or location (where it was
loaded to enable the migration of keys and data to take place) and loaded to the location
where it is required for production work.
The section Loading the new LMK explains how to load the LMK to the location it is
desired, but in addition the LMK should be deleted from its temporary location. This can
be done by using one of the following methods:
Console
LMK deletion is achieved using the DM console command. This command requires Secure
state and authorization - in a multiple authorize state environment, the activity to be
authorized is admin.console.
Note that the DM console command also deletes the relevant old key in Key Change
Storage, avoiding the need to do this separately.
The LMK is deleted using the button displayed against the LMK in payShield Manager’s
Operational / LMK Operations / Local Master Keys tab. This can only be done in Secure
state. See the payShield Manager User Guide for more detailed information.

Chapter 11 – TR-31 Key Blocks

In the payments environment, keys often have to be shared between two or more
parties, and these organizations may be using different Master File Keys (MFKs – the
generic term for master keys performing the functions of the payShield 9000 LMK)
and/or types of HSM. There is therefore a need to securely export the operational keys
from one system and import them into another.
The legacy way for implementing this is defined in the ANSI X9.17 standard. However, a
number of weaknesses have been identified in this method, and the standard has been
withdrawn. The ANSI standard X9.24 (Retail Financial Services Symmetric Key
Management Part 1: Using Symmetric Techniques) of 2009 places requirements on the
management of TDES keys which cannot be satisfied when using X9.17. The ANSI X9
Committee published Technical Report 31 (TR-31) on Interoperable Secure Key Exchange
Key Block Specification for Symmetric Algorithms in 2010 to describe a method for
secure key exchange which meets the needs of X9.24. This is based on the use of Key
Blocks, which TR-31 defines.
The Thales payShield 9000 supports the use of TR-31 Key Blocks. It also continues to
support the use of X9.17 because this method, although no longer meeting the needs of
standards, is still in widespread use.
This chapter describes TR-31 Key Blocks and their implementation in the Thales
payShield 9000.
Relationship between Thales Key Blocks and TR-31 Key

Blocks
See Chapter 8.
TR-31 Key Block Structure

A TR-31 key block is comprised of four elements:
Key Scheme Key Block Optional Encrypted

Authenticator
Tag ("R") Header Header Key Data (8 or 16 ASCII
(1 byte) (16 ASCII (ASCII characters, (variable length, characters)
characters) variable length) ASCII encoded)
a 16-byte (clear) Key Block Header, which defines the key usage (e.g. Visa PVV) and mode of use (e.g.
verification only), the algorithm with which the key is used (e.g. TDES) and the limitations on the
exportability of the key (e.g. no export permitted);
a (clear) Optional Header block, which can be used (for example) to define the key set identifier;
the Encrypted Key Data, which includes the actual key itself, encrypted under the "encryption variant"
of the wrapping key;
a Key Block Authenticator, calculated using the "authentication variant" of the wrapping key; the use of
the Authenticator prevents unauthorized modification of the Key Block.
Currently, the TR-31 standard only permits key encryption data using the DES or TDES
algorithms; the wrapping key must be a TDES key, but the key contained in the Key
Block may be a single, double or triple length key using any one of the accepted

algorithms. The standard has been designed to be sufficiently flexible so that other types
of key can be wrapped in a Key Block in the future.
Key Block Header

The Key Block Header governs how the key contained in the Key Block may be used.
Only specific field values for the Header are permitted for HSM commands. If a Key Block
with the "wrong" Header is submitted in a command message then the HSM will return
an error code. The structure of the Header is as follows:

0 Version ID value = "A"; current version
1-4 Key Block Length total length of Key Block (decimal)
5-6 Key Usage e.g. key encryption, data encryption
7 Algorithm e.g. DES, TDES
8 Mode of Use e.g. encrypt only
Key Version e.g. version of key in the Key Block or used to
9-10
Number indicate that the key is a key component
11 Exportability e.g. exportable under a trusted key
Number of number of Optional Header blocks

12-13
optional blocks (Decimal)
Reserved for
14-15 value = "00"
future use
The sections that follow define valid values for the fields described in the Key Block
Header.
Note: there are constant additions to the range of available values: the latest sets of
values can be found in the TR-31 report.
Key Block Length (Bytes 1-4)

Bytes 1-4 of the Header contain the length of the entire key block, namely Header,
Optional Header Blocks, encrypted Key Data and the Authenticator. The length of the
key block is calculated after encoding and is represented as 4 numeric (ASCII) digits.
For example, if the total key block length is 112 characters (bytes) then the value in byte
1 will be "0", the value in bytes 2 and 3 will be "1" and the value in byte 4 will be "2"
(i.e. X'30313132).

Key Usage (Bytes 5-6)

Bytes 5-6 of the Header define the primary usage of the key contained in the key block.
The following table defines the usage code, and how Thales key block usage codes are
converted to TR-31 codes.
Corresponding
Value Definition
Thales KB Key Usage
B0 Base Derivation Key (BDK) B0, 41, 42, 43
B1 DUKPT Initial Key (IKEY) B1
C0 Card Verification Key C0, 11, 12, 13
D0 Data Encryption Key (Generic) D0, 21, 22, 23
E0 EMV/Chip card Master Key: Application E0
Cryptogram (MKAC)
E1 EMV/Chip card Master Key: Secure Messaging E1
for Confidentiality (MKSMC)
E2 EMV/Chip card Master Key: Secure Messaging E2
for Integrity (MKSMI)
E3 EMV/Chip card Master Key: Data Authentication E3
Code (MKDAC)
E4 EMV/Chip card Master Key: Dynamic Numbers E4
(MKDN)
E5 EMV/Chip card Master Key: Card Personalisation E5
E6 EMV/chip card Master Key: Other E6, 31, 32
I0 Initialization Value I0
K0 Key Encryption / Wrapping Key (Generic) K0, 51, 52
M0 ISO 16609 MAC algorithm 1 (using 3-DES) M0
M1 ISO 9797-1 MAC algorithm 1 M1
P0 PIN Encryption Key (Generic) P0, 71, 72, 73
V0 PIN Verification Key (Generic) V0
V1 PIN Verification Key (IBM 3624 algorithm) V1
V2 PIN Verification Key (Visa PVV algorithm) V2
All-numeric
Reserved for Proprietary Use
values
Note: How Key Usage codes are converted when exporting from Thales Key Block format
to TR-31 key format are also shown in Appendix C.

Algorithm (Byte 7)
Byte 7 of the Header defines the cryptographic algorithm with which the key contained in
the key block will be used. The following values are defined, although only two of these
values are currently supported:
Value Hex Algorithm

A X'41 AES (Included for future reference)
D X'44 DES (included for backwards compatibility)
E X'45 Elliptic Curve (included for future reference)
H X'48 HMAC –SHA1 (included for future reference)
R X'52 RSA (included for future reference)
S X'53 DSA (included for future reference)
T X'54 Triple DES (TDES)
Numeric Values Reserved for Proprietary Use
Mode of Use (Byte 8)

Byte 8 of the Header defines the operation that the key contained in the key block can
perform.
Value Hex Definition

B X'42 Both Encrypt and Decrypt
C X'43 MAC Calculate (Generate or Verify)
D X'44 Decrypt Only
E X'45 Encrypt Only
G X'47 MAC Generate Only
N X'4E No special restrictions or not applicable
S X'53 Signature Only
V X'56 MAC Verify Only
X X'58 Key Derivation
Numeric values Reserved for Proprietary Use
Key Version Number (Bytes 9-10)

Bytes 9-10 of the Header define the version number of the key contained in the key
block or that the key is actually a key component. The following values will be
supported:
First Second Key value field meaning

Character Character
0 0 Key versioning is not used for this key.
The value carried in this Key Block is a
Any
c component of a key. Local rules dictate the
character
proper use of a component.
Any other combination The key version field indicates the version of
of characters the key carried in the Key Block.

Exportability (Byte 11)

Byte 11 of the TR-31 Key Block Header specifies the "exportability" of the key contained
in the Key Block. This defines the conditions under which the key contained in the Key
Block can be exported outside the cryptographic domain in which the key is found. A key
is defined to be trusted if it is in either Thales Key Block or TR-31 Key Block format. Any
other format key is said to be untrusted. The following values are supported:
Value Exportability
May only be exported in a trusted Key Block, provided the

E
wrapping key itself is trusted
N No export permitted
Sensitive; all other export possibilities are permitted,
S provided such export has been enabled via the payShield
9000 security settings
Numeric
Reserved for Proprietary Use
Values
"Sensitive" export includes, for example, the case when a key is exported in ANSI X9.17
format. This type of export is disabled by default in the payShield 9000 security settings
and must be specifically enabled (e.g. using the CS console command) if required.
When a key is exported in a TR-31 Key Block format, byte 11 in the exported Key Block
dictates how further export must be handled by the recipient of the Key Block. Hence, if
the received byte 11 has value "E" then further "trusted" export is permitted, but if byte
11 has value "N" then no further export will be permitted.
Such considerations must be taken into account when the key is initially generated. It is
possible to change the value of byte 11 from "E" or "S" to "N" (so that no further export
will be permitted), via an optional field at the end of an HSM key export command
message.
Number of Optional Blocks (Bytes 12-13)

The TR-31 Key Block format allows a key block to contain up to 99 Optional Header
Blocks which can be used to include additional (optional) data within the Key Block.
Optional Header Blocks are described below.
Bytes 12-13 of the Header specify the number of Optional Header Blocks in the key
block. A value of "00" (X'3030) indicates there are no optional blocks. A value of "12"
(X'3132) indicates that there are 12 optional blocks.
Example
As an example, a TR-31 Key Block Header of
A0072V2TG22N0000
indicates:
 a Key Block of 72 bytes,
 that the key contained in the Key Block may only be used with the Visa PVV
algorithm (the "V2" field),
 that it is a TDES key (the "T" field),
 that it may only be used for PVV generation ("G"),

 the key version number is "22",

 the key may not be exported (the "N" field), and
 there are no Optional Header blocks in the Key Block.
Optional Header
The Optional Header comprises a number of Optional Header blocks, each with the
structure:

0-1 Identifier Optional Header block identifier
Optional Header block length
2-3 Length
(hexadecimal)
4-n Data Optional Header block data
Currently, only three types of optional block have been defined in TR-31:
Optional
Header Block Usage
ID
Key set identifier; as defined in ANSI X9.24-2004 Part 1,
KS
Annex E
Key Block values; used to define the version of the set of
KV
Key Block field values
Padding block; to ensure that the overall length of the
PB Optional Header blocks is a multiple of the encryption
block length
Reserved for proprietary use. If proprietary identifiers are
Numeric used, it is the responsibility of the application owner to
Values ensure that all necessary devices support the proprietary
Optional Block identifiers that they will use.
Other types of optional blocks will be supported by the payShield 9000 as and when they
are specified.
Using TR-31 Key Blocks

TR-31 Key Blocks are relevant to HSM commands that are used for key import or key
export. Key Blocks themselves generally replace the existing X9.17 format encrypted
keys in the HSM command or response messages.
In some cases, additional fields are required at the end of the command message to
allow construction of the exported Key Block. Such fields are preceded by a special
delimiter, the "&" character.
The key scheme identifier "R" is used to indicate to the HSM that the Key field is a TR-31
Key Block.
Most of the HSM legacy commands will not be upgraded to support TR-31 Key Blocks
since there are more flexible versions of these commands available which will support
TR-31.

Licensing
Use of TR-31 Key Blocks on the payShield 9000 is enabled by applying optional license
HSM9-LIC006. (Note that no optional license is required to enable use of Thales Key
Blocks.)
Key Scheme Tags

The table below summarises the key scheme tags (or identifiers) relevant to key blocks
supported in payShield 9000 software:
Tag ID Key Scheme

R ANSI TR-31 Key Block format
S Thales Key Block format
VeriFone/GISKE Key Block
V
format
GISKE Key Block

The GISKE Key Block is an early version of the TR-31 Key Block and is supported by
some VeriFone terminals. The HSM’s host A8 command has been modified to support
export of terminal keys in the GISKE format. The command would be the same as for a
command structured for standard TR-31 but with the "R" key scheme tag replaced with
"V" to indicate that the exported key should be in GISKE Key Block format.

Chapter 12 – DES Key Support

DES Keys
The payShield 9000 HSM host commands support single-, double and triple-length DES
keys. The current command set is backward compatible with earlier versions. The
commands support extensions to enable the specification of key length and key
encryption scheme to use.
Key Usage
If the first character of the key is a hexadecimal character (0 – 9 or A - F) or "K" the
commands will operate as previously specified. In most circumstances the key is single-
length except for ZMKs when the ZMK length is configured for double-length or for
specific keys that are double-length by definition. This is the 16H or 32H length and
types referenced in the command structures in the payShield 9000 Host Command
Reference Manual.
To support double and triple-length keys throughout the command set key scheme tags
have been defined these enable an HSM to determine the key length and encryption
mechanism used for a key. The key scheme tag prefixes the key. This is the 1A+32H or
1A+48H length and types in the command structures.
Key Encryption Schemes

There are a number of key encryption schemes supported by an HSM:
ANSI X9.17 method

Each key of a double- or triple-length key is encrypted separately using the ECB mode of
encryption. This scheme is only available for import and export of keys and must be
enabled in the security settings (e.g. by using the CS (Configure Security) console
command).
The tags for this scheme are:
 X – Double-length DES keys.

 Y – Triple-length DES keys.
Variant method
The payShield 9000 HSM supports the Thales Variant scheme, for the encryption and
authentication of keys.
Information about the Variant key scheme can be found in Chapter 7.
Thales Key Block Method

The payShield 9000 HSM supports the Thales Key Block method, for the encryption and
The structure of the Thales Key Block and other related information can be found in
Chapter 8.
X9 TR-31 Method
Information on the TR-31 key encryption scheme is provided in Chapter 11.

GISKE Method
For full details of the Verifone/GISKE key encryption scheme, refer to the GISKE
specification [Reference 8].
Key Generate, Import and Export

All the key management commands have extensions to enable the specification of the
key scheme to use when encrypting a key. This also defines the key length to generate
within key generation commands. For import and export of keys the key schemes must
be consistent as far as length is concerned i.e. if a double-length key is input the key
scheme flag defining the output must also be for a double-length key.
The extension consists of a delimiter ";" and three single character option fields. If the
extension is used all fields must be provided. If the command does not use an option, "0"
or any valid value can be entered in that field. The option will be ignored during
processing.
The option fields are:

 Key scheme for encrypting the output key under ZMK.
 Key scheme for encrypting the output key under LMK.
 Key check value type.
The valid values for these options are:
Key under Z Thales Variant Method – for single-length keys

ZMK U Thales Variant Method – for double-length keys
T Thales Variant Method – for triple-length keys
X ANSI X9.17 Method – for double-length keys
Y ANSI X9.17 Method – for triple-length keys
R X9 TR-31 Key Block Method – for single-, double- or triple-
length keys
Key under V Verifone/GISKE Key Block Method – for double- or triple-
TMK length keys
Key under Z Thales Variant Method – for single-length keys
LMK U Thales Variant Method – for double-length keys
T Thales Variant Method – for triple-length keys
S Thales Key Block Method – for single-, double- or triple-
length keys
Key check 0 KCV is 16-hex digits (backwards compatible mode)
value (except for DW & DY where an 8-hex KCV is returned)
1 KCV is 6-hex digits

2 KCV length is defined in the specific command
Rejection of Weak, Semi-Weak, & Possibly Weak Keys

All HSM commands that generate keys ensure that the standard DES weak, semi-weak,
or possibly weak keys cannot be used. If the new key matches one of the listed weak,
semi-weak, or possibly weak keys it is rejected and the key generation process is
repeated.

DES Weak Keys

0101 0101 0101 0101
FEFE FEFE FEFE FEFE
1F1F 1F1F 0E0E 0E0E

E0E0 E0E0 F1F1 F1F1
DES Semi-Weak Keys

01FE 01FE 01FE 01FE
FE01 FE01 FE01 FE01
1FE0 1FE0 0EF1 0EF1

E01F E01F F10E F10E
01E0 01E0 01F1 01F1

E001 E001 F101 F101
1FFE 1FFE 0EFE 0EFE

FE1F FE1F FE0E FE0E
011F 011F 010E 010E

1F01 1F01 0E01 0E01
E0FE E0FE F1FE F1FE

FEE0 FEE0 FEF1 FEF1
DES Possibly Weak Keys

0101 1F1F 0101 0E0E
0101 E0E0 0101 F1F1
0101 FEFE 0101 FEFE
011F 1F01 010E 0E01
011F E0FE 010E F1FE
011F FEE0 010E FEF1
01E0 1FFE 01F1 0EFE
01E0 1FFE 01F1 F10E
01E0 E001 01F1 F101
01E0 FE1F 01F1 FE0E
01FE 1FE0 01FE 0EF1
01FE E01F 01FE F10E
01FE FE01 01FE FE01
1F01 011F 0E01 010E
1F01 E0FE 0E01 F1FE

1F01 FEE0 0E01 FEF1

1F1F 0101 0E0E 0101
1F1F E0E0 0E0E F1F1
1F1F FEFE 0E0E FEFE
1FE0 01FE 0EF1 01FE
1FE0 E01F 0EF1 F10E
1FE0 FE01 0EF1 FE01
1FFE 01E0 0EFE 01F1
1FFE E001 0EFE F001
1FFE FE1F 0EFE FE0E
E001 01E0 F101 01F1
E001 1FFE F101 0EFE
E001 FE1F F101 FE0E
E01F 01FE F10E 01FE
E01F 1FE0 F10E 0EF1
E01F FE01 F10E FE01
E0E0 0101 F1F1 0101
E0E0 1F1F F1F1 0E0E
E0E0 FEFE F1F1 FEFE
E0FE 011F F1FE 010E
E0FE 1F01 F1FE 0E01
E0FE FEE0 F1FE FEF1
FE01 01FE FE01 01FE
FE01 1FE0 FE01 0EF1
FE1F 01E0 FE0E 01F1
FE1F E001 FE0E F101
FE1F 1FFE FE0E 0EFE
FEE0 011F FEF1 010E
FEE0 1F01 FEF1 0E01
FEE0 E0FE FEF1 F1FE
FEFE 0101 FEFE 0101
FEFE 1F1F FEFE 0E0E
FEFE E0E0 FEFE F1F1

Chapter 13 – AES Key Support

Overview
AES Keys
AES is (like DES and TDES) a symmetric algorithm used to encrypt data, but provides
significantly higher encryption strength than DES/TDES. AES keys have lengths of 128,
192, or 256 bits. The comparative strengths of the algorithms are:
Algorithm Key Length Bits of

Security
DES 56-bit 56
TDES Double-length (112-bit) 80
TDES Triple-length (168-bit) 112
AES 128-bit 128
AES 192-bit 192
AES 256-bit 256
When an AES Key Block LMK is installed, the payShield 9000 will support the use of 128-
bit, 192-bit and 256-bit AES keys for key management, data encryption and data
authentication. AES keys are only supported when using the Thales Key Block scheme.
Note that the use of AES keys (and an AES Key Block LMK) requires the HSM to have the
AES license (HSM9-LIC007) installed.
Key Management Keys

The payShield 9000 supports the generation and use of two types of general purpose key
encryption keys: a Zone Master Key (ZMK) and a Terminal Master Key (TMK).
The ZMK and TMK may be 128-bit, 192-bit or 256-bit AES keys, and the subordinate
keys encrypted by the ZMK and TMK may be AES or DES keys.
The traditional DES-based ZMK and TMK are able to encrypt AES and DES subordinate
keys.
Data Authentication Keys

The payShield 9000supports the generation and use of two types of data authentication
keys: a Zone Authentication Key (ZAK) and a Terminal Authentication Key (TAK).
The ZAK and TAK may be 128-bit, 192-bit or 256-bit AES keys, and the supported
authentication methods are CBC-MAC and CMAC.
Data Encryption Keys

The payShield 9000supports the generation and use of four types of data encryption
keys: a Zone Encryption Key (ZEK), a Terminal Encryption Key (TEK), a Data Encryption
Key (DEK), and an encryption key derived from a DUKPT BDK.
The ZEK, TEK and DEK may be 128-bit, 192-bit or 256-bit AES Keys, and the supported
encryption modes are ECB, CBC, CFB8 and CFB64.

Key Encryption Schemes

There are a number of key encryption schemes supported by a payShield 9000, but only
one scheme supports the use of AES keys:
Thales Key Block Method

The payShield 9000 HSM supports the Thales Key Block method, for the encryption and
The structure of the Thales Key Block and other related information can be found in
Chapter 8.
Support for AES in the payShield 9000

Support for the AES algorithm in payShield 9000 includes:
 256-bit AES Key Block LMKs to protect AES working keys plus other keys (except
single DES) and data protected in the HSM by LMKs.
 Use of AES for ZMKs and TMKs.
 Use of AES working keys for data encryption and MACing.
 Support for 128-, 192-, and 256-bit AES keys.
 Export/import of AES working keys using Thales Key Blocks. (Note: the TR-31
standard does not currently support the AES algorithm.)
 Use of a Console or payShield Manager to manage AES keys and AES Key Block
LMKs.
The next section in this chapter gives information on implementing AES on existing
payShield 9000s. Later sections indicate how host commands, console commands, and
Local payShield Manager menu options support AES.
The following table shows the keys used in the payShield 9000, indicating which keys can
use AES.
Key
Variant Key
Block
Key Description AES* LMK Key Type
LMK Key
Typeø Code
Usage
Base Derivation Key (BDK) B0 009 BDK
Base Derivation Key (BDK) Type 2 41 609 BDK2
Card Verification Key C0 402 CVK
Card Verification Key (American Express CSC) 11 402 CSCK
Card Verification Key (Mastercard CVC) 12 402 CVK
Card Verification Key (Visa CVV) 13 402 CVK
CBC MAC (AES) Yes M5 n/a n/a
CMAC (AES) Yes M6 n/a n/a
Data Encryption Key Yes 21 00B DEK

Key
Variant Key
Block
LMK Key
Typeø Code
Usage
Data Encryption Key (Generic) Yes D0 00B, 00A, DEK,
30B ZEK,
TEK
Dynamic CVV Master Key 32 709 MK-

CVC3
EMV/Chip card Master Key: Application E0 109 MK-AC

Cryptogram
EMV/Chip card Master Key: Data E3 409 MK-

Authentication Code DAC
EMV/Chip card Master Key: Dynamic Numbers E4 509 MK-DN
EMV/Chip card Master Key: Secure Messaging E1 309 MK-

for Confidentiality SMC
EMV/Chip card Master Key: Secure Messaging E2 209 MK-

for Integrity SMI
HMAC key (using SHA-1) 61 10C HMAC
IPEK (DUKPT) B1 302 IPEK
ISO 16609 MAC algorithm 1 (using 3-DES) M0 003, 008 TAK,

ZAK
ISO 9797-1 MAC algorithm 1 M1 003, 008 TAK,

ZAK
ISO 9797-1 MAC algorithm 3 M3 003, 008 TAK,

ZAK
Key Encryption / Wrapping Key (Generic) Yes K0 002/ 80D, TMK,

000 ZMK
PIN Encryption Key (Generic) P0 002 / 70D PEK
PIN Verification Key (Generic) V0 002 PVK
PIN Verification Key (IBM 3624 algorithm) V1 002 PVK
PIN Verification Key (Visa PVV algorithm) V2 002 PVK
RSA Private Key 03 00C RSA-

SK

Key
Variant Key
Block
LMK Key
Typeø Code
Usage
RSA Public Key 02 00D RSA-
PK
Terminal Key Encryption Key Yes 51 002 / 80D TMK
Terminal PIN Encryption Key 71 002 / 70D TPK
Terminal/Data Encryption Key (TEK) Yes 23 30B TEK
Transaction Key Scheme Terminal Key 73 002 / 90D TKR

Register
Visa Cash Master Load Key (KML) 200 KML
WatchWord Key 01 006 WWK
Zone Key Encryption Key Yes 52 000 ZMK
Zone PIN Encryption Key 72 001 ZPK
Zone/Data Encryption Key Yes 22 00A ZEK
* Only available when using an AES Key Block LMK

Ø
Where 2 key types are given (e.g. 002/70D), the key type depends on the
security setting "Enforce key type 002 separation for PCI HSM compliance" - see
Chapter 10 in the payShield 9000 General Information Manual.
This table does not include keys used for AS2805 (optional license LIC003), OBKM
(optional license LIC004), and card issuing (optional licenses 011, 016, 018, 023). The
commands used in these licenses do not support key block LMKs and therefore cannot
use AES keys.
As and when updates to the standards published by bodies such as ANSI X9, ISO, and
EMVCo become available, the payShield 9000 software will be extended to support
additional AES key usages.
Support of AES requires optional license HSM9-LIC007 to be installed on the payShield
9000.
Implementing AES on an existing payShield 9000

Re-encrypting existing keys under an AES Key Block LMK
An AES Key Block LMK must be installed if it is required to use AES working keys: these
keys cannot be protected using a Variant or Key Block TDES LMK.
Even if there is no requirement to use AES working keys, users may wish to use AES Key
Block LMKs to protect TDES and other working keys because of the greater security
strength that the 256-bit AES Key Block LMK provides compared to a TDES LMK.
Where a payShield 9000 is equipped with an appropriate number of LMKs, it may not be
necessary to re-encrypt existing working keys under a new AES Key Block LMK: the
existing working keys could be left encrypted under the existing LMKs, with only new
working keys (including AES keys) being encrypted under a new AES Key Block LMK.

The multiple LMK approach may not be satisfactory, for example if:
 the payShield 9000 has an insufficient number of LMKs available,

 only one LMK can be used because the host applications have not been adapted to
make use of multiple LMKs,
 the AES Key Block LMK is being used to provide enhanced security for existing
working keys and data.
In this case, it will be necessary to re-encrypt existing working keys and data which are
still required from the old LMK they are currently encrypted under to the new AES LMK.
The process for such an LMK migration is described in Chapter 10. This process is based
on:
 multiple uses of the BW host command, which re-encrypts a working key from an
old LMK to a new LMK,
 multiple uses of the BG host command to re-encrypt PINs,
 multiple use of the LO host command to re-encrypt decimalization tables.
The chapter on LMK migration also outlines how to install the AES Key Block LMK.
Note that:
 Any type of working key (including key encryption keys, but excluding single-DES
keys) and any data that can be encrypted under a payShield 9000 LMK can be
encrypted using an AES Key Block LMK. The use of AES Key Block LMKs is not
limited to AES keys.
 AES keys cannot be encrypted under a TDES LMK (whether Variant or Key Block
type).
 Keys can be re-encrypted from any type of LMK to an AES Key Block LMK.
 Keys encrypted under an AES Key Block LMK can only be re-encrypted to another
AES Key Block LMK - they cannot be migrated to a TDES LMK of any type.
Creating AES working keys

Once an AES Key Block LMK has been installed, it is possible to create (i.e. generate or
import) AES working keys, encrypted under the AES Key Block LMK, for use with the
payShield 9000. It may also be necessary to export AES working keys.
This can be achieved with the key management facilities available using:
 Console commands - see the sub-section on AES Key Management in the section
on support for AES in console command.
 Host commands - see the sub-section on AES Key Management in the section on
support for AES in host commands.
Support for AES in host commands

Processing data using AES keys
The commands in this table allow AES working keys to be used to process data. These
commands also support the use of AES key block LMKs.
Host Command Summary of Changes Made
M0 Encrypt Data Block Support for AES encryption keys.
M2 Decrypt Data Block Support for AES encryption keys.

M4 Translate Data Block Support for Source/Destination AES

encryption keys.
M6 Generate MAC Choice of MAC Algorithm extended to

include:
‘5’ : CBC-MAC (AES only)

‘6’ : CMAC (AES only)
Choice of Padding Method extended to
include:
‘4’ : AES CMAC Padding.

Key can be a CMAC or CBC-MAC key.
M8 Verify MAC Choice of MAC Algorithm extended to

include:

Choice of Padding Method extended to
include:

Key can be a CMAC or CBC-MAC key.
MY Verify and Translate MAC Choice of Source/Destination MAC Algorithm

extended to include:

Choice of Source/Destination Padding
Method extended to include:

Source/Destination Key can be a CMAC or
CBC-MAC key.
AES Key Management

The following key management host commands can be used with AES working keys.
These commands also support AES key block LMKs.

A0 Generate a key Choice of Algorithm when using AES key

block LMKs extended to include:
‘A1’ – 128-bit AES key

Generated key can be encrypted under an
AES ZMK or TMK. AES keys can also be
encrypted using a TDES ZMK/TMK.
A2 Generate and Print a Component Choice of Algorithm when using AES key
block LMKs extended to include:

A4 Form a Key from Encrypted Allows an AES key to be formed from
Components components and encrypted under an AES
Key Block LMK.
A6 Import a Key Allows an AES key to be imported. Support

is provided for AES ZMKs, but the AES key
can also be encrypted using a TDES ZMK.
A8 Export a Key An AES key can be encrypted under a

ZMK/TMK. Support is provided for AES
ZMK/TMKs, but the AES key can also be
encrypted using a TDES ZMK/TMK.
BY Translate ZMK from ZMK to LMK The ZMK being translated can be an AES
encryption ZMK. And the encrypting ZMK can be an AES
key. The LMK that the ZMK is to be
translated to must, of course, be an AES
Key Block LMK.
BW Translate Keys from Old LMK to Supports AES keys & LMKs
New LMK and Migrate to New Key
Type
NE Generate and Print a Key as Split Choice of Algorithm when using AES key
Components block LMKs extended to include:

AES Key Block LMK support

The following host commands are able to accept keys and other data protected by AES
key block LMKs.
BA Encrypt a Clear PIN The output PIN can be encrypted using an

AES Key Block LMK.

BC Verify a Terminal PIN Using the The input PIN can be encrypted using an
Comparison Method AES Key Block LMK.
BE Verify an Interchange PIN Using The input PIN can be encrypted using an
the Comparison Method AES Key Block LMK.
BG Translate a PIN and PIN Length The input PIN can be encrypted under an
AES Key Block LMK.
BK Generate an IBM PIN Offset (of a Support is provided for decimalization tables
customer selected PIN) encrypted using AES Key Block LMKs.
(NOTE: AES PIN Block formats are not

defined, so the input PIN Block must be
DES- encrypted.)
BQ Translate PIN Algorithm PIN can be encrypted using an AES Key

Block LMK.
BS Erase the Key Change Storage Supports AES keys
BU Generate a Key Check Value Supports AES keys
CA Translate a PIN from TPK to ZPK Supports TDES TPK/ZPK encrypted under an
Encryption AES Key Block LMK
CC Translate a PIN from One ZPK to Supports TDES ZPK encrypted under an AES
Another Key Block LMK
CE Generate a Diebold PIN Offset The input PIN can be encrypted using an
AES Key Block LMK.
CG Verify a Terminal PIN Using the Supports TDES TPK encrypted under an AES
Diebold Method Key Block LMK
CI Translate a PIN from BDK to ZPK Supports TDES BDK/ZPK encrypted under an
Encryption (DUKPT) AES Key Block LMK
CK Verify a PIN Using the IBM Support is provided for decimalization tables
Method (DUKPT) encrypted using AES Key Block LMKs.
CM Verify a PIN Using the VISA PVV Supports TDES BDK/PVK encrypted under an
Method (DUKPT) AES Key Block LMK
CO Verify a PIN Using the Diebold Supports TDES BDK encrypted under an AES
Method (DUKPT) Key Block LMK
CQ Verify a PIN Using the Encrypted The encrypted data base PIN can be
PIN Method (DUKPT) encrypted using AES Key Block LMKs.
CS Modify Key Block Header Supports AES Key Block LMKs
CU Verify & Generate a VISA PVV (of Supports TDES TPK/ZPK/PVK encrypted
a customer selected PIN) under an AES Key Block LMK
CW Generate a Card Verification Supports TDES CVK encrypted under an AES

Code/Value Key Block LMK

CY Verify a Card Verification Supports TDES CVK encrypted under an AES

Code/Value Key Block LMK
DA Verify a Terminal PIN Using the Support is provided for decimalization tables
IBM Method encrypted using AES Key Block LMKs.
DC Verify a Terminal PIN Using the Supports TDES TPK/PVK encrypted under an
VISA Method AES Key Block LMK
DE Generate an IBM PIN Offset (of Support is provided for decimalization tables
an LMK encrypted PIN) encrypted using AES Key Block LMKs.
The input PIN can be encrypted using an

AES Key Block LMK.
DG Generate a VISA PIN Verification The input PIN can be encrypted using an
Value (of an LMK encrypted PIN) AES Key Block LMK.
DU Verify & Generate an IBM PIN Support is provided for decimalization tables
Offset (of customer selected new encrypted using AES Key Block LMKs.
PIN)
EA Verify an Interchange PIN Using Support is provided for decimalization tables

the IBM Method encrypted using AES Key Block LMKs.
EC Verify an Interchange PIN Using Supports TDES ZPK/PVK encrypted under an

the VISA Method AES Key Block LMK
EE Derive a PIN Using the IBM Support is provided for decimalization tables
Method encrypted using AES Key Block LMKs.
The generated PIN can be encrypted using

an AES Key Block LMK.
EG Verify an Interchange PIN Using Supports TDES ZPK encrypted under an AES
the Diebold Method Key Block LMK
EI Generate a Public/Private Key Output private key can encrypted under an

Pair AES Key Block LMK.
EK Load a Private Key Input private key can encrypted under an

AES Key Block LMK.
EM Translate a Private Key Input & Output private key can encrypted
under an AES Key Block LMK.
EO Import a Public Key MAC using AES Key Block LMK
EQ Validate a Public Key MAC using AES Key Block LMK
ES Validate a Certificate and Import The input private key can be encrypted
the Public Key using an AES Key Block LMK.
EU Translate a Public Key MAC using AES Key Block LMK
EW Generate an RSA Signature Input private key can encrypted under an

AES Key Block LMK.

EY Validate an RSA Signature MAC using AES Key Block LMK
FU Verify a Watchword Response Supports TDES WWK encrypted under an

AES Key Block LMK
FW Generate a VISA PIN Verification Supports TDES TPK/ZPK/PVK encrypted

Value (of a customer selected under an AES Key Block LMK
PIN)
G0 Translate a PIN from BDK to ZPK The input BDK and ZPK can be encrypted
Encryption (3 DES DUKPT) using an AES Key Block LMK.
GA Derive a PIN using the Diebold The generated PIN can be encrypted using
method an AES Key Block LMK.
GI Import Key under an RSA Public The imported private key can be encrypted
Key under an AES Key Block LMK.
The output TDES key can be encrypted

using an AES key block LMK.
GK Export Key under an RSA Public The input private, TDES, and HMAC keys can
Key be encrypted using an AES Key Block LMK.
GO Verify a PIN Using the IBM Support is provided for decimalization tables
Method (3 DES DUKPT) encrypted using AES Key Block LMKs.
GQ Verify a PIN Using the VISA PVV Supports TDES BDK/PVK encrypted under an
Method (3 DES DUKPT) AES Key Block LMK
GS Verify a PIN Using the Diebold Supports TDES BDK encrypted under an AES
Method (3 DES DUKPT) Key Block LMK
GU Verify a PIN Using the Encrypted The encrypted data base PIN can be
PIN Method (3 DES DUKPT) encrypted using AES Key Block LMKs.
GW Generate/Verify a MAC (3 DES Supports TDES BDK encrypted under an AES

DUKPT) Key Block LMK
JA Generate a Random PIN The generated PIN can be encrypted using

JC Translate a PIN from TPK to LMK The output PIN can be encrypted using an
Encryption AES Key Block LMK.
(NOTE: AES PIN Block formats are net

DES-encrypted.)
JE Translate a PIN from ZPK to LMK The output PIN can be encrypted using an

JG Translate a PIN from LMK to ZPK The input PIN can be encrypted using an
(NOTE: AES PIN Block formats are net

DES- encrypted.)
K0 Decrypt Encrypted Counters (EMV Input TDES MK-AC key can be encrypted
4.x) under AES Key Block LMK
K2 Verify Truncated Application Input TDES MK-AC key can be encrypted

Cryptogram (MasterCard CAP) under AES Key Block LMK
KQ ARQC Verification and/or ARPC Input TDES MK-AC key can be encrypted
Generation (EMV 3.1.1) under AES Key Block LMK
KS Data Authentication Code and Input TDES MK-DAC and MK-DN keys can be
Dynamic Number Verification encrypted under AES Key Block LMK
(EMV 3.1.1)
KU Generate Secure Message (EMV Input TDES MK-SMI, MK-SMC, TK, source
3.1.1) PEK, and MK-AC keys can be encrypted
under AES Key Block LMK
KY Generate Secure Message (EMV Input TDES MK-SMI, MK-SMC, TK, source
4.x) PEK, and MK-AC keys can be encrypted
under AES Key Block LMK
KW ARQC Verification and/or ARPC Input TDES MK-AC key can be encrypted
Generation (EMV 4.x) under AES Key Block LMK
L0 Generate an HMAC Secret Key Output HMAC key can be encrypted under
AES Key Block LMK
LC Verify the Diebold Table in User The Diebold table can be encrypted using an
Storage AES Key Block LMK.
LK Generate a Decimal MAC Supports TDES TAK encrypted under an AES

Key Block LMK
LM Verify a Decimal MAC Supports TDES TAK encrypted under an AES

Key Block LMK
LO Translate Decimalization Table Support is provided for input/output

from Old to New LMK decimalization tables encrypted using AES.
LQ Generate an HMAC on a Block of Input HMAC key can be encrypted under

Data AES Key Block LMK
LS Verify an HMAC on a Block of Input HMAC key can be encrypted under

Data AES Key Block LMK
LU Import an HMAC key under a Supports TDES ZMK encrypted under an AES
ZMK Key Block LMK. The output HMAC key can be
encrypted under an AES Key Block LMK.

LW Export an HMAC key under a ZMK Supports TDES ZMK encrypted under an AES
Key Block LMK. The input HMAC key can be
encrypted under an AES Key Block LMK.
LY Translate a HMAC Key from Old The old and new LMKs can be AES Key Block
LMK to New LMK LMKs.
NG Decrypt an Encrypted PIN The input PIN can be encrypted using an

AES Key Block LMK.
OA Print a PIN Solicitation Mailer Reference number check value can use an
AES Key Block LMK
PE Print PIN/PIN and Solicitation The input PIN can be encrypted using an
Data AES Key Block LMK.
PG Verify PIN/PIN and Solicitation The input PIN can be encrypted using an
Mailer Cryptography AES Key Block LMK.
PM Verify a Dynamic CVV/CVC Supports TDES MK-DCVV encrypted under

an AES Key Block LMK
Q0 Translate Audit Record MAC key The old and new LMKs can be AES Key Block
LMKs.
QA Load Solicitation Data to User Reference number can be protected using an

Storage AES Key Block LMK
QC Final Load of Solicitation Data to Reference number can be protected using an

User Storage AES Key Block LMK
RA Cancel Authorized Activities Authorized activities for an AES Key Block

LMK can be cancelled.
RC Verify Solicitation Mailer Reference number check value can use an

Cryptography AES Key Block LMK
RI Transaction Request With a PIN The input Terminal Key Register can be
(T/AQ Key) encrypted using an AES Key Block LMK. The
output Response MAC Residue and TPK can
be encrypted using an AES Key Block LMK.
RK Transaction Request Without a The input Terminal Key Register can be

PIN encrypted using an AES Key Block LMK. The
output Response MAC Residue can be
encrypted using an AES Key Block LMK.
RM Administration Request Message The input Terminal Key Register can be

encrypted using an AES Key Block LMK. The
output Response MAC Residue can be
encrypted using an AES Key Block LMK.
RO Transaction Response with Auth The input Terminal Key Register, ZPK, and
Para from Card Issuer Request MAC Residue can be encrypted
using an AES Key Block LMK. The output
Response MAC Residue and Terminal Key
Register can be encrypted using an AES Key
Block LMK.

RQ Generate Auth Para and The input Terminal Key Register and
Transaction Response Request MAC Residue can be encrypted
using an AES Key Block LMK. The output
Response MAC Residue and Terminal Key
Register can be encrypted using an AES Key
Block LMK.
RS Confirmation The input Terminal Key Register and

Request MAC Residue can be encrypted
using an AES Key Block LMK.
RU Transaction Request With a PIN Support for output KEYVAL encrypted under
(T/CI Key) an AES Key Block LMK.
RW Translate KEYVAL Support for input KEYVAL encrypted under

RY (Mode 3) Calculate Card Security Support for input CSCK encrypted under an
Codes AES Key Block LMK.
RY (Mode 4) Verify Card Security Support for input CSCK encrypted under an
Codes AES Key Block LMK.
Support for AES in console commands

Managing the HSM
These console commands, used to manage the payShield 9000, take account of the AES
algorithm.
Console Command Summary of Changes Made
DT Diagnostic Test Tests the AES algorithm
VR View Software Revision Reports on availability of AES algorithm and

Number relevant NIST certifications.
AES Key Management

The following key management console commands can be used with AES working keys.
These commands also support AES key block LMKs.
CK Generate a Check Value Can generate a value for keys, including AES
keys, encrypted under an AES key block LMK.
EC Encrypt Clear Component Can encrypt an AES component. TDES

components may be, and AES components must
be, encrypted under an AES key block LMK.
FK Form Key from Components Can form an AES key from components. TDES
keys may be, and AES keys must be, encrypted
under an AES key block LMK.
GC Generate Key Component Can generate an AES key component. TDES

components may be, and AES components must

be, encrypted under an AES key block LMK.
GS Generate Key and Write Can generate AES keys/components. TDES keys
Components to Smartcard may be, and AES keys must be, encrypted under
an AES key block LMK.
IK Import Key Can import an AES key.
The ZMK used to encrypt TDES or AES keys to

be imported can be an AES key and/or can be
encrypted under an AES key block LMK.
Imported TDES keys may be, and imported AES

keys must be, encrypted under an AES key block
LMK.
KE Export Key Can export an AES key.
For the key to be exported, TDES keys may be,

and AES keys must be, encrypted under an AES
key block LMK.
The ZMK used to encrypt the exported keys can

be an AES key and/or can be encrypted under an
AES key block LMK.
KG Generate Key Can generate an AES key. TDES keys may be,
and AES keys must be, encrypted under an AES
key block LMK.

The following console commands are able to accept keys and other data protected by
AES key block LMKs.
A Enter the Authorized State / Can authorize for AES key block LMKs.
Authorize Activity
CO Create an Authorizing Officer Can copy cards containing AES key block LMK
Smartcard components.
CV Generate a Card Verification Can use a CVK encrypted under an AES key
Value block LMK.
DC Duplicate LMK Component Can copy cards holding AES key block LMK
Sets components.
DM Delete LMK Can delete AES key block LMKs.
DO Delete ‘Old’ LMK from Key Can delete AES key block LMKs.
Change Storage
ED Encrypt Decimalization Table Decimalisation tables can now be encrypted

under an AES key block LMK.

GK Generate LMK Component Can generate AES key block LMK components. A
single use of the command generates all the
required components.
LK Load LMK Can load AES key block LMKs.
LO Move ‘Old’ LMKs into Key Can work with AES key block LMKs. AES Key
Change Storage Block LMKs cannot be loaded as the old LMK
where the new LMK is TDES (either variant or
key block).
MI Generate a MAC on an IPB Can use an AES key block LMK.
PV Generate a VISA PVV Can use an AES key block LMK.
R Load the Diebold Table The table can be encrypted using an AES key
block LMK.
TD Translate Decimalization Decimalisation tables can be translated to

Table encryption under an AES key block LMK.
V Verify LMK Store Now works with AES key block LMKs
VC Verify the Contents of a Can verify cards holding AES key block LMK
Smartcard components.
VT View LMK Table Reports on AES key block LMKs
Support for AES in payShield Manager

Managing the HSM
These payShield Manager options, used to manage the payShield 9000, have been
modified to take account of the AES algorithm.
Menu Option Summary of Changes Made
Operational / Local master Can copy cards holding AES key block LMK
keys / Duplicate components.
Status / Tests the AES algorithm

Health Statistics/Diagnostics /
Diagnostics
Status / Software Info / Reports on availability of AES and relevant NIST

FIPS/Licensing certifications.

The following payShield Manager options are able to manage LMKs protected by AES key
block LMKs.

Menu Option Summary of Changes Made
Operational / LMK Operations Can verify status of an AES RLMK card

/ Local Master Keys / Verify
Operational / LMK Operations Can generate AES key block RLMK cards.
/ Local Master Keys /
Generate
Operational / LMK Operations Can copy AES key block RLMK cards.
/ Local Master Keys /
Duplicate
Operational / LMK Operations Can load AES key block LMKs.

/ Local Master Keys / Install
Operational / LMK Operations Can uninstall or replace AES key block LMKs.
/ Local master Keys /
Operational / LMK Operations Can install AES key block LMKs into Key Change
/ Key Block Storage / Install Storage. AES Key Block LMKs cannot be loaded as the
old LMK where the new LMK is TDES (either variant or
key block).
Operational / LMK Operations Can uninstall or replace AES key block LMKs in Key
/ Key Block Storage / Change Storage

Chapter 14 – PIN Block Formats

General
For PIN verification and PIN translation, the HSM requires the PIN to be input as an
encrypted 16-character PIN block. The plaintext data within the PIN block comprises the
PIN and some form of padding to ensure that this data is 16 characters. The padding
mechanism is known as the PIN block format. The HSM supports a number of PIN block
formats, each identified by a 2-digit PIN block format code. Formats 34, 35, 41 and 42
are used for EMV PIN change operations and are only available to the KU and KY
commands.
PCI HSM Compliance

In order to comply with the requirements of the PCI HSM Certification, there are
restrictions on the PIN Block format translations and usage which are allowed. These are
enforced by the payShield 9000 security setting "Restrict PIN block usage for PCI
compliance".
An overview of the needs of PCI HSM compliance relevant to the payShield 9000 is given
in Chapter 10 – PCI HSM Compliance of the payShield 9000 General Information Manual;
in that chapter, the section "Restrictions on PIN Block format translations and usage"
describing the PIN Block limitations.
Definitions of Thales PIN Block Formats

The following table lists the PIN Block formats supported by the standard base software,
together with their default state: each format is described below. Note that PIN Blocks
implemented as part of a custom software development will always be enabled.
Thales ISO Algorithm

Description Default
Format Format supported
01 0 ISO 9564-1 & ANSI X9.8 format 0 DES/3DES Enabled
02 - Docutel ATM format DES/3DES Disabled
03 - Diebold & IBM ATM format DES/3DES Disabled
04 - PLUS Network format DES/3DES Disabled
05 1 ISO 9564-1 format 1 DES/3DES Enabled
34 2 Standard EMV 1996 format DES/3DES Disabled
35 - MasterCard Pay Now & Pay Later format DES/3DES Enabled
41 - Visa/Amex new PIN only format DES/3DES Enabled
42 - Visa/Amex new & old PIN format DES/3DES Enabled
47 3 ISO 9564-1 & ANSI X9.8 format 3 DES/3DES Enabled
48 4 ISO 9564-1 format 4 AES Enabled

Format 01
Format 01 is the ISO 9564-1 Format 0, equivalent to the ANSI X9.8 Format 0 PIN Block,
and can only be encrypted using a DES/3DES key.
The format combines the customer PIN and account number as follows:
 A 16-digit block is made from the digit 0, the length of the PIN, the PIN, and a
pad character (hexadecimal F). For example, for the 5-digit PIN 92389, the block
is:
0592 389F FFFF FFFF
 Another 16-digit block is made from four zeros and the 12 right-most digits of the
account number, excluding the check digit. For example, for the 13-digit account
number 4000 0012 3456 2, where the check digit is 2, the block is:
0000 4000 0012 3456
 The two blocks are exclusive-OR added:
05 92 38 9F FF FF FF FF
00 00 40 00 00 12 34 56
PIN block: 05 92 78 9F FF ED CB A9
Format 02
Format 02 supports Docutel ATMs, and can only be encrypted using a DES/3DES key. A
PIN block is created from the PIN length, a 6-digit PIN, and a user-defined numeric
padding string.
If the PIN has fewer than 6 digits, it is left-justified and zero filled.
For example, for the 5-digit PIN 92389, the PIN digits are 923890.
With pad characters added, the PIN block could be, for example:
5923 8909 8765 4321
where: 98765 4321 is the padding string.
Format 03
Format 03 supports Diebold and IBM ATMs, and can only be encrypted using a DES/3DES
key. It also applies to the Docutel format that does not include a PIN length. The PIN
block is created from the customer PIN and the hexadecimal F padding character. For
example, for the 5-digit PIN 92389, the PIN block is:
9238 9FFF FFFF FFFF
Format 04
Format 04 is the PIN block format adopted by the PLUS network, and can only be
encrypted using a DES/3DES key. The format combines the customer PIN and the related
account number as follows:
 A 16-digit block is made from the digit 0, the length of the PIN, the PIN, and a
pad character (hexadecimal F). For example, for the 5-digit PIN 92389, the block
is:

0592 389F FFFF FFFF
 Another 16-digit block is made from four zeros and the left-most 12 digits of the
account number. For example, for the 16-digit account number 2283 4000 0012
3456, where the check digit is 6, the block is:
0000 2283 4000 0012
The two blocks are exclusive-OR added:
0592 389F FFFF FFFF
0000 2283 4000 0012
PIN block: 0592 1A1C BFFF FFED
Notes: Any transaction that requires a PIN block as a parameter accepts Format
04. The major impact of this format is on the account number field
length: when a PIN block is formatted according to Format 04, the
account number field becomes 18 digits in length.
For the PIN translation CA and CC commands, there are two format fields;
if either is 04, the account number field must be 18 digits. If the account
number is less than 18 digits, it must be right-justified and padded with
X'F on the left.
The following commands can use this format:

BC, BE, CA, CC, CG, DA, DC, EA, EC, EG, G0, JC, JE, BK, FW, CU, DU, JG, KU, KY, GO,
GQ, GS, GU and CI.
When reviewing the details for these commands, consider the change to the account field
that this format requires.
Format 05
Format 05 is the ISO 9564-1 Format 1 PIN Block, and can only be encrypted using a
DES/3DES key.
The PIN block is represented by the following 16 hexadecimal values:

1NPP..P R . . R
Where:
N is the PIN length (4 - C),
PP..P is the N-digit PIN,

R . . R is random padding.
The following validity checks are carried out on incoming Format 05 PIN blocks:
 The first character of the PIN block has value 1.

Error Code 20 is returned if this check fails.
 The PIN digits (in positions 3 - (N+2)) are in the range 0 to 9.
 The second character (N) is in the hexadecimal range 4 - C.

Format 34
Format 34 is the ISO 9564-1 Format 2 PIN Block (the standard EMV PIN block format),
and can only be encrypted using a DES/3DES key. It is only available as an Output from
EMV PIN change commands (KU and KY).
The PIN block is created from a fixed Control Field, the length of the PIN, the customer
PIN itself and the hexadecimal F padding character. PINs from 4 to 12 digits in length are
accommodated.
The 16-digit (8 byte) block is constructed as follows:
C N P P P P P/F P/F P/F P/F P/F P/F P/F P/F F F
Where:
C is a fixed control field of binary value 0010 (X'2).
N is the length of the PIN and can be any binary value from 0100 to
1100 (X'4 to X'C).
P is a digit of the PIN and can be any binary value from 0000 to 1001
(X'0 to X'9).
P/F is either a PIN digit or the binary value 1111 (X'F) filler depending
on the length of the PIN.
F is a filler of binary value 1111 (X'F).
Thus for a 5 digit PIN of 34567, the PIN block would hold the 16 hexadecimal values as
shown below:
2 5 3 4 5 6 7 F F F F F F F F F
Format 35
PIN Block format 35 is the PIN Block required by Europay/MasterCard for their Pay Now
& Pay Later products, and can only be encrypted using a DES/3DES key.
The PIN block is created from a fixed Control Field, the length of the PIN, the customer
PIN itself and the customer account number. PINs from 4 to 12 digits in length are
accommodated.
A 16-digit (8 byte) block is constructed as follows:
Where:
N is the length of the PIN and can be any binary value from 0100 to
1100 (X'4 to X'C).
P is a digit of the PIN and can be any binary value from 0000 to 1001
(X'0 to X'9).

Thus for a 5 digit PIN of 34567, the block would hold the 16 hexadecimal values as
shown below:
2 5 3 4 5 6 7 F F F F F F F F F
Another 16-digit block is made from four zeros and the 12 right-most digits of the
account number, excluding the check digit.
For account number 1234 0000 0123 4562 where 2 is the check digit, the block is:
0 0 0 0 4 0 0 0 0 0 1 2 3 4 5 6
The two blocks are exclusive-ORed on a bit by bit basis:
2 5 3 4 5 6 7 F F F F F F F F F
0 0 0 0 4 0 0 0 0 0 1 2 3 4 5 6
2 5 3 4 1 6 7 F F F E D C B A 9
Format 41
PIN Block Format 41 is the Visa format for PIN change without using the current PIN. The
method for constructing the PIN block is defined in section C.11.2 of reference 9, and can
only be encrypted using a DES/3DES key.
The PIN Block is created using the new PIN and part of the card's unique DEA Key as
follows:
 Construct a 16 hexadecimal digit block of data, by extracting the eight rightmost

digits of the card application's Unique DEA Key A (UDK-A)1 and zero filling it on
the left with eight hexadecimal zeros:
0 0 0 0 0 0 0 0
8 Rightmost digits of card app's unique DEA key A
 Create a second 16 hexadecimal digit block of data as follows:
Where:
N is the length of the new PIN and can be any binary value from 0100
to 1100 (X'4 to X'C).
P is a digit of the new PIN and can be any binary value from 0000 to
1001 (X'0 to X'9).
1
The Thales HSM terminology for the UDK is DK-AC. This is the card-unique key that is
derived from MK-AC, the Master Key for Application Cryptograms.

 Perform an exclusive-OR operation on the blocks of data created in steps 1 and 2

to create the final PIN block.
Format 42
PIN Block Format 42 is the Visa format for PIN change using the current (old) PIN. The
method for constructing the PIN block is defined in section C.11.1 of reference 9, and can
only be encrypted using a DES/3DES key.
The PIN Block is created using the old PIN, the new PIN and part of the card's unique
DEA Key as follows:
 Construct a 16 hexadecimal digit block of data, by extracting the eight rightmost

digits of the card application's Unique DEA Key A (UDK-A)2 and zero filling it on
the left with eight hexadecimal zeros:
0 0 0 0 0 0 0 0
8 Rightmost digits of card app's unique DEA key A
 Create a second 16 hexadecimal digit block of data as follows:
Where:
N is the length of the new PIN and can be any binary value from 0100
to 1100 (X'4 to X'C).
P is a digit of the new PIN and can be any binary value from 0000 to
1001 (X'0 to X'9).
 Create a third 16 decimal digit block of data using the old PIN as follows:
P P P P P P/0 P/0 P/0 P/0 P/0 P/0 P/0 0 0 0 0
Where:
P is a digit of the old PIN and can be any binary value from 0000 to
1001 (X'0 to X'9).
P/0 is either a PIN digit or the binary value 0000 (X'0) filler depending
0 is a filler of binary value 0000 (X'0).
 Perform an exclusive-OR operation on the blocks of data created in steps 1, 2 and

3. The result is called the "Delta PIN".
2
The Thales HSM terminology for the UDK is *DK-AC. This is the card-unique key that is
derived from *MK-AC, the Master Key for Application Cryptograms..

Format 47
PIN Block Format 47 is the ISO 9564-1 Format 3 PIN Block, and can only be encrypted
using a DES/3DES key.
This PIN block is constructed by modulo-2 addition of two 64-bit fields: the plain text PIN
field and the account number field.
The plain text PIN field is formatted as follows:
Where
C = Control field - Binary 0011 (X'3).
N = PIN length - 4-bit binary number with permissible values of 0100 (X'4)
to 1100 (X'C).
P = PIN digit - 4-bit field with permissible values of 0000 (X'0) to 1001
(X'9).
P/F = PIN/Fill digit - Designation of these fields is determined by the PIN

length field.
F = Fill digit - 4-bit field, with values from 1010 (X'A) to 1111 (X'F), where
the fill-digit values are randomly or sequentially selected from this set of
six possible values, such that it is highly unlikely that the identical
configuration of fill digits will be used more than once with the same
account number field by the same PIN encipherment device.
The account number field is formatted as follows:
0 0 0 0 A1 A2 A3 A4 A5 A6 A7 A8 A9 A10 A11 A12
Where:
0 = Pad digit - A 4-bit field; the only permissible value is 0000 (0).
A1 ... A12 = Account Number - Content is the 12 right-most digits of the

primary account number (PAN) excluding the check digit. A12 is the digit
immediately preceding the PAN's check digit. If the PAN excluding the
check digit is less than 12 digits, the digits are right justified and padded
to the left with zeros. Permissible values are 0000 (0) to 1001 (9).

Format 48
PIN Block Format 48 is the ISO 9564-1 Format 4 PIN Block, and can only be used with an
AES key.
The PIN block is constructed using two 128-bit blocks: the first containing the plaintext
PIN, and the second containing the plaintext account number.
The plaintext PIN field is formatted as follows:
C N P P P P P/ P/ P/ P/ P/ P/ P/ P/ F F R R R R R R R R R R R R R R R R
F F F F F F F F
Where
C = Control field – 4-bit field value 0100 (decimal 4).
N = PIN length – 4-bit binary number with permissible values of 0100 (4) to
1100 (12).
P = PIN digit – 4-bit field with permissible values of 0000 (0) to 1001 (9).
P/F = PIN/Fill digit – designation of these fields is determined by the PIN length
field.
F = Fill digit - 4-bit field, with values from 1010 (10)
R = Random digit - 4-bit field, with values from 0000 (0) to 1111 (15)
The plaintext PAN field is formatted as follows:
M A A A A A A A A A A A A A/ A/ A/ A/ A/ A/ A/ 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0
Where
M = PAN length – 4-bit field with permissible values 0000 (0) to 0111 (7), which
when added to 7, indicates the PAN length. If the PAN is less than 12 digits, the
digits right justified and padded to the left with zeros, and M is set to 0.
A = PAN digit – 4-bit field with permissible values 0000 (0) to 1001 (9)
0 = Pad digit – 4-bit field with only permissible value 0000 (0)
A/0 = PAN/Pad digit – designation of these fields is determined by the PAN
length field.

To produce an encrypted PIN block in this format, using an AES PIN encryption key, K:
1. Format the PIN into the plaintext PIN field as shown above.
2. Format the PAN into the plaintext PAN field as shown above.
3. Encrypt the plaintext PIN field (from step 1) using the key, K.
4. XOR the plaintext PAN field (from step 2) with the result of step 3.
5. Encrypt the result of step 4 using the key, K.
To decrypt an encrypted PIN block in this format, using an AES PIN encryption key, K:
1. Format the PAN into the plaintext PAN field as shown above.
2. Decrypt the encrypted PIN block using the key, K.
3. XOR the plaintext PAN field (from step 1) with the result of step 2.
4. Decrypt the result of step 3 using the key, K.
5. Extract the PIN from the result of step 4.

Chapter 15 – User Storage

Introduction
The most common way of storing and managing keys and other sensitive data is on the
host system, outside of the payShield 9000. In this scenario, the data is protected by
being encrypted using the HSM's Local Master Key (LMK), the volume of stored data and
its retrieval mechanism is limited only by the host system's capacity and functional
capabilities (such as database systems), and the keys do not need to be replicated to
multiple locations. The data can be backed up and replicated as desired – e.g. to create
Disaster Recovery datacentres.
In addition, keys and other data can also be stored in the User Storage area inside the
payShield 9000 itself. This method does not provide the capacity or flexibility that is
experienced when storing at the host, but ensures that the data is protected by the
HSM's security.
Performance
The use of keys and key blocks held in user storage will enhance the throughput of
payShield 9000s using asynchronous host communications. With this communications
method, the throughput of the payShield 9000 is limited by the time taken to transmit
the command and response: with the fastest payShield 9000, the throughput is almost
entirely determined by the speed of the connection and the time taken to transmit the
command and response. Because the use of user storage reduces the size of the host
command and therefore the time taken to transmit it to the HSM, the throughput will be
increased.
Performance is unaffected when using high-speed communications interfaces such as

Ethernet or FICON.
The User Storage Area

The User Storage can be used to store any data, not just LMK-encrypted keys. This can
be any data that the user wants to protect, and the following data types that are used by
the payShield 9000:
 PIN Solicitation data.

 PIN Blocks.
 The Diebold table.
 Decimalization tables.
The user storage area has a capacity of 98,304 Bytes. It can hold up to 4,096 blocks of
data:
 Each block is identified by an index, with values ranging from "000" to "FFF" in
hexadecimal characters (equivalent to 0 to 4,095 in decimal).
 Blocks have either:
 a fixed size (of 16, 32, or 48 hexadecimal characters - corresponding to
the size of single-, double-, and triple-length TDES keys), or
 variable size
depending on the block size setting.
 Blocks can contain any information that the user desires.

The user storage area is in tamper-protected volatile memory, and so the stored data will
be lost on events such as a tamper, a power cycle, use of the Restart button, or use of
the RESET console command.
Defining the Block Size

The block size is set using the CS console command or using payShield Manager under
Configuration / Security Settings / General.
Using the CS console command for an example, the relevant prompt is:
User storage key length [S/D/T/V](SINGLE):
Valid entries are S, D, T, or V (or, in fact, any string beginning with these characters)
representing the following block sizes:
S = Fixed Block Size for Single-length keys, i.e. block size of 16 hexadecimal
characters (8 Bytes)
D = Fixed Block Size for Double-length keys, i.e. block size of 32 hexadecimal
T = Fixed Block Size for Triple-length keys, i.e. block size of 48 hexadecimal
V = Variable Block Size
The Variable block size capability was added in payShield 9000 v2.3a. It provides more
flexibility than the S/D/T options, and operates differently. In the notes below, the
operation of User Storage when the block size is selected to be Single/Double/Triple-
length is described first. The operation of User Storage when Variable Block Size is
selected is described later.
User Storage when using Fixed Block Sizes

Loading Data into User Storage with fixed block sizes
Data is loaded into User Storage using the LA host command. This command includes the
following fields:
 Index Address (3H - Valid range "000" to "FFF") - the index pointing to the
location where the first data block is to be written.
 Block Count (2H - Valid range "00" to "20") - the number of data blocks which are
included in the command. Up to 32 data blocks can be included with the
command. The sum of [(Index Address) + (Block Count-1)] must not exceed FFF
(4,095 decimal).
 Data Blocks - a number of blocks of data to be stored. Data must be entered as
ASCII-encoded hexadecimal characters (e.g. the byte with a binary value
00111101, hexadecimal 3D, would be entered as the two characters "3" and "D"
and stored as 2 bytes.) The number of blocks must correspond to the value of
the Block Count field. The size of the data block must correspond to the length set
using CS or payShield Manager Configuration / Security Settings / General: if the
data has a shorter length than this, the block should be padded with hexadecimal
F characters.
Keys shorter than the specified block size can be stored by padding the key to the
specified block size with hexadecimal F characters.
An example of the use of the LA command is provided in the document payShield 9000
Host Command Examples.

Reading Data from User Storage with fixed block sizes

Data can be read from user storage using the LE host command. The command specifies:
 Index Address (3H) - the index pointing to the location where the first data block
is to be read from. (Valid range is "000" to "FFF".)
 Block Count (2H) - the number of data blocks which are to be retrieved. Up to 32
data blocks can be requested. (Valid range is "00" to "20".) The sum of [(Index
Address) + (Block Count-1)] must not exceed FFF (4,095 decimal).
An example of the use of the LE command is provided in the document payShield 9000
Host Command Examples.
Storing and accessing Symmetric Keys in User Storage with fixed

block sizes (Variant LMK)
The host system will receive Variant LMK-encrypted TDES keys from the payShield 9000
when, for example, the HSM is used to generate keys (A0 host command) or import a
key (A6 host command). Typically the LMK-encrypted keys are stored in the host
system's key database, but optionally the host system, can store the LMK-encrypted key
inside the payShield 9000 user storage, by using the method outlined above. The stored
key in this case does not include the alphabetic key scheme indicator (e.g. "U" for
double-length Triple DES, "T" for Triple-length Triple DES).
There are two ways that LMK-encrypted keys can be retrieved from user storage by the
host system. Firstly, the data can be read by the host system using the LE host
command, as outlined above, and then inserting the returned key into a host command
which is then sent to the payShield 9000.
Alternatively, host commands can point to an LMK-encrypted key held in user storage,
avoiding the need to first retrieve the encrypted key from the payShield 9000. In order
to do this, the field in the host command which would normally provide the LMK-
encrypted key would instead include a key reference consisting of:
 The key scheme - e.g. [null] for single-length DES, "U" for double-length Triple
DES, "T" for Triple-length Triple DES.
 "K" to indicate that what follows is an index to user storage.
 The 3-hex character index to the LMK-encrypted key in user storage.
For example:
LMK-encrypted key Type Index Key in host command Key reference in

in User if key provided by host command if
Storage host key stored in user
storage
9A73BC83A90012BD Single 3A8 9A73BC83A90012BD K3A8
DES
23A7BB616A198EFF Double B17 U23A7BB616A198EFF UKB17
1298FAE25D3A4BF5 TDES 1298FAE25D3A4BF5
18A7DE43129C2CD6 Triple 179 T18A7DE43129C2CD6 TK179
BBA965823F5A78A9 TDES BBA965823F5A78A9
9987AA4F5890B0C3 9987AA4F5890B0C3
Examples of the CA host command which include the key in the command and which use
a key reference can be found in the document payShield 9000 Host Command Examples.

Note that it is possible to store and recover keys of a length inconsistent with the Block
Size. This is useful, for example, if it is necessary to store keys of different lengths.
 If the Block Size is set to Single (i.e. 16 hex characters), user storage can still be
used to store double and triple-length keys. In this case, 2 blocks must be
allocated for a double-length key, and three blocks for a triple-length key. When
inserting a key reference in a command (e.g. "UKB17"), the appropriate number
of blocks will be retrieved. Working in this way reduces the number of keys that
can be stored because more than one index address is required for a key - for
example, if only double-length keys were being used, then only 2,048 keys could
be stored.
 As an example, if the double-length encrypted key
92385025801691228682054947200919 was to be stored at index 0FE,
then the example of the LA host command entitled "LA Command - Load
Data to User Storage (double-length TDES key encrypted under a variant
LMK)" in the document payShield 9000 Host Command Examples could be
used.
 If the Block Size is set to Triple (i.e. 48 hex characters), for example, single- or
double-length keys can still be stored. However, the shorter keys must be padded
with hexadecimal F characters to bring them up to the Triple Block size.
User storage and Key Block LMKs with fixed block sizes
When using Key Block LMKs, the LMK-encrypted key can be written to user storage using
the LA host command. The host system can later read the key back from user storage
using the LE host command and insert the it (with the preceding key scheme indicator of
"S") into another host command sent to the payShield 9000.
Note that the key block must be expanded to hex encoding. For example, the following
key block:
0007271TN00S0002B7CC796C2A4909FF12174898C4286E5AE2E8230E89284ED715D1D7F0
should be written to user storage as:

30303037323731544E303053303030324237434337393643324134393039464631323137343
839384334323836453541453245383233304538393238344544373135443144374630
plus any required "F" padding. If the User Storage Block Size has been defined as Double
(32 hexadecimal characters) then this key would be written as the following 5 blocks:
30303037323731544E30305330303032
42374343373936433241343930394646
31323137343839384334323836453541
45324538323330453839323834454437
3135443144374630FFFFFFFFFFFFFFFF
The facility to use key references in commands (e.g. "SK123") is not available when
using key block LMKs.
Storing general data with fixed block sizes

As has been mentioned, any hexadecimal character string can be written to User Storage
and subsequently retrieved.
For example, let's say we wanted to store the following information into User Storage:
Mary had a little lamb,

Its fleece was white as snow.
This would have to be converted to a hexadecimal string:

4D617279206861642061206C6974746C65206C616D622C0D0A49747320666C6565636
52077617320776869746520617320736E6F772E
If the User Storage Block Size has been set to Double (i.e. 32 Hexadecimal characters)
this input would have to be written to User Storage as four 32-character blocks, padded
with Hexadecimal F:
4D617279206861642061206C6974746C
65206C616D622C0D0A49747320666C65
65636520776173207768697465206173
20736E6F772EFFFFFFFFFFFFFFFFFFFF
PIN Solicitation Data with fixed block sizes

When a card issuer has solicited a desired PIN from the cardholder, the cleartext PIN
provided by the cardholder must be encrypted and passed, together with the PAN, to the
card issuer system. In order to ensure that the cleartext PAN and cleartext PIN do not
exist together on the host system, a reference number is substituted for the PAN. A
process is required to convert the reference number + cleartext PIN into a PAN +
encrypted PIN. To do this, the reference number and PIN are loaded into user storage
using the QA and QC commands.
Up to 1,260 records can be loaded using the QC command, and multiple preceding QA
commands (each containing up to 25 records) can be used to load a total of 2,520
records. The user cannot define where this data is to be written in the user storage area.
The PIN solicitation data overwrites existing data in user storage. Therefore any user
storage data must be reloaded after PIN Solicitation has been performed.
The PIN solicitation process is described in Chapter 3.
PIN Blocks with fixed block sizes

If the user storage area has been used to store PIN Blocks, host commands requiring
input of a PIN Block can directly access the PIN Block held in user storage. This is
achieved by replacing the input PIN Block in the command with the ["K" + index]
structure described earlier for referencing keys held in user storage.
Diebold Table with fixed block sizes

If a Diebold Table is loaded in the payShield 9000, it is loaded into user storage using the
R console command. The table consists of 32 contiguous blocks of 16 hexadecimal
characters each. Each LMK has its own Diebold table.
When using the R console command, the user must enter the Index Address for the start
of the table. This can have any value from "000" to "FE0" (to ensure that the 32nd block
is within the index limit of FFF).
The Diebold Table shares the same storage blocks as other data in user storage, and so
the user must ensure that the 32 blocks allocated to the Diebold table are not being used
to store any other data.
The Diebold Table stored in the HSM is encrypted using the LMK. For variant LMKs, this
will use LMK pair 14-15 variant 0 or LMK pair 36-37 variant 6, depending on the security
settings relating to PCI HSM compliance.
The Diebold Table in user storage can be verified using the LC host command.

Decimalization Tables with fixed block sizes

Plaintext and Variant LMK-encrypted decimalization tables can be loaded into storage as
blocks of 16 hexadecimal characters in the same way as TDES keys or other data.
Where the decimalization table is required in host commands (such as BK, DE, EE, GO),
it can be referenced in the command using the same ["K" + index] structure described
earlier for symmetric keys.
Storing a mix of data types with fixed block sizes

As an example, let's say we have set User Storage Block Size to Double (i.e. 32
Hexadecimal characters) and we want to store:
 The key block example in the section on User Storage and Key Block LMKs, at
index decimal 123 (hexadecimal 07B);
 The single-length variant-LMK encoded key 9A73BC83A90012BD, at the next
available index – which would be 128 (hexadecimal 080);
 The example data in the section on Storing general data, at the next available
index – which would be 129 (hexadecimal 081).
This could be done using a single LA host command, where:
 Index address = "07B"

 Block Count = "0A" (i.e. decimal 10)
 The following 10 data blocks are provided:
 30303037323731544E30305330303032 ┐
42374343373936433241343930394646 │
31323137343839384334323836453541 ├ Key Block (5 blocks)
45324538323330453839323834454437 │
3135443144374630FFFFFFFFFFFFFFFF ┘
9A73BC83A90012BDFFFFFFFFFFFFFFFF - Single-length key (1 block)
4D617279206861642061206C6974746C ┐
65206C616D622C0D0A49747320666C65 │
65636520776173207768697465206173 ├ General data (4 blocks)
20736E6F772EFFFFFFFFFFFFFFFFFFFF ┘
Alternatively, this could be done using 3 LA host commands, where:
Command 1 – Key Block

 Index address = "07B"
 Block Count = "05"
 30303037323731544E30305330303032
42374343373936433241343930394646
31323137343839384334323836453541
45324538323330453839323834454437
3135443144374630FFFFFFFFFFFFFFFF
Command 2 – Single-length Key

 Index address = "080"
 The following 1 data block is provided:
 9A73BC83A90012BDFFFFFFFFFFFFFFFF

Command 3 – General Data

 Index address = "081"
 4D617279206861642061206C6974746C
65206C616D622C0D0A49747320666C65
65636520776173207768697465206173
20736E6F772EFFFFFFFFFFFFFFFFFFFF
Storing RSA Keys in the payShield 9000

The User Storage mechanism when using fixed block size as described above is not ideal
for storing RSA keys in the HSM because of the length and variability on length of such
keys. Therefore if fixed block sizes for user storage has been specified, the payShield
9000 provides a separate mechanism for storing up to 21 LMK-encrypted RSA private
keys inside the HSM.
See later in this chapter for how RSA keys can be stored in user storage when variable
block sizes have been specified.
Storing the RSA Private Key in the payShield 9000

The EK host command is used to store LMK-encrypted RSA private keys inside the
payShield 9000. The keys can be encrypted using Variant or Key Block LMKs.
The command requires a Key index in the range 00-20 (decimal) to identify which
location the key is to be loaded to.
Using RSA Private Keys held in the payShield 9000

Once an RSA private key has been stored inside the payShield 9000 using the EK
command, it can be directly referenced by relevant host commands which need to use it
–EW, GI, GK.
These commands include a Private Key Flag field to identify the location (i.e. 00-20)
where the required private key is stored. (Entering 99 into this field indicates that the
private key is included in the command rather than being stored in the HSM.)
User Storage when using Variable Block Sizes

A significant enhancement to the way that User Storage can be utilized was introduced in
payShield 9000 v2.3a. The existing functionality, described earlier in this chapter,
continues to be available where a block size of S, D, or T is selected, and functions in the
same way as previously, offering complete backwards compatibility for legacy
applications using User Storage or storing RSA private keys in the HSM.
The enhanced functionality, where V is selected for the block size, allows RSA keys and
Key Block LMK-encrypted keys to be held in User Storage, and to be referenced by host
commands. Stored keys and data no longer have to be of a fixed length, removing the
need to specify a block size or to pad data blocks to the appropriate size.
The text below assumes that the reader is familiar with the information in the earlier
section on the operation of User Storage when using fixed block sizes, and therefore
identifies only the differences from that information.

Enabling the Enhanced Functionality

The option V(ARIABLE) must be selected for the User storage key length parameter in
the payShield 9000 Security Settings:
User storage key length [S/D/T/V](VARIABLE):
If the S(ingle), D(ouble), or T(riple) options are selected, user storage operates as
described earlier in this chapter, and the enhanced functionality for variable-length user
storage is not available.
If the V(ariable) option is selected, the enhanced functionality described here is

activated. In this case, the user storage data structure is incompatible with that for the
other options, and any existing data in user storage must be re-loaded.
The facility described earlier to store up to 21 RSA private keys in the HSM continues to
be available even if the V(ariable) option is selected.
New Data Structure

The enhanced user storage allows for 4,096 entries, as previously, but the total storage
space has been increased by more than a factor of 5. These entries can now be of
variable length, subject to the following limits:
 For Index Addresses 000-07F (0-127 decimal), the maximum length is 1,000
bytes. This enables the storage of longer data items such as RSA keys or the
Diebold Table, but can be used to store any data such as AES or TDES keys.
 For Index Addresses 080-FFF (128-4095 decimal, i.e. 3,968 entries), the
maximum length is 100 bytes. This is designed for use with shorter data items
such as AES or TDES keys.
Data to be stored can now be defined as being ASCII, ASCII-encoded hexadecimal, or
binary. It is no longer necessary to pad data to the block size.
The stored data can, as previously, be keys, PIN solicitation data, a Diebold table,
decimalization tables, or any other data that the user desires.
Loading Data into user storage with variable block sizes

As previously, data is entered into user storage using the LA host command. However,
the command is modified in the following way:
 a single data item can be loaded at a time, and as a result there is no need to
specify the number of blocks being loaded.
 the data being loaded can be ASCII, ASCII-encoded hexadecimal, or binary. The
command defines which type-of data is to be loaded.
 to allow for variable-length data, the command now includes a field to specify the
data length.
Examples of the use of the LA command with variable block sizes are provided in the
document payShield 9000 Host Command Examples.
Where the loaded data represents keys, the keys can be encrypted using any type of
LMK (i.e. including AES and TDES Key Block types).
Storing a Diebold table with variable block sizes

The Diebold Table must be stored as a single block of 512 hexadecimal characters in one
of the longer user storage blocks with an index in the range 000-07F (000-127 in
decimal).

Reading Data from User Storage with variable block sizes

Data can still be read from user storage using the LE host command. As only a single
record is returned, a block count is no longer required by the command.
An example of the LE command used in this manner is provided in the document

payShield 9000 Host Command Examples.
Referencing keys stored in user storage with variable block sizes

Once a key is held in user storage it can be referenced by host commands which
normally provide the key as part of the command. This now applies to any key type
encrypted under any LMK type. The reference is constructed from the Index Flag "K" plus
the Index Address of the key in user storage: the value of "K" for the Index Flag is used
irrespective of the Index Flag used in the LA host command when the key was loaded
into User Storage.
Here are some examples. <…> indicates binary data represented here as hexadecimal
characters.
LMK-encrypted key LMK Key Index Key in host command Key reference in
Type Type in User if key provided by host command if
Storage host key stored in
user storage
9A73BC83A90012BD Var Sngle 3A8 9A73BC83A90012BD K3A8
TDES DES
23A7BB616A198EFF Var Dble B17 U23A7BB616A198EFF UKB17
1298FAE25D3A4BF5 TDES TDES 1298FAE25D3A4BF5
18A7DE43129C2CD6 Var Triple 179 T18A7DE43129C2CD6 TK179
BBA965823F5A78A9 TDES TDES BBA965823F5A78A9
9987AA4F5890B0C3 9987AA4F5890B0C3
00072B1TN00S0001 Kbl Dble A12 S00072B1TN00S0001 SKA12
3FC2C2BD71EFA6A1 TDES TDES 3FC2C2BD71EFA6A1F6
F65A01CC3EA930CE 5A01CC3EA930CED51
D51E07D8A818AC06 E07D8A818AC06742D
742D1651 1651
<AC5DC5A50CA3D9 Var RSA 01C <AC5DC5A50CA3D929 K01C
293629994FF8452E7 TDES Prv 3629994FF8452E767
67 1024 … (344 bytes of binary
… (344 bytes of data) …
binary data) … 402E0399AC47527F7
402E0399AC47527F E881BA68F1>
7E881BA68F1> (344 bytes of binary
(344 bytes of binary data)
data)
0037603RN00N0202 Kbl RSA 06E S0037603RN00N0202 K06E
0005TPB0B4vzoOWb TDES Prv 0005TPB0B4vzoOWb
<F343F5C367CB557 1024 <F343F5C367CB557
BC217195EBFD4821 BC217195EBFD4821
… (336 bytes of … (336 bytes of binary
binary data) … data) …
09E3AD2CFCE4B045 09E3AD2CFCE4B045
CEC4D2C23061455> CEC4D2C23061455>
99653B1A 99653B1A


Host command examples are included in the document payShield 9000 Host Command
Examples. This includes the following examples relevant to the use of User Storage:
 CA Command - Translate a PIN from TPK to ZPK Encryption (using keys and PIN
Block held in user storage)
 DE Command - Generate an IBM PIN Offset
 EW Command - Generate a signature (with variant LMK-encrypted RSA key held
in user storage)
 EW Command - Generate a signature (with key block LMK-encrypted RSA key
held in user storage)
 JE Command – Translate a PIN from ZPK to LMK encryption
 JG Command – Translate a PIN from LMK to ZPK encryption
 LA Command - Load Data to User Storage (double-length TDES key encrypted
under a variant LMK).
 LA Command - Load Data to User Storage (RSA private key encrypted under a
TDES variant LMK).
 LA Command - Load Data to User Storage (RSA private key encrypted under a
TDES key block LMK).
 LE Command - Read Data from User Storage (single/double/triple block size
setting).
 LE Command - Read Data from User Storage (variable block size setting).
 M0 Command – encrypt a block of data (using a key block LMK-encrypted key
held in user storage).

Chapter 16 – SNMP
Introduction
The payShield 9000 supports industry-standard SNMP (Simple Network Management
Protocol) to provide information about the payShield 9000’s state to external
management devices. Information can be obtained from the payShield 9000 in two
operational modes:
 by the management device polling the payShield 9000 to request information;

 by the payShield 9000 automatically providing an SNMP "Trap" when a significant
event has occurred. The use of traps reduces network traffic compared with
polling, but some polling will generally still be required, for example to detect if
the HSM has been taken offline or has failed.
The information provided by the payShield 9000 is defined in its SNMP MIB (Management
Information Base). The MIB is provided with the payShield 9000 software, and is also
included in this manual at Appendix F.
Network Connectivity
SNMP traffic to and from the payShield 9000 can use any one of its 4 Ethernet ports:
 Host Port 1
 Host port 2
 Management Port
 Auxiliary Port
SNMP is enabled/disabled and the desired port selected by using the SNMP console
command. Users of payShield Manager should use the Configuration / SNMP Settings
dialogue box:
The ports themselves are configured using the CH, CM, and CA console commands.
payShield Manager users can configure host ports using Configuration / Host Settings
and the management port using Configuration / Management Settings.

SNMP traffic to the payShield 9000 is received on UDP port 161, and SNMP traffic is sent
to a specified UDP port (usually 162) at the management device.
SNMP versions
payShield 9000 supports SNMP versions 1, 2, and 3.
For SNMP versions 1 and 2, Communities are set up by providing a read string. For
version 3, Users are set up under a username with details of authentication/privacy
algorithms and passwords. This configuration is done using the SNMPADD (or SNMPDEL
to delete a Community or User) console command or payShield Manager Configuration /
SNMP Settings.
Configuring Traps
For Traps to be sent by the payShield 9000, both SNMP (e.g. using the SNMP console
command) and traps (e.g. using the TRAP console command) must be enabled.
Multiple traps can be configured:
 Current Traps can be viewed using the TRAP console command.

 The UDP port at the management device and the User who is to receive the trap
are configured using the TRAPADD console command.
 Traps are deleted using the TRAPDEL console command.
Information provided by the payShield 9000 through

SNMP
See the MIB at Appendix F for the detailed definition of information available. Below is a
shortened description of the information that can be provided.
MIB Object Name Utilization/Health Check Data

HSM State Information
ps9000StateDevice Current HSM state (Online/Offline/Secure)
ps9000SettingsPCICompliant Whether all settings are compliant with PCI HSM standard.
System
The date and time as reported by the system's Real Time
ps9000SystemDateAndTime
Clock.
ps9000SystemSerialNum Serial number of the payShield 9000.
ps9000VersionSoftwareBaseRelease Base release of software running on the Payshield 9000
ps9000VersionSoftwareRevision Revision of software running on the Payshield 9000
ps9000VersionSoftwareBuildNumber Build number of software running on the Payshield 9000
ps9000VersionSoftwareHSMCoreAPIVe
Core API version of software running on the Payshield 9000
rsion
ps9000EnabledHostCommandsCount Number of host commands enabled
ps9000EnabledHostCommandsList List of enabled commands
Licensing
ps9000LicensingPerformanceModel Maximum transactions per second the unit is licensed for.
ps9000LicensingOptionalLicenseCount Number of optional licences the Payshield 9000 has installed.
ps9000LicensingOptionalLicensesList Optional licenses installed on the payShield 9000.
ps9000LicensingCryptoAlgorithmCount Number of Cryptographic Algorithms enabled by licencing.


ps9000LicensingCryptoAlgorithmList List of licensed Crypto Algorithms.
LMK Information
ps9000LmkNumLoaded The number of LMKs currently loaded into the device
ps9000LmkNumTestLmksLoaded The number of 'test' LMKs loaded (as opposed to production).
The number of old LMKs currently loaded in the Payshield

ps9000LmkNumOldLmksLoaded
9000.
ps9000LmkStatusTable A table that returns the status of all possible LMK sets
Row in the LMK Status table. Each row contains the following
ps9000LmkStatusEntry
objects:
ps9000LmkStatusIndex The index into the LMK Status table
Whether or not an LMK set is currently loaded at this

ps9000LmkStatusLoaded
index in the table.
ps9000LmkStatusAuth Authorised state of this LMK set
Indicates the number of authorised activities if the

ps9000LmkStatusNumAuthActivities
payShield 9000 is set to Multi-Auth mode
ps9000LmkStatusScheme Scheme of the loaded LMK set (variant or key block)
ps9000LmkStatusAlgorithm Algorithm use by the LMK set for encryption.
ps9000LmkStatusLiveTest Status of the currently loaded LMK set - 'Live' or 'Test'.
ps9000LmkStatusComments Description of the LMK set loaded.
ps9000LmkStatusCheckDigits The check digits for an LMK
Utilisation Information
ps9000UtilLoad Instantaneous HSM load
ps9000UtilHostCmdVolume Instantaneous host command volumes
ps9000UtillEnabled Whether collection of utilisation data is enabled
Host Communications Configuration - Async

ps9000HostConnectionAsyncEnabled Whether the unit is configured to provide async host comms.
Whether the process to service host commands is currently

ps9000CommsHostAsyncServer
running over the Async host port.
ps9000HostConnectionAsyncMode Whether Async Transparent mode is set.
ps9000HostConnectionAsyncTerminati
Async terminating sequence.
ngSequence
ps9000HostConnectionAsyncDeviceNa
The name of the async controller.
me
ps9000HostConnectionPortName Name of the physical async port.
ps9000HostConnectionAsyncStatus Status of the host Async interface
ps9000HostConnectionAsyncBaud Baud rate for the host async interface.
ps9000HostConnectionAsyncDataBits Number of data bits for the host async interface.
ps9000HostConnectionAsyncStopBits Number of stop bits for the host async interface.
ps9000HostConnectionAsyncFlowContr
Flow control setting of the host async interface.
ol
ps9000HostConnectionAsyncParity Parity setting of the host async interface.
Host Communications Configuration - Ethernet

ps9000HostConnectionEthernetEnabled Whether the Payshield is configured for ethernet host comms.


ps9000HostConnectionEthernetIIfCoun
Number of physical ethernet interfaces enabled.
t
ps9000HostConnectionEthernetSSLEna
Whether TLS/SSL has been enabled.
bled
ps9000HostConnectionEthernetACLsEn
Whether Access Control Lists are enabled.
abled
ps9000HostConnectionEthernetUDPEna
Whether UDP is enabled.
bled
ps9000HostConnectionEthernetTCPEna
Whether TCP is enabled.
bled
ps9000HostConnectionEthernetMaxTcp
Maximum number of TCP sessions allowed per interface.
Connections
ps9000HostConnectionEthernetTcpKee
TCP keep alive timeout in minutes.
palive
ps9000HostConnectionEthernetWellKn
The well known TCP port.
ownPortTcp
ps9000HostConnectionEthernetWellKn
The well known TLS port.
ownPortTls
Interface specific ethernet configuration/status information,

Ps9000HostConnectionEthernetEntry
showing for each host port:
ps9000HostConnectionEthernetConf
Whether ethernet is configured.
igured
ps9000HostConnectionEthernetInte
Host Port number (1 or 2).
rfaceNumber
ps9000HostConnectionEthernetConf
Whether DHCP or Static IP address.
igMethod
ps9000HostConnectionEthernetHost
Network name (DHCP only).
Name
ps9000HostConnectionEthernetIpAd
IP address.
dress
ps9000HostConnectionEthernetSub
Subnet mask.
netMask
ps9000HostConnectionEthernetGate
Gateway IP address.
way
ps9000HostConnectionEthernetMac
MAC address.
Address
ps9000HostConnectionEthernetPort
Speed/duplexity
Speed
ps9000HostConnectionNumberOfCo
Number of TCP connections in use.
nnectionsUsed
Host Communications Configuration - FICON

Whether or not the Payshield is configured for FICON host
ps9000HostConnectionFiconEnabled
comms.
ps9000HostConnectionFiconControlUni
Control unit address defined in the mainframe I/O definition.
tImage
ps9000HostConnectionFiconControlUni
Starting unit address.
tAddress
ps9000HostConnectionFiconMIH Missing Interrupt Handler value.
Management Port Configuration – Ethernet (payShield Manager)

ps9000ManagementEthernetEnabled Whether payShield Manager is enabled.


ps9000ManagementEthernetConfigMet
Whether DHCP or static address.
hod
ps9000ManagementEthernetNetworkN
Name of this interface if in DHCP mode.
ame
ps9000ManagementEthernetIpAddress IP address.
ps9000ManagementEthernetSubnetMa
Subnet mask.
sk
ps9000ManagementEthernetGateway IP gateway address.
ps9000ManagementEthernetMacAddre
MAC address.
ss
ps9000ManagementEthernetPortSpeed Port speed.
Management Port Configuration – Async (Console)

ps9000ManagementConsoleBaud Baud rate.
ps9000ManagementConsoleDataBits Number of data bits.
ps9000ManagementConsoleStopBits Number of stop bits.
ps9000ManagementConsoleFlowContro
Flow control method.
l
ps9000ManagementConsoleParity Parity setting.
Printer Port Configuration

ps9000Printer-LF-CR-reversed Whether CR and LF are reversed.
ps9000PrinterTimeout-ms Printer timeout value in milliseconds.
ps9000PrinterDelay-ms Printer delay in milliseconds.
ps9000PrinterReport Report of the dynamic state of printers in the system.
Communications Services
Whether the process to service Console Management
ps9000CommsMgmtConsoleState
requests is currently running.
Whether the process to service Management Port requests is

ps9000CommsMgmtGuiState
currently running.

ps9000CommsHostAsyncServer
running over the Async host port.

ps9000CommsHostTcpServer
running over the Ethernet host port using the TCP protocol.

ps9000CommsHostUdpServer
running over the Ethernet host port using the UDP protocol.

ps9000CommsHostFiconServer
running over the FICON host port.
Communication Ports
ps9000HostPortEthernet1 If the first host ethernet port is up and running.
ps9000HostPortEthernet2 If the second host ethernet port is up and running.
ps9000HostPortAsync If the Host Async Port (if present) is up and running.
ps9000HostPortFicon If the Host FICON port (if present) is up and running.
Operator Actions
ps9000PowerOnAlarm Trap indicating the unit has been powered up.
ps9000RestartAlarm Trap generated when the reset button has been pressed.


Collection of settings whose modifications will trigger a
ps9000ModifiedSetting
notification.
ps9000SettingsModifiedAlarm Trap that indicates a setting has been modified.
ps9000NewLicenceAlarm Trap indicating the instalation of a new licence.
ps9000NewSoftwareAlarm Trap indicating that new software has been installed.
ps9000AlarmEraseTimeandDate Time and date the erase button was pressed.
ps9000EraseAlarm Trap indicating that the Erase button was pressed.
Logs
ps9000LogsErrorlogTotalCount Total number of entries in the error log.
ps9000LogsAuditlogTotalCount Total number of entries in the audit log.
ps9000ErrorLogData An error log entry
ps9000ErrorlogAlarm Trap that indicates an errorlog entry has been filed.
Fraud Detection
Whether the allowable PIN verifications/minute, or PIN
ps9000FraudPinVerifyLimitsExceeded
verifications/hour, have been exceeded.
Whether total number of PIN attacks have exceeded the

ps9000FraudPinAttackLimitsExceeded
allowed count.
ps9000HealthCheckCountsPinFailuresM Number of minutes in which the maximum pin verify failures

inuteLimit was exceeded since the last reset of health counters.
ps9000HealthCheckCountsPinFailuresH Number of hours in which the maximum allowable pin failures

ourLimit per hour was exceeded since the last reset of health counters
ps9000HealthCheckCountsPinAttackLi Number of times the pin attack limit was exceeded since the
mitExceeded last reset of health counters.
ps9000FraudType What sort of Fraud event took place.
ps9000FraudAlarm Trap that indicates a fraud limit was exceeded.
Tampers
ps9000StateTamperState Current tamper state of the HSM
ps9000StateTamperDate Date and Time that the last tamper event occurred.
ps9000StateTamperCause The cause of the last tamper event
ps9000TamperAlarm Trap indicating a tamper has been detected.
Health Diagnostics
Number of minutes after midnight the diagnostic tests start
ps9000HealthDiagSelfTestTimeOfDay
at.
ps9000HealthDiagSelfTestOK Whether one or more of the tests in the last self-test failed.
ps9000HealthDiagSelfTestCount Number of self-tests run at the last test cycle.
ps9000HealthDiagSelfTestList Complete results of the last run self-test.
Whether the Payshield 9000 is presently collecting health

ps9000HealthHealthCheckEnabled
check data.
ps9000HealthCheckCountsStartTime Date/Time of last health stats reset.
Date/time of when stats collecting was last disabled. Or, if

ps9000HealthCheckCountsEndTime health stats are not disabled, the Date/Time when this field
was read.
ps9000HealthCheckCountsRebootCount Number of reboots since the last reset of health counters.
ps9000HealthCheckCountsTamperCoun Number of tampers detected since the last reset of health

t counters.


ps9000FanID Identifies fan1 or fan2.
ps9000FanState Provides the status of a fan.
ps9000FanAlarm Trap notifying that a Fan is Operating incorrectly.
ps9000PsuNumber Identifies the power supply unit. 1 or 2.
ps9000PSUFailureAlarm Trap indicating that a Power supply unit has failed.
ps9000BadDataPhysicalPort Physical port that bad data was detected on.
ps9000BadDataProtocol The protocol that bad data detected was transmitted with.
Trap indicating that protocol breaking data has arrived on a

ps9000HostPortBadDataAlarm
port.
ps9000BatteryState State of the battery.
ps9000BatteryAlarm Trap indicating a battery problem.
ps9000DiagnosticID Identifier of a diagnostic test.
ps9000DiagnosticString Identifier of a diagnostic test as a string.
ps9000DiagnosticTestFailureAlarm Trap indicating a diagnostic test has failed.
Traps issued by the payShield 9000

Failure of a daily diagnostic self-test
A Trap message will be issued whenever a test in the daily diagnostic self-tests fails.
The trap is issued using the ps9000DiagnosticTestFailureAlarm MIB object, and the
following supporting information is provided:
 the test which has failed is identified in ps9000DiagnosticID: see Appendix F for
the list of test IDs which may be reported, and
 the failed test is also described as a string in ps9000DiagnosticString.
Tamper
If the payShield 9000 detects a tamper, a Trap will be sent when the unit restarts.
The Trap is issued as MIB object ps9000TamperAlarm, and the following supporting
information is provided:
 the cause of the tamper is reported in ps9000StateTamperCause,

 the date and time of the tamper is reported in ps9000StateTamperDate, and
 the current state of the unit is reported in ps9000StateTamperState.
Powering up
When the payShield 9000 is powered up, a Trap is sent using MIB object
ps9000PowerOnAlarm.
Use of the Restart button

When the Restart button on the payShield 9000 is used, a Trap is sent using MIB object
ps9000RestartAlarm.

Use of the Erase button

When the Erase button on the payShield 9000 is used, a Trap is sent using MIB object
ps9000EraseAlarm and the following information is provided:
 the date and time of the use of the Erase button is provided in
ps9000AlarmEraseTimeandDate.
Fraud Detection
See Chapter 7 of the payShield 9000 General Information Manual for a description of the
payShield 9000's Fraud Detection feature.
If a fraud attempt is detected a Trap is issued in the ps9000FraudAlarm MIB object. The
following supporting information is available:
 the cause of the fraud detection in ps9000FraudType.
Installation of a new license

A Trap is issued when an attempt is made to install a new license on the payShield
9000, using MIB object ps9000NewLicenceAlarm.
Installation of new software

A Trap is issued when an attempt is made to install new software on the payShield
9000, using MIB object ps9000NewSoftwareAlarm.
Power Supply Unit (PSU) failure

When a PSU failure is detected, a Trap is issued using MIB object
ps9000PSUFailureAlarm. Supporting information is:
 the identity of the failed PSU in ps9000PsuNumber.
Abnormal fan speed

When a fan running at an abnormal rotational speed is detected, a Trap is issued using
MIB object ps9000FanAlarm, with the following supporting information:
 the identity (1 or 2) of the abnormal fan in ps9000FanID,

 the nature of the abnormality in ps9000FanState.
New Error Log entry

If a new entry is put into the Error Log a trap is issued using MIB object
ps9000ErrorlogAlarm. The following supporting information is provided:
 the new error log entry in ps9000ErrorLogData.
Invalid or unexpected data received at a host port

A Trap is issued if there is a protocol violation in data received at a host port. This is
notified in MIB object ps9000HostPortBadDataAlarm. The following supporting
information is also provided:
 the physical port involved, in ps9000BadDataPhysicalPort,

 the protocol involved in ps9000BadDataProtocol.

Actual or impending battery problem

The payShield 9000 cannot function if the battery maintaining the volatile memory fails.
If the battery fails or is expected to do so shortly a Trap is issued using MIB object
ps9000BatteryAlarm. The following supporting information is provided:
 battery state in ps9000BatteryState.

Chapter 17 – Key Component

Printing
Introduction
Payment processing is a multi-organizational activity, with the various organizations
involved needing to exchange encryption keys. The working keys that the parties need to
exchange are protected by encrypting them using a KEK: this term covers any Key
Encrypting Key, including specialised KEKs such as Zone Master Keys (ZMKs) or Terminal
Master Keys (TMKs). The problem is how the KEKs themselves are to be exchanged.
Because all of these parties may be using different, incompatible IT infrastructures, KEKs
are typically exchanged by splitting them into multiple components which are printed
out, with each component being given to a different officer in the recipient organization;
the KEK is re-formed at the recipient organization by the component holders coming
together and entering the components into a key-forming application. No one individual
acting alone has complete knowledge of the KEK or the ability to form it in the recipient’s
system.
This document describes how the payShield 9000 could be used to generate and print
KEK components at the issuing organization, and to re-form the KEK from components at
the recipient organization. User organizations must review the suggested methods
described in this document to ensure that they meet the organizations’ security and
operational requirements.
Additional detail in some areas such as creating print forms can be found elsewhere in
this manual. Reference is made here to the use of HSM Host commands. These
commands are described fully in the payShield 9000 Host Command Reference Manual.
Description of the process

Overview
Key Encrypting Keys (KEKs), including specialised keys such as TMKs, ZMKs, and ZCMKs,
are shared between organizations to allow them to securely exchange working keys by
encrypting them using the KEKs.
A KEK that is to be shared between two organizations will be generated by one of the
parties and conveyed to the other in a secure manner. In the payments industry this is
typically done by the issuer splitting the KEK into components which are then delivered
to different individuals at the recipient organization. These individuals come together to
re-form the KEK in the recipient organization’s systems.
Each user organization needs to design its own component distribution process to meet
its operational and security requirements. One possible sequence of events, making use
of a Thales payShield 9000 to provide a high level of security, is as follows:
 At the KEK issuing organization:

 Set up Key Component Print Form.
 Generate and print the desired number of KEK components, and retain a
copy of the components encrypted using the payShield 9000’s Local Master
Key (LMK)

 Deliver each printed component to its designated officer in the recipient

organization.
 Use the encrypted components to form the KEK using a payShield 9000 at
the issuing organization.
 Store the KEK in the issuing organization’s key database, encrypted using
the payShield 9000’s LMK.
 At the recipient organization:
 The component officers come together at a payShield 9000 and
individually enter their components.
 The recipient organization’s payShield 9000 will form the key from the
entered components.
 The payShield 9000 will display the KEK formed from the components,
encrypted with the payShield 9000’s LMK. The LMK-encrypted KEK is
entered into the recipient organization’s key database. It can then be
included in commands used to exchange working keys with the issuing
organization.
 Note: an alternative approach is to use the Thales Key Management
Device (KMD). The KMD is described in the payShield 9000 General
Information Manual.
These stages are described in more detail in the following sections.
The possible process model outlined here can be modified to the needs of individual
organizations. As an example of this, an approach taken by some users of Thales
payment HSMs for setting up TMKs is to pre-print batches of components in secure
envelopes, with an associated reference number: the component check value has been
used for this by at least one organization, but in this case a process must be put in place
to allow for the (unlikely) occurrence of a non-unique value. A supply of components is
provided to each component holder. All the components are also held at the host system.
The component holders visit the ATMs, and each takes any one of their stock of
components and enters it into the ATM to form the ATM’s copy of the TMK. Each
component holder then calls the operations center and provides the reference number of
the component they used. The host computer can then retrieve the same components
and form its copy of the TMK.
As mentioned above, each organization needs to design its own procedures to provide
the level of security that the organization feels is appropriate. It is suggested that these
procedures include the disposal of printed components after they have been used.
Directly Attached printers

Multiple components need to be printed, but they must only be disclosed to the single
user that they are to be addressed to. Using the payShield 9000, the components are
created one at a time. It is suggested that these components are printed at an impact
printer directly attached to the HSM, and onto specialized multi-part, tamper-evident
mailers that prevent the component being accessed until the mailer is opened. Non-
sensitive data, such as date and addressee, can be printed on the outside of the mailer.

Commands,
format,
& request to generate
a component
Host
Computer
Impact
printer
HSM
The payShield 9000 can print to:
 a parallel printer attached to a USB port on the payShield 9000 via a USB-to-
parallel cable available from Thales
 a serial printer attached to a USB port on the payShield 9000 via a USB-to-serial
cable available from Thales
 a USB printer attached to a USB port on the payShield 9000 via a standard USB
cable.
To choose which type of printer to use and to configure the printer, use the CP
(Configure Printer) console command or payShield Manager Configuration / Printer
Settings.
Non-impact Printers
It is unlikely that laser or ink-jet printers can be used in this way, because use of this
type of printer to print secret information (such as PINs) requires specialized stationery
with plasticized windows: it is unlikely that stationery with large enough windows for
component printing will be readily available.
Any type of printer could be used to print components onto plain stationery. However, if
plain stationery is to be used, security measures should be in place to ensure that the
component can be seen by no more than one person and that any one person cannot see
more than one component.
Operation without a directly attached printer

If no directly attached printer is available, components can be displayed to the users. In
this case, security processes must be in place to ensure that each component can be
seen by no more than one person, that any one person cannot see more than one

component, and that procedures are in place to protect the components (e.g. if they are
transcribed onto paper).
Setting up Key Component print forms

A form definition needs to be loaded into the payShield 9000 so that it can format the
output sent to the printer: full details can be found in Chapter 3 of this manual under
Setting up the PIN Mailer form, and the following section indicates how this can be used
for key component printing.
The payShield 9000 can hold a single form definition at a time. Formatting data is loaded
onto the HSM as text strings. This data consists of:
 Formatting symbols to format the data

 Constants (text strings)
 Variable print field markers, which will be populated with data when the PIN
mailers are to be printed.
A key component print formatting string might look as follows:
>L>003^0>033^1>L>003KEY COMPONENT PART 1: ^P>L>003 KEY

COMPONENT PART 2: ^Q>L>003 KEY COMPONENT PART 3:
^R>L>L>003 KEY CHECK VALUE: ^T>L>L>003 DO NOT DISCLOSE
THIS COMPONENT TO ANYONE ELSE>L>F
In this example, the following print formatting symbols are used:
 >L - carriage return + line feed (CR/LF)

 >nnn - skip to output column nnn
 ^n - insert variable print field n: the actual value will be provided at print
time
 >F - Form Feed (FF).
 ^T - the key component check value.
 ^P, ^Q, and ^R have the following meanings:
Key ^P ^Q ^R
length
Single 1st 8 hex digits of 2nd 8 hex digits N/A
component of component
Double 1st 16 hex digits 2nd 16 hex digits N/A
of component of component
Triple 1st 16 hex digits 2nd 16 hex digits 3rd 16 hex digits
of component of component of component
The full set of print formatting symbols is defined in Appendix D.
The above example would print the following key component form:

..(Field 0)....................(Field 1)
..KEY.COMPONENT.PART.1:.xxxxxxxxxxxxxxxx
..KEY.COMPONENT.PART.2:.yyyyyyyyyyyyyyyy
..KEY.COMPONENT.PART.3:.zzzzzzzzzzzzzzzz
..KEY.CHECK.VALUE:.vvvvvv
..DO.NOT.DISCLOSE.THIS.COMPONENT.TO.ANYONE.ELSE
Notes:
 "." is used in this example to indicate where a space would be printed

 "(Field 0)" etc. represents variable data (such as date and addressee) that the
host computer application will provide at print time.
 xxx…x, yyy…y, zzz…z represent parts of the key component, each representing
16 hexadecimal digits.
 vvvvvv represents the component check value
The maximum length of a form definition is 299 symbols and characters of constant data.
This form definition is loaded onto the HSM using payShield 9000 Host commands. The
required host commands are as follows - see the payShield 9000 Host Command
Reference Manual for full details:

PA Load Formatting Data to HSM - to load the first part of the set of symbols
and constant characters.
PC Load Additional Formatting Data to HSM - to load any continuation of the
symbols and constant characters. (PC is a continuation of PA, and must be
preceded by a PA command.)
Generating and printing components

If using a directly-attached printer
The following single payShield 9000 host command performs these actions:
 Generates a random key component.
 Prints the key component at the printer directly attached to the HSM, using the
print form currently installed on the HSM (using the PA and PC host commands).
 Encrypts the component using the HSM’s LMK and returns it to the originating
organization’s host computer system.

A2 Generate and print a component

Typically 3 components will be generated and printed in this way, by running the A2
command once for each component.
Each component will be printed in its own mailer, which should be designed such that the
component cannot be read from the outside of the mailer, and any attempt to access the
component inside the mailer will be evident.
The HSM will provide 2 responses to the A2 command sent by the host:
payShield 9000 Response to Host

A3 Initial response, before printing. This returns the component encrypted
under the HSM’s LMK, and the component check value.
AZ Second response, providing the outcome of the printing operation.
The issuer’s host will receive and hold the encrypted component.
If no HSM-attached printer is available

The A2 Host command depends on the payShield 9000 having a directly attached printer.
Where such a printer is not available, key components can be generated using the
following Console command:
payShield 9000 Console Command

GC Generate key component
This command generates both the clear component and the component encrypted under
the payShield 9000’s LMK and displays them to the user.
The output from this command must be manually written or printed onto the mailer using
a separate system.
Security considerations
Whenever components are output in any way other than inside a secure, tamper-evident
mailer, the originating organization should satisfy themselves that procedures are in
place to ensure that not more than one person can see any component, and that any one
person cannot see more than one component.
Avoiding use of Legacy Commands

The payShield 9000 also provides the NE Host command. This might appear to be a more
convenient method of creating components because a single command generates the key
and prints multiple components.
However, the NE command is provided purely for backwards compatibility with older
systems that were designed to make use of it. It is recommended that use of this
command is avoided, and that it is disabled using the CONFIGCMDS Console command or
in the payShield Manager Configuration / Configure Commands / Host dialogue box,
because it generates components as split keys rather than full-length components which
are XORed together.

Delivery of printed components

These mailers are delivered to the appropriate key management officers at the recipient
organization, using secure delivery methods.
Forming the KEK at the issuer system

If components were printed at a directly attached printer
If a payShield 9000-attached printer has been used to print components, typically 3
components will have been generated using the HSM’s A2 Host command and encrypted
under the HSM’s LMK. These encrypted components are held on the issuer’s host system.
The issuer’s host now forms the KEK from the encrypted components it is holding by
sending the components to a payShield 9000 in the following host command:

A4 Form a key from encrypted components
The payShield 9000 will form the KEK, encrypt it using its LMK, and return the LMK-
encrypted KEK to the host system. The host can now add this encrypted KEK to its key
database. Whenever a cryptographic operation requires the KEK, the encrypted KEK will
be included in the host command sent to the HSM and the HSM will decrypt the KEK and
use it within its secure boundary.
If a directly attached printer was not used

Where no HSM-attached printer is available and components have been generated using
the GC Console command, then the KEK should be formed in the same way as described
in the next section "Forming the KEK at the recipient’s system".
Forming the KEK at the recipient system

The key management officers at the recipient organization will each have received their
own KEK component. Each one of them has access to only one component, and all of the
component holders need to come together to allow the KEK to be formed from the
components.
There are 3 ways that this can be done using the payShield 9000. In each case:
 the component holders come together

 each enters the component they hold
 the KEK is displayed, encrypted under the HSM’s LMK
 the encrypted KEK is noted down and entered into the recipient host system’s key
database, using the appropriate key entry tool at the host.
The three payShield 9000 mechanisms available for doing this are as follows.
Console
The following Console command allows the component holders to enter their components
sequentially and then displays the encrypted key and its check value:

payShield 9000 Console Command

FK Form key from components
This Console command can also form a key from encrypted components (e.g. if the
encrypted components generated by the GC Console command option had been provided
to the recipient).
payShield Manager
The ability to Install an LMK from RLMK Card Set can be found in payShield Manager at
Operational / LMK Operations / Local master Keys.
Key Management Device (KMD)
The standalone KMD can be used to form an LMK-encrypted key from components – see
the payShield 9000 General Information Manual.
Further Information
Further, more detailed information relating to the methodologies described in this
document can be found in the following Thales publications:
 Other chapters in this manual
 1270A546 payShield 9000 Host Command Reference Manual.
 1270A645 payShield Manager User Guide

Chapter 18 – Moving to PCI HSM

Compliance
Introduction
The PCI SSC (Payment Card Industry Security Standards Council) publishes security
standards relating to the issuing of credit/debit cards and the processing of their
transactions. When these standards become mandated by the card schemes,
organizations are audited against those standards that relate to their operations and
equipment manufacturers must ensure that their products comply with the standards
which are relevant to them.
The PCI HSM standard relates specifically to HSMs, such as the payShield 9000. Although
not yet mandated by the card schemes, compliance with the PCI HSM standard is sought
by many users and is required for compliance with certain other PCI standards (e.g.
Point-to-Point Encryption and mPOS; Card Production).
The payShield 9000 hardware and selected versions of software have been certified as
being compliant with this standard. In order to achieve this certification, a number of
changes were made to the payShield 9000 software, some of which apply to user
operation of the device and some of which are relevant to application developers. This
chapter focusses on the changes which may impact on developers:
 PIN Blocks
 Updating Key Type 002 in host commands
 Migrating keys from Key Type 002
 Diebold Table re-encryption
Note that where changes have been made to the payShield 9000 to enable it to comply
with the requirements of the PCI HSM standard, the user can decide whether to use
these changes through the payShield 9000's security settings. If the changes to the
software are not used then the payShield 9000 can run with full compatibility with legacy
units, but it is then not compliant with the requirements of PCI HSM.
A general description of the PCI HSM standard and the effects on operations can be
found at Chapter 10 of the payShield 9000 General Information Manual. That chapter
includes a description of the conditions necessary to make a payShield 9000 compliant
with the PCI HSM standard.
PIN Blocks
Using PIN Block formats in a compliant manner
PCI HSM compliance requires adherence to the recommendations of ISO 9564 / ANSI
X9.8 in terms of allowed PIN Block Format translations and usage.
The allowed translations and usage are a sub-set of what was previously available on the
payShield 9000. Therefore users could already be compliant with ISO 9564 / ANSI X9.8
with older HSMs, simply by using only the allowed functionality. However, for PCI HSM
compliance the payShield 9000 must enforce the limitations.
For users not already conforming to ISO 9564/ANSI X9.8, the payShield 9000 allows the
user to continue operating in this fashion until such time as the user wishes to become

PCI HSM compliant. This is done by manipulating the security setting Restrict PIN block
usage for PCI compliance:
 if this is not set the user can continue to using PIN Block Format translations or
usage outside of those allowed by ISO 9564/ANSI X9.8 and PCI HSM
 if it is set then only the permitted functionality is available.
Permitted PIN Block Format Translations

When the security setting Restrict PIN block usage for PCI compliance is set, the
permissible PIN Block format translations are:
Translation to:
Thales PIN
01 02 03 04 05 34 35 41 42 46 47 48
Block Format
ISO
0 - - - 1 2 - - - - 3 4
Format
01 0   
02 -            
03 -            
04 -     
Translation from:
05 1     
34 2     
35 -     
41 -            
42 -            
46 -            
47 3   
48 4   
Note: the rows shaded light blue indicate that these translations are not currently used in
any payShield 9000 Host commands.
With this security setting, users must ensure that their applications are not requesting
non-permissible PIN Block Format translations when sending any of the following Host
commands to the payShield 9000:

Command
CA Translate PIN from TPK to ZPK

CC Translate PIN from one ZPK to another
G0 Translate a PIN from BDK to BDK or ZPK
Encryption (3DES DUKPT)
G6 Translate PIN from one ZPK to another with
SEED (LIC020)
G8 Translate PIN from TPK to ZPK with SEED
(LIC020)
PIN Block Format for Values Derived from PIN & PAN
When the security setting Restrict PIN block usage for PCI compliance is set, payShield
9000 will enforce the ISO 9564 / ANSI X9.8 and PCI HSM requirement that only Thales
PIN Block formats 01 (ISO format 0), 47 (ISO format 3), and 48 (ISO format 4) may be
used when calculating values (e.g. offsets, PVV) from the PIN and PAN.
The Host commands affected by this setting are:
Command
BK Generate IBM PIN Offset (customer-selected PIN)

CE Generate Diebold PIN Offset
CU Verify & Generate a Visa PVV
DE Generate IBM PIN Offset
DG Generate Visa PVV
DU Verify & Generate IBM PIN Offset
FW Generate Visa PVV (customer-selected PIN)
Where the security setting is not set, this restriction is not enforced and users can
continue to use other PIN Block formats to calculate offsets, PVVs, etc., until such time
as the user wants to implement an ISO 9564/ANSI X9.8 and PCI HSM compliant
environment.
Summary of Actions required

 If not already the case, change applications to use only permitted PIN Block
format translations.
 If not already the case, change applications to use only ISO format 0, 3, and 4
PIN Blocks to calculate values from PIN and PAN.
Updating Key Type 002 in host commands

Note: this change does not affect users who have implemented Key Block LMKs.
Moving to Key Block LMKs is the better approach from a strategic viewpoint:
users who wish to continue working with Variant LMKs should implement the
guidelines provided below.
PCI HSM certification requires additional key separation to be applied to the HSM. This
means that, for users of Variant LMKs, various data and keys in key type 002 (i.e.
encrypted with LMK Pair 14-15, variant 0) must be moved to a different key type.

Users can plan when they want to move the keys from the legacy key type (002) to the
new PCI HSM compliant key types by making use of the security setting Enforce key type
002 separation for PCI HSM compliance:
 If this is not set, then the affected keys remain in key type 002: this provides
interoperability with legacy systems but means that the payShield 9000 is not PCI
HSM compliant.
 If the setting is set, the affected keys use the new key types as required for PCI
HSM compliance.
The keys involved and their new key types are as follows:
New Key New LMK

Key or Data Type Pair
Affecting Base payShield 9000 software:

PVK PIN Verification Key 002 14-15 var 0
(no change) (no change)
TMK Terminal Master Key 80D 36-37 var 8
TPK Terminal PIN Key 70D 36-37 var 7
DbTAB Diebold Table 60D 36-37 var 6
Affecting APACS 40 & 70 applications:
KEYVAL Intermediate PIN Key 70D 36-37 var 7
TKR Terminal Key Register 90D 36-37 var 9
Affecting ESP applications using Optional License LIC004:
PVVK PVV Key 002 14-15 var 0
(no change) (no change)
Affecting APCA-compliant applications using Optional License LIC003:
KT Transaction Key 80D 36-37 var 8
TK Terminal Key 80D 36-37 var 8
PEK PIN Encipherment Key 70D 36-37 var 7
KI Initial Transport Key 80D 36-37 var 8
KCA Sponsor Cross Acquirer Key 80D 36-37 var 8
KMA Acquirer Master Key Encrypting Key 80D 36-37 var 8
Affecting CUP applications using Optional License LIC031:
PEK PIN Encryption Key where PEK Type=1 70D 36-37 var 7
In order to operate with the new key types, Host applications issuing commands to the
HSM which specify the key type must be modified to specify the new key type. The Host
commands affected by this are:

Host Command
A0 Generate a Key
A2 Generate and Print a Component
A4 Form a Key from Encrypted Components
A6 Import a Key
A8 Export a Key
B0 Translate Key Scheme
BK Gen IBM PIN Offset (customer selected PIN)
BU Generate a Key Check Value
BW Translate Keys from Old to New LMK
CU Verify & Generate a VISA PVV (of a customer selected PIN)
DU Verify & Generate an IBM PIN Offset (of customer selected new PIN)
FW Generate a VISA PIN Verification Value (of a customer selected PIN)
GI Import Key under an RSA Public Key

GK Export Key under an RSA Public Key
NE Gen and Print Key as Split Components
Example
If it is required to use the A0 Host command to generate a TPK where:
 the key is to be encrypted under the default Variant LMK
 the key does not need to be encrypted under a ZMK or TMK
 the key does not need to be exported in TR-31 format
 no command message trailer is required.
A legacy application might send the following Host command:
Field Value
Message Header 1234
Command Code A0
Mode 0
Key Type 002
Key Scheme U
If the security setting Enforce key type 002 separation for PCI HSM compliance is set, the
Host command would be modified to the following:

Field Value
Message Header 1234
Command Code A0
Mode 0
Key Type 70D
Key Scheme U
Interoperability with older HSMs

Where users have a mixed estate of PCI HSM compliant and non-compliant payShield
9000 and HSM 8000 HSMs, all of their HSMs must be able to use the same key types.
HSM 8000 users should upgrade to v3.3a or later. These versions of HSM 8000 software
include the same capability of changing key types as described above. Some Host
commands will also be disabled. (Note that the HSM 8000 is not PCI HSM compliant,
even with version 3.3a of software installed.)
Users of payShield 9000 with software versions earlier than v1.2a should upgrade their
HSMs to v1.2a or later. This will provide interoperability but will not necessarily make the
payShield 9000 PCI HSM compliant.
It is not possible for a PCI HSM compliant payShield 9000 HSM to inter-operate with
older Thales RG6000 and RG7000 payment HSMs.
Summary of actions required

 Amend key type values specified in Host commands to take account of the new
key types.
 Upgrade all HSM 8000s to software v3.3a or later. Users of customized software
should get their software ported to base 3.3a or later.
 Upgrade all payShield 9000s to software v1.2a or later. Users of customized
software should get their software ported to base 1.2a or later.
Migrating keys from Key Type 002

Note: this change does not affect users who have implemented Key Block LMKs.
Moving to Key Block LMKs is the better approach from a strategic viewpoint:
users who wish to continue working with Variant LMKs can migrate their keys
following the guidelines provided below.
As described in the section Updating Key Types 002 in Host commands above, a number
of keys will have different key types if the security setting Enforce key type 002
separation for PCI HSM compliance has the PCI HSM compliant value. This means that
the users’ relevant operational keys will need to be migrated from key type 002 to their
new key type.
It is suggested that this can be done as part of the regular LMK refreshes that users
should be performing as part of their security procedures. LMK refresh is performed by a
Host application making use of the payShield 9000’s BW Host command - see Chapter
10. The BW Host command includes an option for the migration of keys from key type
002 at the same time as refreshing the LMK. (The BW command can continue to be used
just for LMK refresh, and can also be used to perform the key migration without LMK
refresh.)

The processes below indicate approaches that might be taken to achieve migration, but
users will need to design processes that suit their own environment. The starting point in
these processes is that transaction processing is using the existing key database, and the
security setting Enforce key type 002 separation for PCI HSM compliance has not been
set on any HSM.
Migrating keys without a change of LMK:

Creating a new key database for the new Key Types
 Create a Host process which will be able to take each affected key from a key
database, Use the BW Host command (example below) to migrate the key from
key type 002 to the new key type, and replace the original key in the key
database with the re-encrypted key returned by the BX response.
 Clone each live key database to a new key database. At this stage the new key
database contains the unmigrated keys and is not being used for processing –
which continues using the live key database.
 For each set of LMKs in use:
 Set up one (or more) payShield 9000 which has the active LMKs loaded
with the security setting Enforce key type 002 separation for PCI HSM
compliance not set.
 Use this HSM with the Host process to migrate all the affected keys in the
new key database. The HSM can continue to be used for transaction
processing using the old unmigrated keys at the same time, if required.
Switching the HSMs to the new Key Types

 The HSMs need to be switched over to use the new key types at a convenient
point. During this switch-over, the HSMs will be unavailable for processing for a
period of up to a few minutes. Depending on the nature of the applications and
the systems design, it may be appropriate to do this switchover for:
 All HSMs using a particular key database. (This might be all HSMs, or all
HSMs for an application, or all HSMs for an LMK – dependent on the
organization of the key databases). This makes it easier for the Host
application to switch between old and new key databases, but could
involve an interruption of service if a Disaster Recovery site is not available
to pick up processing using the old unmigrated keys during this
switchover.
 A single HSM or a sub-set of the HSMs using a key database, leaving other
HSMs available to continue providing a service using the old unmigrated
keys. This avoids a complete interruption of service, but requires the Host
application to determine which key database to use for each HSM – e.g. by
using the NO command.
 For the HSMs to be switched over:
 Suspend processing on the HSMs, or use a failover mechanism (such as an
SRM) to re-direct commands to an alternative HSM.
 Put the HSMs into secure state.
 Set the security setting Enforce key type 002 separation for PCI HSM
compliance.
 Resume processing on the HSMs, but using the new key database and the
Host application modified to use the new key types.
 When the process is complete
 archive the old key database

Migrating keys with a change of LMK:

Creating a new key database for the new Key Types
 Create a Host process which will take each key from a key database, use the BW
Host command (example below) to change the LMK for each key and migrate
relevant keys from key type 002 to the new key type, and write the re-encrypted
key returned by the BX response back to the key database.
 Clone each live key database to a new key database. At this stage the new key
database holds the old unmigrated keys and is not being used for processing –
processing continues using the live key database.
 For each set of LMKs in use:
 Set up one (or more) payShield 9000 which has the old LMK (i.e. the one
currently being used to process transactions) loaded as its live LMK (e.g.
by using the LK Console command) and the new LMK stored in its Key
Change Storage (e.g. by using the LN Console command). The security
setting Enforce key type 002 separation for PCI HSM compliance must not
be set. It can still be used for transaction processing if required.
 Use this HSM with the Host process to migrate all the keys in the new key
database by overwriting the old keys with keys newly encrypted using the
new LMK and new key types
Switching the HSMs to the new Key Types

 The HSMs need to be switched over to use the new key types at a convenient
point. During this switch-over, the HSMs will be unavailable for processing for a
period of up to a few minutes. Depending on the nature of the applications and
the systems design, it may be appropriate to do this switchover for:
 All HSMs using a key database. (This might be all HSMs, or all HSMs for
an application, or all HSMs for an LMK – dependent on the organization of
the key databases). This makes it easier for the Host application to switch
between old and new key databases, but could involve an interruption of
service if a Disaster Recovery is not available.
 A single HSM or a sub-set of the HSMs using a key database, leaving other
HSMs available to continue providing a service. This avoids a complete
interruption of service, but requires the Host application to determine
which key database to use for each HSM – e.g. by using the NO command.
 For the HSMs to be switched over:
 Suspend processing on the HSMs, or use a failover mechanism (such as an
SRM) to re-direct commands to an alternative HSM.
 Put the HSMs into secure state.
 On each HSM set the security setting Enforce key type 002 separation for
PCI HSM compliance.
 On each HSM delete the old LMK (e.g. using the DM Console command)
and load the new LMK (e.g. using the LK Console command).
 Resume processing on the group of HSMs, but using the new key database
and the modified Host application using the new key types.
 When the process is complete:
 archive the old key database
Note that the BW command does not allow keys to be migrated back to key type 002.
Therefore if there is any possibility that the security setting Enforce key type 002
separation for PCI HSM compliance is to be unset then the old key database must be
retained.

Making use of Disaster Recovery (DR) sites

Where a DR site is available that replicates the capabilities of the live site, it may be
appropriate to implement the changes on the DR site where they can be trialed and
tested. This will increase the level of confidence prior to going live.
Examples of using the BW Host Command

If a key is being migrated without change of LMK, where the key:
 is a TPK
 is a Triple-length DES key
 is using the default LMK
 has no message trailer
Field Value
Message Header 1234
Command Code BW
Key Type code E2
Key length 2
Key U12345678…ABCDEF
Delimiter ;
Key Type 70D
Note that when the Key Type Code is E2, no LMK is needed in the Key Change Storage.
If the same key is being migrated but this time with a change of LMK:
Field Value
Message Header 1234
Command Code BW
Key Type code F2
Key length 2
Key U12345678…ABCDEF
Delimiter ;
Key Type 70D
Note that when Key Type Code is F2, both the old LMK (that is being moved away from)
and the new LMK (that is being moved to) must be installed on the payShield 9000. See
Chapter 10 for a discussion about how to have one in LMK Live storage and one in LMK
Key Change Storage.
Thales Professional Services

Thales professional services can work with users in planning and implementing their key
migration.


 Create a Host process to migrate keys from key type 002 (and, if appropriate,
change LMK) using the BW Host command, and generate a new key database.
 At the appropriate time, set the HSM security setting Enforce key type 002
separation for PCI HSM compliance and start using the new key database.
Diebold Table re-encryption

This change will only affect users who are employing the Diebold Table.
The Diebold Table in legacy systems is encrypted using LMK pair 14-15 variant 0 (key
type 002); because of the PCI HSM key separation requirements this will be encrypted
under LMK pair 36-37 variant 6 (key type 60D) when the HSM is required to be PCI HSM
compliant. The encryption key type used is controlled by the security setting Enforce key
type 002 separation for PCI HSM compliance.
Immediately after setting the security setting Enforce key type 002 separation for PCI
HSM compliance on a payShield 9000, the following actions must be taken:
 Erase the existing encrypted version of the Diebold table using the LA Host
command to overwrite it with hexadecimal F digits. The Index Address must be
the same as that used when the encrypted Diebold table was set up; 32 blocks of
16 hexadecimal F digits should be written. (This step is unnecessary if the re-
encrypted Diebold table is to be written to the same location in user storage as
the existing encrypted table.)
 Use the R Console command to load the new Diebold Table. This requires access
to the plaintext version of the Diebold Table.
 Use the LC Host command to verify the Diebold Table.
 Repeat the above steps for each LMK which has an encrypted Diebold Table.
Note that if for any reason the security setting Enforce key type 002 separation for PCI
HSM compliance is unset the Diebold table will have to be re-entered again.

 Re-enter the Diebold table whenever the value of the security setting Enforce key
type 002 separation for PCI HSM compliance is changed.

Appendix A – Key Scheme Table

Whenever a key is entered into the HSM, it must be prefixed by a Key Scheme Tag which
allows the HSM to interpret the key correctly. The following values are supported:
Key
Scheme Notes
Tag
None/Z Encryption of a single-length DES key using X9.17 methods. Used for
encryption of keys under a variant LMK, and can also be used for the
import or export of keys.
U Encryption of a double-length DES key using the variant method; used
for encryption of keys under a variant LMK.
T Encryption of a triple-length DES key using the variant method; used
for encryption of keys under a variant LMK.
X Encryption of a double-length key using X9.17 methods; only available
for import and export of keys. This mode is enabled within the
Configure Security command,
Y Encryption of a triple-length key using X9.17 methods; only available
for import and export of keys. This mode is enabled within the
Configure Security command.
Encryption of keys using Verifone/GISKE methods; used for export of
V
DES keys.
Encryption of keys using TR-31 Key Block methods; only used for
R import or export of keys. The use of this scheme requires optional
license HSM9-LIC006.
Encryption of DES, AES, RSA & HMAC keys using Thales Key Block
S
methods; used for encryption of keys under a key block LMK.

Appendix B – Reduced Character Sets

The HSM optionally (through the security setting "Enable ZEK/TEK encryption") restricts
the character set that can be processed by the data encryption/ decryption commands.
The three options are described in the table below:
"ZEK/TEK Encryption" Setting Byte Value (hex)
ASCII data 0x20 – 0x7E
Binary data 0x00 – 0xFF
None -

Appendix C – Thales Key Block /

TR-31 Key Usage Conversion
When exporting from Thales Key Block format to TR-31 format, the following table is
used to convert the key blocks' Key Usage field:
Internal Exported
(Thales) Key Usage (TR-31)
Key Block Key Block
'41' Base Derivation Key Type 2 (BDK-2) 'B0'
'11' Card verification (American Express CSC) 'C0'
'12' Card verification (Mastercard CVC) 'C0'
'13' Card verification (Visa CVV) 'C0'
'21' Data encryption using a DEK (DEK) 'D0'
'22' Data encryption using a ZEK (ZEK) 'D0'
'31' Visa Cash Master Load Key (KML) 'E6'
'32' Dynamic CVV Master Key (MK-CVC3) 'E6'
'51' Terminal key encryption (TMK) 'K0'
'52' Zone key encryption (ZMK) 'K0'
'71' Terminal PIN encryption (TPK) 'P0'
'72' Zone PIN encryption (ZPK) 'P0'
'73' Terminal Key Register (TKR) 'P0'

Appendix D – Print Formatting Symbols

Printer formatting
The table shows the EBCDIC and ASCII codes for the printer formatting when printing
from the payShield 9000:
Symbol EBCDIC ASCII Meaning

>L 6E D3 3E 4C Line feed, carriage return.
>V 6E E5 3E 56 Vertical tab.
>H 6E C8 3E 48 Horizontal tab.
>F 6E C6 3E 46 Form feed.

>nnn 6E Fn Fn Fn 3E 3n 3n 3n Skip column nnn in relation to left
margin, where nnn is a 3-digit decimal
number.
^M 5F D6 5E 49 For a key document, print third clear
component.
^P 5F D7 5E 50 For a PIN mailer, print clear PIN for
mailer 1. For a key document, print
clear component.
^Q 5F D8 5E 51 For a PIN mailer, print clear PIN for
mailer 2. For a key document, print
clear component or encrypted TMK
(only one-up printing allowed for key
documents).
Print reference number for PIN mailer
^R 5F D9 5E 52
1.
Print reference number for PIN mailer
^S 5F E2 5E 53
2.
Print last 6 account number digits on
^T 5F E3 5E 54
PIN mailer 1.
Print last 6 account number digits on
Û 5F E4 5E 55
PIN mailer 2.
|<L><hh hh 6A <L> <hh 7C <L> <hh Send binary data to printer for
hh ..> hh hh ..> hh hh ..> example printer control string. |
character followed by the length of the
string in bytes <L> 0 - F then the
expanded hex string <hh hh hh ..>.
NOTE: in the columns to the left, the
"<" and ">" characters represent field
boundaries, and are NOT part of the
data to be sent to the printer. For
example (using ASCII), a string of 4
bytes which would be represented in
the 3rd column as 7C<4><1B283358>
would actually be sent as |41B283358
.
^0 5F F0 5E 30 Insert Print Field 0.


. . . .
. . . .
. . . .
^F 5F C6 5E 46 Insert Print Field 15.
^^10 5F 5F F1 F0 5E 5E 31 30 Insert Print Field 16.
. . . .
. . . .
^^1F 5F 5F F1 C6 5E 5E 31 46 Insert Print Field 31.
Printing PINs in Word Format

Two print formatting symbols are provided for printing PINs in word format.
For example:
ONE TWO THREE FOUR.
English is used as the default setting. The symbols can be used in addition to the
symbols for printing PINs in numeric format (e.g., 1234).

^V 5F E3 5E 56 Print the clear PIN in word format for mailer 1.
Can be used for either a one-up or a two-up
PIN mailer.
e.g. ONE TWO THREE FOUR
^W 5F E6 5E 57 Print the clear PIN in word format for mailer 2.

Can be used only for a two-up PIN mailer.
e.g. ONE TWO THREE FOUR
Printing PINs in Columns

Four print formatting symbols are provided for printing PINs (both words and numerics)
in columns. For example:
1 ONE
2 TWO
3 THREE
4 FOUR
For the following definition of print symbols an n is used to indicate which digit of a PIN is
to be printed. The relationship between PIN digits and n is as follows:
PIN 1 2 3 4 5 6 7 8 9 10 11 12

Digit
‘n’ 1 2 3 4 5 6 7 8 9 A B C

^Pn 5F D7 5E 50 Print the clear PIN digit n in number format
F1-F9 31-39 for mailer 1. Can be used for either a one-
or C1-C3 or 41-43 up or a two-up PIN mailer.
e.g. 1
^Qn 5F D8 5E 51 Print the clear PIN digit n in number format
F1-F9 31-39 for mailer 2. Can be used only for two-up
or C1-C3 or 41-43 PIN mailer.
e.g. 1
^Vn 5F E3 5E 56 Print the clear PIN digit n in word format
F1-F9 31-39 for mailer 1. Can be used for either a one-
or C1-C3 or 41-43 up or a two-up PIN mailer.
e.g. ONE
^Wn 5F E6 5E 57 Print the clear PIN digit n in word format
F1-F9 31-39 for mailer 2. Can be used only for two-up
or C1-C3 or 41-43 PIN mailer.
e.g. ONE

Appendix E – Example laser printer

formatting control codes
The following is an example of how an application can pass format control commands for
a laser printer to a payShield 9000 as print formatting symbols in PA and PC Host
commands, as discussed in Chapter 3 on PIN Printing and Solicitation. This information,
based on certain types of HP printer, should be viewed simply as an example to help
developers generate an appropriate symbol sequence for their own printer.
For a full explanation of the print formatting symbols see the payShield 9000 Host
Programmer’s Manual.
The example symbol sequence is as follows, and is explained in the subsequent table.
>L
>L|91B2661393030763048|91B2666313030793358|51B28313055|B1B28733170333
676323554|D1B266136373930763133343048
>005^P
>L|A1B287330703130763354|91B2661393030763048
>005^^00
>L
>005^^01
>L
>005^^02
>L
>005^^03
>L
>005^^04
>L
>005^^05
>L
>005^^06
>L
>F
Symbol Interpretation Notes

>L Line feed, carriage return
|91B2661393030763048 Send the following 9 bytes of Position the print head 900
binary data to the printer: decipoints vertically, 0
".&a900v0H" decipoints horizontally.
|91B2666313030793358 Send the following 9 bytes of Select overlay
binary data to the printer:
".&f100y3X"
|51B28313055 Send the following 5 bytes of Select font ID=10U (PC-8)
binary data to the printer:
".(10U"
|B1B2873317033367632 Send the following 11 bytes Select font Type Face
3554 of binary data to the printer:
".(s1p36v25T"

Symbol Interpretation Notes

|D1B2661363739307631 Send the following 13 bytes Position the print head 6790
33343048 of binary data to the printer: decipoints vertically, 1340
>005^P Skip to col. 5 and print the
PIN
|A1B2873307031307633 Send the following 10 bytes Select font Type Face
54 of binary data to the printer:
".(s0p10v3T"
|91B2661393030763048 Send the following 9 bytes of Position the print head 900
binary data to the printer: decipoints vertically, 0
>005^^00 Skip to col. 5 and print field 0
>F Form feed

Appendix F – SNMP MIB

Chapter 16 describes the payShield 9000's capabilities with respect to SNMP. This
appendix provides the MIB (Management Information Base) for the data that the
payShield 9000 can provide over SNMP. The MIB is also included on the payShield 9000
software media.
--------------------------------------------------------------------------------------------------
-- Thales e-Security, Inc.
-- Version: 1.0
-- Date: June 10, 2010
-- Changes:
THALES-PAYSHIELD DEFINITIONS ::= BEGIN
IMPORTS
NOTIFICATION-TYPE, OBJECT-TYPE, MODULE-IDENTITY,
enterprises, IpAddress, Integer32, Gauge32
FROM SNMPv2-SMI
TEXTUAL-CONVENTION, MacAddress, DisplayString,
DateAndTime, TruthValue
FROM SNMPv2-TC;
payshield9000MIB MODULE-IDENTITY
LAST-UPDATED "201606060810Z"
ORGANIZATION
"Thales e-Security"
CONTACT-INFO
"954 888 6200"
DESCRIPTION
"Provides utilization and state information for Thales e-Security's Payshield 9000
devices.
The utilization statistics provide information on the device's current host command
processing load. The state information provides status on currently loaded LMKs,
the status of processes used to service host and management commands,
and network interfaces.
Added Version,Logs,Health, Host Connection, Management,Printer and
PCI Security settings branches."
REVISION "201304030810Z"
DESCRIPTION
"Updates"
REVISION "201507122215Z"
DESCRIPTION
"Added support for snmp traps."
REVISION "201606060115Z"

DESCRIPTION
"Added MIB enhancements"
::= { ps9000 1 }
TC1 ::= TEXTUAL-CONVENTION

STATUS current
DESCRIPTION
""
SYNTAX Integer32
-- This MIB describes the structure of Thales e-Security's management

-- Information base. The variables are structured based on the RFC
-- for the Structure of Management Information (SMI), RFC1155, and
-- the format of the definitions is as per RFC1212, the Concise MIB
-- Defintions RFC
-- The object identifiers below have been assigned by the Thales e-Security
-- Management Group. All new Thales e-Security MIB's should be inserted into this
-- MIB.
thalesEsecurity OBJECT IDENTIFIER ::= { enterprises 4096 }

thalesEsecurityDevs OBJECT IDENTIFIER ::= { thalesEsecurity 1 }
payshield9000 OBJECT IDENTIFIER ::= { thalesEsecurityDevs 9000 }
thalesEsecurityMibs OBJECT IDENTIFIER ::= { thalesEsecurity 2 }
raProductMibs OBJECT IDENTIFIER ::= { thalesEsecurityMibs 2 }
-- Payshield 9000
ps9000 OBJECT IDENTIFIER ::= { raProductMibs 9000 }
-- Ths utilization statistics provide information on the device's current host command
-- processing load.
ps9000Util OBJECT IDENTIFIER ::= { ps9000 2 }

ps9000State OBJECT IDENTIFIER ::= { ps9000 3 }
ps9000StateTamper OBJECT IDENTIFIER ::= { ps9000State 2 }
ps9000Lmk OBJECT IDENTIFIER ::= { ps9000 4 }
ps9000Comms OBJECT IDENTIFIER ::= { ps9000 5 }
ps9000CommsMgmt OBJECT IDENTIFIER ::= { ps9000Comms 1 }
ps9000CommsHost OBJECT IDENTIFIER ::= { ps9000Comms 2 }
ps9000HostPort OBJECT IDENTIFIER ::= { ps9000CommsHost 5 }
-- System information for the Payshield 9000 device.
ps9000System OBJECT IDENTIFIER ::= { ps9000 6 }
-- Provides information on whether or not the Fraud Detection limits have been exceeded.

ps9000Fraud OBJECT IDENTIFIER ::= { ps9000 7 }
-- Contains information to identify the software running on the Paysheild.
ps9000Version OBJECT IDENTIFIER ::= { ps9000 8 }
-- Provides information pertaining to the licencing of the Paysheild.
ps9000Licensing OBJECT IDENTIFIER ::= { ps9000 9 }
-- Provides the number of and list of host commands that are enabled on this Paysheild.
ps9000EnabledHostCommands OBJECT IDENTIFIER ::= { ps9000 10 }
-- Info on the system logs.
ps9000Logs OBJECT IDENTIFIER ::= { ps9000 11 }
-- Info on the Errorlog
ps9000LogsErrorlog OBJECT IDENTIFIER ::= { ps9000Logs 1 }
-- Info about the system audit log.
ps9000LogsAuditlog OBJECT IDENTIFIER ::= { ps9000Logs 2 }
-- Data pertaining to the diagnostic self tests and the HealthCheckCounts.
ps9000Health OBJECT IDENTIFIER ::= { ps9000 12 }
-- Provides the number of diagnostic tests last performed and the results of each test.
ps9000HealthDiagSelfTest OBJECT IDENTIFIER ::= { ps9000Health 1 }
-- Health check counts for the Payshield. These cover reboots, tampers and suspicious
-- pin verification failure patterns
ps9000HealthCheckCounts OBJECT IDENTIFIER ::= { ps9000Health 2 }
-- Contains information about the configuration of Host interfaces. For enabled interfaces
-- details about the physical and protocol configuration are provided.
ps9000HostConnection OBJECT IDENTIFIER ::= { ps9000 13 }
-- Settings and states of the Host ethernet interfaces.

-- Only available when ps9000HostConnectionEthernetEnabled is TRUE.

ps9000HostConnectionEthernet OBJECT IDENTIFIER ::= { ps9000HostConnection 4 }
-- Settings and states of the Host async interface

-- . Only available when ConnectionSerialEnabled is TRUE.
ps9000HostConnectionAsync OBJECT IDENTIFIER ::= { ps9000HostConnection 5 }
-- Configuration of the FICON interface. Only available if ps9000HostConnectionEnabled

-- is true.
ps9000HostConnectionFicon OBJECT IDENTIFIER ::= { ps9000HostConnection 6 }
-- The detailed configuration info of the console async and ethernet management interfaces.
ps9000Management OBJECT IDENTIFIER ::= { ps9000 14 }
-- Configuration information about the Management ethernet interface.
ps9000ManagementEthernet OBJECT IDENTIFIER ::= { ps9000Management 1 }
-- Configuration information about the management serial console interface
ps9000ManagementConsole OBJECT IDENTIFIER ::= { ps9000Management 2 }
-- Data concerning the printer configuration of the unit. This includes the universally
-- used settings for all printers and the printer report on the actual printer hooked up.
-- This is the identical report the console QP command and the payShield Manager give.
ps9000Printer OBJECT IDENTIFIER ::= { ps9000 15 }
-- Payshield settings.
ps9000Settings OBJECT IDENTIFIER ::= { ps9000 16 }

Notifications OBJECT IDENTIFIER ::= { thalesEsecurity 999 }
paySheild OBJECT IDENTIFIER ::= { Notifications 1 }
ps9000AlarmdataStructures OBJECT IDENTIFIER ::= { paySheild 1 }
-- Information pertaining to the operation of the ps9000 fans.
ps9000AlarmFans OBJECT IDENTIFIER ::= { ps9000AlarmdataStructures 1 }
-- Provides information on the status of the HSM9000 power supply units
ps9000AlarmPSU OBJECT IDENTIFIER ::= { ps9000AlarmdataStructures 2 }

ps9000AlarmBadPortData OBJECT IDENTIFIER ::= { ps9000AlarmdataStructures 3 }
ps9000AlarmErrorLog OBJECT IDENTIFIER ::= { ps9000AlarmdataStructures 4 }
ps9000AlarmBattery OBJECT IDENTIFIER ::= { ps9000AlarmdataStructures 5 }
ps9000AlarmDiagnostic OBJECT IDENTIFIER ::= { ps9000AlarmdataStructures 6 }

ps9000AlarmFraud OBJECT IDENTIFIER ::= { ps9000AlarmdataStructures 7 }

ps9000AlarmErase OBJECT IDENTIFIER ::= { ps9000AlarmdataStructures 8 }
ps9000AlarmSettingsModified OBJECT IDENTIFIER ::= { ps9000AlarmdataStructures 9 }
ps9000tTraps OBJECT IDENTIFIER ::= { paySheild 2 }
ps9000UtilLoad OBJECT-TYPE
SYNTAX Gauge32 (0..100)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Displays the instantaneous load for all host commands processed by the
payshield 9000 in the previous time period. The load is represented as a percentage of the
total processing capacity of the device."
::= { ps9000Util 1 }
-- The octet string is formatted as follows (where CC is command code, e.g. A0):
--
-- <measurement period in seconds>,<num commands in report><LINE FEED>
-- "CC",<total number commands>;"CC",<total number commands>; ... etc...
ps9000UtilHostCmdVolume OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..484))
STATUS current
DESCRIPTION
"Lists all host commands that have been processed within the previous time
period and the number of transactions processed per second. Note that if a large variety of
commands are processed, then this list may be incomplete and will contain the commands that
consumed the highest proportion of the device's capacity."
::= { ps9000Util 2 }
ps9000UtillEnabled OBJECT-TYPE
SYNTAX TruthValue
STATUS current
DESCRIPTION
"True if Utilization turned on"
::= { ps9000Util 3 }
ps9000StateDevice OBJECT-TYPE
SYNTAX INTEGER {
payshieldStateUnavailable (1),
payshieldStateOnline (2),
payshieldStateOffline (3),
payshieldStateSecure (4)
}
STATUS current
DESCRIPTION
"Indicates the current state of the Payshield 9000"

::= { ps9000State 1 }
ps9000StateTamperState OBJECT-TYPE
SYNTAX INTEGER {
ps9000StateTamperStateUnknown (1),
ps9000StateTamperStateOK (2),
ps9000StateTamperStateTamper (3)
}
STATUS current
DESCRIPTION
"Indicates whether the device is currently in a tamper state."
::= { ps9000StateTamper 1 }
ps9000StateTamperDate OBJECT-TYPE
SYNTAX DateAndTime
STATUS current
DESCRIPTION
"The Date and Time that the last tamper event occurred. A NULL value indicates
that the unit has not registered any tamper events."
ps9000StateTamperCause OBJECT-TYPE
SYNTAX INTEGER {
ps9000StateTamperUnavailable (1),
ps9000StateTamperCauseTempOutOfRange (2),
ps9000StateTamperCauseBatteryLow (3),
ps9000StateTamperCauseEraseButtonPressed (4),
ps9000StateTamperCauseSecurityProcessorWatchdog (5),
ps9000StateTamperCauseSecurityProcessorRestart (6),
ps9000StateTamperCausePowerTooHigh (7),
ps9000StateTamperCauseMotionDetected (8),
ps9000StateTamperCauseCaseTampered (9),
ps9000StateTamperCauseTSPPModule (10),
ps9000StateTamperGeneral (11)
}
STATUS current
DESCRIPTION
"The cause of the last tamper event"
ps9000LmkNumLoaded OBJECT-TYPE
SYNTAX Integer32
STATUS current
DESCRIPTION

"The number of LMKs currently loaded into the device"

::= { ps9000Lmk 1 }
ps9000LmkNumTestLmksLoaded OBJECT-TYPE
SYNTAX Integer32
STATUS current
DESCRIPTION
"Indicates the number of 'test' LMKs loaded (as opposed to production). When
the Payshield 9000 is operating in a live environment, no test LMKs should be loaded and this
field should be returned as 0."
::= { ps9000Lmk 2 }
ps9000LmkNumOldLmksLoaded OBJECT-TYPE
SYNTAX Integer32
STATUS current
DESCRIPTION
"Indicates the number of old LMKs currently loaded in the Payshield 9000. Old
LMKs should be stored in the device only as long as they are needed for translation purposes.
Once all LMK-protected data has been placed under the control of the new LMK set, then the old
LMK set should be deleted."
::= { ps9000Lmk 3 }
ps9000LmkStatusTable OBJECT-TYPE
SYNTAX SEQUENCE OF Ps9000LmkStatusEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table that returns the status of all possible LMK sets."
::= { ps9000Lmk 4 }
ps9000LmkStatusEntry OBJECT-TYPE
SYNTAX Ps9000LmkStatusEntry
STATUS current
DESCRIPTION
"Row in the LMK Status table"
INDEX { ps9000LmkStatusIndex }
::= { ps9000LmkStatusTable 1 }
Ps9000LmkStatusEntry ::= SEQUENCE {

ps9000LmkStatusIndex
Integer32,
ps9000LmkStatusLoaded
TruthValue,
ps9000LmkStatusAuth
TruthValue,
ps9000LmkStatusNumAuthActivities
Integer32,

ps9000LmkStatusScheme
INTEGER,
ps9000LmkStatusAlgorithm
INTEGER,
ps9000LmkStatusLiveTest
INTEGER,
ps9000LmkStatusComments
OCTET STRING,
ps9000LmkStatusCheckDigits
DisplayString
}
ps9000LmkStatusIndex OBJECT-TYPE
SYNTAX Integer32 (1..20)
STATUS current
DESCRIPTION
"The index into the LMK Status table"
::= { ps9000LmkStatusEntry 1 }
ps9000LmkStatusLoaded OBJECT-TYPE
SYNTAX TruthValue
STATUS current
DESCRIPTION
"Indicates whether or not an LMK set is currently loaded at this index in the
table. Returns TRUE if loaded, else FALSE."
ps9000LmkStatusAuth OBJECT-TYPE
SYNTAX TruthValue
STATUS current
DESCRIPTION
"Authorised state of this LMK set. A value of TRUE indicates that the LMK is in
an authorised state; FALSE indicates that it is not authorised."
ps9000LmkStatusNumAuthActivities OBJECT-TYPE
SYNTAX Integer32
STATUS current
DESCRIPTION
"Indicates the number of authorised activities if the Payshield 9000 is set to
Multi-Auth mode. If not in multi-auth mode, this node returns 0."
ps9000LmkStatusScheme OBJECT-TYPE
SYNTAX INTEGER {

lmkSchemeUnknown (1),
lmkSchemeVariant (2),
lmkSchemeKey Block (3),
lmkSchemeAes (4)
}
STATUS current
DESCRIPTION
"Indicates the scheme of the loaded LMK set (variant, key block, or AES)"
ps9000LmkStatusAlgorithm OBJECT-TYPE
SYNTAX INTEGER {
lmkAlgorithmUnknown (1),
lmkAlgorithm3Des2Key (2),
lmkAlgorithm3Des3Key (3),
lmkAlgorithmAes256 (4)
}
STATUS current
DESCRIPTION
"Indicates the algorithm use by the LMK set for encryption. "
ps9000LmkStatusLiveTest OBJECT-TYPE
SYNTAX INTEGER {
lmkStatusUnknown (1),
lmkStatusLive (2),
lmkStatusTest (3)
}
STATUS current
DESCRIPTION
"Indicates the status of the currently loaded LMK set. This will be either
'Live' or 'Test'. Note that test LMKs should not be loaded into a Payshield 9000 operating in
a live customer environment."
ps9000LmkStatusComments OBJECT-TYPE
STATUS current
DESCRIPTION
"Textual description of the LMK set loaded. A string of length 0 indicates that
no description is stored"
ps9000LmkStatusCheckDigits OBJECT-TYPE
SYNTAX DisplayString

STATUS current
DESCRIPTION
"Indicates the check digits for an LMK. "
ps9000CommsMgmtConsoleState OBJECT-TYPE
SYNTAX INTEGER {
ps9000CommsMgmtConsoleStateUp (1),
ps9000CommsMgmtConsoleStateDown (2),
ps9000CommsMgmtConsoleStateDisabledByGui (3),
ps9000CommsMgmtConsoleStateUnavailable (4)
}
STATUS current
DESCRIPTION
" Indicates whether the process to service Console Management requests is
currently running. ps9000CommsMgmtConsoleStateUp (1) indicates that it is; all the other
states indicate that the console is currently inactive. "
::= { ps9000CommsMgmt 1 }
ps9000CommsMgmtGuiState OBJECT-TYPE
SYNTAX INTEGER {
ps9000CommsMgmtGuiStateUp (1),
ps9000CommsMgmtGuiStateDown (2),
ps9000CommsMgmtGuiStateUnavailable (3)
}
STATUS current
DESCRIPTION
" Indicates whether the process to service GUI requests is currently running.
ps9000CommsMgmtGuiStateUp (1) indicates that it is; all the other states indicate that the GUI
is currently inactive. "
::= { ps9000CommsMgmt 2 }
ps9000CommsHostAsyncServer OBJECT-TYPE
SYNTAX INTEGER {
ps9000CommsHostAsyncServerUp (1),
ps9000CommsHostAsyncServerDown (2),
ps9000CommsHostAsyncServerNotEnabled (3)
}
STATUS current
DESCRIPTION
" Indicates whether the process to service host commands is currently running
over the Async host port. ps9000CommsHostAsyncServerUp (1) indicates that it is; all the other
states indicate that Async is currently inactive. "
::= { ps9000CommsHost 1 }
ps9000CommsHostTcpServer OBJECT-TYPE

SYNTAX INTEGER {
ps9000CommsHostTcpServerUp (1),
ps9000CommsHostTcpServerDown (2),
ps9000CommsHostTcpServerNotEnabled (3)
}
STATUS current
DESCRIPTION
over the Ethernet host port using the TCP protocol. ps9000CommsHostTcpServerUp (1) indicates
that it is; all the other states indicate that TCP is currently inactive. "
ps9000CommsHostUdpServer OBJECT-TYPE
SYNTAX INTEGER {
ps9000CommsHostUdpServerUp (1),
ps9000CommsHostUdpServerDown (2),
ps9000CommsHostUdpServerNotEnabled (3)
}
STATUS current
DESCRIPTION
over the Ethernet host port using the UDP protocol. ps9000CommsHostUdpServerUp (1) indicates
that it is; all the other states indicate that UDP is currently inactive. "
ps9000CommsHostFiconServer OBJECT-TYPE
SYNTAX INTEGER {
ps9000CommsHostFiconServerUp (1),
ps9000CommsHostFiconServerDown (2),
ps9000CommsHostFiconServerNotEnabled (3)
}
STATUS current
DESCRIPTION
over the FICON host port. ps9000CommsHostFiconServerUp (1) indicates that it is; all the other
states indicate that FICON is currently inactive. "
ps9000HostPortEthernet1 OBJECT-TYPE
SYNTAX INTEGER {
ps9000HostPortEthernet1Up (1),
ps9000HostPortEthernet1Down (2),
ps9000HostPortEthernet1Unavailable (3),
ps9000HostPortEthernet1NotConfigured (4)
}
STATUS current

DESCRIPTION
" Indicates if the first host ethernet port is up and running."
::= { ps9000HostPort 1 }
ps9000HostPortEthernet2 OBJECT-TYPE
SYNTAX INTEGER {
ps9000HostPortEthernet2Up (1),
ps9000HostPortEthernet2Down (2),
ps9000HostPortEthernet2Unavailable (3),
ps9000HostPortEthernet2NotConfigured (4)
}
STATUS current
DESCRIPTION
" Indicates if the second host ethernet port is up and running."
ps9000HostPortAsync OBJECT-TYPE
SYNTAX INTEGER {
ps9000HostPortAsyncUp (1),
ps9000HostPortAsyncDown (2),
ps9000HostPortAsyncUnavailable (3),
ps9000HostPortAsyncNotConfigured (4)
}
STATUS current
DESCRIPTION
"Indicates if the Async Port (if present) is up and running."
ps9000HostPortFicon OBJECT-TYPE
SYNTAX INTEGER {
ps9000HostPortFiconUp (1),
ps9000HostPortFiconDown (2),
ps9000HostPortFiconUnavailable (3),
ps9000HostPortFiconNotConfigured (4)
}
STATUS current
DESCRIPTION
"Indicates if the FICON port (if present) is up and running."
ps9000SystemDateAndTime OBJECT-TYPE
SYNTAX DateAndTime
STATUS current
DESCRIPTION

"The date and time as reported by the system's Real Time Clock."
::= { ps9000System 1 }
ps9000SystemSerialNum OBJECT-TYPE
STATUS current
DESCRIPTION
"Displays the serial number of the Payshield 9000."
::= { ps9000System 2 }
ps9000FraudPinVerifyLimitsExceeded OBJECT-TYPE
SYNTAX TruthValue
STATUS current
DESCRIPTION
"Returns TRUE if fraud detection is turned on, and either the allowable PIN
verifications/minute, or PIN verifications/hour, have been exceeded."
::= { ps9000Fraud 1 }
ps9000FraudPinAttackLimitsExceeded OBJECT-TYPE
SYNTAX TruthValue
STATUS current
DESCRIPTION
"Returns TRUE if Fraud detection is turned on, AND the total number of PIN
attacks have exceeded the allowed count."
::= { ps9000Fraud 2 }
ps9000VersionSoftwareBaseRelease OBJECT-TYPE
STATUS current
DESCRIPTION
"Software base release of software running on the Payshield.
"
::= { ps9000Version 1 }
ps9000VersionSoftwareRevision OBJECT-TYPE
STATUS current
DESCRIPTION
"Software Revision of the software running on the Payshield.
"
::= { ps9000Version 2 }
ps9000VersionSoftwareBuildNumber OBJECT-TYPE

STATUS current
DESCRIPTION
"Build number of the software running on the Payshield.
"
::= { ps9000Version 3 }
ps9000VersionSoftwareHSMCoreAPIVersion OBJECT-TYPE
STATUS current
DESCRIPTION
"HSM core API version of the software running on the Payshield.
"
::= { ps9000Version 4 }
ps9000LicensingPerformanceModel OBJECT-TYPE
SYNTAX Integer32
STATUS current
DESCRIPTION
"The maximum transactions per second this unit is licensed for."
::= { ps9000Licensing 1 }
ps9000LicensingOptionalLicenseCount OBJECT-TYPE
SYNTAX Integer32
STATUS current
DESCRIPTION
"The number of optional licences this Payshield unit has installed."
ps9000LicensingOptionalLicensesList OBJECT-TYPE
STATUS current
DESCRIPTION
"The optional licenses this Payshield unit is licenced for separated by ';'
"
ps9000LicensingCryptoAlgorithmCount OBJECT-TYPE
SYNTAX Integer32
STATUS current
DESCRIPTION
"The number of Cryptographic Algorithms enabled by the Payshield's licencing."

ps9000LicensingCryptoAlgorithmList OBJECT-TYPE
SYNTAX OCTET STRING
STATUS current
DESCRIPTION
"The list of Crypto Algorithms the licencing supports. These will be
descriptive strings each
terminated by a semi-colon ';'.
There will be ps9000LicensingCryptoAlgorithmCount of them."
ps9000EnabledHostCommandsCount OBJECT-TYPE
SYNTAX Integer32
STATUS current
DESCRIPTION
"The number of host commands enabled on this Payshield.
"
::= { ps9000EnabledHostCommands 1 }
ps9000EnabledHostCommandsList OBJECT-TYPE
STATUS current
DESCRIPTION
"Enitre list of enabled commands separated by a semi-colon ';'.
"
::= { ps9000EnabledHostCommands 2 }
ps9000LogsErrorlogTotalCount OBJECT-TYPE
SYNTAX Integer32
STATUS current
DESCRIPTION
"Total number of entries in the errorlog
"
::= { ps9000LogsErrorlog 1 }
ps9000LogsAuditlogTotalCount OBJECT-TYPE
SYNTAX Integer32
STATUS current
DESCRIPTION
"Total number of entries in the audit log.
"
::= { ps9000LogsAuditlog 1 }

ps9000HealthDiagSelfTestTimeOfDay OBJECT-TYPE
SYNTAX Integer32
STATUS current
DESCRIPTION
"The number of minutess after midnite the diagnostic tests begins at.
"
::= { ps9000HealthDiagSelfTest 1 }
ps9000HealthDiagSelfTestOK OBJECT-TYPE
SYNTAX TruthValue
STATUS current
DESCRIPTION
"True unless one or more of the tests in the last self test failed .
"
ps9000HealthDiagSelfTestCount OBJECT-TYPE
SYNTAX Integer32
STATUS current
DESCRIPTION
"The number of self tests run last test cycle on this Payshield.
"
ps9000HealthDiagSelfTestList OBJECT-TYPE
STATUS current
DESCRIPTION
"The complete results of the last run self test.
Syntax of string Testname:testresult;
Test/results pairs are separated by a colon ':'
They are delimited by a semi-colon ; .
Results are the string 'passed' or 'failed'.
There are ps9000HealthDiagSelfTestCount of them.
"
ps9000HealthHealthCheckEnabled OBJECT-TYPE
SYNTAX TruthValue
STATUS current
DESCRIPTION

"Whether the Payshield is presently collecting health check data."

::= { ps9000HealthCheckCounts 1 }
ps9000HealthCheckCountsStartTime OBJECT-TYPE
SYNTAX DateAndTime
STATUS current
DESCRIPTION
"Date/Time of last health stats reset."
ps9000HealthCheckCountsEndTime OBJECT-TYPE
SYNTAX DateAndTime
STATUS current
DESCRIPTION
"Date/time of when stats collecting was last disabled.
If health stats are not disabled, the Date/Time when this field was read."
ps9000HealthCheckCountsRebootCount OBJECT-TYPE
SYNTAX Integer32
STATUS current
DESCRIPTION
"Number of times the Payshield rebooted since the last reset of health
counters"
ps9000HealthCheckCountsTamperCount OBJECT-TYPE
SYNTAX Integer32
STATUS current
DESCRIPTION
"The number of tampers detected since the last reset of health counters."
ps9000HealthCheckCountsPinFailuresMinuteLimit OBJECT-TYPE
SYNTAX Integer32
STATUS current
DESCRIPTION
"The number of minutes in which the maximum pin verify failures was exceeded
since the last reset of health counters"
ps9000HealthCheckCountsPinFailuresHourLimit OBJECT-TYPE
SYNTAX Integer32

STATUS current
DESCRIPTION
"The number of hours in which the maximum allowable pin failures per hour was
exceeded since the last reset of health counters"
ps9000HealthCheckCountsPinAttackLimitExceeded OBJECT-TYPE
SYNTAX Integer32
STATUS current
DESCRIPTION
"The number of times the pin attack limit was exceeded since the last reset of
health counters"
ps9000HostConnectionEthernetEnabled OBJECT-TYPE
SYNTAX TruthValue
STATUS current
DESCRIPTION
"Whether the Payshield is configured to provide ethernet host interfaces. "
::= { ps9000HostConnection 1 }
ps9000HostConnectionAsyncEnabled OBJECT-TYPE
SYNTAX TruthValue
STATUS current
DESCRIPTION
"Whether the Payshield is configured to provide an async host interface."
ps9000HostConnectionFiconEnabled OBJECT-TYPE
SYNTAX TruthValue
STATUS current
DESCRIPTION
"Whether or not the Payshield is configured to provide a FICON host interface."
ps9000HostConnectionEthernetIIfCount OBJECT-TYPE
SYNTAX Integer32
STATUS current
DESCRIPTION
"The number of physical ethernet interfaces enabled to process host commands.
This will be 1 or 2."
::= { ps9000HostConnectionEthernet 1 }

ps9000HostConnectionEthernetSSLEnabled OBJECT-TYPE
SYNTAX TruthValue
STATUS current
DESCRIPTION
"If true TLS/SSL has been enabled."
ps9000HostConnectionEthernetACLsEnabled OBJECT-TYPE
SYNTAX TruthValue
STATUS current
DESCRIPTION
"Whether Access Control Lists are enabled."
ps9000HostConnectionEthernetUDPEnabled OBJECT-TYPE
SYNTAX TruthValue
STATUS current
DESCRIPTION
"Whether UDP is enabled."
ps9000HostConnectionEthernetTCPEnabled OBJECT-TYPE
SYNTAX TruthValue
STATUS current
DESCRIPTION
"Whether TCP is enabled."
ps9000HostConnectionEthernetMaxTcpConnections OBJECT-TYPE
SYNTAX Integer32
STATUS current
DESCRIPTION
"The maximum number of TCP sessions allowed per interface.
(0-64)"
ps9000HostConnectionEthernetTcpKeepalive OBJECT-TYPE
SYNTAX Integer32
STATUS current
DESCRIPTION
"TCP keep alive timeout in minutes.

(0-120)
"
ps9000HostConnectionEthernetWellKnownPortTcp OBJECT-TYPE
SYNTAX Integer32
STATUS current
DESCRIPTION
"The well known TCP port
(0-65535)"
ps9000HostConnectionEthernetWellKnownPortTls OBJECT-TYPE
SYNTAX Integer32
STATUS current
DESCRIPTION
"The well known TLS port.
(0-65535)"
ps9000HostConnectionEthernetTable OBJECT-TYPE
SYNTAX SEQUENCE OF Ps9000HostConnectionEthernetEntry
STATUS current
DESCRIPTION
"The interface specific ethernet configuration/status information.
For interfaces that are disabled or fields that are not relevent,
all values will be set to a NULL value."
ps9000HostConnectionEthernetEntry OBJECT-TYPE
SYNTAX Ps9000HostConnectionEthernetEntry
STATUS current
DESCRIPTION
""
INDEX { ps9000HostConnectionEthernetIndex }
::= { ps9000HostConnectionEthernetTable 1 }
Ps9000HostConnectionEthernetEntry ::= SEQUENCE {

ps9000HostConnectionEthernetIndex
Integer32,
ps9000HostConnectionEthernetConfigured
TruthValue,
ps9000HostConnectionEthernetInterfaceNumber
Integer32,

ps9000HostConnectionEthernetConfigMethod
INTEGER,
ps9000HostConnectionEthernetHostName
DisplayString,
ps9000HostConnectionEthernetIpAddress
IpAddress,
ps9000HostConnectionEthernetSubnetMask
IpAddress,
ps9000HostConnectionEthernetGateway
IpAddress,
ps9000HostConnectionEthernetMacAddress
MacAddress,
ps9000HostConnectionEthernetPortSpeed
DisplayString,
ps9000HostConnectionNumberOfConnectionsUsed
Integer32
}
ps9000HostConnectionEthernetIndex OBJECT-TYPE
STATUS current
DESCRIPTION
""
::= { ps9000HostConnectionEthernetEntry 1 }
ps9000HostConnectionEthernetConfigured OBJECT-TYPE
SYNTAX TruthValue
STATUS current
DESCRIPTION
"Tells whether a row of the table is configured. For a 1 interface system it is
possible
that the configured interface could be either the first or second one.
"
ps9000HostConnectionEthernetInterfaceNumber OBJECT-TYPE
STATUS current
DESCRIPTION
"This binds a row to a physical host ethernet interface.
1 corresponds to Ethernet interface HostPortEthernet1
2 corresponds to Ethernet interface HostPortEthernett2"
ps9000HostConnectionEthernetConfigMethod OBJECT-TYPE

SYNTAX INTEGER {
ps9000HostConnectionEthernetConfigMethodStatic (0),
ps9000HostConnectionEthernetConfigMethodDHCP (1),
ps9000HostConnectionEthernetConfigMethodUnknown (2)
}
STATUS current
DESCRIPTION
"DHCP and static ip configuration are the possibilities . When we are
statically configured we report
the addresses and such are set from the payShield's configuration. When we use
DHCP these
values are configured by the network.
"
ps9000HostConnectionEthernetHostName OBJECT-TYPE
STATUS current
DESCRIPTION
"Network Name is present for a DHCP configured port only.
If the ethernet port is configured statically set to 'NotApplicable'.
If the ethernet port is not configured set to 'Interface not enabled'."
ps9000HostConnectionEthernetIpAddress OBJECT-TYPE
SYNTAX IpAddress
STATUS current
DESCRIPTION
"IP address for this interface.
If this interface is not enabled returns 000.000.000.000"
ps9000HostConnectionEthernetSubnetMask OBJECT-TYPE
SYNTAX IpAddress
STATUS current
DESCRIPTION
"Subnet mask for this interface.
If this interface is not enabled returns 000.000.000.000"
ps9000HostConnectionEthernetGateway OBJECT-TYPE
SYNTAX IpAddress
STATUS current

DESCRIPTION
"Gateway ip address used by this interface.
if this interface is not enabled returns 000,000,000,000"
ps9000HostConnectionEthernetMacAddress OBJECT-TYPE
SYNTAX MacAddress
STATUS current
DESCRIPTION
"MAC address for this ethernet interface.
If this ionterface is not enabled returns 00.00.00.00.00.00"
ps9000HostConnectionEthernetPortSpeed OBJECT-TYPE
STATUS current
DESCRIPTION
"Describes the speed/duplex this port is configured at.
If the port is configured for 'ethernet autoselect' returns:
'ethernet autoselect(speed/duplex )'
If the ethernet interface is not confiigured returns:
'Interface not enabled'"
ps9000HostConnectionNumberOfConnectionsUsed OBJECT-TYPE
SYNTAX Integer32
STATUS current
DESCRIPTION
"The Number of TCP connections in use for this physical interface.
range (0-ps9000HostConnectionMaxTcpConnections)"
ps9000HostConnectionAsyncMode OBJECT-TYPE
SYNTAX INTEGER {
ps9000HostConnectionAsyncAsync (0),
ps9000HostConnectionAsyncTransparent (1),
ps9000HostConnectionAsyncModeUnknown (3)
}
STATUS current
DESCRIPTION
"The Payshield async host interface can be configured for Async and Transparent
formatting of the async data stream."
::= { ps9000HostConnectionAsync 1 }

ps9000HostConnectionAsyncTerminatingSequence OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(2))
STATUS current
DESCRIPTION
"Two hex values each 0 to 255.
"
ps9000HostConnectionAsyncDeviceName OBJECT-TYPE
STATUS current
DESCRIPTION
"The name of the async controller
example:
USB-Serial Controller by Prolific Technology Inc."
ps9000HostConnectionPortName OBJECT-TYPE
STATUS current
DESCRIPTION
"A string describing the name of the physical port. This was selected by the
user when
the serial port was configured.
"
ps9000HostConnectionAsyncStatus OBJECT-TYPE
SYNTAX INTEGER {
ps9000HostConnectionAsyncReady (0),
ps9000HostConnectionAsyncMissing (1),
ps9000HostConnectionAsyncUnavailable (2),
ps9000HostConnectionAsyncError (3)
}
STATUS current
DESCRIPTION
"The status of the Host Async interface"
ps9000HostConnectionAsyncBaud OBJECT-TYPE
SYNTAX INTEGER {
ps9000HostConnectionAsyncBaudUnknown (0),
ps9000HostConnectionAsyncBaud1200 (1200),

ps9000HostConnectionAsyncBaud115200 (115200)
}
STATUS current
DESCRIPTION
"The baud rate for the host async interface. "
ps9000HostConnectionAsyncDataBits OBJECT-TYPE
SYNTAX INTEGER {
ps9000HostConnectionAsyncDataBits5 (5),
ps9000HostConnectionAsyncDataBitsUnknown (99)
}
STATUS current
DESCRIPTION
"The number of data bits for the host async interface.
"
ps9000HostConnectionAsyncStopBits OBJECT-TYPE
SYNTAX INTEGER {
ps9000HostConnectionAsyncStopBits1 (1),
ps9000HostConnectionAsyncStopBits2 (2),
ps9000HostConnectionAsyncStopBitsUnknown (99)
}
STATUS current
DESCRIPTION
"The number of stop bits for the host async interface.
"
ps9000HostConnectionAsyncFlowControl OBJECT-TYPE
SYNTAX INTEGER {
ps9000HostConnectionAsyncFlowControlNone (0),
ps9000HostConnectionAsyncFlowControlHW (1),
ps9000HostConnectionAsyncFlowControlSW (2),
ps9000HostConnectionAsyncFlowControlUnknown (4)
}

STATUS current
DESCRIPTION
"The flow control setting of the host async interface."
ps9000HostConnectionAsyncParity OBJECT-TYPE
SYNTAX INTEGER {
ps9000HostConnectionAsyncParityOdd (0),
ps9000HostConnectionAsyncParityEven (1),
ps9000HostConnectionAsyncParityNone (2),
ps9000HostConnectionAsyncParityUnknown (3)
}
STATUS current
DESCRIPTION
"The parity setting of the host async interface."
ps9000HostConnectionFiconControlUnitImage OBJECT-TYPE
STATUS current
DESCRIPTION
"This is the control unit address defined in the mainframe I/O definition
(CUADD on CNTLUNIT statement).
(0-255)"
::= { ps9000HostConnectionFicon 1 }
ps9000HostConnectionFiconControlUnitAddress OBJECT-TYPE
STATUS current
DESCRIPTION
"The starting unit address for this control unit.
16 devices are enumerated from this point (UNITADD on CNTLUNIT statement).
(0-255)"
ps9000HostConnectionFiconMIH OBJECT-TYPE
SYNTAX Integer32
STATUS current
DESCRIPTION
"This specifies the missing interrupt handler value to be used in the read
device
characteristics CCW for the mainframe. It is in minutes.
If set to 0, the mainframe setting is used

(0-60)"
ps9000ManagementEthernetEnabled OBJECT-TYPE
SYNTAX TruthValue
STATUS current
DESCRIPTION
"Whether payShield Manager is enabled."
::= { ps9000ManagementEthernet 1 }
ps9000ManagementEthernetConfigMethod OBJECT-TYPE
SYNTAX INTEGER {
ps9000ManagementEthernetConfigMethodStatic (0),
ps9000ManagementEthernetConfigMethodDHCP (1),
ps9000ManagementEthernetConfigMethodUnknown (3)
}
STATUS current
DESCRIPTION
"The method the management ethernet interface uses to obtain its ethernet
address.
ps9000ManagementEthernetConfigMethodStatic - uses local stored information
ps9000ManagementEthernetConfigMethodDHCP - obtains settings from the network"
ps9000ManagementEthernetNetworkName OBJECT-TYPE
STATUS current
DESCRIPTION
"The name the Payshield assigns to this interface if in DHCP mode.
If the ethernet port is configured statically set to 'DoesNotApply'."
ps9000ManagementEthernetIpAddress OBJECT-TYPE
SYNTAX IpAddress
STATUS current
DESCRIPTION
"The managment ethernet interface's ip address.
If ps9000ManagementEthernetConfigMethod is set to DHCP, it will be set by the
network.
If ps9000ManagementEthernetConfigMethoS is set to static it will be set to the
payShield's
configured value.
A value of 00:00:00:00 means it is not successfuly fetched."

ps9000ManagementEthernetSubnetMask OBJECT-TYPE
SYNTAX IpAddress
STATUS current
DESCRIPTION
"The managment ethernet interface's ip subnet mask.
network.
If ps9000ManagementEthernetConfigMethodt is set to static it will be to the
Payshield's
configured value.
A value of 00:00:00:00 means it was not successfuly fetched."
ps9000ManagementEthernetGateway OBJECT-TYPE
SYNTAX IpAddress
STATUS current
DESCRIPTION
"The managment ethernet interface's ip gateway address.
network.
If ps9000ManagementEthernetConfigMethod is set to Static it will be set to the
Payshield's
configured value.
A value of 00:00:00:00 means it was not successfuly fetched."
ps9000ManagementEthernetMacAddress OBJECT-TYPE
SYNTAX MacAddress
STATUS current
DESCRIPTION
"The managment ethernet interface's MAC address.
Will be set to 00:00:00:00:00:00 if not successfuly fetched."
ps9000ManagementEthernetPortSpeed OBJECT-TYPE
STATUS current
DESCRIPTION
"String that describes the speed configured and the actual connection
properties.
Form is config (actual)
eg : ethernet autoselect (100baseTX full-duplex)"
ps9000ManagementConsoleBaud OBJECT-TYPE
SYNTAX INTEGER {

ps9000ManagementConsoleBaudUnknown (0),
ps9000ManagementConsoleBaud1200 (1200),
ps9000ManagementConsoleBaud115200 (115200)
}
STATUS current
DESCRIPTION
"Baud rate for Management console async interface."
::= { ps9000ManagementConsole 1 }
ps9000ManagementConsoleDataBits OBJECT-TYPE
SYNTAX INTEGER {
ps9000ManagementConsoleDataBits5 (5),
ps9000ManagementConsoleDataBitsUnknown (99)
}
STATUS current
DESCRIPTION
"The length of data in bits for the management console async interface, "
ps9000ManagementConsoleStopBits OBJECT-TYPE
SYNTAX INTEGER {
ps9000ManagementConsoleStopBits1 (1),
ps9000ManagementConsoleStopBits2 (2),
ps9000ManagementConsoleStopBitsUnknown (99)
}
STATUS current
DESCRIPTION
"Number of stop bits for the Console Management async interface. "
ps9000ManagementConsoleFlowControl OBJECT-TYPE
SYNTAX INTEGER {
ps9000ManagementConsoleFlowControlNone (0),
ps9000ManagementConsoleFlowControlSW (1),
ps9000ManagementConsoleFlowControlHW (2),
ps9000ManagementConsoleFlowControlUnknown (3)

}
STATUS current
DESCRIPTION
"Flow control setting for the management console async interface."
ps9000ManagementConsoleParity OBJECT-TYPE
SYNTAX INTEGER {
ps9000ManagementConsoleParityNone (0),
ps9000ManagementConsoleParityOdd (1),
ps9000ManagementConsoleParityEven (2),
ps9000ManagementConsoleParityUnknown (3)
}
STATUS current
DESCRIPTION
"The parity setting of the management console async interface."
ps9000Printer-LF-CR-reversed OBJECT-TYPE
SYNTAX TruthValue
STATUS current
DESCRIPTION
"Whether CR and LF are reversed "
::= { ps9000Printer 1 }
ps9000PrinterTimeout-ms OBJECT-TYPE
SYNTAX Integer32
STATUS current
DESCRIPTION
"Printer timeout value in milliseconds.
(1000, 86400000)"
::= { ps9000Printer 2 }
ps9000PrinterDelay-ms OBJECT-TYPE
SYNTAX Integer32
STATUS current
DESCRIPTION
"Printer delay in milliseconds
(0-7200000)"
::= { ps9000Printer 3 }
ps9000PrinterReport OBJECT-TYPE

STATUS current
DESCRIPTION
"The report of the dynamic state of printers in the system as produced fo QP
and the
payShield Manager. It will consist of printable characters."
::= { ps9000Printer 4 }
ps9000SettingsPCICompliant OBJECT-TYPE
SYNTAX TruthValue
STATUS current
DESCRIPTION
"True if all security settings are PCI compliant.
"
::= { ps9000Settings 1 }
ps9000FanID OBJECT-TYPE
SYNTAX INTEGER {
ps9000Fan1 (1),
ps9000Fan2 (2)
}
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"Identifies fan1 or fan2."
::= { ps9000AlarmFans 1 }
ps9000FanState OBJECT-TYPE
SYNTAX INTEGER {
ps9000FanOK (0),
ps9000FansCtl (1),
ps9000FanFail (2),
ps9000FanSlow (3),
ps9000FanFast (4)
}
STATUS current
DESCRIPTION
"Provides the status of a fan."
::= { ps9000AlarmFans 2 }
ps9000PsuNumber OBJECT-TYPE
SYNTAX INTEGER {
ps9000PSU-1 (1),
ps9000PSU-2 (2)
}

STATUS current
DESCRIPTION
"Identifies the power supply unit. 1 or 2."
::= { ps9000AlarmPSU 1 }
ps9000BadDataPhysicalPort OBJECT-TYPE
SYNTAX INTEGER {
ps9000Host1 (1),
ps9000Host2 (2),
ps9000Async (3),
ps9000Ficon (4)
}
STATUS current
DESCRIPTION
"The Physical port the bad data was detected on."
::= { ps9000AlarmBadPortData 1 }
ps9000BadDataProtocol OBJECT-TYPE
SYNTAX INTEGER {
ps9000TCP (0),
ps9000UDP (1),
ps9000Async (2),
ps9000Ficon (3)
}
STATUS current
DESCRIPTION
"The method that bad data detected was transmitted."
::= { ps9000AlarmBadPortData 2 }
-- Text of last error sent to ErrorLog
ps9000ErrorLogData OBJECT-TYPE
STATUS current
DESCRIPTION
"A textual error log entry as stored in the system. "
::= { ps9000AlarmErrorLog 1 }
ps9000BatteryState OBJECT-TYPE
SYNTAX INTEGER {
ps9000BatteryStateOK (0),
ps9000BatteryStateWarning (1),
ps9000BatteryStateFailure (2)
}

STATUS current
DESCRIPTION
"State of the battery. "
::= { ps9000AlarmBattery 1 }
ps9000DiagnosticID OBJECT-TYPE
SYNTAX INTEGER {
ps9000Diag-AES (1),
ps9000Diag-DES (2),
ps9000Diag-MD5 (3),
ps9000Diag-Memory (4),
ps9000Diag-Power (5),
ps9000Diag-RNG (6),
ps9000Diag-RSA (7),
ps9000Diag-RTC (8),
ps9000Diag-SHA (9),
ps9000Diag-Temperature (10),
ps9000Diag-Fans (11),
ps9000Diag-Voltage (12),
ps9000Diag-cust1 (13),
ps9000Diag-Async (33),
ps9000Diag-Udp (34),
ps9000Diag-Tcp (35),
ps9000Diag-Ficon (36),
ps9000Diag-custproto1 (37),

ps9000Diag-custproto8 (44)
}
STATUS current
DESCRIPTION
"Diagnostic identifier as a code."
::= { ps9000AlarmDiagnostic 1 }
ps9000DiagnosticString OBJECT-TYPE
STATUS current
DESCRIPTION
"Diagnostic identifier as a string."
::= { ps9000AlarmDiagnostic 2 }
ps9000FraudType OBJECT-TYPE
SYNTAX INTEGER {
ps9000FraudExceededFailuresPerMinute (1),
ps9000FraudExceededFailuresPerHour (2),
ps9000FraudExceededAttackLimit (3)
}
STATUS current
DESCRIPTION
"Indicates what sort of Fraud event took place."
::= { ps9000AlarmFraud 1 }
ps9000AlarmEraseTimeandDate OBJECT-TYPE
SYNTAX DateAndTime (SIZE(8))
STATUS current
DESCRIPTION
"Indicates the time and date the erase button was pressed."
::= { ps9000AlarmErase 1 }
ps9000ModifiedSetting OBJECT-TYPE
SYNTAX INTEGER {
ps9000ModifiedSecuritySetting (1),
ps9000ModifiedPciSetting (2),
ps9000ModifiedAuditedItems (3),
ps9000ModifiedEnabledPinblocks (4)
}
STATUS current
DESCRIPTION

"Collection of settings whose modifications will trigger a notification"

::= { ps9000AlarmSettingsModified 1 }
ps9000PowerOnAlarm NOTIFICATION-TYPE
STATUS current
DESCRIPTION
"SNMP Trap indicating the unit has been powered up."
::= { ps9000tTraps 1 }
ps9000RestartAlarm NOTIFICATION-TYPE
STATUS current
DESCRIPTION
"SNMP trap generated when the reset button has been pressed."
::= { ps9000tTraps 2 }
ps9000EraseAlarm NOTIFICATION-TYPE
OBJECTS { ps9000AlarmEraseTimeandDate }
STATUS current
DESCRIPTION
"SNMP trap indicating that the Erase button was pressed."
::= { ps9000tTraps 3 }
ps9000NewLicenceAlarm NOTIFICATION-TYPE
STATUS current
DESCRIPTION
"SNMPA trap indicating the instalation of a new licence."
::= { ps9000tTraps 4 }
ps9000NewSoftwareAlarm NOTIFICATION-TYPE
STATUS current
DESCRIPTION
"SNMP Trap indicating that new software has been installed."
::= { ps9000tTraps 5 }
ps9000PSUFailureAlarm NOTIFICATION-TYPE
OBJECTS { ps9000PsuNumber }
STATUS current
DESCRIPTION
"SNMP trap indicating that a Power supply unit has failed."
::= { ps9000tTraps 6 }
ps9000BatteryAlarm NOTIFICATION-TYPE
OBJECTS { ps9000BatteryState }
STATUS current
DESCRIPTION
"SNMP trap indicating a battery problem. Either it is in the warning zone of
2.5volts - 2.8 volts
or in the fault zone of < 2.5 volts."

::= { ps9000tTraps 7 }
ps9000FanAlarm NOTIFICATION-TYPE
OBJECTS { ps9000FanID,
ps9000FanState }
STATUS current
DESCRIPTION
"SNMP trap notifying that a Fan is Operating incorrectly."
::= { ps9000tTraps 8 }
ps9000TamperAlarm NOTIFICATION-TYPE
OBJECTS { ps9000StateTamperCause,
ps9000StateTamperDate,
ps9000StateTamperState }
STATUS current
DESCRIPTION
"SNMP trap indicating a tamper has been detected. Detected tamper is reported."
::= { ps9000tTraps 9 }
ps9000HostPortBadDataAlarm NOTIFICATION-TYPE
OBJECTS { ps9000BadDataPhysicalPort,
ps9000BadDataProtocol }
STATUS current
DESCRIPTION
"SNMP Trap indicating that protocol breaking data has arrived on a port.
Indicates which physical interface it arrived on and what protocol was being
used."
::= { ps9000tTraps 10 }
ps9000FraudAlarm NOTIFICATION-TYPE
OBJECTS { ps9000FraudType }
STATUS current
DESCRIPTION
"SNMP Trap that indicates a fraud limit was exceeded. "
::= { ps9000tTraps 11 }
ps9000DiagnosticTestFailureAlarm NOTIFICATION-TYPE
OBJECTS { ps9000DiagnosticID,
ps9000DiagnosticString }
STATUS current
DESCRIPTION
"SNMP Trap indicating a diagnostivc test has failed. Indicates which test
failed."
::= { ps9000tTraps 12 }
ps9000ErrorlogAlarm NOTIFICATION-TYPE
OBJECTS { ps9000ErrorLogData }
STATUS current

DESCRIPTION
"SNMP Trap that indicates an errorlog entry has been filed. Contains the
entry."
::= { ps9000tTraps 13 }
ps9000SettingsModifiedAlarm NOTIFICATION-TYPE
OBJECTS { ps9000ModifiedSetting }
STATUS current
DESCRIPTION
"SNMP Trap that indicates a setting of the Payshield has been modified
.It includes a ps9000ModifiedSetting object which ids which setting was
changed."
::= { ps9000tTraps 14 }
END
-- This MIB was created using NuDesign Team's Visual MIBuilder (Ver 4.7).

1270A542-033 Host Programmer v3.1

Uploaded by

Copyright:

Available Formats

1270A542-033 Host Programmer v3.1

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

1270A542-033 Host Programmer v3.1

Uploaded by

Copyright:

Available Formats

Thales e-Security

payShield 9000 v3.1

Host Programmer’s Manual

Setting up the PIN Mailer form at the payShield 9000 ................................................................................ 29

Thales e-Security Page 3 30 March 2017

Sample Data Definitions (2048-bit RSA keys) .............................................................................................. 78

Thales e-Security Page 4 30 March 2017

About LMKs................................................................................................................................................ 117

Thales e-Security Page 5 30 March 2017

Thales e-Security Page 6 30 March 2017

DEFINITIONS OF THALES PIN BLOCK FORMATS ............................................................. 171

Thales e-Security Page 7 30 March 2017

New Error Log entry ................................................................................................................................... 197

Thales e-Security Page 8 30 March 2017

End User License Agreement

Thales e-Security Page 9 30 March 2017

6. Intellectual Property Indemnification

Thales e-Security Page 10 30 March 2017

11. U.S. Government Acquisitions

12. Governing Law and Dispute Resolution

Thales e-Security Page 11 30 March 2017

13. Elliptic Curve Cryptography Activation

Thales e-Security Page 12 30 March 2017

1270A542-033 Issue 33 payShield 9000 v3.1 March 2017

Thales e-Security Page 13 30 March 2017

1 payShield 9000 Console Reference Manual

Thales e-Security Page 14 30 March 2017

Typically an HSM is used in a real-time, online environment performing key

This manual contains programming notes to assist the application programmer. A

PCI HSM Certification and Compliance

Thales e-Security Page 15 30 March 2017

Command Message Format

Start of Text Character

Thales e-Security Page 16 30 March 2017

End of Text Character

Response Message Format

 Start of Text Character (if applicable)

End of Text Character

Data Message Trailer

Thales e-Security Page 17 30 March 2017

Start of Text Character

End of Text Characters

In an asynchronous system it can be configured to be one or two characters in length,

Thales e-Security Page 18 30 March 2017

ASCII Character Codes

ASCII HEX ASCII HEX ASCII HEX ASCII HEX

EBCDIC Character Codes

Thales e-Security Page 19 30 March 2017

EBCDIC HEX EBCDIC HEX EBCDIC HEX EBCDIC HEX

Input/Output Flow Control

Thales e-Security Page 20 30 March 2017

Thales e-Security Page 21 30 March 2017

Use of Multiple HSM units

Thales e-Security Page 22 30 March 2017

Chapter 2 – Host Connections

 Asynchronous RS232 (via a USB-to-serial cable)

Asynchronous Connected Option

Transparent Asynchronous Connected Option

STX COUNT COMMAND/DATA LRC ETX

Thales e-Security Page 23 30 March 2017