payShield 9000

payShield 9000 and DUKPT

Application Note

PWPR0534-001
April 2013

www.thales-esecurity.com
 payShield 9000 and DUKPT

>> Table of Contents

>> Table of Contents .................................................................................. 2

>> References ........................................................................................... 3

>> Introduction .......................................................................................... 4

>> How DUKPT works ................................................................................ 5

>> Variations on DUKPT ............................................................................. 9

>> DUKPT for Point-to-Point Encryption and Mobile Acceptance .................... 11

>> The Role of Payment HSMs .................................................................. 12

>> The Thales payShield 9000................................................................... 13

>> payShield 9000 Host Commands for DUKPT .......................................... 16

>> Appendix A - Abbreviations ................................................................... 20

>> Appendix B - Licensing of Commands ..................................................... 22

Page 2 of 25 Thales e-Security

>> References

>> References

Some of the documents referred to below are confidential and have limited
availability.

No. Document Publisher

1 1270A546 payShield 9000 Host Command Reference Manual. Thales

(This document has restricted availability.)

2 1270A593 payShield 9000 General Information Manual. (This Thales

document has restricted availability.)

3 1270A544 payShield 9000 Console reference Manual. (This Thales

document has restricted availability.)

4 1270A596 Local HSM Manager’s User Guide. (This document has Thales
restricted availability.)

5 PWPR0532 payShield 9000 and Remote Key Loading (Application Thales

Note)

6 ANS X9.24-1:2009 - Retail Financial Services Symmetric Key ANSI

Management. Part 1: Using Symmetric Techniques

Thales e-Security Page 3 of 25

>> Introduction

>> Introduction

DUKPT (Derived Unique Key Per Transaction) is a scheme to manage TDES (Triple-
DES) encryption keys in a card payment environment. It has traditionally been used
with POS (Point of Sale) terminals in North America, but adoption is growing in
other regions and for other applications - and so DUKPT is becoming increasingly
important in the payments space.
The Thales payShield 9000 (and its predecessor, the HSM 8000) is an HSM
designed specifically for use with card payments and card issuance, and is the
market leader in these applications. Because of its central role in protecting card
payments, the payShield 9000 has supported DUKPT since its initial release, and
this support has been extended in later software releases as the scope of DUKPT
has grown.
This document describes the DUKPT key management scheme, the payShield
9000, and how the payShield 9000 can be used to support and secure the use of
DUKPT by payment processors.

Thales e-Security Page 4 of 25

>> How DUKPT works

>> How DUKPT works

DUKPT is a key management scheme for TDES keys used by POS terminals which
manages keys for use in encrypting PIN blocks, encrypting other data, and message
authentication (MACing). DUKPT is typically used between merchants and their
Acquirer. The Acquirer will repackage the transaction data for passage through the
payments network (which uses Master/Session key management) before passing it
to a payments switch.

The strength of DUKPT lies in the fact that a new, unique key is generated for each
transaction, such that if a transaction key is compromised this cannot be used to
attack previous transactions at that terminal or transactions at any other terminal.
In addition, key management in the DUKPT environment is simplified by having a
single master key which can manage an entire estate of terminals,
Three levels of keys are employed in DUKPT:
1. Base Derivation Key (BDK) - a TDES master key owned by the acquirer. The
BDK is used for a large number of terminals - perhaps all the terminals that
the provider ships, or to a model of terminals, or to a serial number range.
2. Initial Key (IKEY or IK) - a TDES key that is unique to a terminal. The IKEY is
used to initiate the sequence of transaction keys, and is then discarded by
the terminal.
3. Transaction key - generated within the terminal. Keys for PIN encryption,
data encryption, and MACing are derived from the transaction key. Each
transaction is provided with a unique key to protect its data. When the
encrypted data is received by the Acquirer, the Acquirer will derive the same
transaction key using the same process that the terminal used to derive the
encryption key.

Thales e-Security Page 5 of 25

>> How DUKPT works

