This section covers the following payment HSM topics:

The Excrypt Plus and Excrypt SSP Enterprise v.2 hardware security modules (HSMs) handle cryptographic processing and key management for various payments-related use cases. Our HSMs protect data in transit, in use, and at rest through various physical and logical security measures. In addition, the HSM, validated under FIPS 140-2 Level 3 and PCI HSM standards, complies with all relevant regulatory requirements for payment transaction processing, including those set out by Accredited Standards Committee X9.

The Secure Cryptographic Device (SCD) contained within the Excrypt Plus and Excrypt SSP Enterprise v.2 HSMs handles all sensitive operations and supports common algorithms used in the payments industry such as 3DES, AES, RSA, ECC, as well as a range of key derivation and wrapping methods, message authentication algorithms, and more.

Most payment applications communicate with the Excrypt Plus or Excrypt SSP Enterprise v.2 by using one of our four payments APIs: Excrypt, Standard, International, and REST. The Excrypt Universal Interface, comprising the first three of these APIs, integrates directly with virtually all major payment application providers and enables easy replacement of legacy HSMs without application code changes.

Excrypt Plus or Excrypt SSP Enterprise v.2 use typically falls under one of two payment use cases covered in this document: Issuing or Acquiring.

For the most part, the Excrypt, Standard, and RESTful (JSON) APIs are quite similar in their syntax. For all three, the HSM knows when the command starts and stops based on opening and closing delimiters, and then in between each field in the command are values of a specific format (binary, hex, or decimal) and length or length range.

International commands have no delimiters, and the HSM determines the value for each field based on the length of the field and the offset of the field. As an alternative method for International commands, the HSM can determine when a command has ended based on a timer. For example, 15 ms after it stops receiving data, the HSM assumes that the entire command has been sent.

If you need more information about the following command sets, see the User Guide for either the Excrypt SSP Enterprise v.2 or the Excrypt Plus.

The Excrypt Universal Interface (UI) is an API that runs on the Excrypt family of products.

The UI interfaces directly with any host transaction processing application, whether it is vendor-supplied or developed in-house, and it enables support for common domestic and international message formats for PIN translation, PIN verification, and key management.

The Excrypt UI is a unique offering among industry APIs because it can interpret a range of different command syntaxes used in host applications with the following benfits:

Support for the Standard and International command sets on the Excrypt line of our HSMs enables you to get up and running quickly with minimal changes to existing code.

The Excrypt command set is based on tags and values (for example, AO is the tag and ECHO is the value). Command have beginning and ending delimiters for the entire command (open an close brackets, [ and ]) delimiters for each field (semicolon, ;). JSON works the same way. It has beginning and end delimiters, tags, tokens, and field delimiters. Except JSON is typically communicated over an HTTP call.

We added JSON support to our HSMs so you can interface with the HSM by using RESTful API operations, exposing the Excrypt command set in a RESTful JSON data structure over an HTTP operations. RESTful libraries are plentiful and make it easy for developers because they eliminate the need for socket management or TLS.

We support the following key blocks, described in this section:

Because a cryptogram is simply an encrypted blob of data with no additional security mechanism other than the encryption itself, we recommend using TR-31 key blocks to manage keys.

The ANSI X9.24-1-2017 specification describes TR-31 key blocks. The key block structure consists of three parts (Header, encrypted key data, and Message Authentication Code (MAC)):

Our HSMs use TR-31 key blocks for external key escrow and key transport. We recommend using TR-31 key blocks to manage keys instead of cryptograms because key blocks safeguard against unauthorized substitution, replacement, or misuse of cryptographic keys by embedding information about a key within the key and data itself. Cryptograms, however, do not provide this extra level of security.

A key that is secured by the AKB consists of three parts:

The International key block structure defines four blocks instead of the three blocks defined by the TR-31:

Adding the optional extra header block provides more leeway in the management of the key.

You can also store keys the HSM. Generate the keys on the internal HSM, wrap them with a major key, and store them on the HSM internal storage table in one of the 25,000 available key slots. However, you can use these leys only with cryptographic operations on the internal HSM.

You must use this method of key storage if you use the PKCS #11 library, which does not support external key escrow. For this reason, this method is favored by those using the HSM in a General Purpose environment. Note that this method is not available through the International API, but you can use the Excrypt and Standard APIs, as well as managing the keys through Excrypt Manager and Web Portal interfaces.

When considering different key storage methods, the following considerations come into play:

Various options are available for transporting keys from an external source to a HSM. The process you choose depends on the key source (that is, where you are transferring the keys from), the key type (symmetric versus asymmetric), and the number of keys that you need to move.

Typically, third-party (non-) HSMs and key management servers support exporting keys, including private keys, under a wrapping key (such as as a KEK). In some cases, you must put the HSM or key management server in a special export mode. Refer to the documentation specific to each third-party HSM or key management server for details.

Exporting keys from software sources is often a more straightforward process than exporting from HSMs because you can transfer keys in PKCS #12 format. PKCS #12 defines an archive file format for storing many cryptography objects as a single file. Commonly, you can use it to bundle a private key with its X.509 certificate or to bundle all the members of a chain of trust.

If you have the clear private key and its corresponding certificate, you can also use the following Open SSL command to generate a PKCS #12 file:

Use the following methods to import encrypted keys into a HSM:

Use the following methods to import clear keys into our HSMs.

We recommend mutually authenticating to the HSM by using client certificates, but we do support server-side authentication. To enable server-side authentication, select the Allow Anonymous option for the Excrypt Port.

In a non-production setting, you can use clear socket for connections to the Excrypt HSM. However, do not use this setting in production because all traffic is unencrypted and in the clear.