1270A593-034 General Information v3.2

Thales e-Security
payShield 9000 v3.2
General Information Manual

1270A593-034 3 August 2017
payShield 9000 General Information Manual
Contents
CONTENTS .......................................................................................................... 2
END USER LICENSE AGREEMENT ......................................................................... 8
REVISION STATUS ............................................................................................ 12
CHAPTER 1 – INTRODUCTION........................................................................... 13
PAYSHIELD9000 MANUALS .................................................................................... 13
OVERVIEW OF THE PAYSHIELD 9000 .......................................................................... 14
USE OF MULTIPLE HSM UNITS ................................................................................. 14
PCI HSM CERTIFICATION AND COMPLIANCE ................................................................. 15
BACKWARDS COMPATIBILITY.................................................................................... 15
CHAPTER 2 – DESCRIPTION OF THE PAYSHIELD 9000 ..................................... 17
PHYSICAL DESCRIPTION ......................................................................................... 17
FRONT PANEL ..................................................................................................... 17
Keys and Locks ............................................................................................................................................. 17
Smartcard Reader ........................................................................................................................................ 18
LEDs ............................................................................................................................................................. 18
USB Ports ..................................................................................................................................................... 20
Reset Button ................................................................................................................................................ 20
REAR PANEL ....................................................................................................... 20
Power Sockets .............................................................................................................................................. 20
Ethernet Host Port 1 and 2 .......................................................................................................................... 21
Ethernet Management Port ......................................................................................................................... 21
Ethernet Aux Port ........................................................................................................................................ 21
USB Ports ..................................................................................................................................................... 21
FICON Ports.................................................................................................................................................. 21
Erase button ................................................................................................................................................ 22
MECHANICAL AND ELECTRICAL SPECIFICATIONS ............................................................. 22
Dimensions .................................................................................................................................................. 22
Power (per Unit) .......................................................................................................................................... 22
Environmental ............................................................................................................................................. 22
PAYSHIELD 9000 HSM FACILITIES ............................................................................ 22
Key Management ........................................................................................................................................ 22
Types of Keys Used by an HSM .................................................................................................................... 23
Error Log ...................................................................................................................................................... 25
Audit Log...................................................................................................................................................... 26
Temperature and Motion Sensors ............................................................................................................... 26
Utilisation and Health Check Data ............................................................................................................... 26
CHAPTER 3 – LOCAL MASTER KEYS (LMKS) ...................................................... 28
CHAPTER 4 – VARIANT KEY SCHEME ................................................................ 29
CHAPTER 5 – KEY BLOCK KEY SCHEME ............................................................. 30
CHAPTER 6 – PIN BLOCK FORMATS .................................................................. 31
CHAPTER 7 – FRAUD DETECTION FUNCTIONS .................................................. 32
CHAPTER 8 – UTILIZATION DATA ..................................................................... 33
DATA PROVIDED TO THE USER ................................................................................. 33
DATA COLLECTION PERIOD...................................................................................... 33
INTERPRETING THE OUTPUT ..................................................................................... 34
Overall HSM Loading ................................................................................................................................... 34
Host Command Volumes ............................................................................................................................. 37
REPORTING MECHANISMS ....................................................................................... 38
CONSOLE COMMANDS............................................................................................ 38
PAYSHIELD MANAGER COMMANDS ............................................................................. 39

HOST COMMANDS ................................................................................................ 39
CHAPTER 9 – HEALTH CHECK DATA .................................................................. 41
DATA PROVIDED TO THE USER ................................................................................. 41
Accumulated Counts. ................................................................................................................................... 41
Instantaneous Status. .................................................................................................................................. 42
REPORTING MECHANISMS ....................................................................................... 43
CONSOLE COMMANDS............................................................................................ 44
PAYSHIELD MANAGER COMMANDS ............................................................................. 44
HOST COMMANDS ................................................................................................ 45
CHAPTER 10 – PCI HSM COMPLIANCE .............................................................. 46
INTRODUCTION ................................................................................................... 46
WHAT IS NEEDED TO BE PCI HSM COMPLIANT? ............................................................. 46
Use of non-certified software ...................................................................................................................... 47
HOW TO TELL WHETHER YOUR PAYSHIELD 9000 IS PCI HSM COMPLIANT .............................. 47
Ordering PCI HSM compliant units .............................................................................................................. 48
ONLINE CERTIFICATES ........................................................................................... 49
SHIPMENT TO THE END-USER AND SUBSEQUENT HANDLING OF THE PAYSHIELD 9000 .................. 49
Shipping ....................................................................................................................................................... 50
After Delivery to the end user's delivery address ......................................................................................... 54
Returning a payShield 9000 for Servicing .................................................................................................... 55
INTEROPERABILITY WITH HSM 8000 ......................................................................... 56
CHANGES INTRODUCED FOR PCI HSM CERTIFICATION ..................................................... 56
USER AUTHENTICATION ......................................................................................... 57
Authentication by password ........................................................................................................................ 57
Minimum PIN Length ................................................................................................................................... 57
Smartcard PIN entry timeout ....................................................................................................................... 57
MULTIPLE COMPONENTS WHEN FORMING KEYS .............................................................. 57
TIME LIMITATION ON AUTHORIZED STATES ................................................................... 57
Single Authorized State................................................................................................................................ 58
Multiple Authorized Activities...................................................................................................................... 58
KEY SEPARATION ................................................................................................. 58
Key Block LMKs ............................................................................................................................................ 58
Variant LMK Key Type changes.................................................................................................................... 58
Migrating keys to the new key type ............................................................................................................ 59
Disabled Host Commands ............................................................................................................................ 60
Changes to parameters when sending Host commands ............................................................................. 60
Interoperability with HSM 8000 units .......................................................................................................... 61
RESTRICTIONS ON PIN BLOCK FORMAT TRANSLATIONS AND USAGE....................................... 61
Applying the restrictions .............................................................................................................................. 61
Restrictions on PIN Block Format translations............................................................................................. 61
Restrictions on PIN Block Format usage ...................................................................................................... 63
AUTOMATED SELF-TESTS ........................................................................................ 63
ENHANCED AUDIT LOG ........................................................................................... 63
Recording of smartcard serial numbers ....................................................................................................... 63
Automated Event recording ......................................................................................................................... 63
Removed Console commands ...................................................................................................................... 64
INFORMATION ON STATUS OF PCI HSM COMPLIANCE ....................................................... 64
On starting the payShield 9000 ................................................................................................................... 64
VR Console Command .................................................................................................................................. 65
CS Console Command .................................................................................................................................. 66
NO Host Command ...................................................................................................................................... 66
MOVING BETWEEN COMPLIANT AND NON-COMPLIANT STATES ............................................. 66
LEGAL NOTICE FROM PCI SSC ................................................................................. 66
Legal Terms and Conditions ......................................................................................................................... 67
CHAPTER 11 – DES KEY SUPPORT ..................................................................... 68
Thales e-Security Page 3 3 August 2017

CHAPTER 12 – AES KEY SUPPORT ..................................................................... 69

CHAPTER 13 – TRANSACTION KEY SCHEMES .................................................... 70
CHAPTER 14 – SECURE HOST COMMUNICATIONS ............................................. 71
INTRODUCTION ................................................................................................... 71
PAYSHIELD 9000 SECURE HOST COMMUNICATIONS ........................................................ 71
WORKING WITH IBM Z/OS MAINFRAMES .................................................................... 71
OVERVIEW OF TLS/SSL ON THE PAYSHIELD 9000 ......................................................... 72
WHAT TLS/SSL PROVIDES ..................................................................................... 72
HOW TLS/SSL WORKS ......................................................................................... 72
TLS/SSL Support ........................................................................................................................................... 73
Supported Cipher Suites ............................................................................................................................... 73
Cipher Suite Negotiation .............................................................................................................................. 74
Data compression ........................................................................................................................................ 75
THE HSM RECOVERY KEY (HRK) .............................................................................. 75
HSM Certificates .......................................................................................................................................... 75
Application Certificates................................................................................................................................ 76
Out-of-Date Certificates .............................................................................................................................. 77
PERFORMANCE CONSIDERATIONS ............................................................................... 77
SECURITY CONSIDERATIONS .................................................................................... 77
SUPPORT FOR USB MEMORY STICKS .......................................................................... 77
CONFIGURING TLS/SSL ON THE PAYSHIELD 9000 ......................................................... 78
Checking availability of TLS/SSL ................................................................................................................... 78
Configuring the Ethernet Ports .................................................................................................................... 79
Managing the HRK....................................................................................................................................... 80
Managing Certificates ................................................................................................................................. 82
CERTIFICATE EXAMPLES ......................................................................................... 87
Intermediate CA Certificate ......................................................................................................................... 87
Client Certificate .......................................................................................................................................... 88
OPENSSL CONFIGURATION FILE ............................................................................... 89
NOTICES ........................................................................................................... 89
ACCESS CONTROL LISTS (ACLS) .............................................................................. 89
CHAPTER 15 – PERFORMANCE .......................................................................... 90
GENERAL........................................................................................................... 90
THE RSA BOOSTER LICENSE (HSM9-LIC033) ............................................................. 90
Variability of RSA Performance.................................................................................................................... 92
Factors affecting achieved performance ..................................................................................................... 93
Benefits provided by RSA Booster the License ............................................................................................. 94
THE HOST INTERFACE........................................................................................... 101
Asynchronous Communications ................................................................................................................. 101
FICON ......................................................................................................................................................... 101
HOST COMMAND TYPE .......................................................................................... 101
SECURE HOST COMMUNICATIONS ............................................................................. 101
AUDITING OF HOST COMMANDS ............................................................................... 101
UTILIZATION DATA COLLECTION .............................................................................. 102
TYPE OF LMK .................................................................................................... 102
CHAPTER 16 – USER STORAGE ........................................................................ 103
CHAPTER 17 – THE AUDIT LOG ....................................................................... 104
INTRODUCTION .................................................................................................. 104
OVERVIEW ........................................................................................................ 104
CORRECT USE OF THE AUDIT LOG ............................................................................ 104
FORCIBLY RECORDED ITEMS .................................................................................... 105
PCI HSM Compliance.................................................................................................................................. 105
Recording Deletion of Audit Log ................................................................................................................ 105
DISCRETIONARY AUDIT LOG ENTRIES ........................................................................ 106

PROTECTION OF THE AUDIT LOG .............................................................................. 106

CONFIGURING THE AUDIT LOG ................................................................................ 107
The AUDITOPTIONS console command ..................................................................................................... 107
payShield Manager Auditing screen .......................................................................................................... 107
VIEWING THE AUDIT LOG ...................................................................................... 108
The AUDITLOG console command ............................................................................................................. 108
THE PAYSHIELD MANAGER AUDIT LOG SCREEN ............................................................. 109
PRINTING THE AUDIT LOG...................................................................................... 109
The AUDITPRINT console command .......................................................................................................... 109
The Q4 Host Command .............................................................................................................................. 110
The payShield Manager Audit Log Screen ................................................................................................. 111
RETRIEVING AUDIT LOG ENTRIES TO THE HOST SYSTEM ................................................... 111
Centralized Logging ................................................................................................................................... 111
DELETING RECORDS FROM THE AUDIT LOG .................................................................. 111
The CLEARAUDIT console command .......................................................................................................... 111
The payShield Manager Audit Log Screen ................................................................................................. 112
OTHER AUDIT LOG MANAGEMENT FUNCTIONS .............................................................. 112
Translating MAC on LMK Refresh .............................................................................................................. 112
Verifying an Audit Log Record ................................................................................................................... 112
CHAPTER 18 – TAMPER PROTECTION ............................................................. 113
INTRODUCTION .................................................................................................. 113
Certifications.............................................................................................................................................. 113
TAMPER RESPONSIVENESS IN THE PAYSHIELD 9000 ....................................................... 113
Types of Tamper Actions............................................................................................................................ 113
Physical Access .......................................................................................................................................... 114
Environmental Changes ............................................................................................................................. 114
Voluntary Tamper ...................................................................................................................................... 114
Fraud Attack .............................................................................................................................................. 114
Tamper State ............................................................................................................................................. 115
Deletion of the HSM Secrets ...................................................................................................................... 115
Error Log Entries ........................................................................................................................................ 116
TEMPERATURE SENSOR ......................................................................................... 116
Description ................................................................................................................................................. 116
Triggering of the Temperature Sensor ....................................................................................................... 117
Error Log .................................................................................................................................................... 117
MOTION SENSOR ................................................................................................ 118
Description ................................................................................................................................................. 118
Sensitivity of the sensor ............................................................................................................................. 119
If the Motion Sensor is activated ............................................................................................................... 119
Error Log .................................................................................................................................................... 120
Enabling the Motion Alarm ....................................................................................................................... 120
RECOVERING FROM TAMPER STATE ........................................................................... 121
CHAPTER 19 – REMOTE MANAGEMENT AND CENTRALIZED MONITORING....... 123
INTRODUCTION .................................................................................................. 123
PAYSHIELD MANAGER VS. CIPHERTRUST ..................................................................... 123
PAYSHIELD MANAGER ........................................................................................... 124
Connection ................................................................................................................................................. 124
The Trust Model ......................................................................................................................................... 124
Commissioning a payShield 9000 .............................................................................................................. 125
The HSM Recovery Key (HRK) .................................................................................................................... 127
Migrating from Remote HSM Manager..................................................................................................... 127
Upgrading from earlier versions of payShield 9000 .................................................................................. 128
User interface for a commissioned payShield 9000 ................................................................................... 128
payShield Manager main activities ........................................................................................................... 129

CIPHERTRUST .................................................................................................... 131