It can be seen from this process that there is no requirement for the Acquirer and
terminal to exchange keys - except in the unlikely event of a terminal generating a
million transaction keys and therefore requiring a new IKEY.
The DUKPT method is defined in the ANSI standard X9.24 Part 1.
It is likely that DUKPT will be able to manage AES keys in the future.

The Base Derivation Key (BDK)

The BDK is a double-length TDES key which is usually generated and owned by the
acquirer, and is used for a large number of terminals. (If the BDK is owned by an
organisation other than the Acquirer, it will need to be distributed to the Acquirer to
enable them to process transactions. It will also need to be distributed to any other
organisation involved in generating IKEYs.) Multiple BDKs will generally be held to
allow for different terminal families or groups. BDK distribution can be done:
 electronically, with the BDK protected by a Zone Master Key (ZMK), or
 in the form of printed components, with separate component holders
coming together to enable the BDK to be formed from their components.
A stored BDK must be protected by encryption using an appropriate Key Encryption
Key (KEK) whenever it exists outside of a Tamper Resistant Security Module
(TRSM). Where Thales payment HSMs are used, BDKs are protected by the HSM’s
Local Master Key (LMK).

The Initial Key (IKEY or IK)

The IKEY (originally referred to as an IPEK - Initial PIN Encryption Key) is unique to
its terminal. The IKEY is calculated from:
 the BDK
 the Key Serial Number (KSN) which is unique to the terminal.
The KSN has a maximum length of 80 bits, and has the following structure:

Element Length Description

Key Set Identifier 5-9 Hex chars. Identifies the BDK to be used for this
(20-36 bits) terminal.
Sub-key Identifier 1 Hex char. Currently set to 0
(4 bits)
Device Identifier 2-5 Hex chars. Unique identifier (i.e. serial number) for this
(8-20 bits) terminal (always even).
Transaction Counter 1 bit + 5 Hex chars. Counter of the number of PIN encryptions
(21 bits) since terminal was initialized.

The first 3 elements in the table above form the Initial Key Serial Number, and do
not change during the life of the terminal (unless a new IKEY is loaded for any
reason).
Often only 64 bits of the KSN are used, with the KSN padded with “F” Hex
characters to the left. In this scheme, the KSN would have the following structure:

Thales e-Security Page 6 of 25

>> How DUKPT works

1. Padding - 4 “F” Hex characters, 16 bits.

2. Key set identifier - 6 Hex characters, 24 bits. This allows for about 16
million different BDKs.
3. Device Identifier - 5 Hex characters, 20 bits. This includes one bit of the
Transaction Counter, leaving 19 bits for the actual Device Identifier. This
means that about half a million different devices can be managed by the
Device Identifier.
4. Transaction Counter - 5 Hex characters, 20 bits (plus the bit included in the
Device Identifier). This allows for about 1 million transactions before a new
IKEY would be required - a limit which is unlikely to be reached.
Once created, the IKEY is installed into the terminal. (The IKEY is also recreated
transiently by the Acquirer when processing transactions from the terminal in order
to derive the same transaction key that the terminal used to encrypt its data.)

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

Processing by the Acquirer

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

Thales e-Security Page 7 of 25

>> How DUKPT works

Summary of DUKPT Operations

Notes:
1. KSN0 = Initial Key Serial Number (with Transaction Counter = 0). May be
modified by Acquirer before generating IKEY.
2. KSNT = Key Serial Number for the transaction, with Transaction Counter
incremented)
3. The BDKs held by the acquirer will be protected using an HSM.
4. The Acquirer operations shown here will involve the use of an HSM for
various cryptographic functions.

Thales e-Security Page 8 of 25

>> Variations on DUKPT

>> Variations on DUKPT

Data Encryption using a PIN Encryption Key Variant

The traditional method of implementing DUKPT X9.24-1:2004 is where the
terminal is initially loaded with an IKEY, and thereafter derives a new PIN encryption
key (and optionally a new MAC key) for each transaction it performs. Since this
method does not support the derivation of data encryption keys, some terminal
vendors have implemented the following hybrid method, using two BDKs: one of
which is used to derive the PIN encryption keys and MAC keys, and a second BDK
which is used to derive the data encryption keys.
In this case, the terminal is initially loaded with IKEYa and IKEYb (which have been
derived from BDKa and BDKb respectively). During each transaction, the terminal
derives two keys, TransactionKeya and TransactionKeyb. The PIN encryption key
(and optionally the MAC key) is derived from TransactionKeya using X9.24-1:2004
compliant methods. The data encryption key is derived from TransactionKeyb using
the PIN encryption key derivation method described in X9.24-1:2004.

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

Data Translation to DUKPT

In the diagram at the start to the previous chapter, the data flow is from the POS
terminal to the Acquirer and then into the standard payments network. As
mentioned in the previous chapter, this will involve translating DUKPT data to
formats used by the payments network.
However, consider the following environment:

Thales e-Security Page 9 of 25

>> Variations on DUKPT

Here we have an additional link in the chain - the Payment Gateway. This is an
intermediary between the merchant and the Acquirer. The Payment Gateway
provides various services to the Merchant, and might be needed because the
merchant is too small to have a direct relationship with an Acquirer. For the
present discussion we shall assume that the Payment Gateway is required because
the Acquirer provides support for only DUKPT terminals, but the merchant does not
support DUKPT.
In such an environment, the Payment Gateway will implement master/session key
management with the merchant POS terminals, using the same data and PIN Block
formats as the payments network. However, because the Acquirer supports only
DUKPT key management and data formats on the terminal side, the Payment
Gateway must have the capability to translate data to DUKPT formats.

Thales e-Security Page 10 of 25

>> DUKPT for Point-to-Point Encryption and Mobile Acceptance

>> DUKPT for Point-to-Point Encryption

and Mobile Acceptance

Point-to-Point Encryption (P2PE)

Traditionally in card payment processing, only the PIN is encrypted (in the form of a
PIN Block) - other data such as the PAN has generally not been encrypted: PCI DSS
covers the Acquirer domain and requires encryption of cardholder data such as the
PAN when the data passes over a public network, but not where the data is on a
secure private network.
Encrypting cardholder data at the merchant, at the Acquirer, and on the network
connecting them - whether this is a private network or not - takes the data out of
scope of PCI DSS compliance and audit. This is very attractive to merchants and
Acquirers because of the cost of PCI DSS compliance and audits, and so there is a
growing interest in encrypting all cardholder data in the Acquirer domain - this is
referred to as P2PE.
A wide variety of P2PE implementations are available, with proprietary designs by
their vendors. These implementations may involve a Payment Gateway.
DUKPT is often used as the key management method for a P2PE solution, because
it provides a standardised way of exchanging encrypted data (not just PINs) and
high levels of security.

Mobile Acceptance (or Mobile Point of Sale - mPOS)

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

Thales e-Security Page 11 of 25

>> The Role of Payment HSMs

>> The Role of Payment HSMs

HSMs provide a secure platform for performing cryptographic functions, protecting
secret data against attackers either within or outside of the organisation. They can
undertake tasks such as:
 Generating keys
 Protecting keys by encrypting with a master key (the LMK in Thales
terminology)
 Encrypting/decrypting data
 Importing/exporting keys
 Translating data (such as PIN Blocks) between encryption under one scheme
to encryption under another scheme.
 Calculating and verifying various types of check values.
 Performing MACing and hashing.
The card schemes require that organisations (Acquirers, Switches, and Issuers)
who are processing their cards’ transactions use HSMs for certain cryptographic
functions. Even for functions not covered by these mandates, use of HSMs is best
security practise for these organisations.
Systems and products used by these organisations must comply with standards
developed by PCI - a body set up by the card schemes. Acquirers’ systems are
audited against the PCI DSS standard. Payments products must comply with a
number of standards and are certified against various PCI standards. For instance,
payment terminals, including DUKPT-capable devices, must be certified against the
PCI PED (PIN Entry Device) standard. In the case of HSMs, PCI introduced the PCI
HSM standard fairly recently. Although this standard is not yet mandated by the
card schemes, PCI in their standard for P2PE specify that the HSMs used by the
acquirer are certified to either FIPS 140-2 or the PCI HSM standard.