Overview .................................................................................................................................................... 132
The Administrator Role .............................................................................................................................. 133
The Group Manager Role........................................................................................................................... 136
Reports for Group Managers ..................................................................................................................... 139
Alarms........................................................................................................................................................ 140
CHAPTER 20 - MIGRATING FROM HSM 8000 TO PAYSHIELD 9000 .................. 143
INTRODUCTION .................................................................................................. 143
OVERVIEW ........................................................................................................ 143
HOST API (COMMANDS) AND LICENSING .................................................................... 144
Full backwards compatibility of the Host API ............................................................................................ 144
Licensing of functionality - payShield 9000 software packages ................................................................ 144
HSM HARDWARE ................................................................................................ 144
Similarity of hardware operation............................................................................................................... 145
Connectivity ............................................................................................................................................... 146
Updated connectors .................................................................................................................................. 146
LOADING SOFTWARE AND LICENSES........................................................................... 148
Use of industry-standard tools .................................................................................................................. 148
payShield Manager .................................................................................................................................... 148
OPERATING AND MANAGING THE HSM ....................................................................... 148
No major changes to operation or management ...................................................................................... 148
User authentication changes in payShield 9000 ........................................................................................ 148
Host Ethernet Ports.................................................................................................................................... 149
Diagnostics ................................................................................................................................................ 150
Utilization Information .............................................................................................................................. 150
Audit Log.................................................................................................................................................... 150
Configuration ............................................................................................................................................. 151
Authorization ............................................................................................................................................. 151
LMKs .......................................................................................................................................................... 152
Performance .............................................................................................................................................. 152
payShield Manager .................................................................................................................................... 153
Withdrawn Console Commands ................................................................................................................ 153
CUSTOM SOFTWARE ............................................................................................. 154
What is custom software? ......................................................................................................................... 154
Is the customization still required? ............................................................................................................ 154
Ordering ports to payShield 9000 .............................................................................................................. 154
Inclusion of base functionality enhancements........................................................................................... 155
PCI PTS HSM CERTIFICATION................................................................................ 155
Background ................................................................................................................................................ 155
Software changes implemented in the payShield 9000 ............................................................................. 155
Security Settings ........................................................................................................................................ 155
Further information ................................................................................................................................... 156
CHAPTER 21 – INFORMATION FOR SECURITY AUDITORS ............................... 157
INTRODUCTION .................................................................................................. 157
FIPS 140-2 ..................................................................................................... 157
PCI HSM ......................................................................................................... 157
APCA (AUSTRALIAN PAYMENTS CLEARING ASSOCIATION) ................................................ 157
MEPS (METHODE D'EVALUATION DES PRODUITS SECURITAIRE "BANCAIRES") ........................ 158
GBIC (GERMAN BANKING INDUSTRY COMMITTEE) / ZKA (ZENTRALER KREDITAUSSCHUSS) ....... 158
ISO 13491 (FINANCIAL SERVICES - SECURE CRYPTOGRAPHIC DEVICES (RETAIL)) ................... 158
SP800-22 ....................................................................................................... 158
CHAPTER 22 – THE KEY MANAGEMENT DEVICE (KMD) ................................... 159
INTRODUCTION .................................................................................................. 159
THE KMD......................................................................................................... 159
THE KMD TRANSPORT KEY (KTK) ........................................................................... 160

USERS AND ROLES .............................................................................................. 160

OUTLINE OF KMD OPERATIONS................................................................................ 161
APPENDIX A – ERROR LOG CODES .................................................................. 162
GENERAL.......................................................................................................... 162
DESCRIPTION .................................................................................................... 162
SEVERITY ......................................................................................................... 162
ERROR CODES ................................................................................................... 162
SUB-CODES ...................................................................................................... 163
Sub-Codes for Main Error Code = 1 (Utility System Errors) ........................................................................ 163
Sub-Codes for Main Error Code = 2 (Cryptographic System Errors) ........................................................... 164
Sub-Codes for Main Error Code = 3 (Application System Errors) ............................................................... 164
Sub-Codes for Main Error Code = 4 (Key Manager System Errors) ............................................................ 165
Sub-Codes for Main Error Code = 5 (Encrypted File System Errors) ........................................................... 165
MULTIPLE ENTRIES .............................................................................................. 165
APPENDIX B – CORE HSM COMMANDS ............................................................ 167
APPENDIX C – KEY SCHEME TABLE ................................................................. 169
APPENDIX D – LIST OF AUTHORIZABLE ACTIVITIES ...................................... 170
APPENDIX E – REDUCED CHARACTER SETS .................................................... 175
APPENDIX F – THALES KEY BLOCK / TR-31 KEY USAGE CONVERSION ............ 176
APPENDIX G – GLOSSARY ............................................................................... 177
APPENDIX H – ABBREVIATIONS ..................................................................... 187
APPENDIX I – OTHER USEFUL DOCUMENTS .................................................... 193
PAYSHIELD 9000 MANUALS ................................................................................... 193
CIPHERTRUST MANUALS ........................................................................................ 194
APPLICATION NOTES ............................................................................................ 194
OTHER DOCUMENTS............................................................................................. 194

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
1270A593-034 Issue 34 payShield 9000 v3.2 August 2017

Chapter 1 – Introduction
payShield 9000 Manuals
This manual contains general reference information and data relating to the payShield
9000 payment HSM and its operation. For other specific payShield 9000 information, see
the following manuals:
 1270A545 payShield 9000 Security Operations Manual – providing guidance on

how to manage and operate the payShield 9000 securely.
 1271A543 payShield 9000 Installation Manual – information on the installation of
the payShield 9000
 1270A544 payShield 9000 Console Reference Manual – how to use a Console
("dumb" terminal) to manage and operate the payShield 9000.
 1270A542 payShield 9000 Host Programmers Manual – guidance to technical staff
on integrating the payShield 9000 into their host application systems.
 1270A546 payShield 9000 Host Command Reference Manual – details on the
structure and usage of host commands and responses in the base software and in
optional licenses not described elsewhere.
 1270A592 payShield 9000 Host Command Reference Manual Addendum for
Optional License LIC014 (WebPIN Commands) – details on structure and usage of
host commands and responses available through optional license LIC014.
Optional License LIC017 (HE & HG Commands) – details on structure and usage of
Optional License LIC020 (SEED Algorithm Commands) – details on structure and
usage of host commands and responses available through optional license LIC020.
Optional License LIC031 (CUP Commands) – details on structure and usage of
Optional License LIC034 (MU and MW Commands) – details on structure and
usage of host commands and responses available through optional license LIC034.
 1270A548 payShield 9000 Contactless & EMV Card Issuing Reference Manual -
details on structure and usage of host commands and responses available through
optional licenses LIC016, LIC018, and LIC023.
 1270A547 payShield 9000 Australian Standards Reference Manual – details on
implementation of AS 2805 and structure and usage of associated host commands
and responses available through optional license LIC003.
 1270A541 payShield 9000 OBKM and CEPS Command Reference Manual – details
on implementation for MasterCard OBKM, structure and usage of associated host
commands and responses available through optional license LIC004.
 1270A646 payShield 9000 Host Command Examples – examples of a number of
payShield 9000 host commands, plus Python scripts which can be sued to test
commands.
 1270A647 Applications Using the payShield 9000 – descriptions of how the
payShield 9000 can be deployed in a number of payment-related applications.
 1270A645 payShield Manager User's Guide – how to configure and use the
payShield Manager to manage and operate the payShield 9000.

Overview of the payShield 9000

The payShield 9000 hardware security module (HSM) provides cryptographic commands
to support network and point-to-point data security for payment card applications. Acting
as a peripheral to a Host computer, the HSM provides cryptographic facilities such as
those required to implement key management, message authentication and Personal
Identification Number (PIN) encryption in real time online environments. The HSM is
made physically secure by locks, electronic switches and tamper-detection circuits.
payShield 9000: front view
The payShield 9000 HSM supports a large number of standard commands and can be
customized to perform client-specific cryptographic commands. Standard commands
include:
 Generating and verifying Personal Identification Numbers (PINs) such as those

used with bank accounts and credit cards.
 Generating encrypted card values such as Card Verification Values (CVVs) for the
payment card industry.
 PIN solicitation, to obtain a new PIN from a card holder (against a reference
number).
 Generating keys for use in Electronic Funds Transfer Point of Sale (EFTPOS)
systems.
 Key management in non-EFTPOS systems.
 Generating and verifying Message Authorization Codes (MACs) for messages
transferred via telecommunications networks.
The payShield 9000 HSM is normally online to the Host and does not require operator
monitoring or intervention. The HSM performs cryptographic processing in response to
commands from the Host. The Host sends command messages, which consist of
command codes and other fields that are required by the HSM in order to process the
commands. The HSM processes the command messages and generates response
messages, which also contain a variable number of fields (depending on the message
type). Some commands, mainly involving plain text data, are entered by the user via the
associated HSM console or payShield Manager:
 The HSM Console is a dumb-terminal interface physically connected to the

payShield 9000 via one of the available USB ports through a supplied USB-serial
converter that allows management commands to be executed.
 The payShield Manager is a browser-based management interface providing a
graphical interface to the management commands.
Use of Multiple HSM units

A typical system has two or more payShield 9000 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.

Typically redundancy is built into the system design by providing more capacity than is
required to allow commands to be switched away from a failed or withdrawn unit (e.g. by
using a management system such as the Thales SRM (Security Resource Manager) for
IBM z/OS hosts. 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.
PCI HSM Certification and Compliance

Selected payShield 9000 software versions are certified to the PCI HSM security
standard. Prior to PCI HSM certification being mandated by the card schemes, only some
versions of base payShield 9000 software will be certified. Once the mandates are in
place it is expected that all versions of base software will be PCI HSM certified.
Further information about PCI HSM compliance is given in Chapter 10 – PCI HSM
Compliance.
Backwards Compatibility
Wherever possible, the payShield 9000 HSM provides host commands that are backwards
compatible with implementations on older versions of the Thales (or Racal) HSMs - e.g.
HSM8000, RG7000, RG6000. However, there are exceptions to this general rule, as
outlined below:
 The payShield 9000 may process command parameters in a different order than
previous Thales HSMs. Therefore, it is possible to receive different error codes
when the same command executed on different HSMs (e.g. when more than one
error is found in the input data).
 The payShield 9000 has a fixed buffer size of 32K bytes per connection. Some
older HSMs had buffer sizes that varied according to the chosen communication
protocol, but these were always less than 32K bytes.
 Usually as a result of security enhancements being applied to the HSMs, some
default configuration settings have changed. If required (and if the security risks
are understood and accepted) these settings can be changed using the
appropriate console configuration command. For example:
 Single-DES: the default is "Disabled" instead of "Enabled".
 Decimalization Table: the default configuration enforced the use of
encrypted Decimalization Tables. Older HSMs only used plaintext
Decimalization Tables.
 Authorization Requirement: some commands' authorization requirements
may have changed.
 Authorization Process: the default configuration enforced the use of
multiple Authorized Activities. Older HSMs only used a single Authorized
State.
 The recommended method of importing/exporting keys is via a key block
format. The use of X9.17 and variant formats is still supported, but must
be specifically enabled.
 Compliance with PCI HSM requirements introduce some rules which may cause
incompatibility between PCI HSM compliant payShield 9000 HSMs and earlier non-
compliant HSMs:

 A number of keys have been allocated new key types. This will require
some keys to be migrated to their key type, and changes to some Host
commands.
 Certain PIN Block format translations are not permitted.
 Only certain PIN Block formats are permissible for calculation of values
(such as Offsets and PVVs) from PANs and PINs.
Switches are provided in the security settings to allow the user to select whether to
operate in the "classic" manner or in the PCI HSM compliant manner.
In order to allow continuing interoperability between HSM 8000 and payShield 9000
units, a version of HSM 8000 software is available which implements the same key types
as are used in PCI HSM compliant payShield 9000s.
Further details can be found in Chapter 10 – PCI HSM Compliance.

Chapter 2 – Description of the

payShield 9000
Physical Description
A payShield 9000 HSM can stand alone or can be part of a system consisting of a number
of units in a standard 19-inch cabinet. The front panel of each unit is accessible from the
front of the cabinet. The units are supported on telescopic runners so that they can slide
out via the front of the cabinet.
Front Panel
Left Key 8 LEDs Right Key
Card reader
Serial number USB ports Reset button
payShield 9000 HSM: front view
Keys and Locks

On the front panel are two cam locks, which secure the payShield 9000 HSM in the rack.
The locks have different keys, so the HSM can be removed from the rack only when the
holders of both metal keys are present.
The locks provide security in two ways:
 When in the locked position, the HSM cannot be removed from the rack. Both
locks need to be unlocked for the unit to be removed; this can only be achieved
by the presence of two key holders, as each lock requires a different key. The
mechanical locking of the unit into the rack thus provides low level resistance to a
direct attack. Note that the unit itself cannot be opened.
 Micro-switches are attached to the locks, wired to inputs on the internal circuit
board, allowing the security state of the HSM to be changed. Three states are
supported, Online (both locked), Offline (one locked and one unlocked) and
Secure (both unlocked). See the table below.

State Left hand lock Right hand lock

Normal (online) Locked (activated) Locked (activated)
Offline Locked Unlocked
Offline Unlocked Locked
Secure Unlocked Unlocked
Note: When being managed using payShield Manager, the locks should be in their
locked (Online) position, with both keys removed and held in secure storage. The HSM
state is changed using administrator smartcards and a card reader attached to the
payShield Manager PC. A single administrator, using one administrator smartcard (either
a left card or a right card), can switch the HSM from Online into its Offline state. A
second administrator, of the other type, is required to insert their smartcard in the card
reader, in order that the HSM can be switched from Offline to the Secure state.
Smartcard Reader
The smartcard reader built into the payShield 9000 is an ISO card compliant type with
automatic card ejection. The card is ejected at standard points in HSM operation:
 On completion of a smartcard related operation.

 Following premature command termination when the user presses the
CTRL-C key combination.
 When the HSM is reset by the RESET button on its front panel.
 During diagnostic testing.
LEDs
There are 8 LEDs on the front panel. These are:
 Power
 LMK
 Host 1
 Host 2
 Error Log
 Alarm
 Test
 Management
Power LED
A payShield 9000 HSM may have one or two power supply sockets on the rear panel.
The Power LED on the front panel indicates the condition of the power supply and can be
used to diagnose a power failure or interruptions to supply.

LED Description
indicator
Green For dual-power payShield 9000 units:
Power is being supplied through both sockets.
For single-power supply payShield 9000 units:
Power supply is on.
Yellow Power supplied through upper socket only. The lower socket is not
(dual-power providing power.
units only)
Red Power supplied through lower socket only. The upper socket is not
(dual-power providing power.
units only)
Error LED
The Error indicator is normally extinguished. It is illuminated if the HSM's continuous
automatic self-checks have detected a fault. The Error LED also indicates the state of the
error log. If a new error has occurred since the error log was last checked then the LED
flashes. Once the error log has been investigated, it illuminates continuously until the
error log is erased. A security setting is available to extinguish the error log when it has
been viewed.
LMK LED
The LMK indicator illuminates (green) when one or more LMKs are installed in the HSM.
Alarm LED
The Alarm indicator illuminates when the HSM is triggered into an alarmed state by a
security compromise. All secure data stored in the HSM is erased. When the sensor
causing the alarm is no longer triggering, the HSM will automatically be rebooted, and
the Alarm LED will be extinguished. To extinguish the Alarm LED, the HSM must be
rebooted by powering off and powering on again. Following an alarm condition, the
LMK(s) will need to be reloaded into the HSM. If the alarm condition is still present after
rebooting, the Alarm LED remains illuminated; in this case the HSM must be returned to
Thales for investigation and repair.
Host 1 & Host 2 LEDs

These indicators show host communication with the HSM. The separate indicators show
activity via the two Ethernet or the two FICON Host ports on the rear of the unit.
These LEDs illuminate when data is either received or transmitted. They flash when a
small amount of data is being sent and illuminate steadily when the HSM is busy. If no
data is being received from the host, they remain extinguished.
Management LED
Indicates communication with the HSM via the Management port.
Note:
 The payShield Manager uses the Management Ethernet port is for communication
between your payShield 9000 HSM and the Management PC.
Test LED
Not currently in use.

USB Ports
Two USB ports are provided on the front panel of the payShield 9000 HSM. (An additional
4 USB ports are provided on the rear panel.)
One may be used to connect the HSM to a standard console terminal. The connection is
via a USB-to-Serial (9 pin) adapter lead, supplied by Thales. Almost any asynchronous
ASCII terminal is suitable for use with the HSM as a console terminal.
Notes:
 Use of payShield Manager avoids the need for a console.

 When connecting serial or parallel interface devices to USB ports, it is essential
that a USB adapter is acquired from Thales. Adapters are available for USB-Serial,
USB-Centronics parallel, and USB-25 Pin parallel. Adapters from other sources
must not be used as the payShield 9000 will not have the required drivers.
Reset Button
The red Reset button is recessed in the front panel to prevent accidental activation. If the
Reset button is pressed for approximately 2 seconds, it performs a reboot.
The reset process automatically ejects any smartcard that is in the smartcard reader.
Rear Panel
Ethernet Ethernet Aux

Dual power input Management Port
(factory fit option) Port (not in use) 4x USB ports
Earth Ethernet Host Port 2

Erase
button
FICON Ports
(factory-fit option)
Ethernet Host Port 1
payShield 9000 HSM: rear view
Power Sockets
The payShield 9000 HSM is provided with one or two IEC style power sockets and 20 mm
fuse holders. Each socket provides power to a separate distribution unit within the HSM.

You can connect a power supply to either or both sockets.
The use of a dual power supply unit allows the HSM to receive power from two
independent supplies. This redundancy is designed to help prevent any break in the
operation of the HSM in the event of:
 An outage in either one of the power supplies

 Failure of either of the power distribution units within the HSM
Note: There is no on/off switch on the HSM, so it powers-up as soon as it is connected
and power supply is turned-on.
Ethernet Host Port 1 and 2

The two Ethernet Host ports are RJ45 sockets.
Important Note: In order to ensure that a payShield 9000 only processes

commands on behalf of the legitimate host computer, it is strongly
recommended that a private Ethernet network segment is used. The only
devices on this network should be the host and its associated HSM(s).
Ethernet Management Port

The Ethernet Management port is an RJ45 socket. If you are using the payShield
Manager, the Management PC must be connected to this port either directly or via your
secure WAN.
It is recommended that the Management Ethernet Port and Host Ethernet Ports all have
IP subnets independent of one another.
Ethernet Aux Port

This port can be used for SNMP traffic.
USB Ports
The 4 USB ports on the rear panel of the HSM can be used:
 To provide asynchronous serial Host communications.*

 To connect a local serial*, parallel*, or native-USB printer.
* When connecting serial or parallel interface devices to USB ports, it is essential that
a USB adapter is acquired from Thales. Adapters are available for USB-Serial, USB-
Centronics parallel, and USB-25 Pin parallel. Adapters from other sources must not be
used as the payShield 9000 will not have the required drivers.
A further 2 USB ports are provided on the front panel of the payShield 9000.
FICON Ports
payShield 9000 units can be ordered with an optional FICON interface for connection to
IBM mainframe hosts using fiber optics. (This interface cannot subsequently be added to
units ordered without the option.)
This offers a FICON fiber optic port with either a shortwave (850 nm) multi-mode or
longwave (1310 nm) multi-mode interface with an LC connector. The interface auto-
switches between speeds of 2, 4, and 8 Gbps.
Although the FICON interface has 2 physical ports, only Port 1 can be used at present.

Erase button
The Erase "button" is recessed into the panel and requires a thin probe (like a
straightened paper clip) to operate it.
When pressed, Erase will perform a reset, like the button on the front panel but will also
erase the HSM's secure memory.
Note: This button will function even if there is a software fault or electric power to the
HSM has been lost.
Mechanical and Electrical Specifications

Dimensions
Height: 85 mm (3.35 in)
Width: 478 mm (18.82 in)
Depth: 417 mm (16.42 in)

Weight: 7.5 kg (16 lb.) (Dual PSU unit)
Power (per Unit)

Voltage: 100 to 240 V AC Universal Input
Frequency: 47 to 63 Hz
Consumption: 100 W (maximum)
Rating: 100-240Vac, 2.1 - 0.85A
Environmental
Operating
Temperature: 0 to +40° C
Humidity: 10 to 90% (non-condensing)
payShield 9000 HSM Facilities

The payShield 9000 HSM provides an extensive range of functions including support for
key management, PIN & card management, data encryption & authentication and EMV
transaction processing.
Key Management
Security for key management is ensured by the use of an enforced key hierarchy (see
diagram below) and the use of multiple Local Master Keys (LMKs). The payShield 9000
HSM can use smartcards (compatible with ISO 7816) to provide a convenient means of
handling LMKs.

HSM
Local Master Keys
Manually-distributed
Key-Encrypting Keys
Automatically-distributed
Data-Encrypting Keys
Data
Figure 1 - Key Hierarchy
Types of Keys Used by an HSM

Local Master Key (LMK)
Up to 20 LMKs can be installed in a payShield 9000. These can be a mix of two types:
 A Variant LMK is a set of 40 double- or triple-length DES keys, arranged in pairs,

with different pairs (and variants of those pairs) being used to encrypt different
types of keys. This is the standard LMK format supported in all previous versions
of Thales (Racal) 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.
 A Key Block LMK is either a triple-length DES key, or a 256-bit AES key, and is
used to encrypt keys in a key block format. A Key Block LMK is not compatible
with a Variant LMK, and it can only be used to encrypt keys in the key block
format.
Note: The term "Key Block LMK" refers to the 'key block' method of encrypting
keys; a Key Block LMK is not itself stored in the key block format.
For an HSM to operate, the LMKs must be created and loaded. Because the DES /AES
algorithms depend on a key for secrecy, and because the security of all keys and data
encrypted for storage depend on the LMKs, they must be created and maintained in a
secure manner. Provision is made to allow the LMKs to be changed and keys or data
encrypted under them to be translated to encryption under the new LMKs.
All keys when stored locally (i.e. not in transit between systems) are encrypted under the
LMK.

Zone Master Key

A Zone Master Key (ZMK) is a key-encrypting key which is distributed manually between
two (or more) communicating sites, within a shared network, in order that further keys
can be exchanged automatically (without the need for manual intervention). The ZMK is
used to encrypt keys of a lower level for transmission. For local storage, a ZMK is
encrypted under one of the LMK pairs.
Within the VISA environment this is known as a ZCMK.
The payShield 9000 supports the use of a single-length, double-length or triple-length

DES ZMK, or a 128-bit, 192-bit or 256-bit AES ZMK.
Zone PIN Key

A Zone PIN Key (ZPK) is a data encrypting key which is distributed automatically, and is
used to encrypt PINs for transfer between communicating parties (for example, between
acquirers and issuers). For transmission, a ZPK is encrypted under a ZMK; for local
storage it is encrypted under one of the LMK pairs.

DES ZPK.
Terminal Master Key

A Terminal Master Key (TMK) is a key-encrypting key which is distributed manually, or
automatically under a previously installed TMK. It is used to distribute data-encrypting
keys, within a local (non-shared) network, to an ATM or POS terminal or similar. The TMK
is used to encrypt other TMKs or keys of a lower level for transmission. For local storage,
a TMK is encrypted under one of the LMK pairs.

DES TMK, or a 128-bit, 192-bit or 256-bit AES TMK.
Terminal PIN Key

A Terminal PIN Key (TPK) is a data-encrypting key which is used to encrypt PINs for
transmission, within a local network, between a terminal and the terminal data acquirer.
For transmission, a TPK is encrypted under a TMK; for local storage it is encrypted under
one of the LMK pairs.

DES TPK.
Terminal Authentication Key

A Terminal Authentication Key (TAK) is a data-encrypting key which is used to generate
and verify a Message Authentication Code (MAC) when data is transmitted, within a local
network, between a terminal and the terminal data acquirer. For transmission, a TAK is
encrypted under a TMK or ZMK; for local storage it is encrypted under one of the LMK
pairs.

DES TAK, or a 128-bit, 192-bit or 256-bit AES TAK.
Terminal Encryption Key

A Terminal Encryption Key (TEK) is a data-encrypting key which is used to encrypt and
decrypt messages for transmission, within a local network, between a terminal and the

terminal data acquirer. For transmission, a TEK is encrypted under a TMK or ZMK; for
local storage it is encrypted under one of the LMK pairs.
DES TEK, or a 128-bit, 192-bit or 256-bit AES TEK.
PIN Verification Key

A PIN Verification Key (PVK) is a data-encrypting key which is used to generate and
verify PIN verification data and thus verify the authenticity of a PIN. For transmission, a
PVK is encrypted under a TMK or under a ZMK; for local storage, it is encrypted under
one of the LMK pairs.

DES PVK.
Card Verification Key

A Card Verification Key (CVK) is similar to a PIN Verification Key, but for Card
information instead of a PIN.

DES CVK.
Master/Session Key
The master/session key management scheme involves setting up a master key between
two communicating parties (for example an acquirer and an issuer or an acquirer and a
terminal) under which data-encrypting keys are exchanged for use during a session. Key
installation and updating must be organized by the institutions involved (i.e., within the
application programs).
The HSM supports master/session key management in both shared and local networks,
but distinguishes between the two and maintains separate key hierarchies.
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 seven severity levels:
 System is unusable.
 Action must be taken immediately.
 Critical conditions.
 Error conditions.
 Warning conditions
 Normal but significant condition.
 Informational.
 Debug-level message.
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 or, depending on the security settings,
extinguished. If the log is cleared, the Error LED is extinguished.
Error codes are defined in Appendix A.
Audit Log
The payShield 9000 provides an audit logging capability, enabling security officers to
select a number of activities and functions whose usage is recorded in an Audit Log.
Certain items are always recorded in the Audit Log, and this cannot be disabled.
The purpose of the Audit Log is to enable security officers to make regular checks on
security-related actions that the payShield 9000 is being asked to perform, and to assist
in forensic examination of any suspected security breaches.
The Audit Log also provides facilities for its entries to be viewed, printed, and archived to
a host computer.
This Audit Log is described in detail in Chapter 17.
Temperature and Motion Sensors

Apart from to the requirements of the standards that the payShield 9000 complies with
(such as FIPS 140-2 and PCI HSM), the payShield HSM provides additional facilities
which users can employ to achieve even higher levels of physical security. These include:
 Temperature alarm, triggered by a temperature sensor. (This sensor is

permanently enabled.)
 Motion alarm, triggered by a motion sensor. (This sensor is disabled by default,

and can be enabled by the user.)
The temperature and motion sensors in the payShield 9000 provide a mechanism to
detect any unusual changes in the module's operational environment beyond a set of
predefined thresholds.
These capabilities may be unfamiliar or not well understood, and as a result some users
have not enabled the motion sensor and therefore are not achieving as high a level of
security as the payShield 9000 is capable of offering.
The payShield 9000 temperature and motion sensors are discussed in more detail in
Chapter 18.
Utilisation and Health Check Data

The payShield 9000 facilities include two distinct sets of information which are aimed at
helping users to understand what is going on with the unit and to subsequently manage
and administer their HSM more effectively:
 Utilization data – to let the user see how heavily loaded the HSM is and the
commands that are being processed. This data is provided in the following
categories:
 Overall HSM loading since last data reset. This shows the loading of the
HSM (in terms of percentage of capacity) averaged since the last time the
user reset the data.
 "Instantaneous" HSM loading. This provides the loading (as a percentage
of the HSM's capacity) of the HSM over a short period immediately prior to
the time of requesting the data.

 Host Command volumes since last data reset. This information tells the
user how many of each host command have been processed since the last
time that the user reset the data.
 "Instantaneous" Host Command Volumes. This report shows how many of
each host command have been processed over a short period immediately
prior to the time of requesting the data.
 Health Check data – to let the user check on a number of factors relating to the
health of the HSM, in the following categories:
 Accumulated counts of health-related events. This provides counts of a
number of events since the last time the data was reset by the user.
 Instantaneous Status of health-related factors. This reports on the status
of various factors at the time that the user requests the information.
This information can be accessed in the following ways:
 payShield Manager (see Chapter 19).
 Console commands
 Printing at an HSM-attached printer
 Host Commands
 SNMP
Not all of the data is available through all media. For example, "instantaneous" utilization
data is not available via host commands as this data is intended for use in an ad hoc
manner, as opposed to the pre-programmed environment that host commands are used
for. On the other hand, SNMP is aimed at status reporting, and so not all accumulated
data is provided through SNMP.
These capabilities are described in Chapter 8 and Chapter 9.
This data can also be accessed using the CipherTrust product (see Chapter 19). The
relevant manuals should be consulted for further information.

Chapter 3 – Local Master Keys

(LMKs)
This chapter has been moved to the payShield 9000 Host Programmer's Manual.

Chapter 4 – Variant Key Scheme


Chapter 5 – Key Block Key Scheme


Chapter 6 – PIN Block Formats


Chapter 7 – Fraud Detection

Functions
The payShield 9000 HSM has fraud detection functions designed to detect and prevent
'brute force' attacks, where (for example) large numbers of PINs are submitted until the
correct PIN is discovered.
The detection works by counting how many failed PIN verifies are detected in one minute
and in one hour. Each time that these counts exceed limits specified in the A5 console
command or in payShield Manager at Configuration / General Settings / Fraud, the PIN
Attack Counter is incremented. If the PIN Attack Counter exceeds the specified PIN
Attack Limit, then a PIN Attack is assumed.
The A5 console command or payShield Manager at Configuration / General Settings /
Fraud also determines how the HSM will react. The user can select "On" for full pro-active
response to the limits being exceeded, or "Logging Only" in order to record (in the Health
Check Data) the limits being exceeded without taking any further action.
An entry is always made in the Audit Log if any of the limits are exceeded.
If the Logging Only option has been selected, then the payShield 9000 will provide
counts of how many times the per-minute and per-hour limits have been exceeded and
the total number of PIN Attacks detected. This information is provided as part of the
Health Check Data provided by the HEALTHSTATS command or payShield Manager
Status / Health Statistics/Diagnostics (see Chapter 9), and is therefore only available if
Health Check data has been enabled using the HEALTHENABLE console command or
Status / Health Statistics/Diagnostics in payShield Manager. The counts can be reset
using the "Reset All Stats" option in the HEALTHSTATS command or at Status / Health
Statistics/Diagnostics in payShield Manager.
Note that the term "Logging" here refers to capture of the information in the Health
Check data. Audit Log entries are always made when the limits are exceeded.
If the "On" option has been selected, then the reporting provided by the Logging Only
option is again provided. In addition, if either of the per-minute or per-hour counts
exceeds the specified limits the HSM forces all PIN verification commands to return an
error 39 in their response. The HSM will continue to return error 39 until the console
command A7 is used to re-enable PIN verification. If the PIN Attack Counter reaches the
PIN attack limit then the HSM will clear the LMKs from it memory. Installing the LMKs will
set the PIN attack counter to 0.
The following list specifies the PIN verification host commands to which the limits apply:
 DA – Verify a Terminal PIN Using the IBM Method

 EA – Verify an Interchange PIN Using the IBM Method
 CG – Verify a Terminal PIN Using the Diebold Method
 EG – Verify an Interchange PIN Using the Diebold Method
 DC – Verify a Terminal PIN Using the Visa Method
 EC – Verify an Interchange PIN Using the Visa Method
 BC – Verify a Terminal PIN Using the Comparison Method
 BE – Verify an Interchange PIN Using the Comparison Method

Chapter 8 – Utilization Data

The payShield 9000 provides users with data about how heavily utilized the HSM is. This
is designed to allow users to re-balance loading between their various payShield 9000s,
and to optimize their purchasing of additional capacity.
The Utilization Data facilities involve the console, Local and payShield Manager, and the
Host interface. Detailed information concerning the commands and operations involved
are described in the relevant manuals. This chapter gives a high-level overview of the
Utilization Data capability and how it works.
See the CipherTrust manuals for information about accessing Utilization Data for the
whole estate of payShield 9000s by using CipherTrust.
Data Provided to the User

The Utilization Data facility provides 2 sets of data to the user:
 Overall HSM Loading. This data is provided as an instantaneous snapshot of

current loading or as a series of numbers indicating since the last data reset for
how many seconds the HSM was loaded from 0-10% of its capacity, for how many
seconds the loading was in the range 10-20%, for how many seconds it was in
the range 20-30%, and so on.
 Host Command Volumes. This data indicates how many times each host
command has been processed, and the average transactions per second (tps) for
each command.
Data Collection Period

There are 2 types of period over which the data is collected:
 Since Last Reset. Data is accumulated since the last time that the user reset the
utilization data. This data includes the number of seconds that the data is
accumulated over, allowing average transaction rates to be calculated. Data will
continue to accumulate until the next time the data is explicitly reset. There is no
facility at the HSM to select data between 2 dates (other than between last reset
and now), but the accumulated data can be retrieved at any time without
resetting it. This means that time-series data can be achieved by regular retrieval
of data to an external host computer. (The separately licensed CipherTrust
product can provide statistics between selected end and start dates/times.)
Collection of data can be suspended and resumed without resetting the data. This
means that meaningful results can still be returned if the HSM is temporarily
taken out of service or re-purposed.
Data accumulation, including the number of seconds that the data is accumulated
over, is automatically suspended when the HSM is not online.
The collected data is persistent over re-starts and power being switched off, but is
reset when new software is installed on the HSM.
 "Instantaneous" data. It is also possible to get a view of the loading of the HSM
right now by asking for instantaneous data, helping administrators investigate
throughput or performance issues as they are occurring. This provides utilization
data over the most recent period: the length of this period can be configured from
1 to 60 seconds.

Interpreting the Output

Overall HSM Loading
The data provided allows the user to create histograms of the following format:
9000
8000
7000
6000
5000
4000
3000
2000
1000
0
Chart Example 1
This example indicates an HSM which is "comfortably" loaded and could take on more
work. It shows that on 1,000 occasions (i.e. 1-second periods) it was under 10% loaded;
on 3,000 occasions it was loaded between 10 and 20%, and so on. The most common
loading was in the range 30-40%, and it was never more than 70% loaded.

16000
14000
12000
10000
8000
6000
4000
2000
0
Chart Example 2
This example depicts an HSM which is under stress, and which needs its load reducing by
re-balancing workload between the HSM estate or by adding additional capacity.
Note the "100%" column in these examples: this indicates how frequently the HSM was
working at its full capacity – and it is most likely that some of the demanded load (i.e.
what the HSM was being asked to do) would have experienced significant latency or even
time-outs at the host.
To achieve maximum throughput on the HSM it needs to be driven with multiple

connections (or threads). Optimum performance is normally achieved with 4-8 threads
(depending on the HSM performance model and the commands being processed).
Running with only a single thread can significantly reduce the throughput of the HSM,
and means that you will not be able to reach the rated throughput for the machine.
Output using the Console

For users working at a Console, the information is provided as a table of numbers. The
output from the UTILSTATS command for data accumulated since the last reset includes
data of the following format:

HSM Serial Number: A4665271570Q
Report Generation Time: 05-Mar-2011 23:19.59

Report Start Time: 01-Jan-2011 14:25.01
Report End Time: 05-Mar-2011 23:19.59
Total number of secs: 123,456
HSM Loading:
0-10%: 56,789
10-20%: 24,109
20-30%: 21,445
30-40%: 12,382
40-50%: 3,288
50-60%: 2,917
60-70%: 2,123
70-80%: 403
80-90%: 0
90-100%: 0
100%: 0
Instantaneous loading is presented in the following format:
Instantaneous HSM Load: 15%
Further information on using the console for Utilization Data is given below.
Output using payShield Manager

For users managing the payShield 9000 using payShield manager, the output is
presented in graphical form:

Host Command Volumes

Data is provided for each host command that has been used since the collection of data
started. It shows for each command the number of times that command has been run,
and the average transactions per second for that command over the data collection
period.
It is important to recognize that not all commands have the same effect on HSM loading.
The rated performance of the HSM (e.g. 1,500 tps for the X performance model) relates
to how many CA host commands (PIN Block Translation) the HSM could run in a second.
Most other host commands will run at the same speed as the CA command, but some will
run more slowly (and impose a greater load on the HSM) and a few will run faster.
Even looking at an individual command, the speed it runs at may depend on the options
or payload associated with it. For example, the speed of commands using RSA keys is
heavily dependent on the RSA key length; and commands which encrypt/decrypt blocks
of data run more slowly with larger data blocks.

For users working at a Console, the information is provided as a table of numbers. The
output from the UTILSTATS command for both data accumulated since the last reset and
for "instantaneous" data includes data of the following format:

Host Command Volumes:
Cmd Code Total Transactions Average TPS
A0 589 0.00
DA 692,442 5.61
CA 15,927,678 129.02
EI 23,456 0.19
M0 168,558 1.37

For users managing the payShield 9000 using payShield manager, the output is
presented in graphical form:
Reporting Mechanisms
The Utilization data can be accessed using:
 the Console.
 payShield Manager
 Host commands
 Printing at the HSM-attached printer
 SNMP
Console Commands
The following console commands are available to operate the Utilization Data facility.
These commands are described in detail in the payShield 9000 Console Reference
Manual.

 UTILCFG – allows the data collection period for "instantaneous" data to be

configured.
 UTILENABLE – allows gathering of utilization data to be suspended or resumed.
 UTILSTATS – allows the utilization data to be viewed at the console, printed at an
HSM-attached printer, and reset.
 SNMP – displays the SNMP Communities (for SNMP v1 and v2) or Users (for SNMP
v3) that are currently set up.
 SNMPADD – allows SNMP Communities or Users to be added
 SNMPDEL – allows SNMP Communities or Users to be removed
PayShield Manager Commands

In payShield Manager, the following buttons are available to manage and view the
utilization statistics (See the payShield Manager Users Guide for Details):
 Status / Utilization Statistic:
 Cumulative Tab
 CPU Load
 Command Totals
 Command TPS
 Instantaneous Tab
 CPU Load
 Command Totals
Command Load
The following items are available in Configuration / SNMP Settings to manage the SNMP
interface:
 Enabled: Check this box to enable SNMP reporting, uncheck it to disable
 Enabled on Port: Which port to use for SNMP traffic
 Version 1 or 2 (V1/V2) Communities
 Versions 1 and 2 of SNMP use Communities. In this section you may add and
remove Communities by clicking on the corresponding plus and minus icons.
 Version 3 (V3) Users
 Version 3 of SNMP uses Users instead of Communities and also requires that the
user specify the authentication and privacy algorithms to be used.
 To add a V3 User, enter the following fields and then click the plus icon:
 Name
 Authentication Algorithm (and password)
 Privacy Algorithm (and password)
 To delete a User, simply click the minus icon next to that user.
Host Commands
The following host commands are available to operate the Utilization Data facility. These
commands are described in detail in the payShield 9000 Host Command Reference
Manual.
 J2 – Get HSM Loading data

 J4 – Get Host Command Volumes
 J6 – Reset Utilization Data

Note that Instantaneous Utilization data is expected to be used by administrators on an

ad hoc, event-driven, basis; it is therefore not provided via the host command interface.

Chapter 9 – Health Check Data

The payShield 9000 provides users with data to help them assess the health state of the
HSM. (See Chapter 8 – Utilization Data for information available on the loading of the
HSM.)
The Health Check Data facilities involve the console, payShield Manager, and the Host
interface. Detailed information concerning the commands and operations involved are
described in the relevant manuals. This chapter gives a high-level overview of the Health
Check Data capability and how it works.
See the CipherTrust manuals for information about accessing Health Check Data for the
whole estate of payShield 9000s by using CipherTrust.
Data Provided to the User

The Health Check Data facility provides 2 sets of data to the user: Accumulated Counts
and Instantaneous Status
Accumulated Counts.
This data provides counts of certain events since the last time that the user reset the
Health Check Data. These counts relate to:
 Re-starts
 Tampers*
 Fraud Detection thresholds being exceeded.
This last item is an important enhancement to the HSM's Fraud Detection functionality
(see Chapter 7). Prior to payShield 9000 v1.1, if the Fraud Detection thresholds were
exceeded the HSM would cease satisfying PIN verification commands and would
ultimately erase its LMKs: this was a barrier to some users deploying the Fraud Detection
functionality. Now users can elect to set Fraud Detection thresholds and monitor whether
these are being exceeded without the HSM ceasing to be fully functional.
Collection of data can be suspended and resumed without resetting the data. This means
that meaningful results can still be returned if the HSM is temporarily taken out of
service or re-purposed.
The collected data is persistent over re-starts and power being switched off, but is reset
if new software is installed on the HSM.
* Note that if you use the Erase button to delete LMKs, this will count as a tamper in the
accumulated counts. But as the HSM automatically clears the tamper state in this
circumstance, the Instantaneous Status (see below) will report that the HSM is not in a
tampered state.

For users working at a Console, the information is provided as part of the output from
the HEALTHSTATS command:

HSM Serial Number: A4665271570Q
Report Generation Time: 05-Jan-2011 04:35.29
Report Start Time: 23-Dec-2010 01:29.41
Report End Time: 05-Jan-2011 04:35.29
Number of reboots: 18
Number of tampers: 6
Failed PIN verifies/minute limit exceeded: 29
Failed PIN verifies/hour limit exceeded: 1
PIN Attack Limit exceeded: 0

payShield Manager users will see output in the following format:
Instantaneous Status.
This provides a range of HSM health check data at the point in time when a request is
made. This will report on:
 Host port status

 Whether Host Command service is running
 Whether Console service is running
 Whether Local/PayShield Manager service is running
 Tamper state*
 LMK information:
 Numbers loaded
 Types of LMK – test/production; variant/key block
 Authorized state

 No. of authorized activities

 Fraud Detection status
 Whether PIN Verifications per min./hour have been exceeded
 If PIN Attack limit exceeded
* Note that if you use the Erase button to delete LMKs, this will count as a tamper in the
accumulated counts (see above). But as the HSM automatically clears the tamper state in
this circumstance, the Instantaneous Status will report that the HSM is not in a tampered
state.

Instantaneous Health Check Data is presented as part of the DT console command:
Payshield Health Check Status
TCP Server: Up
UDP Server: Up
Async Server: Not Enabled
Local/Remote Manager Server: Up
Host Ethernet Link 1: Up
Host Ethernet Link 2: Down
Host Async Link: Not Enabled
Unit Tampered?: Yes
Cause: Case Tampered
Date: 07-Feb-2106 06:28.15
Fraud limits exceeded?: No

PIN attack limit exceeded?: No
payShield Manager users will see output in the Diagnostics Tab under Health
Statistics/Diagnostics in the Status section.
Reporting Mechanisms
The Health Check data can be accessed using:
 the Console.
 payShield Manager
 Host commands.
 Printing at the HSM-attached printer
 SNMP – for instantaneous status only.

Console Commands
The following console commands are available to operate the Health Check Data facility.
These commands are described in detail in the payShield 9000 Console Reference
Manual:
 A5 – Fraud detection: to allow Health Check counters to be accumulated without
the HSM ceasing to execute commands.
 AUDITOPTIONS – to allow data resets to be recorded.
 DT – Diagnostics: this has been enhanced to display the Instantaneous Health
Check data.
 HEALTHENABLE – allows gathering of Health Check counters to be suspended or
resumed.
 HEALTHSTATS – allows the Health Check counters to be viewed at the console,
printed at an HSM-attached printer, and reset.
 SNMP – displays the SNMP Communities (for SNMP v1 and v2) or Users (for SNMP
v3) that are currently set up.
 SNMPADD – allows SNMP Communities or Users to be added
 SNMPDEL – allows SNMP Communities or Users to be removed
payShield Manager Commands

In payShield Manager, the following items are available in the Health
Statistics/Diagnostics tab in the Status section to manage and view the health statistics
(See payShield Manager Users Guide for Details):
 Serial Number
 Report Start Time, End Time, and Generation Time
 Number of Reboots and Tampers
 Pin Verification Failures per Minute and Hour Limits Exceeded
 Pin Attack Limit Exceeded
 Diagnostics: this includes the Instantaneous Health Check data.
The following items are available in the SNMP Settings tab in the Configuration Section to
manage the SNMP interface:
 Enabled: Check this box to enable SNMP reporting, uncheck it to disable

 Enabled on Port: Which port to use for SNMP traffic
 Version 1 or 2 (V1/V2) Communities
 Versions 1 and 2 of SNMP use Communities. In this section you may add and
remove Communities by clicking on the corresponding plus and minus icons.
 Version 3 (V3) Users
 Version 3 of SNMP uses Users instead of Communities and also requires that the
user specify the authentication and privacy algorithms to be used.
 To add a V3 User, enter the following fields and then click the plus icon:
 Name
 Authentication Algorithm (and password)
 Privacy Algorithm (and password)
 To delete a User, simply click the minus icon next to that user.

Host Commands
The following host commands are available to operate the Health Check Data facility.
These commands are described in detail in the payShield 9000 Host Command Reference
Manual.
 J8 – Get Health Check counts
 JK – Get Instantaneous Health Check status
 JI – Reset Health Check Data

Chapter 10 – PCI HSM Compliance

Introduction
The requirements for PCI HSM approval of HSMs used to process card payments and
issue payment cards was published in April 2009; these requirements address the HSM's
hardware, software, and manufacturing/delivery processes. It is expected that the card
schemes will at some point mandate that new HSMs must be certified to PCI HSM.
Thales have introduced PCI HSM certified versions of the payShield 9000 HSM hardware
and software in advance of the mandates coming in to force as a proof of capability of
the HSM, and to provide a product for users who wish to be early adopters of PCI HSM
certified systems or to prepare for certification. Use of PCI HSM certified-HSMs is also
required to meet the requirements of certain other PCI standards (e.g. Point-to-Point
Encryption, mPOS, Card Production)
Until the card scheme mandates come into effect, not all versions of payShield 9000
software will be formally PCI HSM certified. However, all versions of software now
include the changes described in this chapter.
This chapter provides information on changes that have been made to the payShield
9000 in order to achieve PCI HSM certification, and provides guidance to users on how to
operate the HSM in a PCI HSM compliant manner.
The payShield 9000 is certified under Version 1 of the PCI HSM requirements, and the
information in this chapter relates to that version of requirements.
What is needed to be PCI HSM Compliant?

A payShield 9000 is PCI HSM compliant when the following conditions are met:
 The software revision in use is PCI HSM certified.

 The hardware revision is PCI HSM certified.
 The software and hardware revisions are covered by the same certificate.
 Security settings have values compliant with the needs of PCI HSM.
 The payShield 9000 has been shipped in a PCI HSM compliant manner.
Examples of cases where a payShield 9000 is not PCI HSM compliant include:
 A certified software version is installed on a hardware version which has not been
certified.
 Both the hardware and software versions are certified, but are covered by
different certifications.
 Both the hardware and software versions are certified, but relevant security
settings have non-compliant values. This situation is discussed in this chapter. (In
fact, while any of the security settings are non-compliant the payShield 9000 will
report installation of a software revision which does not appear on any certificate.
The software revision number which does appear on a certificate is reported by
the payShield 9000 only when all security settings have appropriate values.)
 Both the hardware and software versions are certified and all security settings
have compliant values, but the HSM was not shipped and delivered to the end
user in a compliant manner.
Formal certifications are not available for payShield 9000 hardware which was
manufactured before Thales introduced PCI HSM certified units. Although such units can
never be PCI HSM compliant, they differ from certified hardware only in minor aspects

which do not affect the security of the unit. Installing PCI HSM certified software on such
hardware results in a payShield 9000 which is still not PCI HSM compliant but which is
functionally similar to the PCI HSM certified product.
Use of non-certified software

The payShield 9000 is not PCI HSM compliant if it is running base or customized
software which has not been certified – even if the customized software is built on a
certified version of base software.
However, such a payShield 9000 will become PCI compliant if certified software is
subsequently installed onto it (assuming that all the other conditions for compliance are
met).
This means that it is acceptable to acquire a payShield 9000 with non-certified software,
and for that payShield to become PCI HSM compliant (assuming that all the other
conditions for compliance are met) when:
 its software version subsequently becomes certified, or
 a different, certified version of software is installed on it.
It is also acceptable for a payShield 9000 which is fully PCI HSM compliant to temporarily
use non-certified software (during which period the payShield 9000 will not be PCI HSM
compliant) and then to regain compliance later when certified software is installed (or its
software becomes certified).
How to tell whether your payShield 9000 is PCI HSM

Compliant
For a payShield 9000 to be PCI HSM compliant, the following conditions must apply:
 The HSM software must have been certified as being PCI HSM compliant, such
that the software revision number is included on a PCI HSM certificate. The
payShield 9000's software revision number can be accessed using the VR Console
command or Status / Software Info in payShield Manager. It has the format
nnnn-09nn (if there are non-PCI HSM compliant security settings) or nnnn-19nn
(if all security settings are PCI HSM compliant), where 'n' represents a decimal
digit. The software revision number can be compared against those quoted on the
online certificate on the PCI SSC web site (see later in this chapter). The
payShield 9000 Software Release Notes also identify which versions of payShield
9000 software have been PCI HSM certified.
 The relevant software security settings must have the appropriate values (see the
section Moving between Compliant and Non-Compliant states later in this
chapter.) If any of these settings have non-compliant values, the software
revision number will be of the format nnnn-09nn, which means the software is not
PCI HSM certified. If all of these settings have non-compliant values, the software
revision number will be of the format nnnn-19nn: the software revision number
should then be checked against the online certificate on the PCI SSC web site (see
later in this chapter).
 The HSM hardware revision must have been certified as being PCI HSM compliant,
such that the hardware revision number appears on the same PCI HSM certificate
as the software revision number. The hardware revision number is printed as "PCI
HSM Rev." on the label on the rear of the payShield 9000:

Thales e-Security Limited

Marketing Number: HSM9-12S
Part Number: 1600B466
Manufactured: A207410001
MAC Address: H1: 00:D0:FA:04:36:42
H2: 00:D0:FA:04:36:43
Mgt: 00:D0:FA:04:36:44
Aux: 00:D0:FA:04:36:45
Rating: 100-240Vac 2.1A 50/60Hz
Serial Number: B4654274998L
PCI HSM Rev.: 1600B466.02.x.x.x. x.x. x
Bar Code
Label No. 1227A31 Made in the UK
The hardware revision number has the format 1600Xnnn.nn.x.x.x.x.x.x, where:

 "X" represents an upper-case alphabetic character.
 'N' represents a decimal digit.
 "x" is always shown as the letter "x", but is actually a wildcard character
representing a decimal number up to 4 digits long. The values of x do not
generally need to be known, but if required they can be obtained from
Thales support by providing the HSM Serial Number.
The hardware revision number can be checked against the hardware version listed
on the online certificate on the PCI SSC web site (see later in this chapter)..
Formal certifications do not include some payShield 9000 hardware units which
were manufactured prior to PCI HSM mandates coming into effect, including:
 earlier payShield 9000 units which do not have the hardware revision
number printed on the label
 units where the hardware revision number on the label is not included in a
certification. In particular, units with a hardware revision number of the
format 1600X466.00.x.x.x.x.x.x are not PCI HSM certified.
Although such units can never be PCI HSM compliant, they differ from certified
hardware only in minor aspects which do not affect the security of the unit.
Ordering PCI HSM compliant units

Hardware and software certification and PCI compliant shipment can be assured when
ordering a payShield 9000 unit by including in the order the free-of-charge part number
HSM9-PCIHSMCOMP.
This part number is used by Thales sales order processing departments to ensure that
software, hardware, and delivery methods used by Thales are PCI HSM compliant. (Note

that the user is still responsible for ensuring that security settings have compliant
values.)
By default, the latest certified software will be installed. However, users can still specify
that other software (including non-certified versions) is installed. This would mean that
the payShield 9000 is not PCI HSM compliant, but can be made to be compliant at a later
date by installing certified software (with the appropriate security settings).
Online Certificates
In line with PCI recommendations, the online PCI HSM certificate is the only definitive
source of information as to which versions of software and hardware have been certified.
The "PCI HSM Rev" entry on the unit's label must conform to one of the hardware
numbers on the certificate, and the software number and version reported by the VR
console command must match one of the firmware numbers on the certificate.
The PCI HSM Certificate can be viewed on the PCI Document Library site at
https://www.pcisecuritystandards.org/popups/pts_device.php?appnum=4-40069 . The
online certificate will be similar to this:
Users must check the online certificate on the PCI web site to see if their version of
software is certified.
The payShield 9000 software will report on the status of the PCI-relevant security
settings: these must all be in a PCI HSM-compliant state in addition to the certifications
and approved delivery mechanism for the HSM to be PCI compliant.
Shipment to the end-user and subsequent handling of

the payShield 9000
This section describes the understanding that Thales has of the PCI HSM Version 2.0
standard and its impact on shipping and receipt by the user. (The requirements of PCI

HSM Version 2.0 are not directly applicable to the payShield 9000 because it is certified
against Version 1.0 of the requirements. However, the Version 1.0 requirements do not
discuss this subject in sufficient detail, and so the Version 2.0 requirements should be
followed for best security practise.) Thales is not qualified to provide advice on PCI
standards and so readers must make their own judgements as to proper courses of
action to take or discuss their intentions with a PCI QSA.
This section also provides suggestions as to how users should manage the payShield
9000 after it has been delivered to them. The PCI HSM standard is not explicit in this
area, but certain clarifications have been received and are included in the information
provided below.
Warning: The information in this section is not intended to constitute security

or standards compliance advice and should not be relied upon in lieu of
consultation with appropriate technical security and audit compliance advisors
in your own area of operations.
Shipping
Responsibilities
Any organization which is involved in arranging the shipping (whether for the whole
journey, or a "leg" of a multi-part journey) of an HSM which is to be PCI HSM compliant
must ensure that the shipping is conducted in a manner which is compliant with the
requirements of the PCI HSM standard as described in the next section.
The following table outlines a number of common delivery scenarios and shows which
party has responsibility for which section of the payShield 9000's journey. It is important
to understand that Thales's resellers are distinct organizations from Thales, and Thales
does not have responsibility for the shipping "legs" that they organize.
Scenario Responsible party Extent of responsibility

Thales arranges shipping Thales Manufacturing Complete journey, until receipt of
from manufacturing facility Facility payShield 9000 is signed for by the
direct to end user end user.
Thales arranges shipping Thales Manufacturing Up to receipt of payShield 9000 by the

from its manufacturing Facility Thales regional office.
facility to a Thales regional
office, and that Thales Thales regional office From receipt of the payShield 9000
regional office arranges until receipt of the payShield 9000 by
shipping to the end user. the end user.

from its manufacturing Facility Thales regional office.
facility to another Thales
regional office, then that Thales regional office From receipt of the payShield 9000
Thales regional office until receipt of the payShield 9000 by
arranges shipping to a the reseller.
reseller, and the reseller Thales reseller From receipt of the payShield 9000
arranges shipping to the end until receipt of the payShield 9000 by
user. the end user.

from its manufacturing Facility Thales reseller.
facility to a reseller, and that
reseller arranges shipping to Thales reseller. From receipt of the payShield 9000
the end user. until receipt of the payShield 9000 by
the end user.

Scenario Responsible party Extent of responsibility

Reseller arranges collection of Thales reseller Complete journey, until receipt of
payShield 9000 from Thales payShield 9000 is signed for by the
manufacturing facility and end user.
then onward-ships to the end
user.
End user arranges collection End user Complete journey.

of payShield 9000 from
Thales manufacturing facility.
The PCI HSM standard discusses delivery of the HSM to the "facility of initial
deployment". (The version 1.0 requirements used the term "initial key loading facility".)
It does not explicitly place any requirements on the end user where the point of receipt
by the end user organization is not the place where the first LMK will be loaded.
However, Thales recommends that the end user organization implements the controls
described later in this section.
What are the PCI requirements?

The requirements that the PCI HSM standard makes for shipping of payment HSMs can
be found in the document
Payment Card Industry (PCI) Hardware Security Module (HSM) Security

Requirements Version 2.0
in the section entitled
Device Security Requirements Between Manufacturer and Initial Key Loading.
This document can be found on the PCI web site at the following URL:
https://www.pcisecuritystandards.org/security_standards/documents.php?associa
tion=PTS
For reference, the v1.0 requirements can be found at:

https://www.pcisecuritystandards.org/documents/PCI%20HSM%20Security%20R
equirements%20v1.0%20final.pdf .
The v2.0 requirements applying to end users and resellers can be summarized as
follows:
Requirement Description
E1 1. Customers shall be provided with documentation that provides
instruction on validating the authenticity and integrity of the HSM.
2. The HSM is shipped from the manufacturer's facility to the facility
of initial deployment and stored en route under auditable controls
that can account for the location of every HSM at every point in time.
Where multiple parties are involved in organizing the shipping, it is
the responsibility of each party to ensure that the shipping and
storage that they are managing is compliant with this requirement.
E2 Procedures are in place to transfer accountability for the device from
the manufacturer to the facility of initial deployment. Where the
device is shipped via intermediaries such as resellers, accountability
will be with the intermediary from the time at which they receive the
device until the time it is received by the next intermediary or the
point of initial deployment.

E3 While in transit from the manufacturer's facility to the facility of

initial deployment, the device is shipped and stored in tamper-
evident packaging
E4 The device's development-security documentation must provide
means to the facility of initial deployment to assure the authenticity
of the security-relevant components.
E6 The manufacturer must provide the means to the facility of initial
deployment to assure the verification of the authenticity of the HSM
security-related components.
Note that where the same or equivalent requirements appear in the v1.0 requirements
the numbering scheme is different.
Notes on the PCI requirements

Requirement E1.
Item 1 in E1 is satisfied by the payShield 9000 Security Operations Manual. It is
important that users follow the guidance provided in this manual – this is good security
practice, irrespective of the needs of the PCI requirements.
The version 2.0 PCI requirements allows requirement E1 to be met if either items 1 or 2
are applied, although expressing a preference for item 1. However, the version 1.0
requirements do not refer to item 1 and explicitly demands item 2. It is therefore
suggested by Thales that resellers and users ensure that both items are satisfied.
Note that requirement E1 emphasizes that resellers and users are responsible for the
compliance of any part of the shipping process that they are arranging.
Requirement E2.
This is also a requirement under version 1.0. Again, requirement E2 emphasizes that
resellers and users are responsible for the compliance of any part of the shipping process
that they are arranging.
Requirement E3.
This corresponds to Requirement D3 in the version 1.0 requirements. It is satisfied by

the tamper labels affixed by Thales at the factory. Note that the payShield 9000 Security
Operations Manual requires that these labels are checked by users as part of their
procedures when receiving the HSM.
Where the payShield 9000 is shipped via a reseller who has a legitimate need to access
the payShield 9000 (e.g. to install additional licenses), any tamper-evident labels affixed
to the packaging will need to be broken. In this case, the reseller should attach a new
tamper-evident label of their own design, and provide an explanation of the background
to the end user.
Note that the tamper labels affixed to the payShield 9000 itself must never be damaged
or removed.
Requirements E4 and E6.
These are new in the version 2.0 requirements, and so the design of the payShield 9000
does not specifically take these into account. However, these requirements are addressed
by the tamper labels affixed by Thales and the requirement in the payShield 9000
Security Operations Manual for receiving users to inspect them.

Where users have provided suitable contact details to Thales, serial numbers for the
tamper labels and for the unit itself will be provided to the user using a separate delivery
channel (typically e-mail) from the HSM itself. If for any reason the user has not received
a communication of the serial numbers, these should be requested from Thales. The
expected serial numbers should be checked against the actual serial numbers on the
received HSMs.
Relevance to Shipping
Requirements E1 and E2 are those that must be met by whoever is responsible for
arranging the shipping or any part of the shipping between the Thales manufacturing
facility and the end user's facility of initial deployment.
The PCI Security Standards Council does not define how these requirements are to be
met, but parties arranging shipping must ensure that the shipping method meets these
needs and can, if required, be shown to do so. Thales suggests that the capabilities of
the shipping method include:
 A tracking facility, such that when the payShield 9000 is taken by the shipping
organization they provide a tracking number and an online facility to allow the
location of the shipping to be identified at any time.
 Signed receipts, accessible online, as the unit passes between different
organizations. This will typically only involve receipts from the shipping company
when they receive the unit and from the organization that the unit is shipped to.
Shipping by Thales
Thales offers a PCI HSM compliant shipping method. Once the PCI HSM mandates are in
effect, it is expected that all payShield 9000 units will be shipped using that method.
Depending on the region, the PCI HSM compliant shipping method may be different and
more expensive than the method traditionally used by Thales. Therefore in the period
where PCI HSM compliance is optional, end users can choose whether to have PCI HSM
compliant shipping or the lower cost shipping that may traditionally have been used.
Where it is required that a payShield 9000 is PCI HSM compliant, the part number HSM9-
PCIHSMCOMP should be added to the order: this will ensure that the payShield 9000 is
shipped in a PCI HSM compliant manner.
Prices for PCI HSM compliant shipping can be obtained from Thales.
Shipping by Partners and Resellers

Where end users are acquiring their payShield 9000 units through resellers of Thales
products and PCI HSM compliance is required, it is suggested that end users confirm that
the reseller is capable of providing PCI HSM compliant shipping and what any associated
prices are.
The PCI HSM requirements do not address this situation, but Thales suggests that
partners and re-sellers adopt equivalent best-practise procedures as outlined for end
users in the section on Movement within the end user organization .
Collection by End Users

A number of end users arrange for collection of their payShield 9000s from Thales or a
Thales partner or reseller, using their preferred shipping method. End users should
confirm that their shipping method meets the needs of the PCI HSM requirements.

After Delivery to the end user's delivery address

Movement within the end user organization
The PCI HSM standard covers first delivery of the HSM to the "facility of initial
deployment": in the context of the payShield 9000, Thales suggests that this is where
the first LMK is loaded. Where Thales or one of its partners or resellers has taken
responsibility for shipment, their responsibility will end when the unit is received by the
end user organization. The point of receipt at the user organization (e.g. a Goods Inward
department) may not be the facility of initial deployment, and so the end user
organization must ensure that PCI HSM compliance is maintained between the point of
receipt and the initial key loading facility.
Thales believes that spirit of PCI compliance will be met by the following best-practice
procedures where the payShield 9000 is received at a location or by a department
different to that where the initial key (i.e. the first LMK) is loaded, and takes into account
requirements expressed in other PCI standards such as P2PE and PIN Security:
 All advice provided in the payShield 9000 Security Operations Manual should be
followed.
 The devices are securely stored.
 Auditable controls should be maintained that allow the location of the payShield
9000 at every point in time to be accounted for.
 Access to the payShield 9000 should be controlled by a security policy and logged
to ensure that only authorized individuals have access to the HSM. Authorized
individuals should be listed in a formal document. Access should be under dual
control – i.e. single individuals should not have access to the HSM.
 The "chain of custody" must be documented and recorded. If the payShield 9000
passes between internal departments in the user organization (e.g. from Goods
Receipt to Internal Delivery Service to Security Department) then audit records
should be maintained to track the transfer of accountability between the
departments.
 The tamper labels attached to the payShield 9000 casing should never be
removed, but in the case of the PCI HSM standard the integrity of these labels is a
core element of the security processes required for PCI HSM compliance. Therefore
it is particularly important that these tamper labels are not damaged or removed.
However, it is important that users consult their security advisers or auditors for formal
advice, as Thales are not qualified to provide this. Further detail is also available in
various PCI standards, such as P2PE and PIN Security.
Initial inspection
The payShield 9000 Security Operations Manual provides information on the payShield
9000 and its handling which are important for best security practice and to meet the
needs of the PCI HSM standard. All of its advice and procedures must be followed, and
the Initial Inspection Routine must be executed by the appropriate staff as soon as is
practicable after receipt of the payShield 9000 by the end user organization.
The payShield 9000 serial number and tamper label serial numbers should be compared
with those notified by Thales by e-mail. These e-mails are sent for all orders where an e-
mail address is provided with the order: in other cases, or where the e-mail is not
available, the serial numbers can be requested from Thales.

Managing the payShield 9000 after initial key loading

As already mentioned, the PCI HSM requirements end with the first delivery to the facility
of initial deployment (as confirmed in PCI's HSM Technical Frequently Asked Questions).
However, the recommendations in the payShield 9000 Security Operations Manual should
continue to be followed throughout the life of the payShield 9000.
PCI's HSM Technical Frequently Asked Questions also clarify that, although an HSM is not
PCI HSM compliant while it is running non-certified software, PCI HSM compliance can be
established or re-established at a later date by installing certified software – assuming
the other conditions mentioned in the earlier section on Error! Reference source not
found. are satisfied. This is
"subject to the condition that the chain of custody over the HSM following its
receipt at the point of initial deployment has been controlled and is auditable, for
example in accordance with the requirements of PCI PIN or PCI P2PE."
Thales therefore suggests that end users consider and implement the relevant
requirements in the PCI requirements for PIN Security Requirements and Point-to-Point
Encryption. These requirements reflect good security practice, and include aspects such
as:
 dual control
 physical protection
 access controls
 procedures to ensure security and integrity
 inventory control
 tracking of movements
 update control
Returning a payShield 9000 for Servicing

The PCI HSM standard does not address the process for returning HSMs for repair or
servicing. However, Thales makes the following suggestions to maintain the spirit of the
PCI HSM standard. End users should consult their QSA or other security auditor to
discuss any other requirements they consider appropriate.
These suggestions are relevant where the user wishes to maintain PCI HSM compliance
of their payShield 9000s, and where the payShield 9000 meets the conditions of certified
hardware and compliant shipping.
Thales suggests that:
 The user stipulates on the documentation that accompanies the unit (such as the
Thales RAN form) that PCI HSM compliance is required. This is important even if
the old payShield 9000 is to be replaced with a different unit, to ensure that the
replacement unit is PCI HSM compliant.
 The user should ensure that the method they use to ship the unit back to Thales
(or other service organization) meets the needs of PCI HSM compliant shipping, as
outlined earlier in the section in What are the PCI requirements?.
 When the replacement unit is delivered to the end user, it should be handled as
outlined in the sections on Movement within the end user organization and Initial
inspection earlier in this chapter.

Interoperability with HSM 8000

In order to allow backwards interoperability between the current payShield 9000 and
HSM 8000 (and earlier payShield 9000 units), the payShield 9000 security settings
include some items that can be set for PCI HSM compliance or for backwards
compatibility – see the section on Moving between Compliant and Non-Compliant states
later in this chapter. IMPORTANT: if any of these settings have the non-compliant
value then the payShield 9000 is not being operated in a PCI HSM compliant manner and
it cannot be considered as being PCI HSM compliant.
Where payShield 9000 settings have been made to satisfy PCI HSM compliance rather
than backwards compatibility, the PCI HSM-compliant payShield can interoperate with
HSM 8000s running software v3.3a or later, which can support the key type changes that
have to be made in the payShield 9000 for PCI compliance. In this case, the restrictions
described in the section on Restrictions on PIN Block format translations and usage must
also be implemented on the HSM 8000. (These restrictions are not enforced by the HSM
8000, but they should in any case be implemented as part of the overall system design
to meet ISO 9564/ANSI X9.8.)
Changes introduced for PCI HSM Certification

 User Authentication
 Authentication by password
 Minimum PIN length
 Smartcard PIN entry timeout
 Enforcement of use of multiple components when forming keys and LMKs.
 Time limitation on Authorized states
 Key separation (Variant LMKs only)
 Key type changes
 Migrating keys to the new key type
 Disabled Host commands
 Changes to parameters when sending Host commands
 Interoperability with HSM 8000
 Restrictions on PIN Block format translations and usage
 Applying the restrictions
 PIN Block format translations
 PIN Block format usage
 Automated self-tests
 Enhanced audit log
 Automated Event recording
 Disabled Console commands
 Authorization of IK Console command
 Information on status of PCI HSM compliance
 On starting the payShield 9000
 VR Console Command
 CS Console Command
 NO Host Command
These are described in more detail in the following sections.

User Authentication
Authentication by password
User authentication at the HSM and payShield Manager must now use smartcards – the
option to use passwords is not valid where PCI HSM compliance is required.
Therefore for PCI HSM compliance the use of smartcards must be specified in one of the
following ways:
 At the Console, using the CS command to set the response "C" to the following
prompt:
Card/password authorization (local) [C/P]:
 Using payShield Manager, go to Configuration / Security Settings / Initial and
choose the "Smartard" option from the dropdown menu of the "Card/password
authorization (local)" setting. The default setting (on the payShield 9000 as
delivered from the factory) is to use smartcards, i.e. the PCI HSM compliant
value.
Minimum PIN Length

The minimum PIN length when using smartcards for user authentication has been
increased to 5 digits. This means that when setting up PINs for smart cards the PINs
must be at least 5 digits long. (The recommended PIN length remains at 8 digits.)
Existing smartcards created with PINs of only 4 digits can continue to be used. However,
Thales strongly recommend that these PINs are reset to be at least 5 digits long – and
preferably 8 digits long.
Smartcard PIN entry timeout

When smartcard PIN entry is required to authenticate a user, the PIN entry must be
made within 60 seconds of the PIN being requested by the HSM. If the PIN is not entered
within this time, the user activity which caused the PIN entry request will be terminated.
This requirement does not mean that a valid PIN has to be entered within 60 seconds of
initially being requested: if an incorrect PIN is entered, the user will be asked again to
enter the PIN and the 60-second timer will restart.
Multiple Components when Forming Keys

In order to be PCI HSM (and PCI P2PE compliant), operational keys and LMKs must be
formed from multiple components. The security setting "Enforce Multiple Key
Components?" is provided to allow the use of multiple components to be enforced when
forming keys and LMKs. This setting must be YES to allow the payShield 9000 to be PCI
HSM compliant.
Time limitation on Authorized states

The security setting "Enforce Authorization Time Limit?" is available to impose a time
limitation on the authorization of Console commands. This setting must be used in order
to be PCI HSM compliant, and means that Console commands which require
authorization can be authorized for a maximum of 12 hours (720 minutes). If no
authorization period or permanent authorization is requested (in the A Console
command) the authorization will expire after 12 hours (or earlier if the authorization is
cancelled).

This change does not affect:
 Equivalent activities using payShield Manager, as these are limited to a maximum

duration of 60 minutes already.
 Authorization of Host commands.
Note that in payShield 9000 versions 1.2a to 2.2b this time limitation was always
enforced and the user did not have the ability to override it.
Single Authorized State

In this state, multiple authorized activities has not been selected in the CS command).
Host commands will continue to be authorized until the C Console command or RA Host
command is used. Authorization of Console commands will cease after the soonest of:
 The C Console command or RA Host command being used.

 12 hours from when the authorization was set up.
 The unit is re-booted
Multiple Authorized Activities

Where multiple authorized activities has been selected in the CS command, the Host
commands will continue to be authorized until any user-specified time limit is reached, or
the C Console command or RA Host command is used. Authorization of Console
commands will cease after the soonest of:
 The C Console command or RA Host command being used.

 Expiry of any time limit set by the user.
 12 hours from when the activity was authorized.
 The unit is re-booted and the user has elected not to make the activity persistent
when authorizing it.
Key separation
Key Block LMKs
Key Block LMKs, available on the payShield 9000 since its introduction, already meet the
PCI HSM requirements for key separation, and as a result users who have deployed Key
Block LMKs are not affected by this requirement.
Variant LMK Key Type changes

For users who are still operating with Variant LMKs, a number of keys and other data
using key type 002, i.e. encrypted with LMK key pair 14-15 variant 0, must be moved to
other key types. (Host applications not using keys in key type 002 are not affected by
this requirement.)
In order to let users choose between backwards compatibility and PCI HSM compliance
(so that they can plan their move to PCI HSM compliance) a security setting has been
introduced, which can be managed using the CS Console command or Configuration /
Security Settings / Initial in payShield Manager:
Enforce key type 002 separation for PCI HSM compliance
If this is left unset as per the default setting (i.e. as delivered from the factory), the keys
and data are left at key type 002 and the HSM is compatible with older host applications

and HSMs. However, this setting means that the HSM is not being operated in a PCI
HSM compliant manner.
If the setting is set', all of the keys and data previously in key type 002 (except the PVK
and PVVK) will be encrypted/decrypted with the following key types:
Key or Data New Key New LMK

Type Pair
Affecting Base payShield 9000 software:
PVK PIN Verification Key 002 14-15/0
(no change) (no change)
TMK Terminal Master Key 80D 36-37/8
TPK Terminal PIN Key 70D 36-37/7
DbTAB Diebold Table 60D 36-37/6
Affecting APACS 40 & 70 applications:
KEYVAL Intermediate PIN Key 70D 36-37/7
TKR Terminal Key Register 90D 36-37/9
Affecting OBKM applications using Optional License LIC004:
PVVK PVV Key 002 14-15/0
(no change) (no change)
Affecting APCA-compliant applications using Optional License LIC003:
KT Transaction Key 80D 36-37/8
TK Terminal Key 80D 36-37/8
PEK PIN Encipherment Key 70D 36-37/7
KI Initial Transport Key 80D 36-37/8
KCA Sponsor Cross Acquirer Key 80D 36-37/8
KMA Acquirer Master Key Encrypting Key 80D 36-37/8
Affecting CUP applications using Optional License LIC031:
PEK PIN Encryption Key where PEK 70D 36-37/7

Type=1
Migrating keys to the new key type

Before the new key type assignments can be used, the affected keys in the key database
must be migrated from key type 002 to their new key type. It is recommended that this
is performed when LMKs are being refreshed in line with card scheme requirements. The
BW Host Command (Translate Keys from Old LMK to New LMK) has the capability to:
 Move a key from encryption under an old LMK to encryption under a new LMK (as
in previous versions of software)
 Migrate a key from key type 002 to the appropriate new key type, with no change
of LMK.
 Move a key from encryption under an old LMK to encryption under a new LMK and
migrate it from key type 002 to the appropriate new key type.
More information about this can be found in Chapters 10 and 18 of the payShield 9000
Host programmer's Manual.

Disabled Host Commands

A number of legacy Host commands are unable to function when keys are moved to
different key types. These commands will be disabled if the setting Enforce key type 002
separation for PCI HSM compliance is set: their functions can be performed by newer
replacement commands. The commands affected are:
Host Command Replaced by

AA Translate a TMK, TPK or PVK BW Translate Keys from Old LMK to New
LMK
AE Translate a TMK, TPK or PVK from A8 Export a Key
LMK to Another TMK, TPK or PVK
FC Translate a TMK, TPK or PVK from A6 Import a Key
ZMK to LMK Encryption
FE Translate a TMK, TPK or PVK from A8 Export a Key
LMK to ZMK Encryption
FG Generate a pair of PVKs A0 Generate a Key
HC Generate a TMK, TPK or PVK A0 Generate a Key
KA Generate a Key Check Value (Not BU Generate a Key Check Value
Double-Length ZMK)
OE Generate and Print a TMK, TPK or NE Generate and Print a Key as Split
PVK Components
Changes to parameters when sending Host commands

Where applications are using Host commands which identify the key type, the key type
value will need to be changed in line with the above table. The Host commands that are
affected include:
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

Interoperability with HSM 8000 units

HSM 8000 software v3.3a and later includes the same key type change functionality as
described above. This allows HSM 8000 units with this version of software to interoperate
with PCI HSM compliant payShield 9000 units.
Restrictions on PIN Block format translations and usage

The PCI HSM certification requirements limit the PIN Block format translations which can
be made to those permitted by ISO 9564/ANSI X9.8. The requirements can be
summarized as follows:
 Translation from PIN block formats that involve the PAN to PIN Block formats that
do not involve the PAN are not allowed.
 ISO PIN Block formats 0, 1, 2, 3, and 4 cannot be translated into any non-ISO
format.
The requirements also restrict the application of PIN Block formats as follows:
 Only ISO formats 0, 3, and 4 can be used for calculating values derived from the
PIN and PAN such as PIN Offsets and PIN Verification Values (PVV).
Applying the restrictions

In order to let users choose between backwards compatibility and PCI HSM compliance a
new security setting has been introduced:
Restrict PIN block usage for PCI HSM compliance
When the payShield 9000 is shipped from the factory, this setting is not set: this means
that the restrictions are not applied and the payShield 9000 is backwards-compatible
with legacy HSMs.
Note:
 This default setting means that the HSM is not being operated in a PCI
HSM compliant manner.
If this setting is set to have the PCI HSM-compliant value then the restrictions on PIN
Block format translations required for PCI HSM compliance will be applied.
Please see the section Moving between Compliant and Non-Compliant states later in this
document.
Restrictions on PIN Block Format translations

When the setting Restrict PIN block usage for PCI compliance is set, the permissible PIN
Block format translations are limited to:

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   
The rows shaded grey cells indicate that these translations are not currently used in any
payShield 9000 Host commands. (Descriptions of the PIN Block formats can be found in
Chapter 14 of the payShield 9000 Host Programmer's Manual.)
If a Host command requests a PIN Block format translation which is not allowed, error
code 23 will be returned in the response.
The commands that are affected by this include:
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)
Note:
 Further restrictions will apply if the user has disabled any PIN Block formats (e.g.
by using the CONFIGPB Console command). Thales formats 02, 03, 04, and 34
are disabled by default.

Restrictions on PIN Block Format usage

When the setting Restrict PIN block usage for PCI compliance, calculation of values
derived from the PIN and PAN such as PIN Offsets and PIN Verification Values (PVV) may
be done only with Thales PIN Block formats 01 (ISO format 0), 47 (ISO format 3) and
48 (ISO format 4).
The commands affected by this include:
Command
BK Generate IBM PIN Offset (customer-selected PIN)
CU Verify & Generate a Visa PVV
DU Verify & Generate IBM PIN Offset
FW Generate Visa PVV (customer-selected PIN)
Automated self-tests
Self-tests (i.e. those which can be initiated manually using the DT Console command or
via Status / Health Statistics/Diagnostics / Diagnostics in payShield Manager) are now
run automatically and daily. Results can be audited, and any failures are recorded in the
error log.
By default these self-tests run at 09:00. The console command ST or Status / Health
Statistics/Diagnostics / Diagnostics in payShield Manager can be used to allow the user
to select an alternative time for these automated self-tests.
The self-tests can continue to be run manually at other times using the DT Console
command or Status / Health Statistics/Diagnostics / Diagnostics in payShield Manager.
Enhanced audit log

Recording of smartcard serial numbers
The audit log will record the serial number of a smartcard when it is used to log in to
payShield Manager or to run a Console command (i.e. A and LK) where authentication
using smart cards is required. E.g.:
000007DD 15:08:48 19/Apr/2011 Smartcard activated: 20025132
Note that smartcards should always be issued on a personal basis, either by being
permanently allocated to the person or by being signed out to them on a temporary basis
with the issue/return times being recorded.
Automated Event recording

Certain events are now always recorded in the Audit Log, and their recording cannot be
disabled. These events include:
 The use of smartcards (including the serial numbers of the smartcards) for user
authentication at the HSM or payShield Manager.
 The use of the A console commands to authorize activities; the audit record
indicates how long the activity is authorized for.
 Cancellations of authorization.

 Key/component entry actions arising from use of the following Console commands
(or equivalent payShield manager menu items):
Console Command
Current commands
CV Generate a Card Verification Value
FK Form Key from Components
IK Import a Key
LK Load LMK
LO Load 'Old' LMK into Key Change Storage
LN Load 'New' LMK into Key Change Storage
PV Generate a Visa PIN Verification Value
RL Load RMK
Legacy Commands
BK Form a Key from Components
D Form a ZMK from Encrypted Components
DE Form a ZMK from Clear Components
IV Import a CVK or PVK
Removed Console commands

The following legacy Console commands used for key/component entry do not require
authorization and therefore their authorization cannot be automatically audited.
Therefore these commands are disabled, and the specified replacements should be used
in their place:
Console Command Replaced by

DB Import a KML IK Import Key
DF Import a BDK IK* Import Key
K Encrypt a Key Under LMK Variants FK Form Key from Components
14-15
YC Import a CSCK IK Import Key
* The IK (Import Key) Console command previously required authorization only

under certain circumstances. This has been changed so that the IK command
always requires authorization in order to allow its use to be automatically audited
and associated with a user.
Information on status of PCI HSM compliance

On starting the payShield 9000
When re-starting a payShield 9000, one of the following messages will be displayed on
the Console:
 "NOTE: Some security settings are not PCI HSM compliant", or

 "Security settings are consistent with the requirements of PCI HSM." The user is
referred to the PCI web site for information on whether this version of software
has been PCI HSM certified.

In the payShield Manager, use Summary / Configuration Dashboard to check the status
of the PCI HSM-relevant security settings. (See the payShield Manager User Guide for
more information.)
See the section on Moving between Compliant and Non-Compliant states later in this
chapter for more information about the security settings which affect PCI HSM
certification.
VR Console Command
In the output from the VR Console command, one of the following messages will be
displayed to indicate the status of the security settings that affect PCI HSM compliance:
 If all of the security settings are in the compliant state:

PCI HSM Compliance:
Refer to the PCI web site
(https://www.pcisecuritystandards.org/approved_companies_provid
ers/approved_pin_transaction_security.php) for current
certification status of this version of payShield 9000
software.
Security settings are consistent with the requirements of PCI
HSM.
 If some or all of the security settings are not compliant:

PCI HSM Compliance:
Some security settings are not PCI HSM compliant
Where all the security settings that affect PCI HSM compliance are set to the compliant
value, the software revision number is automatically modified to have the format nnnn-
19nn. (If the software number has the format nnnn-09nn then some of the security
settings do not have PCI HSM compliant values.)

See the section on Moving between Compliant and Non-Compliant states later in this
chapter for more information about these settings.
CS Console Command
For certified software, a warning is given for each of the settings that affect PCI HSM
compliance if they have been set to a non-compliant value. See the section on Moving
between Compliant and Non-Compliant states later in this chapter for more information
about these settings. The Console Reference Manual gives examples of the output from
the CS and QS Console commands.
NO Host Command
The NO Host command provides the following information in the response if Mode 01 is
selected:
 Whether all security settings affecting PCI HSM compliance have compliant values
 Whether the key separation setting has a non-compliant values.
 Whether the key separation setting has the compliant value, but some of the
other two security settings which affect PCI HSM compliance have non-compliant
values.
See the section on Moving between Compliant and Non-Compliant states below for more
information about these settings.
Moving between Compliant and Non-Compliant states

As has been discussed in this chapter, there are several security settings which can be
set to non-compliant or compliant values:
 Enforce key type 002 separation for PCI HSM compliance (Y for compliance;
default setting is N)
 Restrict PIN block usage for PCI HSM compliance (Y for compliance; default
setting is N)
 Card/password authorization (C for compliance; default setting is C)
 Enforce Authorization Time Limit (Y for compliance; default setting is Y)
 Enforce Multiple Key Components (Y for compliance; default setting is N)
If any of these settings have a non-compliant value then the HSM is not being operated
in a PCI HSM compliant manner – all of the settings must have the compliant value for
the PCI HSM certification to apply to the unit.
The settings can be changed at will until all of them have the PCI HSM-compliant values:
once all of these settings are PCI HSM-compliant, they cannot be changed unless the
Return to Factory Settings feature is used. (Note: the Return to Factory Settings facility
will reset these security settings to the values as shipped from the factory, but will also
cancel all the other settings that the end user has made. See the user manuals for more
information.)
Legal Notice from PCI SSC

PCI SSC requires that the following statement is communicated to all product purchasers
and issuers:

Legal Terms and Conditions

PCI SSC's approval applies only to payment security devices that are identical to
the payment security device tested by a PCI Security Standards Council
recognized laboratory. If any aspect of the payment security device is different
from that which was tested by the laboratory—even if the payment security
device conforms to the basic product description contained in the letter—then the
payment security device model should not be considered approved, nor promoted
as approved. For example, if a payment security device contains firmware,
software, or physical construction that has the same name or model number as
those tested by the laboratory, but in fact is not identical to those payment
security device samples tested by the laboratory, then the payment security
device should not be considered or promoted as approved. No vendor or other
third party may refer to a payment security device as "PCI Approved," nor
otherwise state or imply that PCI SSC has, in whole or part, approved any aspect
of a vendor or its payment security devices, except to the extent and subject to
the terms and restrictions expressly set forth in a written agreement with PCI
SSC, or in an approval letter. All other references to PCI SSC's approval are
strictly and actively prohibited by PCI SSC. When granted, an approval is provided
by PCI SSC to ensure certain security and operational characteristics important to
the achievement of PCI SSC's goals, but the approval does not under any
circumstances include any endorsement or warranty regarding the functionality,
quality, or performance of any particular product or service. PCI SSC does not
warrant any products or services provided by third parties. Approval does not,
under any circumstances, include or imply any product warranties from PCI SSC,
including, without limitation, any implied warranties of merchantability, fitness for
purpose or noninfringement, all of which are expressly disclaimed by PCI SSC. All
rights and remedies regarding products and services, which have received an
approval, shall be provided by the party providing such products or services, and
not by PCI SSC or the payment brand participants.

Chapter 11 – DES Key Support


Chapter 12 – AES Key Support


Chapter 13 – Transaction Key Schemes


Chapter 14 – Secure Host

Communications
Introduction
Traditionally, HSMs have been connected to host computers via a dedicated network, and
both HSMs and hosts have been located in the same physical location (typically a data
center).
Now, however, HSMs may be located remotely from the host computers - for example
where hosts are in "the cloud". Some users are looking to use networks which are shared
with other traffic - and which may even be public networks. This introduces new
requirements to maintain the security of the HSM environment, i.e.:
 Mutual authentication between the host application and the HSM - to provide
confidence to each "end" that the communication partner is what they expect it to
be.
 Privacy of transmitted data - to prevent any interceptor of the traffic from being
able to read it. (Most secret information (such as keys, PINs) is in fact already
encrypted when outside of the HSM, although PINs may be communicated in the
clear for the purpose of PIN mailer printing. Other information, such as account
numbers, has traditionally been sent in the clear as it was not viewed as being
secret.)
 Integrity of the transmitted data - to ensure that the data is not modified between
sender and receiver.
These requirements are driven by best security practise. In addition, the PCI DSS
standard requires cardholder data, such as account numbers, to be protected when
transmitted over non-private communication interfaces.
payShield 9000 Secure Host Communications

To meet this emerging requirement for secure host communications, payShield 9000
supports the use of TLS to secure traffic between host applications and HSM. SSL is also
supported for communication with applications which do not support TLS, but TLS is the
preferred protocol.
Note: This capability is available for Ethernet connections: it is not appropriate for
Asynchronous or FICON interfaces.
Working with IBM z/OS Mainframes

Users who have payShield 9000 units working with IBM z/OS host systems should make
use of the AT-TLS feature in z/OS. Guidance on how to configure z/OS system can be
found in the Thales document 1270A640 Configuring z/OS and SRM for HSM SSL/TLS
Support, available from Thales support. This document also covers the use of the Thales
SRM for z/OS.
Relevant information is also available in the IBM publication "System Secure Sockets
Layer Programming" for z/OS at chapter 3 on "Using Cryptographic Features with System
SSL".

Overview of TLS/SSL on the payShield 9000
What TLS/SSL Provides

TLS/SSL provides a high level of security for sessions between an Ethernet connected
client application and server application with no prior knowledge of each other and
without any prior exchange of encryption keys. A mutually trusted third party (the CA, or
Certificate Authority) is used to certify that the client and server are the owners of their
respective private and public key pairs used in establishing the communication session.
This trusted environment provides:
 Authentication - the server may authenticate itself to the client (typically a

browser), or the client and server may mutually authenticate themselves to each
other.
 Privacy - the communications traffic is encrypted.
 Integrity assurance - using hash and signature algorithms.
Note that TLS/SSL works between applications. This means that both communicating
applications must be TLS/SSL-enabled, rather than the host and client devices. Proxies
can be implemented to allow non-TLS/SSL-enabled applications to be used over a
TLS/SSL-protected link: here, the authentication is from/to the proxy rather than the
application.
How TLS/SSL Works

The process for setting up a TLS/SSL session can be summarised as follows:
 Both the client and server have their own private (secret) and public keys.
 The public keys are certified by Certificate Authorities (CAs).
 The public key certificates can include multiple, chained CA hierarchies -

e.g. the public key can be certified by one CA (e.g. operated by the
organization owning the key), and this CA certificate is then certified by a
higher-level CA (e.g. a third-party CA trusted by both the key owner and
the key user).
 The client and server can use different CAs.
 The client and server applications negotiate which cipher suite they will use, and
exchange some information (but not keys) that will be needed to establish the
session. The cipher suite defines the algorithms and key lengths that will be used
to establish and protect the session.
 The client and server applications exchange certificates (including their public
keys).
 The client and server validate each other's certificate and extract the public key.
The validation may be performed by contacting the CA online or by using
previously stored CA materials.
 The client application sends an encrypted "Pre-master" secret to the Server

application.

 Server and client applications both independently compute a Master secret from
the Pre-master secret and use this to calculate the symmetric keys to be used to
protect the exchanged data. The keys therefore do not need to be exchanged.
 Following a successful client-server handshake, the application data is exchanged
in records, with the data encrypted using the independently computed keys, and
MACed using the hashing algorithm in the agreed cipher suite.
The following diagram illustrates this, with some additional detail:
Client Server
Supported algorithms, random number
Chosen algorithms, random number, session ID
X.509 certificate
Verify Certificate
X.509 certificate
Calculate Pre-master Secret, Verify Certificate
computed from random numbers.
Pre-master Secret. Encrypted with Server public key.
Certificate Verify – signature over previous messages.

Verify Certificate Verify
Compute Master Secret from Compute Master Secret from
Pre-master Secret & Random Nos. Pre-master Secret & Random Nos.
Used to calculate symmetric keys Used to calculate symmetric keys
Authenticated/encrypted “Finished” message

Verify
Authenticated/encrypted “Finished” message
Verify
Exchange authenticated/encrypted data
Plaintext Encrypted
TLS/SSL Support
payShield 9000 supports the following protocol versions:
 TLS v1.2
 TLS v1.1 (PCI DSS v3.1 recommends against use of this protocol.)
 TLS v1.0 (Use of this protocol is not compliant with PCI DSS v3.1.)
 SSL v3.0. (Thales recommend against use of this protocol and it is disabled by
default. Use of this protocol is not compliant with PCI DSS v3.1.)
The payShield 9000 can simultaneously support TLS/SSL and non-secured (TCP or UDP)
traffic. It is possible to disable TLS/SSL or non-secured traffic. If TLS/SSL is enabled, it
is possible to specify that only TLS is accepted (i.e. SSL is disabled).
Optional License HSM9-LIC036 must be installed on the payShield 9000 to

enable use of TLS or SSL.
Supported Cipher Suites

The payShield 9000 supports the following TLS/SSL cipher suites.

Algorithms
Cipher Suite Name Protocols
Asymm Symm Hash
AES 256-bit
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS v1.2 ECDSA SHA-384
GCM
AES 256-bit
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 TLS v1.2 ECDSA SHA-384
CBC
AES 128-bit
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS v1.2 ECDSA SHA-256
GCM
AES 128-bit
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 TLS v1.2 ECDSA SHA-256
CBC
TLS v1.2
TLS v1.1 AES 256-bit
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA ECDSA SHA-1
TLS v1.0 CBC
SSL V3.0
TLS v1.2
TLS v1.1 AES 128-bit
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA ECDSA SHA-1
TLS v1.0 CBC
SSL v3.0
RSA AES 256-bit
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS v1.2 SHA-384
2048-bit GCM
RSA AES 256-bit
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 TLS v1.2 SHA-256
2048-bit CBC
RSA AES 128-bit
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 TLS v1.2 SHA-256
2048-bit GCM
RSA AES 128-bit
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 TLS v1.2 SHA-256
2048-bit CBC
TLS v1.2
TLS v1.1 RSA AES 256-bit
TLS_DHE_RSA_WITH_AES_256_CBC_SHA SHA-1
TLS v1.0 2048-bit CBC
SSL v3.0
TLS v1.2
TLS v1.1 RSA AES 128-bit
TLS_DHE_RSA_WITH_AES_128_CBC_SHA SHA-1
SSL v3.0
TLS v1.2
TLS v1.1 RSA Triple DES
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA * SHA-1
SSL v3.0
TLS v1.2
TLS v1.1 RSA Triple DES
SSL_RSA_WITH_3DES_EDE_CBC_SHA * SHA-1
SSL v3.0
* These cipher suites are available only if SSL v3.0 has been enabled on the payShield 9000, i.e.
the TLS Enforced setting in the host port configuration has been set to No.
Cipher Suite Negotiation

The Cipher Suites in the table above are listed in decreasing order of preference by the
payShield 9000. When negotiating Cipher Suites, the HSM's preferences will take
precedence over the client's preferences.
Ephemeral key cipher suites are preferred by the payShield 9000. When selected, every
new handshake will require new ephemeral keys be generated; this provides perfect
forward secrecy such that if an attacker should ever break the cryptography being used
for a connection then this will be of no use to the attacker in a subsequent connection. All
of the cipher suites except the last in the above table use ephemeral keys.
When performing a renegotiation of an existing connection, the payShield 9000 will
always force a new session to be negotiated; this protects against a known renegotiation
vulnerability.

Data compression
Connections will not use data compression, protecting against the CRIME vulnerability.
The HSM Recovery Key (HRK)

The HRK is used to encrypt the HSM's private key used by the HSM in establishing the
TLS/SSL session.
The HRK-encrypted private key is held outside of the tamper-protected memory such
that if the HSM detects a tamper event it is not lost: the unencrypted private key used
during live running is held in tamper-protected memory and is lost if the HSM detects a
tamper event.
The private key can therefore be recovered after a tamper event, once the HRK is
installed, by decrypting the encrypted version.
The HRK is generated by the HSM using 2 passphrases entered by security officers.
These passphrases must be provided to reconstitute the HRK when recovering the
private key after a tamper event. It is held in tamper-protected memory such that it is
automatically erased if the HSM detects an attempted tamper.
The HRK also enables recovery of the private key for the PayShield Manager CA.
HSM Certificates
The key pair for the HSM is created by the HSM.
An unencrypted copy of the private key is held in tamper-protected memory, and the
HRK-encrypted copy is held in non-volatile memory.
The HSM generates a Certificate Signing Request (CSR) containing its public key in
PKCS#10 format, and outputs this to the console and, if attached, to a USB memory
device. A Security Officer will generate a certificate signed by their chosen CA and return
the public key certificate and CA's certificate chain to the HSM.

Secure State & Security

HMK installed Officer
Generate Key Pair
Store Private Key in tamper-protected memory
Encrypt Private Key with HMK & store in non-volatile memory
Get CA-signed payShield

Create Certificate Signing Request (CSR)
9000 certificate &
for Public Key
CA certificate
Verify CA-signed payShield 9000 certificate Import certificates to

using private key payShield 9000
Store signed payShield 9000 certificate &

CA certificate
If the host computer applications are using a different CA to the HSM, the HSM's CA
certificate also needs to be imported by the security officers to the applications.
Intermediate CA certificates can be included to a maximum certificate chain depth of 6,

and must include the X509 v3 optional extensions of Subject Key Identifier and Authority
Key Identifier. The signed HSM (server) certificate must include the Authority Key
Identifier extension. (Examples of certificates are given at Certificate Examples below.)
Application Certificates
Each application that wishes to establish a secure communications session using TLS or
SSL will need to provide to the payShield 9000 a public key in the form of a certificate
signed by a CA (or by a hierarchy of CAs). The way that this certificate is obtained will
depend on the standard procedures of the organization and its selected CA mechanism.
The application certificates and their associated CA chain certificates are imported by the
security officer into the HSM using the console, or a USB memory device.
The set of client endpoint certificates forms an effective "White List" of applications that
are entitled to use the HSM through Secure Host Communications. This is used by the
payShield 9000 to mitigate against "man-in-the-middle" attacks.
Intermediate CA certificates can be included to a maximum certificate chain depth of 6,

and must include the X509 v3 optional extensions of Subject Key Identifier and Authority
Key Identifier. The signed application (client) certificate must include the Authority Key
Identifier extension. (Examples of certificates are given at Certificate Examples below.)

Out-of-Date Certificates
If an attempt to establish a Secure Host Communications session is made using an out-
of-date (i.e. expired or not yet valid) certificate, the connection will fail. As a result it is
important for users to have suitable processes in place to manage certificate introduction
and expiry.
As an option, users can audit attempts to use out-of-date certificates.
Performance considerations
For the majority of payShield 9000 functions, users will not notice a difference in
performance when implementing Secure Host Communications.
The following paragraphs indicate situations where a performance impact may be

noticed, but it is difficult to provide comprehensive guidance on the effect because this
will depend on a number of factors, in particular:
 the payShield 9000 performance model

 the TLS/SSL protocol being used
 the cipher suite that has been negotiated
 key lengths being used
 the host commands being used
 the size of the payload where host commands can have different payload sizes
 whether the RSA Booster Licence has been installed
Host commands which do not have large payloads (e.g. PIN Block translation (CA), key
import (A6), RSA key generation (EI) ) will normally run at the same speed as when
using a standard Ethernet interface. However, some combinations of protocol and cipher
suite can result in a small performance drop on the highest payShield 9000 performance
models.
Host commands processing large data blocks (e.g. encryption/decryption of data blocks
(M0/M2), translation of data blocks (M4), MACing (M6, M8) ) can experience a more
significant performance impact as the payload size increases – but again this is
dependent on the protocol/cipher suite combination and is limited to the highest
payShield 9000 performance models.
If the RSA Booster Licence (HSM9-LIC033) is installed on a payShield 9000 which is

implementing Secure Host Communications, the full benefits of the RSA Booster licence
will not be achieved for signature generation with short key lengths or for signature
verification.
Users who want to assess the likely impact on performance when implementing Secure
Host Communications in their specific environment should contact Thales for guidance.
Security considerations
TLS and SSL can only provide a secure environment when implemented correctly. When
implementing TLS/SSL on the payShield 9000, the guidance in the latest version of PCI's
Data Security Standards (DSS) requirements should be followed.
Support for USB Memory Sticks

USB memory sticks are used to transfer material such as certificates in and out of the
payShield 9000. The Operating System used in the payShield 9000 supports most types

of USB memory stick, but may not have the drivers for some of the newer types. If
difficulties are experienced when trying to read from or write to a USB device, an
alternative memory stick should be used.
Configuring TLS/SSL on the payShield 9000

The following sections discuss the use of the following console commands and payShield
Manager actions to configure the payShield 9000 to use TLS or SSL. The payShield 9000
must have license LIC036 installed.
Operation Console
Command
Check Availability of TLS/SSL VR
Configure Ethernet host ports CH
Generate HRK SK
Change HRK Passphrase SP
Restore HRK SL
Generate/Export SSL Server SG
Certificate Signing Request
Export Server (HSM) CA SE
Import Signed Certificate SI
Viewing Certificates held on SV
the HSM
Delete Certificate SD
In the following example output, text in bold+underscore represents inputs made by

the user.
Checking availability of TLS/SSL

The VR console command will report on the availability of TLS/SSL on the payShield
9000. The start of the output will consist of the following information:
Row Dialogue
1 VR
2 Base release: 2.2a
3 Revision: 1346-0910
4 Build Number: 0018
5 HSM Core API Version: 7.0.18
6 Serial Number: A4665302078G
7 Unit info: Licenced
8 Host Configuration: Async,Ethernet,(optional) TLS/SSL
9 Licence Issue No: 5
10 Performance: 220 TPS
11 Base Software: Version 2
12 Ship Counter: 1
13 Crypto: 3DES,AES,RSA
14 LMKs Enabled: 10 LMKs

Row Dialogue
15 Press "Enter" to view additional information...
The following elements are relevant to configuring TLS/SSL:
 Row 8: the availability of TLS/SSL is indicated in the "Host Configuration"

information.
Configuring the Ethernet Ports

The CH (Configure Host) console command allows the Ethernet ports to be configured for
TLS/SSL. The following example shows a payShield 9000 being configured for a single
physical Ethernet port:
Row Dialogue
1 CH
2 Please make a selection. The current setting is in parentheses.
3 Message header length [1-255] (4):
4 Host interface [[A]sync, [E]thernet] (E):
5 Enter Well-Known-Port (1500):
6 Enter Well-Known-TLS-Port (2500):
7 UDP [Y/N] (Y):
8 TCP [Y/N] (Y):
9 TLS/SSL [Y/N] (Y):
10 TLS Enforced [Y/N] (N):
11 Number of connections [1-64] (5):
12 Enter TCP keep alive timeout [1-120 minutes] (120):
13 Number of interfaces [1/2] (1):
14 Interface Number [1/2] (1):
15 Interface Number 1:
16 Enter IP Address (193.240.100.216): 193.240.100.215
17 Enter subnet mask (255.255.255.0):
18 Enter Default Gateway Address (193.240.100.1):
20 Save HOST settings to smart card? [Y/N]: n
The following elements are relevant to configuring TLS/SSL:
 Row 6: a well-known port must be specified for TLS/SSL - the default is 2500.
This is analogous to the well-known port for unsecured host traffic (Row 5), and
can be used in the same way to identify the LMK required for the host command,
i.e.:
 2500 = default LMK
 2501 = LMK 0
 2502 = LMK 1
 etc.
 Row 7 and 8: enable or disable non-secured host traffic (TCP or UDP).
 Row 9: enable or disable secured host traffic.
 Row 10: forces TLS (rather than SSL) to be used to protect secure host traffic.

 Row 11: specifies the number of connections/threads for each port. If a value of 5
was entered and both Ethernet ports were enabled, a total of 10
connections/threads would be available. These connections/threads are shared
between secured and non-secured traffic.
The QH (Query Host) console command used to view the port settings has been modified
to display the new parameters.
Managing the HRK

A number of new console commands and equivalent payShield Manager functions have
been introduced to create and manage the new HRK.
When using the payShield Manager, refer to the payShield Manager User's Guide for
further instruction.
Generate HRK
The HRK is generated using the SK console command while the HSM is in Secure state:
Row Dialogue
1 SK
2 **** NOTE ****
3 Passphrase rules as follows:
4 1 - Must be between 8 and 30 characters long.
5 2 - Can contain spaces
6 3 - Must be comprised of (at a minumum):
7 2 digits
8 2 uppercase characters
9 2 lowercase characters
10 2 symbols (ex. !/?.#:')
11 Enter administrator 1 passphrase: ********************
12 Re-enter administrator 1 passphrase: ********************
13 Enter administrator 2 passphrase: **************
14 Re-enter administrator 2 passphrase: **************
15 Creating HRK. Please, wait ... DONE
16 HRK generated successfully
17 Key synchronisation complete
Notes:
 Rows 11-14: two different passphrases are required, each entered by a different
security officer. These passphrases must be stored securely (in the same way as
key components) to allow subsequent HRK recovery in the event that the HSM
enters a tampered state.
 Rows 3-10: the passphrases must be of an acceptable complexity. Spaces are
allowed.
Change HRK Passphrase

The HRK passphrase should be changed regularly as best security practise, and will need
to be changed if a security officer is replaced by another person. This is accomplished
using the SP console command while the HSM is in Secure state:

Row Dialogue
1 SP
2 **** NOTE ****
3 Passphrase rules as follows:
4 1 - Must be between 8 and 30 characters long.
5 2 - Can contain spaces
6 3 - Must be comprised of (at a minimum):
7 2 digits
8 2 uppercase characters
9 2 lowercase characters
10 2 symbols (ex. !/?.#:')

4 - Cannot use the same passphrase that was used within the past 10 previous
11 attempts
12 Select administrator password to change [1,2]: 1
13 Enter administrator 1 current passphrase: ********************
14 Enter administrator 1 new passphrase: ************
15 Re-enter administrator 1 new passphrase: ************
16 Changing passphrases. Please, wait ... DONE
17 HRK generated successfully
Notes:
 Rows 11-14: two different passphrases are required, each entered by a different
security officer. These passphrases must be stored securely (in the same way as
key components) to allow subsequent HRK recovery in the event that the HSM
enters a tampered state.
 Rows 3-10: the passphrases must be of an acceptable complexity. Spaces are
allowed.
 A Passphrase cannot be re-used until at least 10 generations of passphrase
changes have been made.
Restore HRK
If the HSM detects a tamper event, its private key used to establish TLS/SSL sessions is
deleted. An HRK-encrypted copy of the private key is held in non-volatile memory, and
the key itself can be recovered and restored to tamper-protected memory by entering
the passphrases used at HRK generation into the SL console command while the HSM is
in Secure state:
Row Dialogue
1 SL
2 Enter administrator 1 passphrase: ********************
3 Enter administrator 2 passphrase: **************
4 Recovering HRK. Please, wait ... DONE
5 HRK recovered successfully
6 Key synchronization complete

Managing Certificates
Console commands are available to manage the HSM, application, and CA certificates
required to establish TLS/SSL sessions.
When using the payShield Manager, refer to the payShield Manager User's Guide for
further instruction.
Generate and Export SSL Server Certificate Signing Request

This process generates the HSM key pair, stores the private key in tamper-protected
memory and (in HRK-encrypted form) in non-volatile memory, and creates a Certificate
Signing Request for the public key.
On the console, this is done by using the SG command while the HSM is in Secure state:
Row Dialogue
1 SG
2 Please enter the Subject Information for the Certificate Request:
3 Country Name (2 letter code) [US]: UK
4 State or Province Name (full name) []: Buckinghamshire
5 Locality Name (eg, city) []: Long Crendon
6 Organization Name (eg, company) []: Mega Banking Corporation.
7 Organizational Unit Name (eg, section) []: CorpSecurity
8 Common Name (e.g. server FQDN or YOUR name) []: HSM1
9 Email Address []: michael.mouse@megabank.com
10 Select key type:
11 1 - RSA
12 2 - ECDSA P-256
13 3 - ECDSA P-384
14 4 - ECDSA P-521
15 Type [4]: 1
16 Generating key pair
17 .................................................+++
18 ...+++
20 DONE
21 Do you wish to save to a file [Y/N]:y
22 Enter filename: HSM1
23 File exists - replace? [Y/N]:y
23 -----BEGIN CERTIFICATE REQUEST-----

MIIC9zCCAd8CAQAwgbExCzAJBgNVBAYTAlVLMRgwFgYDVQQIEw9CdWNraW5naGFt
.
.
25 .
.
ehNJSXN703d6vP2aktV3VRHkMvbrkjqT37dU3chCaqkOYOqEMhnCEMdVGw==
26 -----END CERTIFICATE REQUEST-----
Notes:
 Rows 10-15: the key type is selected. If RSA is used, the key will be of 2048-bit
length.

 Rows 11: The RSA is 2048-bit key length.

 Rows 11-14: the client certificate must use the same key type as is used in
the HSM's Certificate Signing Request.
 Rows 21-23: this allows the certificate signing request to be filed (e.g. on a USB
memory device).
 Rows 23-25: the certificate signing request is also displayed on the screen.
Export Server (HSM) CA

The CA certificate used by the HSM must be made available to the host applications. It
can be exported using the SE console command while the HSM is in Secure state:
Row Dialogue
1 SE
2 Do you wish to save to a file [Y/N]:y
3 Enter filename: CACertpS9000.crt
4 payShield Certificate
MIID+TCCAuGgAwIBAgIJAJyPxxP6oxAQMA0GCSqGSIb3DQEBBQUAMIGyM
.
5 .
.
X4FkYiQv2CJb7J/vAw==
6 -----END CERTIFICATE-----
Notes:
 Rows 2-3: the certificate can be saved to a file - e.g. on a USB memory device -
to allow it to be exported.
Import Signed Certificate

Following the certificate signing request, the signed certificate for the HSM's public key
will need to be imported. It will also be necessary to import:
 all signed certificates for applications

 Self-signed certificate for the root CA
 Where a chained CA hierarchy is being used, certificates for each intermediate CA
signed by the next CA up in the hierarchy.
On the console, this is done using the SI command while the HSM is in Secure state:
Row Dialogue
1 SI
2 Select File
3 1 - RsaServerRootCA.crt
4 2 - TCPUDPSIM.crt
5 3 - RsaClientRootCA.crt
6 4 - hsm1.crt
7 File: 1
8 Imported Trusted CA Certificate
9 Issued to: payShield Certificate, Issued by: payShield Certificate
10 Validity : May 9 10:59:22 2013 GMT to May 7 10:59:22 2023 GMT
11 Unique ID: 9C8FC713FAA31010 - AC03FAD5 (Root)

Row Dialogue
12 Do you wish to import another certificate? n
Notes:
 Rows 3-6 in this example identify files available on a USB memory device
attached to the HSM. The user identifies at Row 7 which of these is to be
imported.
 The user is informed if no certificates are found on the USB memory device.
Viewing certificates held on the HSM

The payShield 9000 will establish TLS/SSL sessions only with applications for which it has
stored a copy of their certificate. All stored certificates (including the payShield's own
certificate and CA certificates) can be viewed using the SV console command:
Row Dialogue
1 SV
2 HSM Private Key installed: Yes
3 HSM Certificate installed:
4 1 - Issued to: HSM-0002, Issued by: Bank XYZ
6 Unique ID: 2050 - AC03FAD5
7 Client certificate(s) installed:
8 2 - Issued to: Client Certificate, Issued by: Client Certificate
10 Unique ID: 2016 - D221289A
11 CA Certificate(s) installed:
14 Unique ID: C14FF9DE78FB441A - D221289A (Root)
15 4 - Issued to: payShield Certificate, Issued by: payShield Certificate
18 Chain of Trust validated:
19 payShield Certificate (Root)
20 Select an item to view: 1
21 Certificate:
22 Data:
23 Version: 3 (0x2)
24 Serial Number: 8273 (0x2051)
25 Signature Algorithm: sha1WithRSAEncryption

Issuer: C=UK, ST=Greater London, L=London, O=Bank XYZ, OU=RootCA,
26 CN=Bank XYZ/emailAddress=root@bankxyz.com
27 Validity
28 Not Before: May 21 15:05:51 2013 GMT
29 Not After : May 21 15:05:51 2014 GMT

Row Dialogue
Subject: C=UK, ST=Greater London, O=Bank XYZ, OU=Operations, CN=HSM-
30 0002/emailAddress=bill@bankxyz.com
31 Subject Public Key Info:
32 Public Key Algorithm: rsaEncryption
33 Public-Key: (2048 bit)
34 Modulus:
35 00:aa:31:e6:90:46:fe:e9:26:8b:93:39:5a:8c:be:
36 …
37 3d:39:2b:d7:06:47:04:6a:54:d2:12:4e:ac:9a:a3:
38 5b:49
39 Exponent: 65537 (0x10001)
40 X509v3 extensions:
41 X509v3 Basic Constraints:
42 CA:FALSE
43 X509v3 Key Usage:
44 Digital Signature, Non Repudiation, Key Encipherment
45 Signature Algorithm: sha1WithRSAEncryption
46 b8:e9:e9:8f:2e:f9:50:93:a1:8b:8d:0b:e5:fd:ef:6f:6c:05:
47 …
48 59:0d:df:85:b7:48:c6:02:d9:16:f9:80:e5:c9:c2:69:7f:06:
49 2b:ba:18:9f
50 Do you wish to view another certificate? N
Notes:
 Row 20: the number for the required certificate as offered in rows 4, 8, 12, and
15 should be entered.
Delete Certificate
Where it is no longer required to establish TLS/SSL connections with an application or
where a certificate has been withdrawn or updated, it will be necessary to delete the
certificate stored on the payShield 9000. This can be achieved using the SD console
command while the HSM is in Secure state:
Row Dialogue
1 SD
2 HSM Private Key installed: Yes
3 HSM Certificate installed:
4 1 - Issued to: HSM1, Issued by: payShield Certificate
6 Unique ID: 204D - AC03FAD5
7 Client certificate(s) installed:
10 Unique ID: 2016 - D221289A

Row Dialogue
11 CA Certificate(s) installed:
14 Unique ID: C14FF9DE78FB441A - D221289A (Root)
15 4 - Issued to: payShield Certificate, Issued by: payShield Certificate
18 Chain of Trust validated:
20 payShield Certificate (Root)
21 5 - HSM Private Key
22 Select an item to delete (6 for ALL): 6
23 Do you wish to delete another certificate? n
Auditing attempted use of out-of-date certificates.

Users can choose to record in the payShield 9000's Audit Log any attempts made to
establish a Secure Host Communications session using an out-of-date certificate. This
option is enabled/disabled using the AUDITOPTIONS console command:
Row Dialogue
1 AUDITOPTIONS
2 Audit User Actions: NO
3 Audit Error Responses to Host Commands: NO
4 Audit utilization data resets: NO
5 Audit diagnostic self tests: NO
6 Audit ACL connection failures: YES
7 Audit out-of-date Certificates for Secure Host Sessions: NO
Audit Counter Value:
8 0000005A
9 List of Audited Console Commands:
10 List of Audited Host Commands:
11 Audit User Actions? [Y/N]: n
12 Audit Error Responses to Host Commands? [Y/N]: n
13 Audit Utilization Data Resets? [Y/N]: n
14 Audit Automatic Self Testing? [Y/N]: n
15 Audit ACL connection failures? [Y/N]: n
16 Audit out-of-date Certificates for Secure Host sessions? [Y/N]: y
17 Current Audit Counter value is: 0000005A
18 Enter new value or <Return> for no change:
20 Modify Audited Command List? [Y/N]: n
21 Audit User Actions: NO
22 Audit Error Responses to Host Commands: NO
23 Audit utilization data resets: NO
24 Audit diagnostic self tests: NO

Row Dialogue
25 Audit ACL connection failures: NO
26 Audit out-of-date Certificates for Secure Host Sessions: YES
Audit Counter Value:
27 0000005A
28 List of Audited Console Commands:
29 List of Audited Host Commands:
30 Save Audit Settings to Smartcard? [Y/N]: n
The resulting Audit Log entries will be of the following formats:

0000002F 10:25:22 02/Jul/2016 Certificate has expired.
Unique ID: A8F66A587213303F - 2BA3B089
00000027 22:24:33 02/Jul/2014 Certificate not yet valid.
Unique ID: A8F66A587213303F - 2BA3B089
Certificate Examples
Intermediate CA Certificate
Intermediate CA Certificate:
Data:
Version: 3 (0x2)
Serial Number: 762114 (0xba102)
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, ST=Florida, L=Plantation,
CN=RsaClientRootCA.thalesesec.com
Validity
Not Before: Jul 10 18:55:49 2013 GMT
Not After : Jul 10 18:55:49 2014 GMT
Subject: C=US, ST=Florida, CN=RsaClientIntCA1.thalesesec.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:b0:2d:f9:ce:ba:b1:40:f5:c2:43:1d:3f:bd:a1:
2e:e6:5b:73:f3:0c:ed:ce:de:71:80:2a:dc:ca:3a:
0e:b7:8a:82:56:86:80:1c:65:b2:47:6f:0d:77:d7:
78:db:d3:51:e4:32:50:5e:cf:ae:05:7b:a4:5f:c2:
d2:90:d5:70:63:b4:6a:56:a4:c5:4c:2e:1d:47:f0:
59:b6:10:f4:c9:46:1e:9c:db:43:43:80:76:aa:40:
78:fe:23:73:ab:c1:1e:15:8b:7a:e1:66:b5:57:3b:
bf:d0:3a:e6:7d:ed:32:c2:21:fc:57:7b:b1:62:51:
bc:d7:38:8f:4e:df:76:cc:5a:c3:5a:ca:75:2c:86:
e6:fc:82:b6:5e:fd:c8:14:ca:f2:c6:9b:c8:33:58:
9b:fd:90:ea:ec:b6:77:0e:fe:12:35:be:89:b3:68:
6e:69:46:5c:03:8c:41:5f:c3:d3:99:58:d5:35:7a:
88:41:ce:50:7e:5a:a2:ff:28:36:73:86:61:94:23:
24:69:86:5c:73:31:60:ee:b8:ad:d4:fe:3c:b8:65:
50:35:49:6d:08:9a:2b:d4:26:b6:97:1c:ba:d1:c2:
c3:fe:4b:bf:4b:27:be:d6:57:d7:97:37:10:23:f1:
4d:33:5b:41:d7:8e:55:bf:9a:76:05:50:5d:8f:f0:
ef:43
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:TRUE
X509v3 Subject Key Identifier:
DE:C0:02:1B:48:37:6B:C3:34:F5:9E:D0:8A:32:12:5E:ED:1C:50:2C
X509v3 Authority Key Identifier:
keyid:08:20:EB:E6:51:CF:7F:08:D3:9D:33:A4:DC:48:AE:2E:5D:6C:

F3:EC

4b:07:e2:e2:90:60:0a:dc:29:56:bb:65:8b:9a:62:3c:a0:70:
22:0c:8c:fe:2f:7b:9f:46:9a:ac:fb:6b:f7:e4:4a:d5:54:b4:
c9:46:97:e3:82:d7:66:ed:5d:e6:24:e8:8c:b8:8b:86:0c:82:
bf:00:e3:6c:73:bc:27:0b:aa:02:07:f9:10:1d:9a:fc:2e:7e:
34:6d:74:6a:90:73:14:8a:ba:81:77:74:66:01:e5:da:4d:54:
ed:18:c5:f7:7d:e4:62:24:ec:f6:80:86:b3:56:43:ec:d5:48:
90:fd:a4:28:e5:89:7f:60:a9:a9:a7:67:3c:cd:f1:22:7b:0e:
dd:16:a8:09:a8:6e:0e:97:a8:26:cc:94:fb:95:a2:1f:8e:83:
ee:6c:6d:f7:f4:ec:fe:2b:bd:bf:ce:a8:5f:f2:6f:92:89:80:
f0:41:83:89:56:3e:9a:47:e0:24:28:6a:fd:69:05:a7:6a:fd:
66:4e:2d:35:69:54:4c:00:8b:52:3c:26:f1:8a:35:82:e3:d4:
b8:f8:09:e6:0e:6f:3b:3a:c6:9c:f5:23:c6:5e:9c:00:fa:90:
21:aa:4c:fa:fd:84:bf:87:55:b9:a1:0e:d8:82:92:07:79:08:
9b:49:fd:89:3d:c1:f4:61:ba:c0:9a:ac:e3:d5:75:ec:3a:51:
c5:70:59:23
Client Certificate
Client Certificate:
Data:
Version: 3 (0x2)
Serial Number: 762369 (0xba201)
Issuer: C=US, ST=Florida, L=Plantation,
CN=RsaClientRootCA.thalesesec.com
Validity
Not Before: Jul 16 21:34:50 2013 GMT
Not After : Jul 16 21:34:50 2014 GMT
Subject: C=US, ST=Florida, CN=RSAClient.thalesesec.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:f6:26:4d:61:3d:62:22:62:44:59:57:f0:60:a4:
a0:63:c0:2a:24:a3:45:d5:2c:c2:1b:2c:70:f7:2d:
29:da:48:af:cd:17:b2:5b:05:08:dd:b6:27:5e:d6:
f7:e6:a7:56:df:d5:e6:07:e6:dd:4f:2a:68:58:60:
4d:e2:08:8d:ee:04:e0:d2:29:35:36:0c:8b:38:88:
f3:ea:9a:2e:35:f6:3d:b9:73:99:53:f1:0f:76:10:
74:10:19:9d:02:71:49:0b:0c:29:e4:af:91:f5:ac:
73:0c:d2:e0:7c:d8:b1:d3:0b:72:94:6b:6b:9b:f1:
c1:6e:22:5e:ee:77:d0:40:3c:cd:2a:cc:82:83:a6:
af:c3:b6:d9:b5:9b:85:c3:b3:00:64:f1:50:5a:f1:
88:c0:3b:f2:c7:d0:c2:d2:76:bf:9f:5c:7a:f4:a4:
7c:8e:c7:ab:a0:2b:dc:69:c3:95:51:f4:73:ad:ac:
a3:32:85:a1:15:79:d6:d0:e1:be:a7:00:33:60:1c:
21:90:7c:2b:9e:e1:09:13:fa:de:fd:31:90:db:6d:
89:f8:f4:e7:a4:b0:0b:c4:d5:e4:f3:67:20:e1:17:
4a:65:3a:f0:08:57:4b:85:a2:3c:1f:17:cd:a3:3a:
01:3c:e0:d2:39:27:de:38:53:3e:e7:43:09:58:21:
95:f7
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Key Usage:
Digital Signature, Key Agreement
X509v3 Authority Key Identifier:
keyid:08:20:EB:E6:51:CF:7F:08:D3:9D:33:A4:DC:48:AE:2E:5D:
6C:F3:EC

78:e5:d2:5f:cd:03:8e:65:e3:40:7d:9c:25:15:41:ed:da:67:
7d:d4:86:cb:7c:84:75:e4:3a:36:a0:ec:a1:28:ba:7d:37:ba:
b3:2f:48:f4:0e:24:56:e1:df:0e:f9:cf:8c:7f:b7:bc:57:99:

6c:de:c9:30:3b:47:12:d0:be:c9:f9:d4:c3:87:c0:e6:36:b4:
7a:e1:fa:8e:51:32:fb:6a:fd:08:87:93:ab:3b:67:42:a7:1d:
a8:46:07:04:4a:5a:ad:a6:b6:60:89:7a:50:e1:8d:48:97:af:
8b:e1:98:8b:f2:3a:26:a6:cf:c6:a7:18:36:ff:9c:05:95:3a:
b2:a3:88:61:02:d8:31:df:bc:97:77:9c:e7:ce:33:65:20:f0:
27:0c:2e:db:b5:d2:ab:82:3d:c3:d4:c5:2b:29:82:b4:21:d1:
48:ed:eb:ff:56:14:34:c9:62:99:cd:7b:73:c9:93:01:3d:d2:
a8:37:5f:0d:4a:2f:56:1d:d0:57:95:f8:7c:aa:f7:5e:bb:09:
1e:7c:74:81:be:b4:1e:03:a3:e5:1a:bc:ba:7a:04:02:57:b5:
00:1f:f8:32:29:74:1b:5d:f1:96:b8:f9:3e:f3:02:bb:dc:de:
4e:35:43:cd:4e:80:a3:60:69:a2:47:97:7a:2e:e4:0f:f3:d3:
b1:22:76:40
OpenSSL Configuration File

Where OpenSSL is being used to provide TLS/SSL support on the host system, the
configuration file must contain the following:
[ v3_client ]
basicConstraints = CA:FALSE
#extendedKeyUsage = clientAuth
keyUsage = keyAgreement, digitalSignature
authorityKeyIdentifier = keyid,issuer
[ v3_server ]
basicConstraints = CA:FALSE
extendedKeyUsage = serverAuth
keyUsage = keyAgreement, keyEncipherment,
digitalSignature, nonRepudiation
[ v3_ca ]
basicConstraints = CA:true
subjectKeyIdentifier = hash
Notices
This product includes software developed by the OpenSSL Project for use in the OpenSSL
Toolkit. (http://www.openssl.org/)
This product includes cryptographic software written by Eric Young (eay@cryptsoft.com)
Access Control Lists (ACLs)

Another host communications security feature, although not directly associated with the
Secure Host Communications facility, is the ability to set up whitelists of acceptable host
IP addresses using Access Control Lists (ACLs). See the payShield 9000 Console
Reference Manual and the payShield Manager User Guide for information on setting up
ACLs.

Chapter 15 – Performance
General
The payShield 9000 is available in a number of performance models. These models are
identified by an alphabetic character (e.g. Model M, H, or X) but are normally referred to
by their rated performance in terms of transactions per second (tps) – for example, the
Model M is referred to as the "220 tps model", the Model H as the "800 tps model", and
the Model X as the "1500 tps model".
The tps rating refers specifically to the maximum rate that the payShield 9000 can
process CA host commands (i.e. Triple-DES PIN Block translations). Many other host
commands run at the same rate, but some, which are particularly computation-intensive,
will run at lower rates and a few run at higher rates.
The rated throughput is achieved when:
 The host interface is using TCP/IP running on a 1 Gbps Ethernet with no other
traffic.
 Enough connections/threads are being used to achieve the maximum throughput.
(The number of threads required depends on the host command and payShield
9000 performance model being used, but the use of 8 threads or more can
generally be assumed to provide maximum throughput.)
 Command/response processing at the host does not introduce any delays.
 No other commands are being sent to the HSM.
 No options which may impact performance are being used on the HSM (e.g.
Secure Host Communications, auditing of host commands).
payShield 9000 models (except the 1500 tps model) can be uprated after purchase to a
higher performance model.
This chapter gives information on the factors that can affect the performance of the
payShield 9000.
The RSA Booster License (HSM9-LIC033)

This boosts the RSA performance of any payShield 9000 performance model to a level
significantly higher than that of the payShield 9000 Model X (which is rated at 1,500 CA
commands per second). This license offers performance benefits to users of all models of
payShield 9000.
An additional benefit of the RSA Booster License is that it also enhances the performance
of a number of host commands related to processing digests (such as MACs).
Notes:
 the RSA Booster License increases the performance of RSA (or digest)
operations rather than the whole host command. Where a host command
performs multiple operations, the performance of only the RSA (or digest)
operations is boosted.
 HSM9-LIC002 must be installed on the payShield 9000 to enable RSA operations.
The RSA Booster License will enhance the performance of the following base software
host commands:

ID Description
EI Generate RSA key pair
ES Validate a Cert and Import the Public Key
EW Generate an RSA Signature
EY Validate an RSA Signature
GI Import Key under an RSA Public Key
GK Export Key under an RSA Public Key
GM Hash a Block of Data
H2 Calculate RSA Public Key Verification Code
H4 Generate KEKs for Node-Node interchange with RSA
H6 Receive KEKr for Node-Node interchange with RSA
H8 Encrypt Cross Acquirer KEK under Initial Transport Key
I0 Encrypt Terminal Key under the LMK
I2 Import MULTOS Transport Key Certifying Key
I4 Import MULTOS Hash Modulus Key
I6 Translate MULTOS KTU
I8 MULTOS ALU Generator
J0 Generate Issuer RSA Key Set (MC/Europay)
JO Validate CA Self-Signed Cert (MC/Europay)
JS ARQC Ver'n &/or ARPC Gen (CUP)
JU Generate Secure Message (CUP)
K0 Decrypt Encrypted Counters (EMV 4.x)
K2 Verify Trunc App Cryptogram (M/c CAP)
KE Generate Issuer RSA Key set and Public Key Certificate
KG Validate Issuer Public Key Certificate
KI Derive Card Unique DES Keys
KK Validate a Certification Authority Self-Signed Certificate
KM Generate Static Data Authentication Signature

ID Description
KO Generate Card RSA Key Set and Public Key Certificate
KQ ARQC Verification and/or ARPC Generation (EMV 3.1.1)
KS Data Authentication Code and Dynamic Number Verification (EMV 3.1.1)
KU Generate Secure Message (EMV 3.1.1)
KW ARQC Ver'n &/or ARPC Gen (EMV 4.x)
KY Generate Secure Message (EMV 4.x)
NY Generate IVCVC3 and static CVC3
PM Verify a Dynamic CVV (dCVV)
R8 Import Transport Key Set
T0 Unlinked Load Transaction Request
T6 Verify RCEP
U2 Compute HCEP
V8 Validate the H2LSAM
XK Verify ISO PIN Block from Internet, return New Encrypted PIN, verify MAC X9.19
XM Verify ISO PIN Block from Internet, verify MAC X9.19
XO Verify MAC using ANSI X9.19
XQ Generate MAC using ANSI X9.19
XS Translate ISO PIN Block from Internet, verify/generate MAC
ZM Translate Encrypted PIN to Encrypted Alphanumeric PIN
ZU Verify PIN Block from Internet, return new encrypted PIN & verify MAC ANSI X9.19
Custom host commands which involve standard RSA (or digest) operations will also enjoy
a performance boost if the RSA Booster License is installed.
This section provides guidance on the performance levels that can be expected for some
of the most important host commands using RSA when using the RSA Booster License.
Variability of RSA Performance

The performance of RSA-based commands is heavily dependent on the length of RSA
keys used, and this is reflected in the information given in this section.
For key generation, the time to generate RSA keys is not deterministic - that is, the time
to generate keys of a given length will vary such that it is not possible to predict
accurately how long the key generation will actually take.

For other RSA functions (e.g. signature generation and verification), the performance is
dependent on the actual key used. Thus the time taken to generate signatures (for
example) using the same length of key will vary.
Therefore performance observed by users may be different from the typical values
quoted in this section.
Factors affecting achieved performance

As described later in this section, there are a number of factors that will affect the actual
performance achieved on a payShield 9000 unit. The following notes indicate where
these factors have a particular relevance to the RSA Booster License.
Secure Host Communications

Using Secure Host Communications can have a noticeable negative impact on the
performance of RSA operations on a payShield 9000 with the RSA Booster License.
Connections/Threads
Multiple connections (or threads) must be used to achieve maximum throughput on the
payShield 9000. This is particularly important for RSA commands (with or without the
RSA Booster License) that run at a high rate (e.g. signature generation with small key
lengths, or signature verification). In general, maximum performance is achieved with
the use of 8 or more connections/threads.
Auditing
The auditing of frequently used host commands can have a significant effect on
performance. This is unlikely to noticeably affect RSA key generation, but could have a
negative impact on signature generation and verification - especially with short key
lengths.
LMK type
For users of the RSA Booster License, little difference in benefits will be observed
between variant and key block LMKs when:
 generating keys, or
 generating signatures with key lengths of 1024 bits or more.
For:
 signature generation with lower key lengths or
 signature verification,
then greater benefits are achieved by using the RSA Booster License for variant LMKs
than for key block LMKs.
Utilization data
The collection of utilization data has little impact on the performance benefits of the RSA
Booster License for:
 key generation, or
 signature generation with key lengths of 1024 bits or more.
The RSA Booster License continues to provide performance benefits in the following cases
when utilization data is being collected, but the benefit is not as great:

 signature generation with key lengths below 1024 bits.
 signature verification.
Benefits provided by RSA Booster the License

The following charts show the benefit in RSA performance that can be expected by
adding the RSA Booster License to a payShield 9000. The charts cover the 3 main RSA
functions (key generation, signature generation, signature verification) for a range of key
lengths.
The x-axis shows the rated performance of the payShield 9000 model in terms of CA host
command transactions per second (e.g. a Model X unit is rated at 1,500 CA tps).
The y-axis shows the performance (in terms of the transactions per second for the RSA
operation) for the unboosted payShield 9000 and for the payShield 9000 with the RSA
Booster License.
The measurements below used a payShield 9000 with the following configuration:
 TCP/IP host interface.
 Dedicated 1Gbps network

 Secure Host Communications not used.
 Variant LMK.
 No other commands being run on the payShield 9000.
 Utilization data gathering turned off.
 No auditing of host commands.
 Sufficient connections/threads to achieve maximum throughput.
 No account taken of command processing time at the host itself.
 Version 2.2a software.
Legend:
Without RSA Booster License

With RSA Booster License

RSA Key Generation (EI host command)
TPS 90
80
70
60 Key length = 512 bits

50
40
30
20
10
0
0 300 600 900 1200 1500
payShield 9000 TPS Rating (for CA command)
TPS 18
16
14

10
0
0 300 600 900 1200 1500

TPS 5
4.5
4
3.5
Key length = 1536 bits
3
2.5
2
1.5
1
0.5
0
0 300 600 900 1200 1500
TPS 1.8
1.6
1.4
1.2 Key length = 2048 bits

1
0.8
0.6
0.4
0.2
0
0 300 600 900 1200 1500

Signature Generation (EW host command)
TPS 2500
2000

1500
1000
500
0
0 300 600 900 1200 1500
TPS 500
450
400
350
300
250
200
150
100
50
0
0 300 600 900 1200 1500

TPS 180
160
140

100
80
60
40
20
0
0 300 600 900 1200 1500
TPS 80
70
60
50
40
30
20
10
0
0 300 600 900 1200 1500

Signature Verification (EY host command)
TPS 3000
2500
1500
1000
500
0
0 300 600 900 1200 1500
TPS 3000
2500
1500
1000
500
0
0 300 600 900 1200 1500

TPS 2500
2000

1500
1000
500
0
0 300 600 900 1200 1500
TPS 1400
1200
1000
800
600
400
200
0
0 300 600 900 1200 1500

The Host Interface

Asynchronous Communications
The use of Asynchronous host communications will significantly limit throughput. The bit
rate of even the fastest asynchronous link supported on the payShield 9000 is only about
0.01% of the speed of Gigabit Ethernet, and so the time taken for commands and
responses to be transmitted becomes the limiting factor for throughput.
Furthermore, asynchronous communications do not support anything equivalent to
multiple threads/connections, which is required to achieve maximum throughput.
FICON
To achieve maximum throughput using FICON host communications it is necessary to
use multiple connections, in a similar way to TCP/IP. In some cases, FICON may not
provide as high a throughput as TCP/IP.
Host Command Type

As stated previously, the rated performance of a payShield 9000 is based on its ability to
process the CA host command. Most commands will run at the same rate as the CA
command, but some will run at a lower rate. The most noteworthy cases are:
 RSA key generation (EI host command).

 Other RSA operations with longer key lengths. (The same RSA operations with
shorter key lengths will run faster than CA on some performance models of
payShield 9000.)
 Message encryption/decryption commands (e.g. M0, M2) with larger data block
sizes.

The use of the Secure Host Communications facility (optional license HSM9-LIC036 – to
protect the host-HSM link using TLS or SSL) will not have an impact on performance in
most situations. Any performance impact depends on a wide range of factors including
the TLS or SSL version in use and the cipher suite negotiated between HSM and host; the
most likely usages that can result in a noticeable performance impact when using Secure
Host Communications are:
 Encrypting/decrypting very large message blocks (e.g. by using the M0 or M2 host

command) on the 1500 tps model
 Using RSA commands with the RSA Booster License (HSM9-LIC033).
Auditing of Host Commands

The auditing of console/management commands, user actions, low-rate commands such
as RSA key generation (EI host command), or host commands which are used
infrequently will have no noticeable effect on performance.
When an event is audited, an entry has to be written to the audit log file. Where this
happens at a high rate, it will impact on throughput of the HSM. For example, an acquirer
who has decided to audit the CA host command on a heavily-loaded 1500 tps model will
experience a noticeable drop in throughput.

For maximum throughput, users should therefore not audit host commands which are
being run at a high rate. If the goal of auditing host commands is to track errors, it is
more efficient to use the option to audit error responses.
Utilization Data Collection

If the collection of utilization data is turned on (e.g. by the UTILENABLE console
command), users will generally not notice any effect on performance. However, where an
option is being used that may have an effect on performance (e.g. Secure Host
Communications or auditing of host commands), then the collection of utilization data
may emphasise the effect.
Type of LMK
The performance delivered by the payShield 9000 is generally the same irrespective of
whether Variant or Key Block LMKs are being used. However, where an option is being
used that may have an effect on performance (e.g. Secure Host Communications or
auditing of host commands), then the use of Key Block LMKs may emphasise the effect.

Chapter 16 – User Storage


Chapter 17 – The Audit Log

Introduction
The payShield 9000 provides an audit logging capability, enabling security officers to
select a number of activities and functions whose usage is recorded in an Audit Log.
Certain items are always recorded in the Audit Log, and this cannot be disabled.
The purpose of the Audit Log is to enable security officers to make regular checks on
security-related actions that the payShield 9000 is being asked to perform, and to assist
in forensic examination of any suspected security breaches.
The Audit Log also provides facilities for its entries to be viewed, printed, and archived to
a host computer.
This chapter describes the capabilities and usage of the payShield 9000 Audit Log.
Overview
The Audit Log is held securely in non-volatile memory in the payShield 9000: it survives
power cycling, payShield 9000 restarts, tamper attempts, and software upgrades.
It always records certain events and use of functions. In addition, security officers can
elect to log other events and functions.
The Audit Log can be viewed, printed, erased, and retrieved or archived to a host
computer. It can record 50,000 items. When the audit log is filled, the earliest entry is
deleted to allow the most recent entry to be added. It is therefore important that entries
are archived to a host computer frequently enough such that the Audit Log does not get
filled. The frequency with which this needs to be performed will depend on how many
items are being recorded.
A message authentication code (MAC) is associated with each individual audit entry,
enabling easy detection of any fraudulent attempt to modify the audit record.
Correct Use of the Audit Log

The Audit Log has been designed to capture information which will be examined when
investigating any potential security issues: it is not intended for use as a general log of
what the HSM is being used for, for example by logging all host commands (which can
impact on performance). Audit Log entries should be reviewed at regular and frequent
intervals to allow:
 any necessary actions to be taken,
 any records that need to be retained for future reference to be printed or archived
to the host system,
 the Audit Log to be cleared. It is important that the Audit Log is kept as small as
possible to optimise performance. It is particularly important that the Audit Log is
not allowed to reach its maximum size.
Logging high-frequency events which correspond to normal usage of the HSM and which
have no significance in terms of security introduces a number of problems:
 Creating too many records to allow significant records to be found and
interpreted.

 Causing loss of audit records if the audit log capacity is exhausted before the
audit records have been archived.
 Negatively impacting on performance, because of the additional processing
required to create and record audit records, especially when the audit log capacity
is exhausted and the log needs to be "rotated" (i.e. the oldest record deleted to
allow the new record to be added).
Later sections describe how the options for recording events to the audit log can be
configured. It is recommended that as few host commands as possible are audited: error
responses to host commands may well be indicative of a security threat, and the audit
options allow such responses to be logged without having to audit normally executing
host commands.
Forcibly recorded items

A number of items are always recorded in the Audit Log: this cannot be disabled.
PCI HSM Compliance

Most of these forcible recorded items were introduced to meet requirements of PCI HSM
certification. These items are:
 Use of smartcards to authenticate users to the payShield 9000 or payShield

Manager. The serial number of the smartcard is recorded as part of the Audit Log
record.
 Use of the A and C console commands to initiate and cancel authorization of

activities. The Audit Log entry shows for how long the activity was authorized.
 Use of the following console commands or the equivalent payShield Manager

actions. The Audit Log records made in this way will indicate the successful
completion of the command:
Console Command
Current commands
CV Generate a Card Verification Value
FK Form Key from Components
IK Import a Key
LK Load LMK
LO Load 'Old' LMK into Key Change Storage
LN Load 'New' LMK into Key Change Storage
PV Generate a Visa PIN Verification Value
RL Load RMK
Legacy Commands
BK Form a Key from Components
D Form a ZMK from Encrypted Components
DE Form a ZMK from Clear Components
IV Import a CVK or PVK
Recording Deletion of Audit Log

The Audit Log will include a record to indicate that the Audit Log has been erased.

Discretionary Audit Log entries

It is possible to request that any of the following events are recorded in the Audit Log:
 Use of combination of any console commands or payShield Manager actions. The
Audit Log records made in this way will indicate the initiation of the command
rather than its successful completion. This is different to the way that a forcibly
audited command would be recorded, where the successful completion of the
command/action is recorded – see the preceding section.
 Auditing activity on host ports:
 Use of any desired selection of host commands. As discussed in an earlier

section, this facility should be used carefully to avoid logging of high
volumes of host commands which are executing normally: it is generally
better to log just error responses (see next item), as these may well be
indicative of a security issue.
 Receipt of an error response to a host command (payShield 9000 software

v2.0b or later).
 Failures to establish host connections arising from the Access Control List
(ACL).
 Attempts to use out-of-date certificates when trying to establish Secure
Host Communication sessions.
 User actions:
 Clearing of Audit Log
 Loading an LMK or an Old/New LMK

 Erasing an LMK or an Old/New LMK
 Loading a license file - successful
 Loading a license file - failed
 Change of state
 Power cycle.
 Resetting of Utilization Data.
 Results of automatic daily self-tests – indicating whether the tests were successful
or identifying any specific tests that failed.
Protection of the Audit Log

The payShield 9000 provides a number of features specifically aimed at protecting the
Audit Log:
 Each Audit Log record is MACed using a unique MACing key protected by the LMK.
A host command is available to allow the MAC to be verified at a later time.
 Audit log entries can be archived by printing to a printer attached to the payShield
9000.
 Audit Log entries can be retrieved to the host system for secure electronic
archiving.

 Console actions to configure or delete the Audit Log require Authorisation using
the Management LMK. Equivalent actions on payShield Manager require Security
Officers to be logged on.
 Host Commands to delete Audit Log records must be authorised.
 Deletion of the Audit Log always results in a record of this event being added into
the otherwise now blank Audit Log.
Configuring the Audit Log
The AUDITOPTIONS console command

When a console (i.e. dumb character terminal) is used to manage the payShield 9000,
the AUDITOPTIONS console command is used to configure the auditing options – see the
payShield 9000 Console Reference Manual for full details and examples.
payShield Manager Auditing screen

The payShield Manager Audit Settings screen on the Configuration page performs the
same functions as the AUDITOPTIONS console command.
The General tab controls which of the following events are currently audited:
 User Actions
 Error Responses to Host Commands
 Utilization Data Resets
 Diagnostic Self Tests
 ACL Connection Failures
 Out-of-date Certificates for Secure Host Sessions
The Console Cmds tab controls which console commands are currently audited.
The Host Cmds tab controls which host commands are currently audited.
The Manager tab controls which payShield Manager actions are currently audited.

Viewing the Audit Log

The AUDITLOG console command
The AUDITLOG command allows the audit log to be viewed on the console. The most
recent entries are displayed first. Note that even at the maximum supported line speed
of 115.2 Kbps, a full audit log with 50,000 entries will take 10-20 minutes to display.
Here is an example of output from AUDITLOG:

Offline> AUDITLOG <Return>
Audit Log (10 entries)
Counter Time Date Command/Event
--------------------------------------------------------------
0000010B 13:55:00 02/Jul/2013 Diagnostic self test failure: Power
0000010A 16:45:07 01/Jul/2013 Authorised activity admin..host was
cancelled for LMK id 0
00000109 16:45:05 01/Jul/2013 Authorised activity admin..console:123 was
cancelled
00000108 15:54:02 01/Jul/2013 Key I/O command BK executed
00000107 15:35:55 01/Jul/2013 Activity component..console:123 was
authorised for LMK id 0
00000106 15:08:48 01/Jul/2013 Smartcard activated: 20025151
00000105 15:08:48 01/Jul/2013 Smartcard activated: 20025132
00000104 10:42:32 01/Jul/2013 Host command CA, response 00
00000103 10:36:03 01/Jul/2013 Host command CA, response 69
00000102 10:34:57 01/Jul/2013 System restarted
00000101 10:32:48 01/Jul/2013 Keylock turned to Online
00000100 10:32:21 01/Jul/2013 Console command CH
000000FF 09:01:56 01/Jul/2013 Diagnostic self tests passed.
Offline>
This example provides the following information:
 The unit's automatic self tests ran successfully on the 1st of July at 09:01:56
(Counter = 000000FF), but on the 2nd of July at 13:55:00 they failed because of a
power supply unit failure (Counter = 0000010B).
 On the 1st July at 10:32:21 the CH command was run at the console (Counter =
00000100). This is a discretionary audit log entry.
 On the 1st July at 15:54:02 the BK console command was successfully executed
(Counter = 00000108). This is a forcibly recorded item.
 On the 1st July at 10:32:48 the user turned the metal key(s) to put the payShield
9000 into Online state (Counter = 00000101).
 On the 1st July at 10:34:57 the system restarted – e.g. because the power was
cycled or the user pressed the Reset button on the front panel (Counter =
00000102).
 On the 1st July at 10:36:03 (Counter = 00000103) the CA host command was run
but received a response of 69 (PIN Block format has been disabled). However, at
10:42:32 (Counter = 00000104) the CA command was run successfully (response
= 00).
 On the 1st July at 15:08:48 the smartcards with serial numbers 20025132 and
20025151 were used to authenticate security officers to the payShield 9000.
Subsequently the following authorization activities were performed under the
oversight of the "owners" of these smartcards:

 at 15:35:55 all component console commands were authorized for LMK 0

for a duration of 2 hours and 3 minutes (123 minutes) (Counter =
00000107)
 at 16:45:05 the authorization of admin console commands for LMK 0,
originally authorized for 123 minutes, was cancelled (Counter = 00000109)
 at 16:45:07 the authorization for all admin host commands for LMK 0 was
cancelled (Counter = 0000010A).
The payShield Manager Audit Log Screen

When using payShield Manager, the Audit Log screen on the Status page displays the
current contents of the audit log:
The Download button allows the Audit Log to be saved as a file, which can then be
printed if required.
Printing the Audit Log
The AUDITPRINT console command

The AUDITPRINT command prints the audit log to a printer attached to the payShield
9000. The command can be used to print all Audit Log records or just those that have
not been archived: a flag is set against each printed record to indicate that it has been
archived in this way.
The output has the following format:

The identification of the audited item is shown in the "Command" Column. This
information is fully described at Appendix B of the payShield 9000 Host Command
Reference Manual, but a summary is provided here:
 For host commands, the entry has the format shown in the above example. "H"
identifies the entry as a Host Command, "M2" represents the host command that
was used, and "06" was the response code.
 For a Console command, the entry is of the format "C XX 00". "C" identifies the
event as a Console command. "XX" identifies the Console Command: in the case
of a 2-charcater Console Command this is the actual command code, whereas for
other console commands a 2 hexadecimal code (defined in the payShield 9000
Host Command Reference Manual) is used. "00" is always reported in the
response code field.
 For a Fraud Detection event, the entry has the format "F XX 99", where "F"
identifies that this is for a Fraud Detection event, "XX" represents the command
code that caused the event to arise, and the response code field identifies which
Fraud Detection threshold was exceeded. (See Chapter 7 for more information
about the Fraud Detection facility on the payShield 9000.)
 For user actions, the entry has the format "A XX 00". "A" identifies this as a user
action, "XX" represents the identity of the User Action (defined in the payShield
9000 Host Command Reference Manual), and the response code is always set to
"00".
Each record is MACed with a unique, random MACing key, to allow the integrity of the
record to be confirmed.
The Q4 Host Command

The Q4 host command is used to archive Audit Log records to a printer attached to the
payShield 9000: a flag is set against the record to indicate that it has been archived in
this way.
There are options to print/archive the next non-archived record, to print/archive all non-
archived records, or to print/archive all records.
See the payShield 9000 Host Command Reference Manual for a full description of the Q4
command.


As described above, the payShield Manager Audit Log screen on the Status page displays
the current contents of the audit log. The Download button allows the Audit Log to be
saved as a file, which can then be printed if required.
Retrieving Audit Log entries to the host system

The Q2 Host Command
The Q2 host command is used to copy individual Audit Log entries to the host computer
system. The command retrieves the next record that has not previously been retrieved
by the host.
See the payShield 9000 Host Command Reference Manual for a full description of the Q4
command.
The format of the record is fully described at Appendix B of the payShield 9000 Host
Command Reference Manual. It is very similar to that described previously for the
printed record, except that:
 2-digit numeric codes are used in place of the single alphabetic character
identifying the event type;
 the record includes the Archived and Retrieved status flags.
Centralized Logging
Thales Advanced Solutions Group (ASG) can provide Java tools and services to allow the
Audit Log records from an estate of payShield 9000s to be retrieved to a centralized
system. A Java API can be used by Java developers for integration into business
applications. Audit Log records can be assembled into single files that can be monitored
by SIEM agents, or can be sent to central log servers, syslog, etc.
Deleting records from the Audit Log

It is important that records are deleted from the Audit Log before a significant volume of
entries builds up. If the size of the audit log grows to multiple thousands of entries, the
following will result:
 Performance of executing host commands will begin to drop.

 If the Audit Log reaches its maximum size of 50,000 records there will be a major
drop in performance because of the processing required to "rotate" the Audit Log
such that the oldest record is deleted to allow the newest record to be added.
 The rotation of the Audit Log when it has reached its maximum size results in the
oldest records being lost.
The payShield 9000 user should implement processes to investigate new Audit Log
entries, print Audit Log entries or retrieve them to a host system, and then clear the
Audit Log.
The CLEARAUDIT console command

The CLEARAUDIT Console Command deletes all records in the Audit Log. This command
must be authorised, and when used results in a record of the deletion being put into the
fresh, otherwise empty Audit Log.


This dialogue box has been discussed earlier in the document. The Clear button can be
used by Security Officers to delete all Audit Log entries.
The Q6 Host Command

The Q6 host command can be used under authorization to delete from the Audit Log
either:
 all records previously retrieved to the host, or
 all archived records.
Other Audit Log Management Functions
Translating MAC on LMK Refresh

The MAC calculated on a record uses a MACing key which is encrypted under the LMK.
When the LMK is changed, the MACing keys need to be translated to the new LMK. This is
done by using the Q0 Host Command.
Verifying an Audit Log Record

The MAC on an Audit Log record can be verified by using the Q8 Host Command.

Chapter 18 – Tamper protection

Introduction
Tamper protection is implemented in three tiers:
1. Tamper resistance – using a design that makes it difficult for the attacker to
attempt to access the secure area of the payShield 9000. This is done partially
using physical characteristics such as using toughened materials and providing no
path that can be used by probes to make contact with the electronics inside the
HSM. Logical characteristics add to the tamper resistance, for example by not
providing any software utilities which can access secret data.
However, it is recognised that an HSM cannot prevent all attempts at physical

access to its internal components. An HSM that could resist high-performance
drills, gunshots, explosives, chemical attacks, oxyacetylene cutting torches, etc.,
would be so expensive, large, and heavy that it would not be a practicable
proposition for potential users.
2. Tamper evidence – any tamper activity must be evident to the owner of the HSM.
For example:
 tamper labels are used to show if the lid of the payShield 9000 has
been opened: a tamper label will clearly indicate whether it has been
peeled off, torn, or cut;
 all other labels attached to the payShield 9000 are transparent to

ensure that the HSM's operator can see any holes drilled or cut into the
casing;
 detected tamper attempts are recorded in error logs.
 LEDs are illuminated on the front panel of the payShield 9000.
3. Tamper responsiveness – the HSM takes actions in response to a detected tamper

event to ensure that the secret data being protected by the HSM cannot be
accessed by attackers even where they have gained access to the internal
components of the HSM.
This chapter concentrates on the tamper responsiveness of the payShield 9000.
Certifications
The payShield 9000 is certified to the PCI PIN Transaction Security (PTS) standard for
HSMs, and its cryptographic module is certified to the FIPS 140-2 standard at Level 3.
These certifications provide independent assurances of the payShield 9000's tamper
protection mechanisms.
Tamper responsiveness in the payShield 9000
Types of Tamper Actions

A payShield 9000 may be subjected to the following types of tamper attempts:
1. Physical access to the components inside the HSM.
2. Environmental changes.

3. Voluntary tamper.
4. Fraud Attack.
These are discussed in the following sections.
Physical Access
An attacker may attempt to gain physical access to the components inside the HSM, for
example to attach probes to data paths or microchips in order to read data. This may be
attempted by removing or bending the lid, or by drilling or cutting through the casing
and circuit boards inside the casing.
The payShield 9000 can detect removal or partial removal of the lid, distortion of the lid,
and physical access to the secure components of the HSM.
On detection of such an attempted tamper, the payShield 9000 will enter the tamper
state, as described in a later section.
Environmental Changes
An attacker may attempt to change environmental conditions, such as temperatures or
voltages, in order to affect the operation of the HSM. The payShield 9000 will detect such
actions. The temperature sensor is described in more detail later in this chapter.
An attacker may also try to remove an HSM and take it to a workshop or other location
where they can attempt attacks at their leisure. The payShield 9000 makes this difficult
by locking itself into a rack or cabinet when it is in Online or Offline state. In addition, the
payShield 9000 provides a configurable motion sensor to detect if the unit is being
moved. The motion sensor is described in more detail later in this chapter.
On detection of such an attempted tamper, the payShield 9000 will enter the tamper
state, as described in a later section.
Voluntary Tamper
A payShield 9000 operator can voluntary trigger a tamper condition on the HSM, by
inserting a probe into the "Erase" hole on the rear of the HSM. This might be done, for
example, if the operator believes some kind of attack is being launched somewhere on
their system and they want to rapidly disable the HSM.
On detection of such a voluntary tamper, the payShield 9000 will enter the tamper state,
as described in a later section.
Fraud Attack
Whereas the preceding tamper actions require physical access to the payShield 9000, a
Fraud Attack could be launched from any computer that can communicate with the HSM.
A Fraud Attack is essentially a brute force attack to uncover PINs. By issuing a sequence
of commands to the HSM to verify a PIN, the attacker can keep trying different PINs until
they receive a positive PIN verification response to indicate that the PIN is correct.
The payShield 9000 offers an optional Fraud Detection mechanism to protect against this
type of attack – see Chapter 7. The HSM operator can set a number of limits (e.g. using
the A5 console command or the Configuration / General Settings / Fraud dialogue box in
payShield Manager):
1. A maximum permitted number of PIN Verification failures in any one minute.

2. A maximum permitted number of PIN Verification failures in any one hour.
3. A maximum number of times that limits 1 or 2 may be exceeded.

If any of these limits are exceeded, an entry is made in the payShield 9000 Audit Log. In
addition, the following actions may be requested by the user:
 If Limits 1 or 2 are exceeded, the HSM user can elect to take actions as follows:
o If the "Logging Only" option is selected, to add the event to the

appropriate counter in the payShield 9000 Health Check counts; or
o Increment the Health Check counts and also cease processing PIN
verification requests by returning error response 39 to each appropriate
host command. Processing of other commands continues as normal.
 If Limit 3 is exceeded, the user can elect to take actions as follows:
o If the "Logging Only" option is selected and Health Check counts have
been enabled, to add the event to the appropriate counter in the payShield
9000 Health Check counts; or
o Increment the Fraud Detection counters in the Health Check counts if the
Health Check counts have been enabled, and also enter a tamper state as
described below.
Tamper State
When the payShield 9000 detects a tamper attempt, it will:
 Delete the HSM secrets– see the later section on this.

 Re-start the HSM.
 Make an entry in the Error log – see the later section on this.
 Illuminate the "Alarm" LED on the front panel of the payShield 9000: the LED will
extinguish when the cause of the tamper is removed.
 Flash the "Error Log" LED on the front panel of the payShield 9000.
 If Health Check Counts have been enabled, increment the tamper count.
Deletion of the HSM Secrets

As described above, detection of a tamper will result in deletion of the HSM's secrets
(depending on user settings in the case of Fraud Attacks). The secrets that will be
deleted are:
 Local Master Keys (LMK). The LMKs are stored in the HSM and used to encrypt all
the keys that are protected by the payShield 9000, and some other data such as
PINs and Decimalization tables. If the LMKs are deleted the HSM can no longer
decrypt any protected data and essentially becomes inoperative. To re-enable the
payShield 9000, the LMKs must be re-installed from components held on
smartcards: this requires the co-operation of multiple (usually three) officers,
ensuring that the HSM is not re-enabled until the cause of the tamper has been
investigated.
 Private keys, used for capabilities such as payShield Manager and Secure Host
Communications. To re-enable these capabilities, the Private keys must be re-
loaded by using the HSM Recovery Key (HRK).

Error Log Entries

When a tamper is detected, an entry is made in the payShield 9000's error log: this will
in turn cause the "Error Log" LED on the front panel of the payShield 9000 to flash.
Here is an example of the Error log entries arising from voluntary use of the "Erase"
switch:
2: Apr 09 12:15:00 ERROR: [Tamper(1) Latched at [2015/04/09,
12:14:36]] (Severity: 2, Code = 0x00000004, Sub-Code = 0x00000000)
3: Apr 09 12:15:00 ERROR: [Tamper Latched State [LR1 = 0x0200, LR2 =
0x0000]] (Severity: 2, Code = 0x00000004, Sub-Code = 0x00000000)
4: Apr 09 12:15:00 ERROR: [ Tamper LR1 [0x0200 = Rear-mounted
erase button engaged]] (Severity: 2, Code = 0x00000004, Sub-Code =
0x00000000)
5: Apr 09 12:15:00 ERROR: [Tamper Current State [CR1 = 0x0000, CR2 =
6: Apr 09 12:15:00 ERROR: [ Tamper CR2 [0x8000 = DS3640 TEI
asserted]] (Severity: 2, Code = 0x00000004, Sub-Code = 0x00000000)
7: Apr 09 12:15:00 ERROR: [Attempting to clear tamper(1)] (Severity:
2, Code =0x00000004, Sub-Code = 0x00000000)
8: Apr 09 12:15:01 ERROR: [Tamper cleared on try (1)] (Severity: 2,
Code = 0x00000004, Sub-Code = 0x00000000)
The following entries in the Error Log arise from a tamper detected by the motion sensor:
11: Apr 09 12:17:58 ERROR: [Tamper(1) Latched at [2015/04/09,
12: Apr 09 12:17:58 ERROR: [Tamper Latched State [LR1 = 0x0100, LR2
= 0x0004]](Severity: 2, Code = 0x00000004, Sub-Code = 0x00000000)
13: Apr 09 12:17:58 ERROR: [ Tamper LR1 [0x0100 = Microcontroller
signaled tamper condition]] (Severity: 2, Code = 0x00000004, Sub-Code
= 0x00000000)
14: Apr 09 12:17:58 ERROR: [ Tamper LR2 [0x0004 = Motion sensor
detected motion events above thresholds]] (Severity: 2, Code =
0x00000004, Sub-Code = 0x00000000)
15: Apr 09 12:17:58 ERROR: [Tamper Current State [CR1 = 0x0000, CR2
= 0x8000]](Severity: 2, Code = 0x00000004, Sub-Code = 0x00000000)
16: Apr 09 12:17:58 ERROR: [ Tamper CR2 [0x8000 = DS3640 TEI
17: Apr 09 12:17:58 ERROR: [Attempting to clear tamper(1)]
(Severity: 2, Code =0x00000004, Sub-Code = 0x00000000)
18: Apr 09 12:17:59 ERROR: [Tamper cleared on try (1)] (Severity: 2,
Code = 0x00000004, Sub-Code = 0x00000000)
Appendix A provides information on Error Log codes.
Temperature Sensor
Description
The payShield 9000 is built around a secure cryptographic module called the TSPP. This
provides the core of the security for the payShield 9000 and is where all the processing
occurs and all the sensitive material is held. The TSPP is certified to FIPS 140-2 Level 3.

The TSPP incorporates a temperature sensor. This is designed to detect an operational

environment which could result in unreliable performance of the security processing
within the payShield 9000, and if triggered it will result in a tamper state. In current
versions of payShield 9000 software the temperature alarm cannot be disabled by users
and is permanently enabled, as can be seen in payShield Manager Configuration /
General Settings / Alarms:
The temperature sensor is active even if the payShield 9000 is disconnected from an
electric power supply: in this environment, the temperature sensing capability is
maintained by the payShield 9000's internal battery, and will still initiate LMK deletion
and tamper state.
Triggering of the Temperature Sensor

If the temperature falls outside of predefined limits, the temperature sensor will initiate a
tamper alarm causing the LMKs to be deleted and the unit will automatically reboot and
attempt to clear the tamper state. If the alarm condition persists, the unit will stop
attempting to clear the tamper after 2 attempts and will remain powered on with limited
functionality such that LMKs cannot be loaded. Deletion of the LMKs prevents the
payShield 9000 executing host commands or console commands which require an LMK to
be present.
Once the stimulus that triggered the alarm has ended, the payShield 9000 will need to be
rebooted to clear the tamper state and allow the LMKs to be reloaded.
An entry will be made in the payShield 9000 error log of the form shown in the next
section: the red "Error Log" LED on the front panel of the payShield 9000 will be flashing
to indicate that there is a new Error Log entry. The "LMK" LED will be extinguished as a
result of the deletion of the LMKs.
Error Log
The entries made in the error log will have formats similar to the following example:
PayShield 9000 Error Log

----------------------
1: Nov 30 00:43:18 ERROR: [Tamper(1) Latched at [2000/00/00,

2: Nov 30 00:43:18 ERROR: [Tamper Latched State [LR1 = 0x0004, LR2 =

3: Nov 30 00:43:18 ERROR: [ Tamper LR1 [0x0004 = Temperature

exceeded maximum operational range]] (Severity: 2, Code = 0x00000004,
Sub-Code = 0x00000000)
4: Nov 30 00:43:18 ERROR: [Tamper Current State [CR1 = 0x0004, CR2 =



7: Nov 30 00:43:41 ERROR: [ Tamper LR1 [0x0004 = Temperature

Sub-Code = 0x00000000)

9: Nov 30 00:43:41 ERROR: [ Tamper CR1 [0x0004 = Temperature

Sub-Code = 0x00000000)
10: Nov 30 00:43:41 ERROR: [ Tamper CR2 [0x8000 = DS3640 TEI

11: Nov 30 00:43:41 ERROR: [Tamper State is 0x0004 and retry count
exceeded (2)] (Severity: 2, Code = 0x00000004, Sub-Code = 0x00000000)
12: Nov 30 00:43:47 ERROR: [Temperature: FAILED - temperature

too high ] (Severity: 3, Code = 0x00000001, Sub-Code = 0x0000000E)
The messages show that a tamper event occurred and is still ongoing. The value of
"0x0004" for the LR1 and CR1 elements indicate that the tamper cause was the
temperature rising above the maximum acceptable level; a value of "0x0002" would
have indicated a temperature that was too low.
Motion Sensor
Description
The payShield 9000 incorporates a motion sensor to detect movement of the unit once it
has been put into service. For operational environments where movement of the
payShield 9000 is deemed a risk, (e.g. removal from a rack), it is recommended that the
motion sensor be enabled: when enabled, the motion sensor will put the payShield 9000
into the tamper state if any motion is detected. The motion sensor allows users to
configure the threshold sensitivity to one of several preset levels: please see the
information below for details on determining the appropriate threshold for your
environment.
The motion sensor used in the payShield 9000 uses the latest technology available at the
time of its design, and is far more sophisticated than the motion sensors available to

earlier models of Thales payment HSMs. The sensor in the payShield 9000 is a 3-axis
accelerometer: it is active even when the payShield 9000 is not connected to an electric
power supply, in which scenario its capability is maintained by the payShield 9000's
internal battery.
Sensitivity of the sensor

The sensor has 3 levels of sensitivity when connected to an electric power supply and a
single sensitivity level when disconnected from electrical power:
Sensitivity HSM powered up HSM disconnected

Setting from power
Low 100 milli-g 165 milli-g
Medium 50 milli-g 165 milli-g
High 15 milli-g 165 milli-g
In this table, "g" means the acceleration due to gravity.

To envisage what these sensitivities mean, the following table gives some examples of
accelerations associated with certain events:
Dynamic/ Event Description Parameter Milli-g

Static
Dynamic Accelerate to walking pace … … in 1 second 100-150 milli-g
Dynamic Accelerate to walking pace … … in 2 seconds 50-75 milli-g
Dynamic Accelerate to walking pace … … in 5 seconds 20-30 milli-g
Static Angle of tilt 0.8 ° 15 milli-g
Static Angle of tilt 1° 18 milli-g
The sensor logic includes a high pass filter to remove very low frequency and static
acceleration. The gravity acceleration vector is automatically adjusted to account for any
slight tilt due to the unit not being perfectly level.
The logic also avoids triggering of the alarm by a sudden and short shock (e.g. someone
bumping into the rack). An acceleration event occurs if the acceleration thresholds above
are exceeded for 2 consecutive sampling periods (of 25 milliseconds each). For the alarm
to be triggered, 12 acceleration events must be recorded over a period of 1.5 seconds.
If the Motion Sensor is activated

If a motion event exceeding the selected threshold level occurs, the motion sensor will
initiate a tamper alarm causing the LMKs to be deleted and the unit will automatically
reboot and attempt to clear the tamper state. Deletion of the LMKs prevents the
payShield 9000 executing host commands or console commands which require an LMK to
be present.

Because a motion is a transient event the payShield 9000 will normally reboot and clear
the tamper state (but the LMKs will still be deleted, of course). If the unit detects an
additional motion event after the reset, it will go through the tamper process again.
An entry will be made in the payShield 9000 error log of the form shown in the next
section: the red "Error Log" LED on the front panel of the payShield 9000 will be flashing
to indicate that there is a new Error Log entry. The "LMK" LED will be extinguished,
indicating the deletion of the LMKs.
Error Log
The entries made in the error log will have formats similar to the following example:
----------------------
1: Jan 11 10:27:25 ERROR: [keyMgr: Tamper(1) Latched at [2013/01/11,

2: Jan 11 10:27:25 ERROR: [keyMgr: Tamper Latched State [LR1 =

0x0100, LR2 = 0x0004]] (Severity: 2, Code = 0x00000004, Sub-Code =
0x00000000)
3: Jan 11 10:27:25 ERROR: [keyMgr: Tamper LR1 [0x0100 =

Microcontroller signaled tamper condition]] (Severity: 2, Code =
0x00000004, Sub-Code = 0x00000000)
4: Jan 11 10:27:25 ERROR: [keyMgr: Tamper LR2 [0x0004 = Motion

sensor detected motion events above thre] (Severity: 2, Code =
0x00000004, Sub-Code = 0x00000000)
5: Jan 11 10:27:25 ERROR: [keyMgr: Tamper Current State [CR1 =

0x0000, CR2 = 0x8000]] (Severity: 2, Code = 0x00000004, Sub-Code =
0x00000000)
6: Jan 11 10:27:25 ERROR: [keyMgr: Tamper CR2 [0x8000 = DS3640 TEI

7: Jan 11 10:27:26 ERROR: [keyMgr: Attempting to clear tamper(1)]

(Severity: 2, Code = 0x00000004, Sub-Code = 0x00000000)
8: Jan 11 10:27:27 ERROR: [keyMgr: Tamper cleared on try (1)]

The messages in this example confirm that the payShield 9000 entered a tamper state
and that the tamper was cleared. Message 4 indicates that the cause was the motion
sensor detecting motion events above the thresholds (which is the meaning of the code
"LR2 = 0x0004").
Enabling the Motion Alarm

By default, the motion alarm is disabled when the payShield 9000 is shipped by Thales.
This is to prevent the unit entering a tamper state prior to delivery to the user as a result
of movement during shipping.
This means that users must actively enable the motion alarm in order to benefit from the
additional security that this offers. This can be done by using:

1. The CL Console command, by entering "L", "M", or "H" to indicate the desired
sensitivity level after the prompt:
"Motion Alarm [Low/Med/High/ofF] (OFF):".
Full details are available in the payShield 9000 Console Reference Manual.
2. The Alarms dialogue box in the payShield Manager General Settings tab in the
Configuration section menu provides a selection box with the Motion Alarm
sensitivity options:
Full details are available in the payShield Manager User Guide.
Recovering from Tamper State

No attempt should be made to return the payShield 9000 to an operational state until an
appropriate Incident Management Process has been followed to investigate the cause of
the tamper, and determine whether a true attack took place and whether the attack was
successful. This process must conform to the guidance given in the payShield 9000
Security Operations Manual, particularly in the sections on Procedural Security and
Inspection Procedures in Appendix A.
The LED indicators will show the following:

 If the "Alarm" LED is still illuminated, the cause of the tamper state is still present
and the payShield 9000 should not be put into service.
 The "Error Log" LED will be flashing after the automatic restart, indicating that
there are new error log entries that have occurred since the error log was last
viewed. These new entries (which will include those resulting from the tamper
detection) should be viewed, and the cause of the tamper identified and any
appropriate action taken. Viewing the error log will cause the "Error Log" LED to
stop flashing and go into a permanently on state. The LED will extinguish when
the error log is deleted.
 The "LMK" LED will be extinguished, showing that the LMKs have been deleted as
a result of the tamper state.

When all investigatory and corrective actions have been taken, the LMK(s) must be
reloaded. Where multiple LMKs are being used, they should be loaded into the same
"slots" or IDs that they occupied before the tamper event.
Where the tamper condition arose from the Fraud Detection facility, PIN verification
processing must be re-enabled by using the A7 console command.
If payShield Manager has been commissioned on the payShield 9000, the HSM will on a
tamper revert to its ex-factory Warranted state and will have to be re-commissioned.
If a tamper state cannot be cleared or tamper states recur without apparent reason,
users with support contracts should return their payShield 9000 to their support provider
for investigation.
Only if you are confident that the payShield 9000 has not been compromised should you
return it to production use by:
 Re-installing LMKs
 Confirming that security settings have the correct values
 Confirming that the correct host/console commands are enabled.
 Confirming that the correct PIN Block formats are enabled.
 Confirming that the appropriate alarms are set.
 Confirming that the host/management/console port settings are correct.

Chapter 19 – Remote Management

and Centralized Monitoring
Introduction
The ability to manage payShield 9000s from a remote location is important for
organizations where operating staff or security officers are remote from data centers,
which have multiple locations, or where access to the data center is restricted. Remote
management offers major benefits in terms of reduced costs, avoiding the tieing up of
staff, and the ability to manage HSMs round the clock even when physical access is not
possible.
The ability to monitor an estate of payShield 9000s from a central location becomes
more important as the size of the estate of HSMs grows. Centralized monitoring provides
operating and security staff with an immediate overview of all the HSMs they are
responsible for, identifies and automatically alerts on current and impending problems
and bottlenecks, and allows management information to be provided to system-wide
management tools.
The payShield 9000 is supported by two products that fulfill these roles:
 payShield Manager – to allow a payShield 9000 to be managed from any

location using a browser, and
 CipherTrust – to allow the whole estate of HSMs to be monitored from
anywhere, to issue alerts, and to provide data to system management tools.
Between them, these two products offer a complete management solution for payShield
9000s.
payShield Manager vs. CipherTrust

payShield Manager CipherTrust
Can be used from anywhere Can be used from anywhere
Operated using a browser Operated using a browser
Modern Graphical User Interface Modern Graphical User Interface
Handles unattended payShield 9000s Handles unattended payShield 9000s

(e.g. in a dark datacenter) (e.g. in a dark datacenter)
Software runs in the payShield 9000 Software runs on a separate host
Licensed by optional license on each Licensed as a server software license plus

payShield 9000 endpoint licenses
Operated by users Runs automatically in the background
Used to manage one payShield 9000 at a Monitors all or a group of payShield 9000s
time at the same time
Makes changes Monitors and alerts
Reduces operating costs and flexibility in Provides visibility on operational status of

access to the payShield 9000. an estate of payShield 9000s

payShield Manager
payShield Manager provides a Graphical User Interface for managing the payShield 9000
and replaces the HSM Manager product used on earlier versions of the payShield 9000
(and on the payShield 9000's predecessor, the HSM 8000). It is embedded in the
payShield 9000 software, and can be used free of charge by operators who are local to
the payShield 9000 being managed: in order to be used remotely from the payShield
9000, optional license HSM9-LIC037 must be installed on the HSM. Users of Remote HSM
Manager can migrate to remote use of payShield Manager free of charge.
payShield Manager offers an alternative to the console as a way of managing the

payShield 9000, and offers a modern user interface, additional security, and the option of
working remotely.
One payShield 9000 can be managed at a time: where it is required to manage multiple
units they can be handled serially.
The following sections provide an overview of the principles of payShield Manager. For
full details of the product see the payShield Manager User Guide, which is included in the
payShield 9000 manuals set.
Security recommendations for payShield Manager can be found at Appendix B of the

payShield 9000 Security Operations Manual.
Connection
payShield Manager is accessed by connecting to the payShield Manager management
port IP address from a suitable browser running on a laptop, tablet, or PC: the list of
supported operating systems and browsers will be regularly extended, and users should
contact their Thales representative or partner to get the latest list.
The computer used to manage the payShield 9000 must be provided with a smartcard
reader. Any card reader supported by the computer can be used, but it is recommended
that a card reader with its own keypad is used as this offers enhanced security.
The payShield Manager computer must have a TCP/IP network connection to the
management port of the payShield 9000 that it is managing. The management port IP
address can be set manually or by DHCP (the default). If the connection is remote, then
optional license HSM9-LIC037 must be installed on the payShield 9000.
payShield Manager uses secure HTTP and the network connection must allow use of port
443: optionally port 80 must be allowed if users do not wish to type "HTTPS" in their
browser
Connection is only possible if the payShield 9000 is in Online state. If the physical keys
are used to change the state of the payShield 9000 during a payShield Manager session,
the payShield Manager connection will be dropped. The console is inoperative while a
payShield Manager session is in progress.
The Trust Model

The payShield Manager operates on a trust model to allow users to configure and operate
the HSM. This trust model relies on 2 parallel key hierarchies. The first key hierarchy
(the Preplaced Trust in the diagram below) consists of key material and signed

certificates installed at the Thales factory: a payShield 9000 which has just been
manufactured and contains this key hierarchy is classed as being "Warranted".
The second key hierarchy (the Customer Trust in the diagram below) consists of signed
certificates installed locally or remotely by the customer: a payShield 9000 which has
this key hierarchy set up is classed as being "Commissioned".
The collection of signed certificates in the Customer Trust is referred to as the Customer
Trust Anchor (CTA).
Consists of key material and

Consists of key material and
signed certificates installed
signed certificates installed at
locally or remotely by the
the Thales factory.
customer.
Facilitates
Remote
Preplaced Trust Installation of
Customer Trust
(e.g. at Thales factory)
warranting warranting commissioning commissioning
Modeled as a separate key

Modeled as a key hierarchy
hierarchy whose elements are
whose elements are placed on
placed on HSMs and smart
HSMs and smart cards.
cards.
The payShield Trust Model
The "Pre-placed Trust" is only used to facilitate the secure, authenticated loading of
"Customer Trust" in a remote environment. Once Customer Trust is installed in a HSM, it
is considered "Commissioned" and management operations can be used.
A Commissioned payShield 9000 returns to the Warranted state if it is deliberately

decommissioned or detects a tamper.
Commissioning a payShield 9000

Commissioning can be accomplished remotely using a browser or locally using a console.
Full details on the commissioning process can be found in the payShield Manager User
Guide.
In outline, the stages in the commissioning process are:

1. Setting up the security domain (i.e. the Customer Trust Anchor, or CTA,
referred to above), using a payShield 9000 which has not yet been commissioned.
This results in the creation of a set of CTA cards using blank smartcards provided
specifically for payShield Manager.

These will be used in an "m of n quorum" fashion – i.e. a total of n cards (or
shares) are created, and any m of these must be present as a quorum when they
are used. Each share must be held by a different trusted officer.
This process can be initiated by connecting the browser to the management port
of any uncommissioned payShield 9000 and using the Commission button on the
landing page.
If a console is being used, the XI command will perform the process.
2. Commissioning each payShield 9000 in the security domain defined by the

CTA. This is done by presenting a quorum of the CTA cards to each
uncommissioned payShield 9000.
This process can be initiated remotely by connecting the browser to the
management port of the uncommissioned payShield 9000 and using the
Commission button on the landing page. When commissioning locally by using a
console, the XH command is used.
3. Set up the HSM Recovery Key (HRK) passphrases. For remote

commissioning using payShield Manager this happens as a continuation of the
commissioning process from stage 2; for local commissioning using the console
this is done using the SK console command before commissioning the payShield
9000. (See information on the HRK below.)

4. Commission Remote Access Control Cards (RACCs). This happens as a

continuation of the commissioning. Left and Right RACCs are created (using blank
payShield Manager smartcards). The cards are PIN-protected.
The RACCs will be used subsequently to access the payShield 9000 when using
payShield Manager, and logically take the place of the right and left metal keys
used when managing the payShield 9000 using a console. The same RACCs can
be registered to multiple HSMs, allowing the same cards to access all of these
payShield 9000s.
When the commissioning process is completed for a payShield 9000, that HSM can then
be managed (locally or remotely) using payShield Manager.
Restricted Users
The RACC cards referred to above can also be used to allow restricted access to
payShield 9000 units. This enables the holder to log on and view certain payShield 9000
information (equivalent to a console user who does not have a metal key) but not to
make any changes.
The HSM Recovery Key (HRK)

A commissioned payShield 9000 has a private key used in establishing TLS/SSL sessions.
This is held in volatile memory, and so this key is lost if the payShield 9000 is
decommissioned or detects a tamper.
In the case of a tamper, the private key needs to be recovered when the payShield 9000
is put back into service. This is possible because a copy of the private key encrypted
under the HRK is held in non-volatile memory. The private key can be reconstituted from
this encrypted copy by using the HRK.
During the commissioning process described above, the HRK is created inside the
payShield 9000 by providing two passphrases, which must be recorded securely.
Following a tamper, the private key can be reconstituted by providing the same
passphrases to the HSM using the SL console command in place of SK during the re-
commissioning process.
Migrating from Remote HSM Manager

Users of Remote HSM Manager on payShield 9000 with base release v2.x or earlier can
migrate to payShield Manager on payShield 9000 with base release v3.0 or later.
For users with a Thales support contract, licensing for payShield Manager equivalent to
that purchased for Remote HSM Manager will be provided free of charge.
In a payShield 9000 which has previously been used with Remote HSM Manager, there
already exists an internally generated trust which can replace the Thales preplaced trust
described earlier. This makes migrating from a payShield 9000 with Remote HSM
Manager to payShield 9000 easier than upgrading a unit which has never had Remote
HSM Manager installed.
The payShield Manager commissioning process can be completed remotely in a similar

fashion to that outlined above. However, there are some differences when commissioning
a payShield 9000 previously used with Remote HSM Manager – see the payShield
Manager User Guide for full details:
 A Migrate button is provided on the payShield Manager landing page of the

uncommissioned payShield 9000 in place of the Commission button.

 At the start of the migration process, Right and Left Remote HSM Manager
Administrator cards must be presented to authenticate the users.
If desired, legacy Administrator, Operator, and Authorizing Officer cards which were
being used for Remote HSM Manager can be migrated for use with payShield Manager.
This can be done by logging in to payShield Manager and using the Legacy Card
Migration accordion in the Domain main activity.
Upgrading from earlier versions of payShield 9000

payShield 9000 units which were not manufactured with base release v3.0 or later and
which have never been set up for use with Remote HSM Manager can be upgraded to
v3.0 or later and set up for management through payShield Manager.
In this situation, the payShield 9000 has neither the Thales Preplaced Trust described
earlier nor the trust generated internally when Remote HSM Manager was implemented.
As a result, payShield Manager must be commissioned locally using a console, and the
following stages must be completed before the commissioning process is started:
 Creation of new Domain Authority (DA) smartcards using the RI console
command.
 Generation of a certificate from the DA cards in each payShield 9000 using the RH
console command.
User interface for a commissioned payShield 9000

payShield Manager presents a modern, browser user interface to the user.
Here is the landing page, presented when the browser has connected to the management
port:
Items 1, 2, and 3 present some summary information about the payShield 9000: display
of this information can be disabled using the payShield 9000's security settings.
Item 4 initiates the login dialog box, and item 5 provides access to tools, including the
ability to choose which smartcard reader to use (where more than one card reader is
attached to the computer).

Once one or more users have been logged in, the payShield 9000 can be managed using
payShield Manager: see the payShield Manager User Guide for a full description of the
functionality.
Here is an example of what payShield Manager users will see:
Some of the main features of the interface are labelled in the above screenshot:
1: Main activity category ("Configuration" in this example).
2: Main option accordion ("Host Settings", in this example). When clicked this
toggles between presenting and hiding the sub-options and information relevant
to this option.
3: Sub-option selection button (where relevant: "Ethernet" in this example).
4: Sub-option selection tab (where relevant: "ACL" in this example).
5: Tools button – provides access to actions appropriate to the displayed
information item.
6: Lock symbol. Indicates whether the information item can be changed. Hovering
over the lock symbol provides information as to why the item is locked.
7: Button to change state of the payShield 9000.
payShield Manager main activities

This section outlines the functions available for each of the main activity categories listed
across the top of the payShield Manager screen.
Summary
 Summary Dashboard: information relating to the payShield 9000 (e.g. serial
number, software version)
 Health Dashboard: summary information relating to the health of the payShield
9000 (e.g. number of error log entries, PSU status, instantaneous loading).
 Configuration Dashboard: outline of main configuration aspects (e.g. host port IP
addresses, PCI HSM status).
 LMKs: providing information about each LMK held on the payShield 9000.

Status
 Device Information: information about the payShield 9000 unit (e.g. name,
performance model).
 Utilization Statistics: providing cumulative and instantaneous data on loading of
the payShield 9000 and on the commands processed by it. (See Chapter 8 for
more information.)
 Health Statistics/Diagnostics: information about the health of the payShield 9000.
(See Chapter 9 for more information.)
 Error Log: ability to view and manage the Error Log.
 Audit Log: ability to view and manage the Audit Log. (See Chapter 17 for more
information.)
 Software Info: information about the software installed on the payShield 9000
(e.g. base release, software number, bootstrap version, status of security settings
in terms of PCI HSM compliance.)
 FIPS/Licensing: showing the payShield 9000 software licenses installed and the
FIPS-validated algorithms. Software and license updates can be initiated from this
area.
Operational
 LMK Operations: currently installed LMKs can be viewed and managed. LMK
smartcards can also be managed from here.
Domain
 payShield Security Group: used to enable which RACC and Restricted cards can be
used with the payShield 9000.
 Security Domain: used to manage the payShield Manager security domain and
smartcards. This section also displays information about the loaded certificates.
 HRK Operations: to change the HRK passphrases.
Configuration
 Host Settings: used to manage the host port settings, including Access Control
Lists and Secure Host communications.
 Printer Settings: manages the configuration of connected printers.
 Security Settings: used to manage all of the payShield 9000's security settings.
 Management Settings: used to manage the management port settings.
 General Settings: for changing settings relating to PIN Blocks, Alarms, Fraud
Detection, Date & Time, and the payShield 9000 unit's name.
 Configure Commands: to enable/disable console and host commands.
 Audit Settings: to control which events and commands are to be included in the
Audit Log. (See Chapter 17 for more information.)
 SNMP Settings: manages the settings relating to SNMP support on the payShield
9000.

The Virtual Console
The Virtual Console main activity brings up a "dumb" terminal emulation window which
allows all console commands (apart from A, AUDITPRINT, CO, DC, EA, EJECT, FC, GK,
GS, GZ, LK, LO, NP, RC, RH, RI, RS, SS, VC, XA, XD, XE, XH, XI, XK, XR, XT, XX, and
XZ) to be run from the browser. This provides enhanced security compared with a real
console because the connection to the payShield 9000 is protected.
CipherTrust
CipherTrust provides a central repository of all information collected from up to 200
payShield 9000 HSMs and monitors information directly from the HSMs including device
utilization, command information and HSM health. CipherTrust also provides alarm and
event notification (via syslog, SNMP, and email) as well as event logging and report
generation from predefined templates. This section describes version 1.1 of CipherTrust.

Overview
CipherTrust is delivered as an Open Virtual Appliance "OVA" format, including a 64-bit

Linux OS. It can be installed on various vSphere and VMware virtualization platforms.
Users can work from any Linux, Apple or Microsoft Windows client workstation that has
network connections to CipherTrust and a supported browser (WebUI access) or SSH
client (CLI access).
CipherTrust "listens" to the estate of payShield 9000 units using SNMP and builds up a
database of information and events. Authorized users can monitor HSMs from their client
workstations. They can also set up alerts so that they are warned by e-mail when certain
events arise or thresholds are reached: this avoids the need for payShield 9000s to be
constantly monitored by the users.
Information about the monitored payShield 9000s can be viewed at group level, with the
ability to drill down to examine individual devices.
CipherTrust can also provide status information to the organization's Security
Information and Event Management (SIEM) system via syslog or SNMP.
Which payShield 9000s can be monitored?

Any payShield 9000 using base software 1.1a or later can be monitored. The following
settings must be made:
 SNMP enabled and users set up for version 3 (using SNMP and SNMPADD console
commands or payShield Manager's Configuration / SNMP).
 Collection of utilization statistics enabled (using UTILENABLE console command or
payShield Manager's Status / Utilization Statistics).
 Period for instantaneous utilization data set to 60 seconds (using UTILCFG console
command or payShield Manager's Status / Utilization Statistics / Instantaneous).
 Collection of Health Check counts enabled. (using HEALTHENABLE console
command or payShield Manager's Status / Heath Statistics/Diagnostics).

Groups
In CipherTrust, the monitored payShield 9000s are allocated to Groups. This allows
different groups of HSMs to be monitored by different users. A payShield 9000 can be
enrolled into multiple groups.
User Roles
CipherTrust users can have one (or both) of two roles:
 Administrator – to manage users, groups, and the CipherTrust installation itself.

There must be at least two Administrators.
 Group Managers – to monitor, and manage the monitoring of, groups of payShield
9000 units. Group Managers can monitor multiple groups of HSMs.
Firewall settings
Firewalls must be configured to allow the passage of the following protocols:
Protocol Transport Port Direction
DNS TCP/UDP 53 Outbound
FTP TCP 21 Both
HTTP TCP/UDP 80 Outbound
HTTPS TCP 443 Both
ICMP Request Both
ICMP Response Both
NTP UDP 123 Outbound
SMTP TCP 25 Outbound
SNMP UDP 161 Outbound
SNMP UDP 162 Outbound
SSH TCP/UDP 22 Inbound
System Log UDP 514 Outbound
Licensing
CipherTrust is licensed as the server software plus a number of endpoint (i.e. monitored
HSM) licenses. The basic license includes the server license and 5 endpoint licenses.
Additional endpoint licenses can be added at any time up to a total of 200.
The server software with up to 8 endpoints can be used without payment in a
demonstration mode for up to 30 days: use beyond this period of time requires payment
for the licenses.
The Administrator Role

Administrators manage the CipherTrust installation and its users. Activities include:
 Upgrading the CipherTrust software.

 Installing licenses.
 Network configuration of the CipherTrust server.

 Managing SSL/TLS certificates.

 Creation (using two passphrases) of the CipherTrust Master Key. (These
passphrases will be required whenever CipherTrust is re-booted.)
 Setting date and time, or configuring use of NTP to get date and time.
 Configuring alarms to be sent to administrators by e-mail or to SIEM systems by
syslog or SNMP Traps.
 Creating Groups and initial Group Managers.
 Creating/deleting users.
 Managing CipherTrust event logs.
Information presented to Administrators

Administrators see information relating to the CipherTrust installation:
 CipherTrust event logs.
 CipherTrust alarms
 User activity
 CipherTrust status
Here is an example of a CipherTrust screen presented to an Administrator, showing
information about the CipherTrust installation itself:


The Group Manager Role

Group Managers are concerned with groups of payShield 9000 units which are being
monitored by CipherTrust. Their activities include:
 Enrolling payShield 9000 devices into their groups.

 Enabling, setting thresholds for, and receiving alarms relating to loading of
payShield 9000s.
 Setting and viewing/receiving event alarms by e-mail.
 Monitoring information presented on individual payShield 9000s and groups of
payShield 9000s.
Information presented to Group Managers

Group Managers see information relating to their groups of payShield 9000s, from which
they can drill down to individual payShield 9000s:
 Group Alarms
 Group events
 Utilization / loading and host command volumes – for individual devices and
summarized across the group.
 Status of monitored devices.
 General information about devices (e.g. serial number, IP address,
online/offline/secure state)
 Health status of individual devices (e.g. tamper state, Fraud detection
information, communication interfaces)
 Monitoring status (e.g. Enabled, Unreachable)
 Installed LMKs
As an example of the ability to drill down, here we see a Group Manager screen showing
utilization and host command volume data for all the groups that the Group Manager has
responsibility for:

The Group Manager can then drill down to see all the devices in a group (e.g. in the Card
Acquiring group):
And then the Group Manager can drill down to see the utilization and host command
volume relating to an individual payShield 9000 within the group:


Note on graphical displays

Utilization and host command volume data can be viewed numerically and graphically at
both the group and individual device level. For utilization data being viewed graphically,
the horizontal (time) scale can be expanded or contracted to allow the user to zoom the
graph in or out to view their desired date and time periods.
Reports for Group Managers

A reporting facility is available for Group Managers, allowing reports to be created for
their group(s) and devices. These reports can be generated as:
 scheduled, recurring reports

 one-time reports, created on demand.
Reports can be saved as files or sent by e-mail.
Two types of report are available:
 Utilization and loading trends – providing group/device utilization charts, top host
commands, and host command volumes.
 Cross-HSM reports – providing health, LMK, and utilization details.
Here is an example of the set-up for a one-time Cross-HSM report:

Alarms
Alarms can be set up relating to:
 The CipherTrust installation. These alarms are sent by e-mail to

Administrators, and can relate to:
 CipherTrust server utilization exceeding the following limits:
 CPU utilization > 95%
 Memory utilization > 90%
 Disk storage utilization > 90%
 CipherTrust license expiry warnings
 Master Key not Generated or not loaded

 Groups and individual monitored devices. These alarms are sent by e-mail to
the Group managers registered for the group. These alarms can relate to:
 Device serial number changed
 LMK changes
 Authorization changes
 Utilization levels exceeding set thresholds
 Change in device connection status
 Change in Online/Offline/Security state
 Tamper
 Fraud Detection
 Change in host port or management port status
 Device added/removed
Alarms can be have different severity, depending on the event type. These range from
Emergency to simple Information. (See the screenshot below.)
Alarms remain active until they are acknowledged, with response information entered
against the alarm. Historical, acknowledged alarms can also be viewed.


Chapter 20 - Migrating from HSM

8000 to payShield 9000
Introduction
The HSM 8000, introduced in 2002, was the predecessor to the payShield 9000; it has
been withdrawn from sale and is no longer supported.
Even though the payShield 9000 is a lot more capable than the HSM 8000, it is
backwards compatible with the HSM 8000 in terms of its host interface software, such
that it is possible to replace an HSM 8000 with a payShield 9000 without any change to
the host system. As a result, it is easy to migrate from the HSM 8000 to the payShield
9000, with minimal disruption to the environment that it operates in.
This document identifies the similarities and differences between the two products and
how this might affect customers, and provides other advice on migrating from the HSM
8000 to the payShield 9000.
It will be seen that the payShield 9000 has major functional advantages over the HSM
8000 - especially over older versions of HSM 8000. Although a straightforward migration
from HSM 8000 to payShield 9000 is easy, users who want to take advantage of the new
capabilities will need to change their operational procedures as outlined later.
Overview
For most users, the task of migrating from HSM 8000 to payShield 9000 will be very
easy. Where Ethernet or Asynchronous host communications are in use it is simply a
case of
 making the appropriate settings on the payShield 9000 (in an almost identical
way to how the settings are made on the HSM 8000)
 loading the HSM 8000's LMKs on the payShield 9000
 unplugging the HSM 8000 from the host connection
 connecting the payShield 9000 in its place. HSM 8000 smartcards can continue to
be used with the payShield 9000.
The most important factor is that the payShield 9000 is fully backwards compatible in
terms of the Host API, and that HSM 8000 custom software can be cost-effectively ported
to the payShield 9000: this is discussed later in the document. This means that no
changes are required to host applications.
There are indeed some changes to how the HSM is managed and operated, reflecting the
more modern hardware and operating system used in the payShield 9000. These
differences are relatively minor and users should easily be able to get to grips with them.
Where the HSM 8000 host connection uses something other than Ethernet or
Asynchronous, then this will need to be changed to a method supported by the payShield
9000.
The payShield 9000 introduces a significant number of enhancements compared to the

HSM 8000 (especially early versions of the HSM 8000), and users will have to adapt
operational and management procedures if they want to take advantage of these. In
general, these enhancements could be ignored in order to keep the migration to
payShield 9000 very straightforward.

This document outlines all of these differences between the two models of HSM and how
these might affect the user. Detailed information is available in the payShield 9000
manuals and the other documents referenced.
Host API (Commands) and Licensing
Full backwards compatibility of the Host API

All of the host commands and responses used in HSM 8000 base software are supported
in exactly the same way on the payShield 9000: indeed, the payShield 9000 uses the
same source code as the HSM 8000. This means that an HSM 8000 running base
software can be replaced by a payShield 9000 without any change needing to be made to
the host application. (Changes would of course be required to take advantage of
enhancements made in the payShield 9000 which were not present in the HSM 8000.)
Licensing of functionality - payShield 9000 software packages

The way that host commands are licensed and packaged on the two HSMs is different:
 On the HSM 8000, the user purchases a base software licence (LIC001) which
provides all core functionality for management of the HSM and its keys, and for
acquiring purposes. To this can be added optional licences to cover requirements
such as additional encryption algorithms (e.g. RSA), additional functionality (e.g.
card issuing), or additional LMKs.
 On the payShield 9000, the user purchases one of a choice of base software
packages, which are tuned for particular applications such as acquiring or card
issuing. These packages provide core functionality plus an appropriate collection
of optional licences. Optional licences can be added where additional functionality
is required.
An HSM 8000 user migrating to payShield 9000 should therefore select the base package
which gives them the lowest cost path to their desired functionality. See the payShield
9000 Application Note PPIF0543 payShield 9000 Application Note: Packages & Licenses
for a description of the packages and licenses available on the payShield 9000.
HSM hardware
Left key 8 status LEDs
Right key
Card reader USB Ports

Serial number
Reset button
Diagram 1: payShield 9000 front panel

Similarity of hardware operation

The main operational characteristics of the payShield 9000 hardware are the same as for
the HSM 8000:
 Use of left and right physical keys for administrators. The same types of locks and
keys are used as for the HSM 8000, and are in the same location on the front
panel.
 Use of smartcards for authenticating users. The same smartcards that were used
on the HSM 8000 can be used on the payShield 9000. As on the HSM 8000, the
card reader is located in the front panel.
 LEDs on the front panel are used to provide various status information, as on the
HSM 8000.
 The payShield 9000 and HSM 8000 occupy the same rack space and use the same
rackmount fittings.
 The payShield 9000 can be operated in the same way as the HSM 8000 using a
console. (payShield Manager replaces HSM Manager on payShield 9000 v3.x and
later, and so users of HSM Manager on the HSM 8000 should familiarise
themselves with the operation of payShield Manager.)
Possible user considerations

The differences between the two types of HSM are as follows. These differences may
require some changes in documented procedures in the user organization:
 The payShield 9000 has 8 multi-colour LEDS to indicate the status of the HSM,
rather than the 5 single-colour LEDs on the HSM 8000. As a result, there are
some differences in how the LEDs are used to show status: the usage of the LEDs
in the payShield 9000 is described in Chapter 2.
Diagram 2: LED status indicators on payShield 9000 front panel
 The HSM 8000 had a single button on the front panel which can perform the
functions of both a Reset (i.e. a re-boot of the software) and an Erase of the
LMKs, dependent on the state of the HSM. In the payShield 9000, these functions
are separated. A Reset is effected by pressing the button on the front panel (see
Diagram 1), whereas an Erase is effected by using the recessed button on the
rear of the HSM (see Diagram 3).
 The payShield 9000 can be ordered with dual power supplies and sockets (see
Diagram 3). Users who wish to take advantage of this high-availability feature
may need to modify their power distribution layout.
 The serial number on the payShield 9000 is also shown at lower-left of the front
panel, allowing it to be viewed easily while the payShield 9000 is fitted in a rack

or cabinet. This may allow users to make some changes to their operational
procedures.
Connectivity
Apart from 2 USB connectors on its front panel (see Diagram 1), the payShield 9000's
connectors are on its rear panel:
Diagram 3: payShield 9000 rear panel
Updated connectors
The connectivity options and the methods of attaching devices differ considerably
between the two HSM models, as the interfaces provided on the payShield 9000 reflect
current technology:
Purpose Type HSM 8000 payShield 9000

6
2 x DE9 Serial Ports USB port2 + adapter1
Console
Management 300-38,400 bps 1,200-115,200 bps
payShield Manager 10/100 Mbit Ethernet Gbit Ethernet Port
DB25 Serial Port4 USB port2 + adapter1
Serial
300-38,400 bps 1,200-115,200 bps
Printer
Parallel DB25 Parallel Port USB port2 + adapter1
USB Not Supported USB port2

Purpose Type HSM 8000 payShield 9000

TCP/IP or UDP 10/100 Mbit Ethernet 2 x Gbit Ethernet Port
5
DA26 serial ports
SNA/SDLC Not supported
(1 x DTE & 1 x DCE)
DA26 serial ports4 USB port2 + adapter1
Asynchronous (1 x DTE & 1 x DCE)
Host
300-38,400 bps 1,200-115,200 bps
ESCON connector
ESCON Not supported
(Option)
FICON connector3.
FICON Not supported
(Option)
Gbit Ethernet Port –
Auxiliary Other uses DB25 Serial Port4
used for SNMP only
Table 1: Comparison of connection options
Notes:
1. The adapters must be acquired from Thales: they incorporate a microprocessor,

the driver for which is included in the HSM software. Adapters are available for
serial (9-pin), parallel (25-pin), and parallel (Centronics) connection.
2. There are 6 USB ports - 2 on the front panel, and 4 on the rear panel. Any of
these ports can be used for any purpose, but where a console is used it must be
in the highest priority USB port, as described in the payShield 9000 Installation
Manual. Native USB printers can be attached without a special adapter.
3. There are 2 FICON ports on payShield 9000 units where the FICON option has
been purchased: at time of writing, only one port is available for use. FICON-
enabled units can be ordered with either a longwave or shortwave transceiver.
4. A single port is shared between these purposes.
5. A single port is shared between these purposes.
6. One on front panel and one on rear panel
Possible user considerations

These differences have the following consequences for users who are migrating from
HSM 8000 to payShield 9000:
 SNA/SDLC is no longer in widespread use, but if SNA/SDLC is in use on the HSM
8000, an alternative must be used on the payShield 9000. The only alternatives
likely to be considered are Ethernet or FICON.
 ESCON is no longer supported by IBM, and has been superseded by FICON. Users
of ESCON on the HSM 8000 will need to choose an alternative on the payShield
9000. FICON would be the obvious choice, although a number of former ESCON
users have now adopted Ethernet.
 Enough USB adapters must be purchased from Thales for connections that need
to be made using the USB ports. (These must be purchased from Thales, as
adapters sourced from elsewhere may use microprocessors which are
incompatible with drivers included in the payShield 9000 software.) The payShield
9000 is shipped with one USB-Serial adapter: this is intended for use with a
console, but can be used for other purposes if it is not required for a console. To
replace existing asynchronous host connection, D25-D9 adapters will also be
required.
 The USB ports and adapters meet the standards for distance and speed for the
various interface types. However, the HSM 8000 serial and parallel ports generally
exceeded the standards for distance and speed, and so users migrating from the

HSM 8000 may need to relocate attached devices so that their distance from the
HSM complies with the standards for the interface.
 Users may wish to take advantage of the dual host Ethernet ports on the
payShield 9000. These are provided to allow independent network routes to the
HSM to be set up, providing resilience against network failure. Both ports can be
active at the same time, each having its own IP address.
Loading software and licenses
Use of industry-standard tools

As with the HSM 8000, payShield 9000 units will be delivered with the appropriate
licenses and software installed. Users should only ever need to install software and/or
licenses if they are changing or updating their HSM software or adding licensed options.
With the HSM 8000, software and licenses are loaded using a Thales proprietary tool
called Imageloader. The payShield 9000 dispenses with this, and uses standard
mechanisms:
 FTP can be used to load software or licences to the payShield 9000. All PCs in
current use incorporate FTP software.
 USB memory sticks can be used to load software (but not licences).
User operating procedures will need to be changed to adapt to these new methods. The
Application Note PPIF0542 payShield 9000 Software & License Update Procedure gives
instructions on how to load software and licences onto the payShield 9000.
payShield Manager
Remote and Local HSM Manager in later versions of HSM 8000 supported software and
license loading. Users of these capabilities should familiarise themselves with the
operation of payShield Manager, which replaces HSM Manager on payShield 9000 v3.x
and later. Software can be updated using payShield Manager at Status / Software info /
Software - for further information see the manual 1270A645 payShield Manager User
Guide.
Operating and managing the HSM
No major changes to operation or management

The vast majority of actions needed to manage the payShield 9000 by using a console or
using the HSM's hardware features (see the section on HSM Hardware) are the same as
on the HSM 8000. (payShield Manager replaces HSM Manager on payShield 9000 v3.x
and later, and so users of HSM Manager on the HSM 8000 should familiarise themselves
with the operation of payShield Manager.) There are however a number of areas where
there are differences arising from enhancements made to the payShield 9000 such that
users may need to modify how they operate.
User authentication changes in payShield 9000

PIN Length
The payShield 9000 has a minimum PIN length of 5 digits for smartcards used to
authenticate users and hold LMK components. This limit is applied when a password is
set or changed: this allows continuing use of existing cards with 4-digit PINs, such that

the 5-digit requirement will only affect users when they change their PIN or create a new
card.
Authentication method
The default method of authenticating users on the payShield 9000 is by smartcards. HSM
8000 users who prefer to use password authentication will need to change their security
settings to enable this.
For users who want to operate their payShield 9000 in a PCI HSM-compliant manner will
have to use smartcard authentication, and so user procedures will need to be changed to
adopt the use of smartcards.
Host Ethernet Ports

Dual Host ports
The payShield 9000 offers two Ethernet ports compared with the HSM 8000's single port.
Where users want to take advantage of the benefits this offers, they will need to
configure both ports.
This is done by using the CH Console command or the payShield Manager Configuration /
Host Settings / Ethernet option. This is very similar to when working with the HSM 8000,
except that the user can choose whether to use 2 host interfaces and is then presented
with configurations for both. The appropriate user manuals provide further details.
Network Speed
The payShield 9000 Ethernet ports run at up to 1 Gbps, compared with 100 Mbps on the
HSM 8000. Users may need to modify their network and host configuration to take
advantage of this.
Subnet separation
The HSM 8000 allowed its management and host Ethernet ports to be configured on the
same subnet. This is still allowed on payShield 9000, but this practice is not
recommended by Thales. It is recommended that host and management Ethernet ports
are put onto different sub-nets when migrating to payShield 9000.
DHCP
DHCP is now supported, allowing the payShield 9000 to obtain its IP addresses from a
DHCP server.
DNS
DNS is now supported, allowing the payShield 9000 to be addressed using a network
name held in the user organization's DNS.

The payShield 9000 offers the facility to protect TCP/IP links between the host computer
and the HSM using TLS. (SSL is also available, but it is recommended that TLS v1.2 is
used for full compliance with the PCI DSS standard.) Users migrating from HSM 8000
may wish to make use of this capability.
Secure Host Communications is described in Chapter 14 of this manual.

Access Control Lists (ACLs)

The Access Control List capability on the payShield 9000 enables users to create a
"whitelist" of IP addresses that the HSM's host ports will accept traffic from. Users
migrating from HSM 8000 may wish to make use of this capability.
See the payShield 9000 Console Reference Manual and the payShield Manager User
Guide for information on setting up ACLs.
Diagnostics
DT Console Command
The DT console command is used on both the HSM 8000 and payShield 9000 to run a
range of self-tests. The payShield 9000 version, however, supports a "verbose" mode
that provides more detailed test results - see the payShield 9000 Console Command
Reference Manual. Users should familiarize themselves with the additional information
available on the payShield 9000.
The DT Console command has been extended in the payShield 9000 to provide additional
data relating to the health of the HSM - see the payShield 9000 Console Command
Reference Manual. When using payShield Manager, this information is available using the
Utilization Statistics and Health Statistics/Diagnostics tabs in the Status section. Some of
this data can be retrieved by the host using the J8 host command.
For further information about the payShield 9000 Health Check capabilities, see Chapter
9 of this manual.
On the payShield 9000 the DT diagnostics are run automatically every 24 hours. Users
should select the time of day that this happens to best meet their needs, using the ST
console command or the Diagnostics tab under Health Statistics/Diagnostics in the Status
section of payShield manager.
TRACERT, NETSTAT, PING

These console commands are available on both HSM 8000 and payShield 9000 to view
the resolve network questions.
The payShield 9000 implementations are more powerful than those in the HSM 8000,
and users should familiarize themselves with the parameters and switches available in
the payShield 9000 versions. See the payShield 9000 Console Command Reference
Manual for details.
Utilization Information
payShield 9000 offers the ability to monitor the loading of the HSM and which commands
are causing this loading. Data can be accessed in numeric form on the console, in
graphical form using payShield Manager, by retrieving it using host commands, or by
sending SNMP requests to the payShield 9000.
Users migrating to the payShield 9000 should familiarize themselves with this valuable
tool by looking at Chapter 8 of this manual.
Audit Log
On payShield 9000 additional information is recorded in the Audit Log and a number of
actions are always recorded, irrespective of any user settings - see Chapter 17 of this

manual. It is recommended that any user procedures relating to analysis of the Audit Log
are updated to take advantage of this.
The size of the audit log on the payShield 9000 has been increased from the 2,000
entries available on the HSM 8000 to 50,000 entries. It is suggested that documented
procedures to ensure archival of the audit log be revised to take advantage of the larger
audit log.
Configuration
Motion sensor
The payShield 9000 has a more sophisticated motion sensor than was available on the
HSM 8000. Rather than a simple on/off security setting, the payShield 9000 motion
sensor offers 3 levels of sensitivity. Documented operational procedures should be
updated to reflect this flexibility and the need to determine the optimal setting for the
environment that the HSM is operating in. More information on the motion sensor can be
found in Chapter 18.
Temperature Sensor
On the HSM 8000 it was possible to configure whether the temperature sensor should be
enabled or not. payShield 9000 enforces activation of the temperature sensor, and this is
no longer a user-selectable option. More information on the temperature sensor can be
found in Chapter 18.
Key import/export
The traditional way to exchange keys with other systems was that defined in X9.17. This
method is now considered to offer weak security, and TR-31 key blocks have been
introduced in the payShield 9000 (and later versions of HSM 8000) as a better solution,
and the default security settings on the payShield 9000 reflect this. However, most users
still work with X9.17, and as a result will need to change the following default security
settings in order to be able continue working with X9.17:
 Enable X9.17 for import: by default this is not set and should be set to enable use
of X9.17.
 Enable X9.17 for export: by default this is not set and should be set to enable use
of X9.17.
 Key export and import in trusted format only: the is set by default and should be
unset to enable use of X9.17.
Authorization
Multiple authorized states
This enhancement, not available in earlier versions of HSM 8000 software, enables
authorization of host and console commands to be controlled in a granular fashion. Prior
to the introduction of this capability, Authorization was turned on or off on an "all or
nothing" basis.
If users wish to take advantage of multiple authorized states, changes will be required in
operational procedures to ensure that only the required authorizations are applied, and
time-limited as appropriate. Users migrating from HSM 8000 and using the "all or
nothing" authorization method can continue to do so, by unsetting Enable multiple
authorised activities security setting: the default is for this to be set.

Capped duration of Console authorizations

payShield 9000 can implement a time limit of 12 hours on how long console commands
can be authorized for to meet the needs of PCI HSM certification. Unless this limitation is
disabled in the security settings (which makes the HSM non-compliant to the PCI HSM
standard) any user procedures relying on longer or permanent authorization of console
commands will need to be amended.
This change does not affect host commands, or operation of payShield Manager.
LMKs
Transferability of existing LMKs
LMKs in use on HSM 8000 can continue to be used on the payShield 9000. The LMKs can
be loaded onto the payShield 9000 from the same LMK cards that are used on the HSM
8000.
The migration from HSM 8000 to payShield 9000 does not require any change to LMKs or
associated procedures, but users may wish to take advantage of the following
enhancements which are available.
Multiple LMKs
The multiple LMK facility is not available in with earlier versions of HSM 8000. It enables
an HSM, through the purchase of appropriate optional licenses, to run multiple LMKs
managed by different security officers, providing separation between purposes,
applications, and clients. Later versions of the HSM 8000 allowed up to 10 LMKs to be
installed: the payShield 9000 allows up to 20 LMKs to be installed.
Users moving from the HSM 8000 to the payShield 9000 may wish to take advantage of
its extended multiple LMK capability. If they do, they will need to change their
operational procedures and use of host commands by their host applications. There are
also changes to console commands where the target LMK needs to be identified.
For further information see Chapter 9 of the payShield 9000 Host Programmer's Manual.
Key Block LMKs

Most HSM 8000 users are deploying the double-length TDES variant type of LMK. In the
payShield 9000 and later versions of HSM 8000, Thales introduced, as an option, a key
block type of LMK, which introduces security advantages. Users wishing to take
advantage of key block LMKs will need to make changes to their host applications to use
key block LMKs - see Chapter 8 of the payShield 9000 Host Programmer's Manual.
Performance
Throughput
The highest performance model (in terms of throughput of the CA host command for PIN
Block translations) available on the HSM 8000 was 800 tps (transactions per second).
The payShield 9000 offers the same performance models as the HSM 8000, and in
addition introduces a 1,500 tps model. Users may wish to review the performance
models they use to achieve optimum price-performance.
As on the HSM 8000, full performance on the payShield 9000 is only achieved when
multiple threads are used with Ethernet interfaces (or multiple connections used with
FICON). Maximum performance is generally achieved by using 4-8 threads (depending

on the performance model and command being used). Users moving to payShield 9000
are advised to use multiple threads where maximized throughput is a requirement: the
payShield 9000 supports up to 64 threads on each of its Ethernet ports.
Users making heavy use of RSA may wish to acquire the RSA Booster License for the
payShield 9000 which significantly boosts the performance of RSA operations.
Latency
Latency for host command processing is much more predictable on the payShield 9000
than on the HSM 8000. Users with host applications which are sensitive to latency (e.g.
to comply with SLAs) should evaluate the improvements available in the payShield 9000
to understand any beneficial impact on their host systems.
Using the Audit Log

The Audit Log capacity on the payShield 9000 is 50,000 records, compared to 2,000
records on the HSM 8000.
Every time that an auditable event is encountered, a record has to be written to the
HSM's non-volatile memory, and when the Audit Log is filled the audit log has to be
"rolled over" to discard the oldest record and add the newest: this takes longer with a
larger Audit Log.
This will generally not have a noticeable impact on performance, but the effect will
become significant if the user has decided to audit frequently used host commands -
especially if the Audit Log is allowed to become full.
Startup Time
The payShield 9000 boots up much faster than the HSM 8000 - about 20 seconds instead
of 2-3 minutes. Operators may need to be reminded that they will no longer have time to
fetch a cup of coffee while the HSM is booting up!
payShield Manager
HSM 8000 users who have been managing their HSM using the Console may wish to take
advantage of the benefits of payShield Manager when migrating to payShield 9000. Such
users will need to commission their payShield Manager environment, and they will need
to purchase the appropriate licenses if they wish to use payShield Manager remotely.
Users who have been using HSM Manager with their HSM 8000 will also need to
commission payShield Manager and purchase Remote payShield Manager licenses (if this
option is required). Remote HSM Manager from the HSM 8000 cannot be used on or
migrated to payShield Manager on the payShield 9000.
LMK component cards used with the smartcard reader on the HSM 8000 can be migrated
to LMK component cards that can be used with payShield Manager.
For further information see the payShield Manager User Guide.
Withdrawn Console Commands

The following Console commands are not relevant to the payShield 9000 and are
therefore not available:

HSM 8000 Console Command Replaced in payShield 9000 by

CA Configure Auxiliary port for use CP Configure printer port
with a serial printer
QA View Auxiliary port configuration QP View printer port configuration
DB Import a KML IK Import Key
DF Import a BDK IK Import Key
K Encrypt a Key Under LMK Variants FK Form Key from Components
14-15
YC Import a CSCK IK Import Key
Table 2: Console commands withdrawn in payShield 9000
Any user procedures which utilize the withdrawn commands should be amended to use
their replacements.
Custom Software
What is custom software?
Custom software is software which has been modified from the standard base software
by Thales, typically for an individual user. It is developed against a specified version of
the base software, and includes the functionality of that base software plus the additional
customization requested (which may involve removal of some functionality). HSM 8000
customized software is any software where the software revision (as reported in the VR
console command or the HSM Manager View / HSM Information option) is not one of the
following:
 1001-08xx
 1053-08xx
 1110-08xx
Is the customization still required?

A lot of functionality that in the past was available only as customization is now included
in the base software. It is suggested that users migrating to payShield 9000 check
whether the functionality for which customization was previously required is now included
in the base payShield 9000 software.
Even if the customized functionality is not available in the standard base software, it
would be worthwhile confirming that it is still required. If it is not, it may be possible to
use base software, or the cost of porting the software to payShield 9000 could be
reduced.
Ordering ports to payShield 9000

Custom software written for the HSM 8000 can be ported to run on the payShield 9000.
This is significantly easier than was the case when migrating from RG7000 to HSM 8000,
especially for custom software written to run with later versions of HSM 8000 base
software.
Where an HSM 8000 user has custom software which they wish to port to the payShield
9000 they should contact their representative of Thales or the authorized partner that
they acquired their payShield 9000 through.

Inclusion of base functionality enhancements

Note that when custom software is ported, it acquires the changes introduced in the base
software since the original customization was developed - such as utilization and health
check reporting, multiple LMKs, and key block LMKs for base commands. (Note that key
block LMKs will not be available for customized commands unless this extension to
customized commands is specifically ordered.)
PCI PTS HSM Certification
Background
PCI have introduced the PCI HSM security standard for payment HSMs. It is expected
that this standard will be mandated by the card schemes at some point, but, as such
mandates will not apply to HSMs already in use, there is no need for the HSM 8000 to be
PCI HSM certified.
However, the mandates will apply to future sales of the payShield 9000, and so Thales
has successfully put the payShield 9000 and selected versions of its software through the
certification process.
Software changes implemented in the payShield 9000

A number of software changes required for PCI HSM compliance have been introduced in
the payShield 9000. Some of these changes will cause the operation of the payShield
9000 to be different to the HSM 8000, and so may require changes in procedures. The
relevant changes are:
 Minimum PIN length of 5 digits for user authentication
 Automated self-tests
 Audit log enhancements
In addition, there are some software changes which can be switched on (for compliance
with PCI HSM) or off (for backwards compatibility) using payShield 9000 security settings
– see the next sub-section.
Security Settings
Using certified hardware and software is not sufficient to ensure PCI HSM compliance of
the payShield 9000.
When users wish to operate their payShield 9000 in a PCI HSM compliant manner, they
will need to change some security settings relating to:
 User authentication by smartcard only (password not allowed)

 Restrictions in PIN Block formats
 Key type changes
 Enforcement of time limitation on console command authorization
 Enforcement of multiple key components
Use of the compliant settings will result in the payShield 9000 operating in a different
way from non-compliant payShield 9000s and HSM 8000s. The differences are the same
irrespective of whether the user was previously using non-compliant payShield 9000 or
HSM 8000.

If a user migrates from HSM 8000 to non-compliant payShield 9000 implementation then
these differences will not have any impact. However, if a user migrates from HSM 8000
directly to a PCI HSM compliant payShield 9000 environment then they will be affected
by the changes required for compliance.
Further information
For further information see Chapter 10 of this manual.

Chapter 21 – Information for

Security Auditors
Introduction
This chapter identifies formal certifications and other supporting material which will assist
security auditors when auditing installations involving payShield 9000 HSMs.
FIPS 140-2
The TSPP (Thales Secure Processing Platform – the secure cryptographic module in the
payShield 9000) has been certified at Level 3 of the FIPS 140-2 security standard.
For all vendors' HSMs being used for card payment and issuance applications, the HSM's
application software is not included in the certification and the HSM is operating outside
of its FIPS certificate when performing any payment card functions. This information is
included in the Security Policy associated with each HSM's FIPS certificate. The PCI HSM
certificate may be of more value as this certification includes all of the software running
on the HSM.
The payShield 9000's FIPS certificate is available online at the NIST website at (see
Cert# 1322):
http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm
PCI HSM
payShield 9000 hardware and specific software versions are certified to the PCI HSM
standard. Any customized software must be separately certified, as it is not covered by
the certification for the base software that it is based on.
The certificate is available only online on the PCI website at:
https://www.pcisecuritystandards.org/popups/pts_device.php?appnum=4-40069
The certificate identifies specific hardware and software (i.e. firmware) versions which
are covered by the certificate.
See Chapter 10 for more information how the PCI HSM standard applies to the payShield
9000 and the conditions required for compliance with the standard.
APCA (Australian Payments Clearing Association)

The payShield 9000 and specific versions of base software have been approved by APCA.
The approved hardware and software (firmware) can be found on the APCA website at:
http://pub1.apca.com.au/ExtraNet/CS3AppDevices.nsf/wApprovedSeries?open&count=2
000&restrictToCategory=SECURITY%20CONTROL%20MODULES
The operation of the payShield 9000 as an APCA-compliant device is described in

1270A547 payShield 9000 Host Command Reference Manual Addendum for License
LIC003 (Australian AS2805 Commands), which is part of the payShield 9000 manuals
set.

MEPS (Methode d'Evaluation des Produits Securitaire

"bancaires")
Products intended for use on the banking networks in France are submitted for
evaluation by Groupement des Cartes Bancaires. This involves the submission of detailed
design documentation and other information about the security mechanisms
implemented. The payShield 9000 with a modified version of software (1327-09xx) has
been certified under MEPS. Users needing information about MEPS approval should
approach their Thales representative or authorized partner.
GBIC (German Banking Industry Committee) / ZKA

(Zentraler Kreditausschuss)
GBIC was formerly referred to as ZKA. Systems processing German domestic cards must
be approved under GBIC. There is no certification process for individual components such
as HSMs, but these components are evaluated as part of the system. Successful
evaluation of an HSM for one system applies only to that system and is not transferrable
to another system: the HSM must be re-evaluated for each system which is to be
certified.
The payShield 9000 has been successfully evaluated as part of a number of systems.
ISO 13491 (Financial services - Secure cryptographic

devices (retail))
ISO 13491 compliance is required to meet certain other standards such as ISO 9564,
which is in turn a requirement for other standards such as PCI PIN Security. There are no
certification processes for these ISO standards, but Thales have commissioned a report
from an independent evaluation laboratory indicating the compliance of payShield 9000
with ISO 13491. If required, a copy of this report can be obtained from Thales e-Security
Product Management group via your Thales representative or authorized partner.
SP800-22
SP800-22 is defined as "A Statistical Test Suite for Random and Pseudorandom Number
Generators for Cryptographic Applications". It is a methodology used in confirming the
quality of random number generators: it is not a standard, does not define required
results, and cannot be certified against. SP800-22 is used by Thales engineering when
implementing random number generators, and by evaluation laboratories when
approving devices such as HSMs.
Thales have commissioned a report from an independent evaluation laboratory indicating
that random number generation in the payShield 9000 is of an appropriate standard
when evaluated using the methodology in SP800-22. If required, a copy of this report
can be obtained from Thales e-Security Product Management group via your Thales
representative or authorized partner.

Chapter 22 – The Key Management

Device (KMD)
Introduction
Secure key management is crucial to the security of the system in which the payShield
9000 is used. One particular area of importance is the exchange of symmetric encryption
keys between parties in the payment network (such as an Acquirer and a Switch) who
need to exchange data securely. There is a large number of such keys, and these need to
be refreshed regularly, and so there is a frequent need to exchange working keys
between parties. In order to protect these keys while they are being exchanged
electronically, the working keys are encrypted by a master key (such as a Zone Master
Key, or ZMK).
The master key still needs to be provided by one party to the other, and this transfer
also has to be secured. However, master keys need to be transferred only infrequently,
and so a less automated mechanism is acceptable. In general the institution providing
the master key will issue it in the form of a number (typically 3) of components to
different officers in the receiving institution, and these officers will come together and
enter their components individually into a secure system such as an HSM. In the case of
the payShield 9000, it will form the master key from those components and output the
master key encrypted under an LMK: the encrypted master key is then loaded into the
institution's key database.
A standard approach that many institutions use is to have a standalone payShield 9000
which is used for key management functions such as this. This unit has the same LMK
installed as the production units to enable it to encrypt the master key such that it can
be used by the production HSMs.
However, there are two issues with this:

 the cost of having an HSM dedicated to this purpose;
 having a key management HSM with the same LMK as the production HSMs
contravenes PCI security standards, in particular the PIN Security Standard; and
 the use of a keyboard for the entry of cleartext components does not meet the
requirements of security audits, in particular TR-39 in the United States.
The Thales Key Management Device (KMD) solves these issues.
This chapter provides an outline of the operational design and features of KMD version
1.1. Detailed information on using the KMD can be found in the Key Management Device
for the payShield 9000 User Guide and security advice is provided in Key Management
Device for payShield 9000 Security Operations Manual.
The KMD
The KMD hardware consists of a secure cryptographic device manufactured by Verifone.
This offers a number of features, of which the most important ones for the KMD are:
 secure, certified hardware;

 smartcard reader;
 touch screen, avoiding the use of a keyboard.

The Thales Key Management Device.
The KMD has dimensions of 153mm H x 192mm W x 57 mm D, and it weighs 0.77 Kg.
The KMD functionality is provided by the installation of Thales software on the hardware.
This functionality provides:
 the security environment,

 administration capabilities, and
 the ability to form encrypted keys from cleartext components.
The KMD Transport Key (KTK)

The KMD encrypts the keys it forms under a KTK: the formed keys are never provided as
cleartext. The KTK-encrypted keys can then be transported to a payShield 9000 which
has the same KTK where it can be translated to encryption under an LMK.
The KTK is a double-length TDES key with the same variants and supporting the same
key types as a payShield 9000 LMK.
Up to 20 KTKs can be stored in a KMD.
Users and Roles

Each user has a KMD smartcard which identifies their roles and privileges.
The KMD supports two types of role:

1. Administrators: the role is linked to a specific KTK. The only function of the
Administrator is to assign Operators for their KTK.
2. Operators: the role is linked to a specific KTK. Operators manage and use the
KMD. Operator roles are assigned to one of two groups – A and B. In order to
perform any function, an Operator from each of Group A and Group B must be
present and have privileges for the KTK being used. One user cannot have
Group A and Group B roles for the same KTK, but can have a Group A role for
one KTK and a Group B role for a different KTK.
Outline of KMD operations

1. A KTK is created as a set of components written to standard payShield 9000
smartcards using the KM console command at a payShield 9000. At least 2
(but usually 3) components must be generated.
2. The KTK is installed into one or more payShield 9000s using the KN console
command. Multiple KTKs can be installed on each HSM.
3. The KTK is loaded into the KMD from component smartcards by the
component holders. Up to 20 KTKs can be installed on one KMD.
4. Users with the Administrator role are assigned to the KTK at the KMD.
Administrators are assigned on an N of M basis, i.e.
 M is the number of Administrators assigned to the KTK. Between 2 and

9 Administrators can be assigned to each KTK (2  M  9).
 N is the quorum of Administrators that must be present when
assigning an Operator role (2  N  M).
5. The Administrators at the KMD assign users with Group A and B Operator roles
to the KTK.
6. KMD Group A and B Operators initiate the process to form a key. The
component holders enter their components into the KMD's touchscreen.
7. The KMD outputs the formed key, encrypted under the KTK, to its screen.
8. The KTK-encrypted key is recorded and entered into a payShield 9000 at the
console.
9. The KTK-encrypted key is translated to an LMK-encrypted key at a payShield

9000 which is a member of the production group of HSMs by using the:
 KK console command, or
 HY host command.
Detailed information about the commands referenced above can be found in the
payShield 9000 Console Reference Manual and the payShield 9000 Host Command
Reference Manual. Activities at the KMD are described in the Key Management Device for
the payShield 9000 User Guide.

Appendix A – Error Log Codes

General
The error log lists each error with a severity, an error code and a sub-code. The error log
only contains the numerical part of the error code and sub-code. Sub-codes relate to a
specific error code.
This Appendix describes the Error Log as viewed when using the Console. When viewing
the Error log using payShield Manager please refer to the payShield Manager User's
Guide.
The text below will make use of the following example of an error log entry:
Description
The error description is contained within a pair of square brackets:

The meaning of some of these descriptions will be obvious (e.g. "[Power Supply:
FAILED (PSU 2 Failed) ]", whereas the full meaning of some messages will require
interpretation by Thales.
Severity
A severity level is provided by the error message:
The meaning of the severity level is given in the following table:
No. Code Meaning

0 LOG_EMERG System is unusable.
1 LOG_ALERT Action must be taken immediately.
2 LOG_CRIT Critical conditions.
3 LOG_ERR Error conditions.
4 LOG_WARNING Warning conditions
5 LOG_NOTICE Normal but significant condition.
6 LOG_INFO Informational.
7 LOG_DEBUG Debug-level message.
Error Codes
The error log entry includes a main error code:
The main error code indicates the general source of the error, as per the following table:

No. Shown as … Code Meaning

1 0x00000001 LS_UTIL Utility system
2 0x00000002 LS_CRYPTO Cryptographic system
3 0x00000003 LS_APP Application system
4 0x00000004 LS_KEYMGR Key Manager system
5 0x00000005 LS_ENCFS Encrypted File System
Sub-Codes
The error log entry also includes a sub-code to provide a more detailed source of the
error:
The value of sub-codes depends on the value of the main error code, as described in the
tables below. A value of 0x00000000 indicates that a more detailed sub-code is not
appropriate.
Sub-Codes for Main Error Code = 1 (Utility System Errors)

No. Shown as … Sub-code Meaning
1 0x00000001 LSS_UTIL_CONFIG Configuration utility sub-system
2 0x00000002 LSS_UTIL_UNUSED Deprecated (was Encrypted File utility sub-
system)
3 0x00000003 LSS_UTIL_I2C I2C utility sub-system
4 0x00000004 LSS_UTIL_INCOMINGD Incoming daemon utility sub-system
5 0x00000005 LSS_UTIL_LED LED utility sub-system
6 0x00000006 LSS_UTIL_NAMESPACE Namespace utility sub-system
7 0x00000007 LSS_UTIL_PATCH Program patch utility sub-system
8 0x00000008 LSS_UTIL_PROC Process manager utility sub-system
9 0x00000009 LSS_UTIL_PSHAPE Performance shaping utility sub-system
10 0x0000000A LSS_UTIL_SMARTCARD Smartcard utility sub-system
11 0x0000000B LSS_UTIL_SPARTAN Spartan FPGA management utility sub-
system
12 0x0000000C LSS_UTIL_SWITCH User switch (push-button & keylock) utility
sub-system
13 0x0000000D LSS_UTIL_SYSID System ID utility sub-system
14 0x0000000E LSS_UTIL_UPDATER System update utility sub-system
15 0x0000000F LSS_UTIL_SHMEM Shared memory utility sub-system
16 0x00000010 LSS_UTIL_LICENSING License management utility sub-system
17 0x00000011 LSS_UTIL_SCR Smartcard Reader utility sub-system
18 0x00000012 LSS_UTIL_EEPROM Resident configuration utility sub-system
19 0x00000013 LSS_UTIL_MEM Memory utility sub-system
20 0x00000014 LSS_UTIL_EVENT Event manager utility sub-system
21 0x00000015 LSS_UTIL_THREADPOOL Thread-pool manager utility sub-system
22 0x00000016 LSS_UTIL_COOKIE Cookie manager

Sub-Codes for Main Error Code = 2 (Cryptographic System Errors)

1 0x00000001 LSS_CRYPTO_DES DES cryptographic sub-system
2 0x00000002 LSS_CRYPTO_RNG Random number generator cryptographic
sub-system
3 0x00000003 LSS_CRYPTO_SHA SHA cryptographic sub-system
4 0x00000004 LSS_CRYPTO_SEC Security engine cryptographic sub-
system
5 0x00000005 LSS_CRYPTO_RMAPI Resource management API cryptographic
sub-system
6 0x00000006 LSS_CRYPTO_RM_SEC Resource management security engine
cryptographic sub-system
7 0x00000007 LSS_CRYPTO_RM_SW Resource management software
cryptographic sub-system
8 0x00000008 LSS_CRYPTO_RSA RSA cryptographic sub-system
9 0x00000009 LSS_CRYPTO_BIGINT Big integer cryptographic sub-system
10 0x0000000A LSS_CRYPTO_ESS ESS API cryptographic sub-system
11 0x0000000B LSS_CRYPTO_AES AES cryptographic sub-system
12 0x0000000C LSS_CRYPTO_HASH Hash cryptographic sub-system
Sub-Codes for Main Error Code = 3 (Application System Errors)

1 0x00000001 LSS_APP_DIAG Diagnostic application sub-system
2 0x00000002 LSS_APP_AUTH Authorization application sub-system
3 0x00000003 LSS_APP_LMK LMK application sub-system
4 0x00000004 LSS_APP_COMMS Communications (TCP, UDP, Async,
FICON) application sub-system
5 0x00000005 LSS_APP_GENERAL General application sub-system
6 0x00000006 LSS_APP_AUDITLOG Audit log application sub-system
7 0x00000007 LSS_APP_CONFIG Configuration application sub-system
8 0x00000008 LSS_APP_CONSOLE Console application sub-system
9 0x00000009 LSS_APP_HOSTCMD Host command application sub-system
10 0x0000000A LSS_APP_PINBLOCK PIN block application sub-system
11 0x0000000B LSS_APP_USRSTORE User storage application sub-system
12 0x0000000C LSS_APP_CHIPCARD Chip card application sub-system
13 0x0000000D LSS_APP_DES DES application sub-system
14 0x0000000E LSS_APP_FRAUD Fraud application sub-system
15 0x0000000F LSS_APP_KEYBLOCK Key Block application sub-system
16 0x00000010 LSS_APP_KEYMAN Key manager application sub-system
17 0x00000011 LSS_APP_MAC MAC application sub-system
18 0x00000012 LSS_APP_MGMT payShield Manager application sub-
system
19 0x00000013 LSS_APP_PARSE Parsing application sub-system


20 0x00000014 LSS_APP_PRINT Printing application sub-system
21 0x00000015 LSS_APP_RSA RSA application sub-system
22 0x00000016 LSS_APP_VISA Visa application sub-system
23 0x00000017 LSS_APP_VPN VPN for remote management application
sub-system
24 0x00000018 LSS_APP_X509CERT X.509 certificate application sub-system
25 0x00000019 LSS_APP_STATE System state application sub-system
26 0x0000001A LSS_APP_POWER Power management application sub-
system
27 0x0000001B LSS_APP_STORAGE Storage application sub-system
28 0x0000001C LSS_APP_COMMANDS Command processing application sub-
system
29 0x0000001D LSS_APP_DIGEST Digest application sub-system
30 0x0000001E LSS_APP_LICENSE Licensing application sub-system
31 0x0000001F LSS_APP_UTILIZATIO Utilization application sub-system
N
32 0x00000020 LSS_APP_SNMP SNMP application sub-system
Sub-Codes for Main Error Code = 4 (Key Manager System Errors)

There are currently no sub-codes.
Sub-Codes for Main Error Code = 5 (Encrypted File System Errors)

There are currently no sub-codes.
Multiple Entries
A single cause may result in multiple entries being made in the error log. The following
example arises from a triggering of the temperature alarm, which initiates a tamper
condition:
----------------------
1: Nov 30 00:43:18 ERROR: [Tamper(1) Latched at [2000/00/00, 00:42:57]]
3: Nov 30 00:43:18 ERROR: [ Tamper LR1 [0x0004 = Temperature exceeded
maximum operational range]] (Severity: 2, Code = 0x00000004, Sub-Code =
0x00000000)
5: Nov 30 00:43:40 ERROR: [Tamper(2) Latched at [2000/00/00, 00:43:19]]

7: Nov 30 00:43:41 ERROR: [ Tamper LR1 [0x0004 = Temperature exceeded

0x00000000)
9: Nov 30 00:43:41 ERROR: [ Tamper CR1 [0x0004 = Temperature exceeded
0x00000000)
10: Nov 30 00:43:41 ERROR: [ Tamper CR2 [0x8000 = DS3640 TEI asserted]]
11: Nov 30 00:43:41 ERROR: [Tamper State is 0x0004 and retry count
exceeded (2)] (Severity: 2, Code = 0x00000004, Sub-Code = 0x00000000)
12: Nov 30 00:43:47 ERROR: [Temperature: FAILED - temperature too high
] (Severity: 3, Code = 0x00000001, Sub-Code = 0x0000000E)
The messages show that a tamper event occurred and is still ongoing. The value of
"0x0004" for the LR1 and CR1 elements indicate that the tamper cause was the
temperature rising above the maximum acceptable level; a value of "0x0002" would
have indicated a temperature that was too low.

Appendix B – Core HSM Commands

The following list of commands consists of "core" payShield 9000 HSM commands which
cannot be disabled.
Console Host
CL – Configure the Alarms BS – Erase the Key Change Storage
QL – Query the Alarm Configuration RA – Cancel the Authorize Activity state
CC – Configure the Console Port LG – Set HSM Response Delay
QC – Query the Console Port NC – Perform Diagnostics and Obtain
Configuration LMK Check Value
CS – Configure Security NO – Return HSM Status Information
QS – Query the Security Configuration
CP – Configure the Printer Port
QP – Query the Printer Port Configuration
CM – Configure the Management Port
QM – Query the Management Port
Configuration
CH – Configure the Host Port
QH – Query the Host Port Configuration
LK – Load new LMK
LO – Load 'Old' LMK into Key Change
Storage
LN – Load 'New' LMK into Key Change
Storage
V – Verify LMK
DC – Duplicate LMK Components
A – Enter Authorize Activity state
C – Cancel Authorize Activity state
VR – Display Version Information
GETCMDS – View the Available Host
Commands
ERRLOG – View Error Log
CLEARERR – Clear Error Log
AUDITLOG – View Audit Log
CLEARAUDIT – Clear Audit Log
AUDITOPTIONS – Select Audit Options
SETTIME – Set the time & date
GETTIME – Get the time & date
SS – Save Settings to Smartcard
RS – Retrieve Settings to Smartcard
DT – Diagnostic Test
N – Single-length DES calculator
$ – Double-length DES calculator
T – Triple-length DES calculator
FC – Format Smartcard
CO – Copy Authorizing Officer Smartcard
VC – Verify Smartcard
NP – Change Smartcard PIN
RC – Read Unidentifiable Smartcard

Console Host
Details
EJECT – Eject a Smartcard
CONFIGCMDS – Configure Commands
CONFIGPB – Configure PIN Blocks

Appendix C – Key Scheme Table

This Appendix has been moved to the payShield 9000 Host Programmer's Manual.

Appendix D – List of Authorizable

Activities
The following table indicates, for each sensitive host or console command, which activity
needs to be authorized. Note that the authorization requirements may differ depending
on whether a Variant or Key Block LMK is used.
Examples:
 Authorizing the activity export.001.host allows export of ZPKs using a host

command (e.g. A8).
 Authorizing the activity export allows export of any (valid) key using a host or
console command.
 Authorizing the activity export..console allows export of any (valid) key using a
console command.
Note: When using a Variant LMK, the key type table determines whether the HSM needs
to be authorized in order to generate, import or export a certain key. Where the key type
table entry indicates 'U' (unconditional), it is not necessary to authorize the HSM for that
activity. Moreover, authorized activities genprint.* and component.* do not examine
the KTT and are always required.
The following table defines a number of 'groups' which, in turn, contain a set of either
key types or key usages. These groups are subsequently referenced in the tables further
below.
Group Contents
generate key 000 200 001 002 402 003 006 008 009 109 209 309 409 509
types 709 00a 00b 70d 80d 90d
Variant LMK
genprint key 000 200 001 002 402 003 006 008 009 109 209 309 409 509
types 709 00a 00b 70d 80d 90d
component key 000 200 001 002 402 003 006 008 009 109 209 309 409 509
types 709 00a 00b 70d 80d 90d
export key 200 001 002 402 003 006 008 009 109 209 309 409 509 709
types 00a 70d 80d 90d
genprint key 01 B0 C0 11 12 13 D0 21 22 E0 E1 E2 E3 E4 E5 31 32
usages K0 51 52 M0 M1 M3 P0 71 72 73 V0 V1 V2
Key Block LMK
component key 01 B0 C0 11 12 13 D0 21 22 E0 E1 E2 E3 E4 E5 31 32
usages K0 51 52 M0 M1 M3 P0 71 72 73 V0 V1 V2
export key 01 B0 C0 11 12 13 D0 21 22 E0 E1 E2 E3 E4 E5 31 32
K0 51 52 M0 M1 M3 61 62 63 64 65 P0 71 72 73 V0 V1
usages V2
import key 01 B0 C0 11 12 13 D0 21 22 E0 E1 E2 E3 E4 E5 31 32
K0 51 52 M0 M1 M3 61 62 63 64 65 P0 71 72 73 V0 V1
usages V2

Command
Sub- Inter-
(H=Host, Description Category
Category face
C=Console)
SYMMETRIC KEY GENERATION
H – A0 Generate Key host
C – KG Generate Key 000

console
Generate Zone Master Key and Write to
Variant LMK
C – GZ
Smartcards
Generate Key Check Value generate
H – BU host
(for Key Check Values > 6 digits) generate
Generate Key Check Value key types
C – CK console
(for Key Check Values > 6 digits)
H – FG Generate a Pair of PVKs 002 host
SYMMETRIC KEY GENERATION / PRINTING

Key Block LMK
H – A2 Generate and Print Component

genprint
genprint host
key usages
H – NE Generate and Print Key as Split Components
H – A2 Generate and Print Component

genprint
Variant LMK
key types
H – NE Generate and Print Key as Split Components
genprint host
H – OC Generate and Print ZMK component 000
H – OE Generate and Print TMK, TPK or PVK 002
SYMMETRIC KEY COMPONENT MANIPULATION
H – A4 Form a Key from Encrypted Components host

Key Block LMK
C – EC Encrypt Clear Component
C – FK Form Key from Components component component

key console
C – GS Generate Key Components and Write to a usages
Smartcard
C – GC Generate Key Component
H – GG Form ZMK from Three ZMK Components
H – GY Form ZMK from 2 to 9 ZMK Components 000 host
H – A4 Form Key from Encrypted Components

Variant LMK
C – BK Form Key from Components
C – EC Encrypt Clear Component component
C – FK Form Key from Components component

console
key types
C – GS Generate Key Components and Write to a
Smartcard
C – GC Generate Key Component

C – DE Form ZMK from Clear Components
C – D Form ZMK from Encrypted Components 000
C – Z Encrypt clear ZMK Component
SYMMETRIC KEY IMPORT
H – BY Translate (Import) ZMK from ZMK to LMK K0 52 host

Key Block LMK
Encryption (from non-key block format)

import
H – A6 Import Key (from non-key block format) import key host
usages
H – LU Import HMAC Key (from non-key block 10C host

format)
Variant LMK
H – FC Translate (Import) TMK, TPK or PVK from ZMK 002

to LMK Encryption
import host
H – BY Translate (Import) ZMK from ZMK to LMK 000
Encryption
SYMMETRIC KEY EXPORT
H – A0 Generate Key (when requested to export

export
generated key to non-key block format) key
Key Block LMK
H – A8 Export Key (to non-key block format) usages host
61 62 63
H – LW Export HMAC Key (to non-key block format) export 64 65
C – KG Generate Key (when requested to export

export
generated key to non-key block format)
key console
C – KE Export Key (to non-key block format) usages
H – A0 Generate Key (when requested to export

generated key) export
key types
H – A8 Export Key
host
H – FE Translate (Export) TMK, TPK or PVK from LMK 002
Variant LMK
to ZMK Encryption
H – LW Export HMAC Key export 10c
C – KG Generate Key (when requested to export

generated key) export
key types
C – KE Export Key console
C – WK Translate (Export) Zone PIN Key 001
ASYMMETRIC KEY MANAGEMENT
Generate a Public/Private Key Pair

Key Block
H – EI generate rsa
LMK
host
H – EO Import a Public Key import rsa-pk
H – EI Generate a Public/Private Key Pair generate rsa

Variant
LMK
host
H – EO Import a Public Key import rsa-pk

CLEAR PIN
H – BA Encrypt a Clear PIN

pin clear host
H – NG Decrypt an Encrypted PIN
PIN MAILER
H – PE Print PIN/PIN Solicitation Data

pin mailer host
H – OA Print a PIN Solicitation Mailer
AUDIT
H – Q6 Delete Audit Record host
C – CLEARAUDIT Clear the Audit Log

audit
C – AUDITOPTIONS Audit Options
console
C – A5 Configure Fraud Detection
C – A7 Re-enable PIN Verification
ADMINISTRATION
C – DM Delete LMK
C – SS Save HSM Settings to a Smartcard
C – RS Retrieve HSM Settings from a Smartcard

admin console
C – LO Load 'Old' LMK into Key Change Storage
C – LN Load 'New' LMK into Key Change Storage
C – SETTIME Set the Time and Date
DIAGNOSTICS
H – KQ ARQC (or TC/AAC) Verification and/or ARPC

Generation
H – K2 Verify Truncated Application Cryptogram (CAP)
H – KW ARQC (or TC/ACC) Verification and/or ARPC

Generation (EMV4.1 including CCD) host
diag
H – KS Data Authentication Code and Dynamic Number
Verification
H – PM Verify a Dynamic CVV
C - Display Health Check counters. (Authorization

HEALTHSTATS required only to Reset the counters.) console
MISCELLANEOUS
H – B0 Translate Key Scheme

host
misc
H – CS Modify Key Block Header
C – R Load the Diebold Table console

C – CV Generate a VISA Card Verification Value
C – PV Generate a VISA PIN Verification Value
C – TD Translate Decimalisation Table
C – ED Encrypt Decimalisation Table
C – MI Generate a MAC on an IPB
COMMAND
H – GI Import DES Key (Auth required if backward gi

compatibity mode is enabled by console CS)
H – TA Print TMK Mailer command ta host
C – IK Import Key ik

Appendix E – Reduced Character

Sets

Appendix F – Thales Key Block /

TR-31 Key Usage Conversion

Appendix G – Glossary
Term Description
Account Number See Primary Account Number
Acquirer An institution (frequently a financial institution) that
manages terminals and switches on-line payment
transactions to the Card Issuer for authorization and
verification
Acquirer Working Key Visa terminology for a Zone PIN Key, specifically one
used to encrypt a PIN block between an Acquirer and
Visa; abbreviated to AWK
Advanced Encryption Cryptographic algorithm, standardized in FIPS 197,
Standard that uses a 128-, 192- or 256-bit key; abbreviated to
AES
ANSI X9.17 A highly influential ANSI standard defining how
symmetric keys should be managed; now withdrawn
and generally regarded as inadequate from a security
perspective
Application Authentication A particular type of Application Cryptogram used in
Cryptogram EMV transactions, specifically for declined transactions;
abbreviated to AAC
Application Cryptogram EMV terminology for a Message Authentication Code;
often abbreviated to AC
Asymmetric Algorithm Generic term for a cryptographic algorithm in which
the decryption key cannot be feasibly deduced from
knowledge of the encryption key, and hence the
encryption key can be made public, whereas the
decryption key must remain secret; examples include
RSA, DSA
Atalla Part of the HP group of companies and supplier of
Hardware Security Modules
Atalla Variant A mechanism to modify a Transport Key, so that
different types of key are encrypted under different
variants of the Transport Key; required when
exchanging keys with Atalla security modules
Australian Transaction Key A specific type of Transaction Key Scheme,
Scheme standardized in AS2605.6.2; often abbreviated to
ATKS
Authentication Parameter A value used in the Racal and Australian Transaction
Key Schemes that "proves" the Issuer's involvement in
the transaction; usually denoted Auth Para (or AP)
Authorization Request A Message Authentication Code generated by an EMV
Cryptogram card using a key derived from a specific Card Master
Key and included in a request message sent to the
Card Issuer; abbreviated to ARQC
Authorization Response A transaction response code generated by a Card
Code Issuer and included in the generation of an
Authorization Response Cryptogram; abbreviated to
ARC

Term Description
Authorization Response A Message Authentication Code generated by an Card
Cryptogram Issuer in response to a request message from an EMV
card; abbreviated to ARPC
Authorized Activity A mode of operation of the HSM that permits one or
more specified sensitive functions to be performed;
requires two passwords to be entered into the HSM,
either manually or (more usually) two smart cards and
PINs.
Authorized State Similar to Authorized Activity, except that Authorized
State is a "global" authorization for all sensitive
functions
Base Derivation Key A cryptographic key used to derive transaction keys
used in the DUKPT scheme; abbreviated to BDK
Card Issuer An institution (usually a financial institution) that
issues payment cards, such as debit or credit cards, to
its customers; the Card Issuer is usually involved in
the on-line authorization and verification of payment
transactions involving these cards
Card Master Keys A generic term for a family of EMV card specific keys
derived from the corresponding Issuer Master Keys
Card Security Code American Express equivalent of a Card Verification
Value; may be 3, 4 or 5 digits in length; abbreviated to
CSC
Card Security Code Key Key used to generate or verify an American Express
Card Security Code; abbreviated to CSCK
Card Verification Code MasterCard equivalent of a Card Verification Value;
abbreviated to CVC
Card Verification Key Generic term for a key used with a Card Verification
Value or a Card Verification Code generation or
verification algorithm; abbreviated to CVK
Card Verification Value A non-secret 3-digit number derived as a cryptographic
function of a card's Primary Account Number, Service
Code and Expiry Date; used by Visa to verify that
these card details have not been modified; abbreviated
to CVV
Certificate Authority A trusted party, who role is to create Public Key
Certificates; usually abbreviated to CA
Chip and PIN A colloquial name for an EMV transaction; see Europay,
MasterCard & Visa
Chip Card See Smart Card
Cipher See Cryptographic Algorithm
Cipher Block Chaining A mode of encryption, whereby blocks of data are
"chained" together during the encryption process (each
block of ciphertext is combined with the next block of
plaintext, prior to encryption of that block); for DES
this mechanism is standardized in ANSI X3.106 and for
3-DES it is standardized in ANSI X9.52; usually
abbreviated to CBC

Term Description
Cipher Feedback A mode of encryption, whereby ciphertext is "fed back"
into the encryption process to provide a form of
"chaining"; for DES this mechanism is standardized in
ANSI X3.106 and for 3-DES it is standardized in ANSI
X9.52; usually abbreviated to CFB
Ciphertext Generic term for unintelligible data that is output from
the encryption process of a cryptographic algorithm
Collision Resistance A property of a Hash Function that makes it infeasible
to find two separate messages that hash to the same
value
Component See Key Component
Cryptographic Algorithm A function that transforms data (plaintext) and a Key
to data (ciphertext) in such a way that the procedure
cannot be reversed without knowledge of the key; also
known as an Encryption Algorithm or a Cipher
Cryptographic Key Value involved in the operation of a Cryptographic
Algorithm; must be kept secret for a symmetric
algorithm and the decryption key must be kept secret
for an asymmetric algorithm
Cryptographic Zone A generic term to indicate those entities that share
common cryptographic keys; usually only two such
entities are involved
Customer PIN See Personal Identification Number
Data Authentication Code An authentication value calculated by the smart card
during an EMV transaction (MasterCard only) and
validated by the Card Issuer; abbreviated to DAC
Data Encryption Algorithm Cryptographic algorithm, standardized in FIPS 46 and
ANSI X3.92, that uses a 56-bit key; more commonly
known as the Data Encryption Standard (DES)
Data Encryption Key Generic HSM terminology for a key used for data
encryption; abbreviated to DEK
Data Encryption Standard See Data Encryption Algorithm
Decimalization Table A function that maps hexadecimal characters to
numeric characters; used in many PIN generation and
verification algorithms, including the Diebold and IBM
3624 schemes
Decryption The inverse process to Encryption, so that ciphertext is
transformed into plaintext by means of a cryptographic
algorithm and a key
Default LMK A specified LMK (when using Multiple LMKs) to provide
a backwards compatible mode of use for the HSM
Derived PIN A value derived from an Account Number and a key,
usually as an intermediate step during the PIN
generation process; also known as a Natural PIN
Derived Unique Key Per A specific type of Transaction Key Scheme, widely used
Transaction Scheme and standardized in ANSI X9.24-1; usually abbreviated
to DUKPT
Diebold PIN Generation Proprietary PIN generation and verification algorithm,
Algorithm invented by Diebold and supported by the HSM;
nowadays this scheme is rarely used

Term Description
Diebold Table A 256 byte data structure used with the Diebold PIN
Generation Algorithm, and stored in the HSM User
Storage
Digital Signature A cryptographic checksum, appended to a message
and used by the recipient of the message to detect
whether the message has been corrupted during
transmission (either accidentally or deliberately);
calculated using the private key of an asymmetric
algorithm and verified using the corresponding public
key
Digital Signature Algorithm Public key algorithm, standardized in FIPS 186, used
for the generation and verification of digital signatures;
usually abbreviated to DSA
Dynamic Card Verification Similar to a (static) Card Verification Value or Card
Value Verification Code, except that it is calculated using a
unique transaction key generated by a smart card
using a specific Card Master Key
Dynamic Number A dynamic authentication value calculated by the
smart card during an EMV transaction (MasterCard
only) and validated by the Card Issuer; abbreviated to
DN
Electronic Codebook A mode of encryption, whereby blocks of data are
independently encrypted; for DES this mechanism is
standardized in ANSI X3.106 and for 3-DES it is
standardized in ANSI X9.52; usually abbreviated to
ECB
Electronic Purse Generic term for a smart card based scheme that
stores an electronic version of cash on the card
Encryption Transformation of meaningful data (plaintext) into
unintelligible data (ciphertext) by means of a
cryptographic algorithm and a key
Encryption Algorithm See Cryptographic Algorithm
Europay, MasterCard and A framework for terminal-based "Chip & PIN" payment
Visa transactions, developed by Europay, MasterCard and
Visa; usually abbreviated simply to EMV (see
www.emvco.com)
Exclusive-or A mathematical operation to combine two binary
numbers; also known as "modulo 2 addition, without
carry"; often abbreviated to XOR
GISKE A proprietary key block format, a forerunner to the
TR-31 Key Block format, supported by some VeriFone
terminals
Hash Function A non-cryptographic technique for compressing
arbitrarily long strings of data to a fixed length, such
that finding Collisions or Pre-images is computationally
infeasible; examples include SHA-1, SHA-2 and MD5;
also known as a Message Digest
IBM 3624 PIN Generation Widely used proprietary PIN generation and verification
Algorithm algorithm, invented by IBM and supported by the HSM
Initialization Value See Initialization Vector

Term Description
Initialization Vector A non-secret value used to in initialize the Cipher Block
Chaining and Cipher Feedback modes of encryption;
may also be used as a "chaining value" when
encrypting a large amount of data; also known as an
Initialization Value and often abbreviated to IV
Integrated Circuit Card See Smart Card
Interchange A generic term for a Cryptographic Zone involving two
or more host systems
Issuer See Card Issuer
Issuer Master Keys A generic term for a family of Card Issuer specific keys
used in EMV to derive card unique keys and
transaction keys; the terminology between Visa and
MasterCard varies considerably and is detailed in the
"EMV Chip Card Commands" section of the payShield
9000 Host Command Reference Manual
Issuer Working Key Visa terminology for a Zone PIN Key, specifically one
used to encrypt a PIN block between Visa and the Card
Issuer; abbreviated to IWK
Key See Cryptographic Key
Key Block A data structure that comprises an encrypted key, a
Header that defines how the key may be used and an
authenticator, calculated over the Header and the
encrypted key
Key Block Header The set of fields in a key block that determine how the
key may be used; typically, such fields will include key
usage, mode of use, algorithm and exportability
Key Block LMK A key scheme whereby keys are encrypted in Key
Block format using a Local Master Key (LMK)
Key Change Storage Tamper-proof area of memory in the HSM that stores
'old' or 'new' LMK(s); used to permit translation of
keys following an LMK change
Key Check Value A mechanism used to verify the correctness of a
cryptographic key; the most common technique is to
encrypt a block of binary zeros with the key and use
the leftmost 24 bits (6 hexadecimal characters) as the
check value; abbreviated to KCV
Key Component Part of a cryptographic key, which when combined with
other key components (e.g. using the exclusive-or
operation) forms the complete key; typically used
when generating an LMK or generating and distributing
a Key Encrypting Key
Key Component Mailer Tamper-evident form used to convey a Key Component
to another party
Keyed-Hash Message A type of Message Authentication Code (MAC)
Authentication Code calculated using a hash function and a secret key; the
best known example is known simply as HMAC ; it uses
the SHA-1 hash function and is standardized in FIPS
198
Key Encrypting Key A generic term for a key (usually a symmetric key)
that is used to encrypt keys for distribution to another
party; usually abbreviated to KEK

Term Description
Key Management General term for the processes involved during the
lifecycle of a cryptographic key; involves key
generation, storage, use, distribution (import and
export), change, deletion, archive, revocation, back-
up, and so on; for symmetric algorithms, the principal
requirement of key management is that keys remain
secret and are only used for their intended purpose;
for asymmetric algorithms, the principal requirements
are that the integrity of public keys is assured and that
private keys remain secret
Key Scheme Mechanism used by the HSM to indicate the mode of
encryption both for stored keys (i.e. encrypted under
the LMK) and for distributed keys (i.e. encrypted under
a Transport Key)
Key Type Code Three character value used with a Variant LMK in the
HSM to identify different key types (and hence to
identify the LMK Pair used to encrypt the key)
LMK See Local Master Key
LMK Identifier A technique used to identify a particular LMK in the
HSM when Multiple LMKs are used
LMK Pair For a Variant LMK, different key types are encrypted
under a pair of (different) variants of the LMK; for
example, a Zone PIN Key is encrypted under LMK pair
06-07
LMK Storage Tamper-proof area of memory in the HSM that stores
the LMK(s)
Local Master Key A 3-DES key (or a set of such keys) stored in the
tamper-protected memory of the HSM and used for
encryption of other keys so they can be stored
securely outside the HSM; abbreviated to LMK
MAC See Message Authentication Code
MAC Residue The bits of the Message Authentication Block (MAB)
that are not used to form the MAC ; typically, when
using DES or 3-DES, the MAC is the leftmost 32 bits of
the MAB and the MAC Residue is the remaining 32 bits;
used, in particular, in the Racal and Australian
Transaction Key Schemes
Management LMK A specified LMK (when using Multiple LMKs) that is
used by the HSM for purposes that are not linked to a
particular LMK; for example, authenticating audit trail
records
Master Key Generic term for a cryptographic key that is used as a
Transport Key or used to derive card or transaction
specific keys; examples include Zone Master Keys and
Master Load Keys
Master Load Key A cryptographic key used to derive card and
transaction specific keys used in the Visa Cash
scheme; abbreviated to KML
Master/Session Key Scheme Generic term for a key management scheme, whereby
Session Keys are updated frequently, encrypted under
a fixed Master Key; often abbreviated to MK/SK

Term Description
MD5 A Hash Function (Message Digest) that outputs a 128-
bit result; nowadays its security is generally regarded
as relatively weak
Message Authentication Final ciphertext block when computing a MAC; may
Block also be used when calculating a MAC over a large
amount of data; often abbreviated to MAB
Message Authentication A cryptographic checksum, appended to a message
Code and used by the recipient of the message to detect
whether the message has been corrupted during
transmission (either accidentally or deliberately);
calculated using a symmetric algorithm; mechanisms
have been standardized in ANSI X9.9, ANSI X9.19 and
ISO 9797 (amongst others); usually abbreviated to
MAC
Message Digest See Hash Function
Multiple LMKs The HSM can support a number of independent LMKs
within a single device; combinations of Variant and Key
Block LMKs can be supported
Natural PIN See Derived PIN
Offline Mode of operation of the HSM that prevents online
communication with the host computer system;
achieved using a single physical key with the HSM;
usually required when changing configuration
parameters
Offset A non-secret value used in some PIN generation
algorithms to link a customer PIN to a Derived PIN
Online Mode of operation of the HSM that permits
communication with a host computer system via the
HSM's host port
Optimal Asymmetric A mechanism specified in PKCS#1, version 2.0, for
Encryption Padding padding data prior to encryption using an RSA public
key or signing using an RSA private key; abbreviated
to OAEP
Optional Key Block Header An optional set of fields in a key block that typically are
used to refine the usage of the key contained in the
key block; for example, a start and end date/time field
may be included
Personal Identification A number known only to the cardholder and used to
Number authenticate the cardholder during a financial
transaction; typically 4 to 6 digits, but may be up to 12
digits in length; abbreviated to PIN
PIN See Personal Identification Number
PIN Block A block of data that contains a PIN and is padded to
the appropriate size prior to encryption; for example,
64 bits in the case of DES
PIN Block Format Mechanism used to pad a PIN to form a PIN Block
PIN Generation Algorithm A technique used to generate (and verify) a PIN;
usually involves an Account Number and a Key
PIN Mailer Tamper-evident form used to convey a PIN from the
Card Issuer's PIN generation facility to the customer

Term Description
PIN Solicitation A technique used to allow a customer to choose his or
her own PIN; now rarely used as customers can
generally change their PINs at terminals
PIN Translation The process of decrypting a PIN block from encryption
under a key and then re-encrypting it under a different
key; required, for example, when a PIN moves from a
Terminal Zone to Interchange; the PIN Block Format
may also be changed during the translation process
PIN Verification Algorithm See PIN Generation Algorithm
PIN Verification Key Generic term for a key used with a PIN generation or
verification algorithm; abbreviated to PVK
PIN Verification Value A non-secret 4-digit number derived as a cryptographic
function of a customer's Account Number and the
customer's PIN; used by Visa as a method of verifying
the customer's PIN; abbreviated to PVV
Plaintext Generic term for meaningful data that is input to the
encryption process of a cryptographic algorithm
Pre-Image Resistance A property of a Hash Function that makes it infeasible
to find a data string that hashes to a specified value
Primary Account Number A unique sequence of numbers assigned to a
cardholder account that identifies the Card Issuer and
type of financial transaction card; usually abbreviated
to PAN
Private Key Common term for the decryption key in a Public Key
Algorithm; sometimes called a Secret Key
Public Key Common term for the encryption key in a Public Key
Algorithm
Public Key Algorithm See Asymmetric Algorithm
Public Key Certificate A data structure that binds together a user's identity
and their Public Key, via a Digital Signature generated
by a Certificate Authority
Public Key Modulus A large number (integer) used in arithmetic
calculations involving Public Key Algorithms; in
general, the larger the number the more secure the
algorithm
Racal PIN Encryption Proprietary technique used by the HSM to encrypt PINs
Algorithm under the LMK for storage on a host database; an
alternative to the Visa PIN Encryption Algorithm and
sometimes referred to as Algorithm B
Racal Transaction Key A specific type of Transaction Key Scheme,
Scheme standardized in APACS 40 & APACS 70; often
abbreviated to RTKS
Reference Number An encrypted version of an Account Number, used with
PIN Solicitation
RSA Public Key Algorithm Commonly used Public Key Algorithm, named after its
inventors, Rivest, Shamir & Adleman; usually
abbreviated simply to RSA
Secret Key See Private Key; sometimes also used to denote a key
used in a Symmetric Algorithm

Term Description
Secure Hash Algorithm A Hash Function whose output is always 160 bits in
(SHA-1) length; standardized in FIPS 180-1; usually
abbreviated to SHA-1
Secure Hash Algorithm A family of Hash Functions with different output
(SHA-2) lengths, standardized in FIPS 180-2,; specifically, SHA-
224, SHA-256, SHA-384 and SHA-512
Secure State Mode of operation of the HSM that is required for
certain highly sensitive functions (for example,
enabling the HSM's tamper-detection circuitry);
achieved using two physical keys with the HSM.
Semi-Weak Keys In DES, a Semi-Weak key pair is a set of two keys
such that the encryption process with one of the keys
is identical to the decryption process using the other
key; DES has eight known pairs of such keys
Session Key Generic term for a cryptographic key that is used (for
example) for data or PIN encryption or MAC calculation
for a limited number of transactions (often just a single
transaction); also known as a Working Key
Smart Card A plastic card (e.g. a debit or credit card) that includes
a microprocessor; also known as a Chip Card or
Integrated Circuit Card (ICC)
Symmetric Algorithm Generic term for a cryptographic algorithm that uses
the same key for both encryption and decryption, and
hence all keys must remain secret; examples include
DES, 3-DES, AES
Terminal A generic term for any device from which retail
payment transactions originate; for example, a Point of
Sale (POS) terminal or an Automated Teller Machine
(ATM)
Terminal Authentication Key HSM terminology for a key used for MAC calculation on
a Terminal Zone; abbreviated to TAK
Terminal Master Key HSM terminology for a Key Encrypting Key used on a
Terminal Zone; abbreviated to TMK
Terminal PIN Key HSM terminology for a key used for encryption of a PIN
Block on a Terminal Zone; abbreviated to TPK
Terminal Zone A Cryptographic Zone involving one or more terminals
and a host system
Thales Key Block A proprietary Key Block format, based on the TR-31
format, and supported by the payShield 9000 HSM
TR-31 Key Block An X9 Technical Report that specifies a particular Key
Block format; expected to be widely adopted by the
financial community
Transaction Certificate A particular type of Application Cryptogram used in
EMV transactions, specifically for accepted
transactions; abbreviated to TC
Transaction Key Scheme Generic term for a Terminal Key Management scheme
that allows keys to change automatically with each
transaction
Transport Key Another name for a Key Encrypting Key

Term Description
Triple Data Encryption Cryptographic algorithm that extends the use of the
Algorithm Data Encryption Standard (DES) algorithm to use
either two or three independent keys (112 or 168 bits,
respectively); often abbreviated to TDES or 3-DES
User Storage Tamper-protected, volatile area of memory in the HSM
that is used to store encrypted keys and other
frequently used data elements (such as Decimalization
Tables), as well as any other data desired by the user.
(See Chapter 15.)
Variant A generic term used to describe a mechanism whereby
keys or other data are encrypted using some form of
"variant" (or "modifier") of the "base" encryption key,
to provide additional security for the key; such
techniques are generally regarded as relatively
insecure
Variant LMK A key scheme used by the HSM whereby different key
types are encrypted under different variants of the
LMK, to provide cryptographic separation of key types
Visa Cash A proprietary electronic purse scheme developed by
Visa
Visa PIN Encryption Proprietary technique used by the HSM to encrypt PINs
Algorithm with the LMK for storage on a host database;
sometimes referred to as Algorithm A
WatchWord A Thales proprietary technique that calculates a
cryptographic response to a given "challenge"
WatchWord Key payShield 9000 terminology for a key used to calculate
a WatchWord response; abbreviated to WWK
Weak Key In DES, a Weak Key is one of four known keys such
that the encryption and decryption processes are
identical when using these keys; more generally, a
Weak Key is any cryptographic key which exhibits
"undesirable" properties
Working Key See Session Key
Zone See Cryptographic Zone
Zone Authentication Key payShield 9000 terminology for a key used for MAC
calculation on Interchange; abbreviated to ZAK
Zone Control Master Key Visa terminology for a Zone Master Key; abbreviated
to ZCMK
Zone Encryption Key payShield 9000 terminology for a key used for data
encryption on Interchange; abbreviated to ZEK
Zone Master Key payShield 9000 terminology for a Key Encrypting Key
used for Interchange; abbreviated to ZMK
Zone PIN Key payShield 9000 terminology for a key used for
encryption of a PIN Block on Interchange; abbreviated
to ZPK

Appendix H – Abbreviations
Abbreviation Description
3DES Triple DES, generally specifically Triple-length
3-D (As in 3-D Secure) Three-domain
3-DES Triple DES, generally specifically Triple-length
AAC Triple DES, probably specifically Triple-length
AAV Accountholder Authentication Value. MasterCard's equivalent of CAVV
and AEVV
AC Application Cryptogram (EMV)
ACS Access Control Server
AES Advanced Encryption Standard (algorithm)
AEVV American Express Verification Value - fulfils a role similar to
MasterCard's AAV and Visa's CAVV.
AHS Access History Server
ANS American National Standard
ANSI American National Standards Institute
AP Authentication Parameter (ATKS and RTKS)
APACS Association for Payment Clearing Services (UK)
APCA Australian Payments Clearing Association
ARC Authorization Response Code (EMV)
ARPC Authorization Response Cryptogram (EMV)
ARQC Authorization Request Cryptogram (EMV)
ASCII American Standard Code for Information Interchange
ASN.1 Abstract Syntax Notation One
ATKS Australian Transaction Key Scheme
ATM Automated Teller Machine
AWK Acquirer Working Key (Visa)
BDK Base Derivation Key (DUKPT)
C64Q CPRQ encoded in Base64
C64S CPRS encoded in Base64
CA Certificate Authority
CAP Chip Authentication Program - MasterCard initiative for using EMV
cards for authenticating users and transactions in online and
telephone banking
CAVV Cardholder Authentication Verification Value - calculated using the
CVV algorithm to provide proof of authentication in a PARes.
Equivalent to MasterCard AAV and American express AEVV.
CBC Cipher Block Chaining
CBC3 Cipher Block Chaining using TDES
CBP (Visa) Cloud Based Payments
CCID Credit Card ID
CCM Counter with CBC-MAC
CFB Cipher Feedback

CFB Cipher Feedback
CMAC Cipher-based MAC
CMS Card Management System (for card issuers)
CPRQ Condensed PAReq (for Mobile devices)
CPRS Condensed PARes (for Mobile devices)
CRReq Card Range Request message (to cache 3-D Secure PAN ranges at
MPI)
CRRes Card Range Response message
CSC Card Security Code - American Express equivalent of CVV/CVC
CSCK Card Security Code Key (American Express)
CSR Certificate Signing Request
CTA Customer Trust Anchor (payShield Manager)
CVC Card Verification Code - Mastercard Equivalent of CVV/CSC
CVK Card Verification Key (Visa & MasterCard)
CVV Card Verification Value (Visa)
CVV Card Verification Value - three-digit field coded on the magnetic
stripe of a Visa bank card. Equivalent to CSC (AmEx) and CVC
(Mastercard). The CVV algorithm is used to calculate the CAVV.
DA Domain Authority (payShield Manager)
DAC Data Authentication Code (EMV, MasterCard)
dCVV Dynamic Card Verification Value
DEA Data Encryption Algorithm (used for DES)
DEK Data Encryption Key
DER Distinguished Encoding Rules
DES Data Encryption Standard (algorithm)
DHE Diffie-Hellman Ephemeral mode for key exchange (TLS terminology)
DN Dynamic Number (EMV, MasterCard)
DPA Dynamic Passcode Authentication. Visa equivalent of CAP.
DSA Digital Signature Algorithm (FIPS 186)
DSS (PCI) Data Security Standard
DTMF Dual-Tone Multi-Frequency (telephone signal tone system)
DUKPT Derived Unique Key per Transaction (transaction key scheme)
EBCDIC (IBM) Extended Binary Code for Data InterChange
ECB Electronic Codebook
ECC Eliptic Curve Cryptography
ECDHE Diffie-Hellman Ephemeral mode for key exchange using elliptic curve
cryptography
ECDSA Elliptic Curve Digital Signature Algorithm
EDH Diffie-Hellman Key Exchange (SSL terminology)
EMV Europay Mastercard Visa - body developing standards for chip cards
EULA End-User License Agreement
FICON IBM Proprietary fiber connectivity technology
FIPS (US) Federal Information Processing Standard

FIPS Federal Information Processing Standard
FPE Format-Preserving Encryption
g Acceleration due to gravity
GBIC German Banking Industry Committee (formerly ZKA)
GCM Galois/Counter Mode
HCE Host Card Emulation
HMAC Keyed-Hash Message Authentication Code (FIPS 198)
HMAC Hash-based MAC
HMK HSM Master Key
HRK HSM Recovery Key
HSM Hardware security Module
ICC Integrated Circuit Card
IETF Internet Engineering Task Force
IFX Interactive Financial eXchange
IK Initial Key (a.k.a. IPEK or IKEY - used in DUKPT)
IKEY Initial Key (a.k.a. IPEK or IK - used in DUKPT)
IP Internet Protocol
IPEK Initial PIN Encryption Key (a.k.a. IKEY - used in DUKPT)
ISO International Standards Organization
IV Initialization Vector
IVR Interactive Voice Response
IWK Issuer Working Key (Visa)
KCV Key Check Value
KEK Key Encryption Key
KLF Key Loading Facility
KMD Key Management Device - standalone unit available from Thales that
performs certain key management functions including forming keys
from components and encrypting them using an HSM's LMK.
KML Master Load Key (Visa Cash)
KSN Key Serial Number (DUKPT)
KTK KMD Transport Key
LED Light-Emitting Diode (indicator light on front panel of payShield
9000)
LMK Local Master Key
LUC Limited-Use Cryptogram
MAC Message Authentication Code (i.e. a keyed hash)
MD Message Digest (algorithm - e.g. MD5)
MEPS Methode d'Evaluation des Produits Securitaire
MIB Management Information Base (SNMP)
milli-g 1/1000th of g
MK/SK Master/Session Key (key management scheme)
MNO Mobile Network Operator

MPI Merchant Plug-In
mPOS Mobile POS (also known as Mobile Acceptance)
NFC Near-Field Communication
NIST National Institute of Standards and Technology
OAEP Optimal Asymmetric Encryption Padding
P2PE Point-to-Point Encryption - generic term to describe protection
between the merchant's terminal and the Acquirer or payment
service provider.
P2PE Point-to-Point Encryption - generic term to describe protection
between the merchant's terminal and the Acquirer or payment
service provider.
PAM Personal Assurance Message - a message the cardholder sets up at
enrolment that is played back during payer authentication to give
assurance that it really is the ACS that is communicating with the
cardholder.
PAN Primary Account Number
PAReq Payer Authentication Request message
PaReq PAReq encoded in Base64
PARes Payer Authentication Response message
PaRes PARes encoded in Base64
PATransReq Payer Authentication Transaction request message (to AHS)
PATransRes Payer Authentication Transaction response message (to AHS)
PCI Shorthand for PCI SSC
PCI DSS PCI Data Security Standard
PCI HSM PCI standard for HSMs (part of the PCI PTS set).
PCI PTS PCI standard for PIN Transaction Security
PCI SSC Payment Card Industry Security Standards Council
PED PIN Entry Device
PIN Personal Identification Number
PKI Public Key Infrastructure
POI Point of Interaction
POS Point of Sale
PSP Payment Service Provider
PTS PIN Transaction Security standard (covering product types such as
PED, SCR, and HSM)
PVK PIN Verification Key
PVKI PIN Verification Key Index (or Indicator)
PVV PIN Verification Value (Visa)
RACC Remote Access Control Card (payShield Manager)
RCA Rich Client Application
RKL Remote Key Loading
RKT Remote Key Transport (alternative term for RKL)
RMK Recovery Master Key
RSA Rivest, Shamir, Adelman (algorithm)

RTKS Racal Transaction Key Scheme
SCD Secure Cryptographic Device (e.g. an HSM)
SCR Secure Card Reader
SE Secure Element (in a mobile phone)
SHA Secure Hash Algorithm
SHA-1 Secure Hash Algorithm (FIPS 180-1)
SHA-2 Secure Hash Algorithm (FIPS 180-2)
SNMP Simple Network Management Protocol
SP (NIST) Special Publication
SP Service Provider
SPA Secure Payment Application - MasterCard specifications and
algorithm for generating cardholder authentication data from
merchant and issuer data components resulting in the creation of an
AAV
SRED Secure Reading and Exchange of Data
SSL Secure Sockets Layer
TAK Terminal Authentication Key
TC Transaction Certificate (EMV)
TCP Transmission Control Protocol (Ethernet)
TDES Triple Data Encryption Standard (algorithm)
TEK Terminal Encryption Key
TLS Transport Layer Security
TPK Terminal PIN Key
TPS (or tps) Transactions per Second
TR-31 (ANSI X9) Technical Report 31 for Interoperable Secure Key
Exchange Key Blocks for Symmetric Algorithms
TRSM Tamper Resistant Security Module (such as an HSM)
TSM Trusted Service Manager
TSPP Thales Secure Processing Platform (secure cryptographic module in
the payShield 9000)
UCAF Universal Cardholder Authentication Field - universal multi-purpose
data transport infrastructure and defined field that is used to
communicate and transport authentication information, including AAV
/ AEVV / CAVV among various stakeholders in a transaction.
UDP User Datagram Protocol
VCBP Visa Cloud Based Payments
VEReq Verify Enrolment Request
VERes Verify Enrolment Response
WWK WatchWord Key (payShield 9000)
X9 Standards Committee accredited to ANSI, responsible for developing
standards relating to Financial Services.
XML eXtended Mark-up Language
XOR Exclusive-or addition
ZAK Zone Authentication Key

ZCMK Zone Control Master Key. (Similar to ZMK.)
ZEK Zone Encryption Key
ZKA Zentraler Kreditausschuss (now GBIC)
ZMK Zone Master Key
ZPK Zone PIN Key

Appendix I – Other Useful

Documents
payShield 9000 Manuals
Doc. No. Title
1270A543 Installation Manual
1270A544 Console Reference Manual
1270A545 Security Operations Manual
1270A645 payShield Manager User's Guide
1270A546 Host Command Reference Manual
1270A547 Australian Standards Reference Manual LIC003
1270A541 Host Command Reference Manual Addendum for Optional License

LIC004 (OBKM & CEPS Commands)

LIC014 (WebPIN Commands)

LIC016, LIC018, LIC023 (Contactless & EMV Card Issuing)

LIC017 (HE & HG Commands)

LIC020 (SEED Algorithm)

LIC031 (CUP)

LIC034 (MU & MW Commands)
1270A542 Host Programmers Manual
1270Axxx payShield 9000 Host Command Examples
1270Axxx Applications Using the payShield 9000

CipherTrust Manuals
Doc. No. Title
PUGD0532 CipherTrust Installation Manual
PUGD0533 CipherTrust User Guide
Application Notes
Doc. No. Title
PPIF0543 Packages and Licenses
PPIF0542 Software and License Update Procedures
Other Documents
Doc. No. Title
PPIF0552 payShield 9000 Decommissioning Guide
PPRN0523 payShield 9000 Release Notes
N/A payShield 9000 Quick Start Guide
1270A579 Regulatory User Warnings & Cautions

1270A593-034 General Information v3.2

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

1270A593-034 General Information v3.2

Hochgeladen von

Copyright:

Verfügbare Formate

Thales e-Security

payShield 9000 v3.2

General Information Manual

PAYSHIELD MANAGER COMMANDS ............................................................................. 39

Thales e-Security Page 3 3 August 2017

CHAPTER 12 – AES KEY SUPPORT ..................................................................... 69

Thales e-Security Page 4 3 August 2017

PROTECTION OF THE AUDIT LOG .............................................................................. 106

Thales e-Security Page 5 3 August 2017

CIPHERTRUST .................................................................................................... 131

Thales e-Security Page 6 3 August 2017

USERS AND ROLES .............................................................................................. 160

Thales e-Security Page 7 3 August 2017

End User License Agreement

Thales e-Security Page 8 3 August 2017

6. Intellectual Property Indemnification

Thales e-Security Page 9 3 August 2017

11. U.S. Government Acquisitions

12. Governing Law and Dispute Resolution

Thales e-Security Page 10 3 August 2017

13. Elliptic Curve Cryptography Activation

Thales e-Security Page 11 3 August 2017

1270A593-034 Issue 34 payShield 9000 v3.2 August 2017

Thales e-Security Page 12 3 August 2017

 1270A545 payShield 9000 Security Operations Manual – providing guidance on

Thales e-Security Page 13 3 August 2017

Overview of the payShield 9000

payShield 9000: front view

 Generating and verifying Personal Identification Numbers (PINs) such as those

 The HSM Console is a dumb-terminal interface physically connected to the

Use of Multiple HSM units

Thales e-Security Page 14 3 August 2017

PCI HSM Certification and Compliance

Thales e-Security Page 15 3 August 2017

Further details can be found in Chapter 10 – PCI HSM Compliance.

Thales e-Security Page 16 3 August 2017

Chapter 2 – Description of the

Left Key 8 LEDs Right Key

payShield 9000 HSM: front view

Keys and Locks

Thales e-Security Page 17 3 August 2017

State Left hand lock Right hand lock

 On completion of a smartcard related operation.

Thales e-Security Page 18 3 August 2017

Host 1 & Host 2 LEDs

Thales e-Security Page 19 3 August 2017

 Use of payShield Manager avoids the need for a console.

Ethernet Ethernet Aux

Earth Ethernet Host Port 2

payShield 9000 HSM: rear view

Thales e-Security Page 20 3 August 2017

You can connect a power supply to either or both sockets.

 An outage in either one of the power supplies

Ethernet Host Port 1 and 2

Important Note: In order to ensure that a payShield 9000 only processes

Ethernet Management Port

Ethernet Aux Port

 To provide asynchronous serial Host communications.*

Thales e-Security Page 21 3 August 2017

Mechanical and Electrical Specifications

Depth: 417 mm (16.42 in)

Power (per Unit)

Consumption: 100 W (maximum)

Rating: 100-240Vac, 2.1 - 0.85A