Thales e-Security Page 12 of 25

>> The Thales payShield 9000

>> The Thales payShield 9000

The payShield 9000 is the latest model of payment HSMs (Hardware Security
Modules) from Thales. (It is backwards compatible with its predecessor, the HSM
8000, but the HSM 8000 provides no support for AES and therefore this
Application Note does not apply to that model.)
The payShield 9000 is an HSM that is designed specifically for use in processing
card payments and in associated activities such as card issuance. Its functions are
geared up to payment-related activities (such as PIN Block processing, or
generating and verifying card verification values).
The HSM is essentially a peripheral to a host computer system which is running a
payment-related application, and provides cryptographic functions in a protected,
secure environment. It meets the appropriate standards and has the required
certifications. Use of an HSM is advised as best practise for security, and is
mandated for certain types of application.

Certifications and standards

The payShield 9000 complies with all the standards required by the payments
industry. Formal certifications include:
 PCI HSM
 FIPS 140-2 Level 3 for the secure cryptographic device that the payShield
9000 is built around.

payShield 9000 Host Commands

The way that the host system and HSM exchange data is by exchanging messages:
the host sends a command to the HSM, and the HSM sends a response. No
payShield 9000-specific API software needs to be to be installed on the host: the
HSM can be used by any host which supports one of the following communication
methods:
 Ethernet - TCP/IP
 Ethernet - UDP
 FICON (IBM proprietary fiber-optic networking)
 Asynchronous serial
The commands sent by the host are identified by a 2-character identifier (e.g. “A2”,
“GK”), and the structure of each command (and its response) is different to reflect
the different parameters and output fields required. In this document, the
commands are referred to by their 2-character identifier: the detailed command
structure is provided in Reference 1.

The payShield 9000 Console

The traditional method of managing Thales payment HSMs was by the use of a
console - an 80-line x 24 character text display running over a serial asynchronous
communication link, or “dumb terminal”.

Thales e-Security Page 13 of 25

>> The Thales payShield 9000

The console is used by entering command codes consisting of one or more

alphanumeric characters to initiate a command, and then entering parameters
specific to the desired command in response to prompts.
The detailed operation of the commands can be found in Reference 3.

Local HSM Manager

Local HSM Manager is designed as a direct replacement for the console (and must
be located next to the payShield 9000), offering a more modern graphical user
interface than the console.
Local HSM Manager is used by selecting options from menus and then entering
data into dialog boxes. Detailed operation of Local HSM Manager is described in
Reference 4.

Remote HSM Manager

Remote HSM Manager offers a similar user interface to that provided by Local
HSM Manager, but allows the payShield 9000 to be managed remotely over a
TCP/IP link from anywhere in the world.
Current versions of Remote HSM Manager do not provide support for AES, and so
this document does not discuss its use.

Local Master Keys (LMKs)

LMKs are the critical secrets on the payShield 9000, and are automatically deleted
if an attempt is made to attack the HSM. The LMKs are used to encrypt all
operational keys (including other master keys).
The payShield 9000 supports 2 types of LMK:
 Variant LMK: this is the traditional type of LMK and still in most widespread
use. Key separation is provided by creating a variant of the LMK to encrypt
different types of key or data. Variant LMKs are double-length TDES keys.
 Keyblock LMK: this is a more modern and more secure type of LMK. Keys
encrypted using the LMK are incorporated into a keyblock which includes
metadata defining aspects such as exportability of the key and what it can be
used for. The keyblock structure used for this is a proprietary Thales design,
based on the TR-31 keyblock described below. Keyblock LMKs are triple-
length TDES keys or 256-bit AES keys.
Variant and Keyblock LMKs are described in Reference 2.
A single payShield 9000 can have multiple LMKs installed, with each LMK managed
by a different security team. This allows multiple applications or clients to be
securely segregated on the same hardware unit. The LMKs installed on a payShield
9000 can be a mix of variant and keyblock types, and DES/TDES and AES
algorithms.

Use of Keyblocks for exporting keys

An important capability of the payShield 9000 is its support for TR-31 keyblocks
when exporting keys.

Thales e-Security Page 14 of 25

>> The Thales payShield 9000

Traditionally, key management specified in ANSI X9.17 has been used to exchange
keys in a multi-vendor environment, where keys are exchanged between products
sourced from different manufacturers such that proprietary exchange mechanisms
cannot be used. X9.17 key exchange is supported by the payShield 9000.
However, X9.17 key exchange has a number of well-recognised security
deficiencies, such as being unable to prevent attacks based on key masquerading
and not providing mechanisms for detecting modifications made to the transmitted
key.
The deficiencies in X9.17 are addressed by the use of TR-31 keyblocks for key
exchange. The TR-31 specification (produced by the ANSI X9 committee) requires
the key being exchanged to be formatted within a block which includes restrictions
on how that key can be used and managed, and uses a MAC to prevent
modifications to the data from going undetected.

Thales e-Security Page 15 of 25

>> payShield 9000 Host Commands for DUKPT

>> payShield 9000 Host Commands for

DUKPT

Thales Key Types for DUKPT

The host commands below use the following Thales key types relating to DUKPT:

Thales Key Type Key Usage Description

Key Type Code (Keyblock
(Variant LMKs)
LMKs)
BDK Type 1 009 B0 Bidirectional key used to protect both terminal-to-
(“BDK-1”) host and host-to-terminal data.
This type of BDK meets the requirements of ANSI
X9.24-1:2004.
For each transaction, this BDK can be used to
derive a PIN encryption key and a (single) data
authentication (MAC) key.
Note: this method cannot be used to derive a data
encryption key.

BDK Type 2 609 41 Unidirectional key. One key is used to protect

(“BDK-2”) terminal-to-host data and a different key is used to
protect host-to-terminal data.
This type of BDK meets the requirements of ANSI
X9.24-1:2009.
For each transaction, this BDK can be used to
derive a PIN encryption key, two (send/receive)
data encryption keys and two (send/receive) data
authentication (MAC) key.

BDK Type 3 809 42 Bidirectional key, also allowing data decryption

(“BDK-3”) using a “PIN verification” variant key. The
transaction key generated from this type of BDK
can be used only for data encryption/decryption.
This type of BDK does not meet the requirements
of ANSI X9.24-1.
For each transaction, this BDK can be used to
derive a data encryption key. The method used to
derive the data encryption key is identical to the
standard X9.24-1 method of deriving the PIN
encryption key.
See the section on Data Encryption using a PIN
Encryption Key Variant
Note: this method cannot be used to derive a PIN
encryption key, or a data authentication (MAC) key.

Thales e-Security Page 16 of 25

>> payShield 9000 Host Commands for DUKPT

Thales Key Type Key Usage Description

Key Type Code (Keyblock
(Variant LMKs)
LMKs)
IKEY 302 B1 Initial key injected into POS terminal from which
future transaction keys are generated.

DUKPT Key Management

payShield 9000 Host Command
ID Command Use
A0 Generate a BDK.
Use Mode = 0 where the key is to be used only by the HSM at this time, or
Mode = 1 if it is also required to be exported to another device, encrypted
under a ZMK. The key type is specified in the command as being the
appropriate type of BDK.

A0 Generate an IKEY.
Use Mode = A where the key is to be used only by the HSM at this time, or
Mode = B if it is also required to be exported to another device, encrypted
under a ZMK or TMK. The key type is specified in the command as being the
appropriate type of BDK.

A6 Import a BDK encrypted under a ZMK. This command would only be used by
the Acquirer if for any reason the BDK was generated by a third party and
passed to the Acquirer.
A8 Export a BDK or IKEY encrypted under a ZMK. This command may be used
by a third party that generates the BDK and passes it to the Acquirer.

Thales e-Security Page 17 of 25

>> payShield 9000 Host Commands for DUKPT

PIN Processing
payShield 9000 Host Command
ID Command Use
G0 Translate a DUKPT PIN Block to encryption under a ZPK. This allows the PIN
to be passed into the payments network. The host provides the appropriate
BDK-1 or BDK-2 as identified in the KSN sent by the terminal. *

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

GQ Verify a PIN Using the VISA PVV Method, with optional MAC verification. The
host provides the appropriate BDK-1 or BDK-2 as identified in the KSN sent
by the terminal. This command would only be used where the Acquirer is the
issuing bank, and the transaction is not being passed through the payments
network.
GS Verify a PIN Using the Diebold Method, with optional MAC verification. The
host provides the appropriate BDK-1 or BDK-2 as identified in the KSN sent
by the terminal. This command would only be used where the Acquirer is the
issuing bank, and the transaction is not being passed through the payments
network.
GU Verify a PIN Using the Encrypted PIN Method, with optional MAC verification.
The host provides the appropriate BDK-1 or BDK-2 as identified in the KSN
sent by the terminal. This command would only be used where the Acquirer
is the issuing bank, and the transaction is not being passed through the
payments network.
* Commands to allow PIN Block translation to DUKPT will be added in a later
version of software.

Thales e-Security Page 18 of 25

>> payShield 9000 Host Commands for DUKPT

MACing
payShield 9000 Host Command
ID Command Use
GW Generate a MAC on a message to be sent to a DUKPT terminal. The host
provides the appropriate BDK-1 or BDK-2 and the KSN for the terminal. Use
modes 4-6 (for BDK-1) or D-F (for BDK-2):
Mode 4 or D: Generate an 8-byte MAC
Mode 5 or E: Generate Approval MAC (4 leftmost bytes of MAC)
Mode 6 or F: Generate Decline MAC (4 rightmost bytes of MAC)

GW Verify a MAC on a message sent from a DUKPT terminal. The host provides
the appropriate BDK-1 or BDK-2 and the KSN for the terminal. Use modes
1-3 (for BDK-1) or A-B (for BDK-2):
Mode 1 or A: Verify an 8-byte MAC
Mode 2 or B: Verify Approval MAC (4 leftmost bytes of MAC)
Mode 3 or C: Verify Decline MAC (4 rightmost bytes of MAC)

Data Encryption and Decryption

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

Thales e-Security Page 19 of 25

>> Appendix A - Abbreviations

>> Appendix A - Abbreviations

AES Advanced Encryption Standard (algorithm)

ANS American National Standard

ANSI American national Standards Institute

BDK Base Derivation Key (DUKPT)

DEA Data Encryption Algorithm (used for DES)

DEK Data Encryption Key

DES Data Encryption Standard using DEA

DSS See PCI DSS

DUKPT Derived Unique Key Per Transaction

FIPS Federal Information Processing Standard

HSM Hardware Security Module

IK Initial Key (a.k.a. IPEK or IKEY - used in DUKPT)

IKEY Initial Key (a.k.a. IPEK or IK - used in DUKPT)

IPEK Initial PIN Encryption Key (a.k.a. IKEY or IK - used in DUKPT)

KEK Key Encryption Key

LMK Local Master Key

KCV Key Check Value

KSN Key Serial Number

mPOS Mobile POS (also known as Mobile Acceptance)

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

POS Point of Sale

PVV PIN Verification Value

RSA Rivest, Shamir, Adelman (algorithm)

TDES Triple DES (algorithm)

Thales e-Security Page 20 of 25

>> Appendix A - Abbreviations

TEK Terminal Encryption Key

TMK Terminal Master Key

TPK Terminal PIN Key

TR-31 A specification from the ANSI X9 committee for Interoperable Secure Key
Exchange Key Blocks for Symmetric Algorithms

TRSM Tamper Resistant Security Module (such as an HSM)

X9 Standards Committee accredited to ANSI, responsible for developing

standards relating to Financial Services.

ZEK Zone Encryption Key

ZMK Zone Master Key

ZPK Zone PIN Key

Thales e-Security Page 21 of 25

>> Appendix B - Licensing of Commands

>> Appendix B - Licensing of Commands

The following tables show the software licenses required for all the host commands
referenced in this document . This information is provided for both the payShield
9000 and its predecessor, the HSM 8000.

payShield 9000
Each payShield 9000 is purchased together with one (and only one) base software
pack. Various packs are available which are optimized for different purposes:

Pack Description

PAC001 Standard Software package

PAC010 Transaction Processing software package

PAC020 Magnetic Stripe Issuers software package

PAC030 EMV Issuers software package

If a required command is not included in the pack that has been purchased with the
payShield 9000, it can be added by acquiring the appropriate Optional License.

Command In Base Software Pack Optional License

PAC PAC PAC PAC
ID Description If not in pack, add:
001 010 020 030

A0 Generate a key     (Not required)

A6 Import a key     (Not required)

A8 Export a key     (Not required)

B0 Translate a key scheme     (Not required)

Translate a PIN from BDK

G0
to ZPK encryption   LIC025

GO
Verify a PIN using the
IBM Method
  LIC025

GQ
Verify a PIN using the
Visa PVV Method
  LIC025

GS
Verify a PIN using the
Diebold Method
  LIC025

Thales e-Security Page 22 of 25

>> Appendix B - Licensing of Commands

Command In Base Software Pack Optional License

PAC PAC PAC PAC
ID Description If not in pack, add:
001 010 020 030

GU
Verify a PIN using the
Encrypted PIN Method
  LIC025

GW Generate/Verify a MAC   LIC025

M0 Encrypt a block of data   LIC008

M2 Decrypt a block of data   LIC008

M4 Translate a block of data   LIC008

HSM 8000
The HSM 8000 is licensed in a different way to the payShield 9000. Every HSM
8000 has a base software license, LIC 001. If the required host command is not
included in this it can be added by acquiring the appropriate Optional License.

In Base
Command Optional License
License

ID Description LIC 001 If not in base, add:

A0 Generate a key  (Not required)

A6 Import a key  (Not required)

A8 Export a key  (Not required)

B0 Translate a key scheme  (Not required)

Translate a PIN from BDK to ZPK
G0
encryption  (Not required)

GO Verify a PIN using the IBM Method  (Not required)

GQ
Verify a PIN using the Visa PVV
Method
 (Not required)

GS
Verify a PIN using the Diebold
Method
 (Not required)

GU
Verify a PIN using the Encrypted
PIN Method
 (Not required)

GW Generate/Verify a MAC  (Not required)

Thales e-Security Page 23 of 25

>> Appendix B - Licensing of Commands

In Base
Command Optional License
License

ID Description LIC 001 If not in base, add:

M0 Encrypt a block of data LIC008

M2 Decrypt a block of data LIC008

M4 Translate a block of data LIC008

Thales e-Security Page 24 of 25

Thales e-Security

V V V

Americas Asia Pacific Europe, Middle East, Africa

THALES e-SECURITY, INC. THALES TRANSPORT & SECURITY THALES e-SECURITY LTD.
900 South Pine Island Road (HONG KONG) LTD. Meadow View House
Suite 710 Unit 4101, 41/F Long Crendon
Plantation 248 Queen's Road East Aylesbury
Florida Wanchai Buckinghamshire
33324. USA Hong Kong, PRC HP18 9EQ. UK
T: +1 888 744 4976 T: +852 2815 8633 T: +44 (0)1844 201800
or +1 954 888 6200
F: +1 954 888 6211 F: +852 2815 8141 F: +44 (0)1844 208550
E: [email protected] E: [email protected] E: [email protected]

© Copyright 1987 - 2013 THALES e-SECURITY LTD

This document is issued by Thales e-Security Limited (hereinafter referred to as Thales) in confidence and is not to be reproduced in
whole or in part without the prior written approval of Thales. The information contained herein is the property of Thales and is to be
used only for the purpose for which it is submitted and is not to be released in whole or in part without the prior written permission
of Thales.