Futurex payment HSMs
This section covers the following payment HSM topics:
- The Excrypt Plus and Excrypt SSP Enterprise V.2
- Supported APIs
- Supported key blocks
- Key storage methods
- Key transport methods
- TLS (Server-side Authentication), Mutual TLS (MTLS), Clear socket
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. Futurex HSMs protect data in transit, in use, and at rest through various physical and logical security measures. In addition, the HSM is validated under FIPS 140-2 Level 3 and PCI HSM standards and 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 using one of Futurex’s four payments APIs, which are referred to in this document as the Excrypt, Standard, International, and REST APIs. The Excrypt Universal Interface, comprising these three APIs, integrates directly with virtually all major payment application providers and allows for easy replacement of legacy HSMs without application code changes.
Excrypt Plus or Excrypt SSP Enterprise v.2 utilization 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 (e.g., binary, hex, 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. An alternative method for International commands is for the HSM to determine when a command has ended based on a timer. For example, 15 ms after data has stopped being received, the HSM will assume that the entire command has been sent.
If you need more information about the different command sets listed below, please refer to the User Guide for either the Excrypt SSP Enterprise v.2 or the Excrypt Plus.
The Excrypt Universal Interface (UI) is an Application Programming Interface (API) that runs on the Excrypt family of Futurex 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 Application Programming Interfaces (API) because it can interpret a range of different command syntaxes used in host applications. It's benefits are numerous, including:
- Extensible design
- Simple command syntax
- Wide-spread compatibility
Support for the Standard command set on the Excrypt line of Futurex HSMs enables customers to get up and running quickly with minimal to no changes to their existing code.
Support for the International command set on the Excrypt line of Futurex HSMs enables customers to get up and running quickly with minimal to no changes to their existing code.
The Excrypt command set is based on tags/values (e.g., AO is the tag and ECHO is the value) and there are beginning and ending delimiters for the entire command (i.e., [ and ]), and there are delimiters for each field (i.e., a 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.
Futurex added JSON support to our HSMs because many customers want to be able to interface with the HSM using RESTful. This is because RESTful libraries are plentiful, and it makes it easy for developers because they don't have to worry about things like socket management or TLS. So now we expose the Excrypt command set in a RESTful JSON data structure over an HTTP POST call.
A cryptogram is simply an encrypted blob of data. Aside from the encryption itself, no additional security mechanisms are baked in. Instead, Futurex recommends using TR-31 key blocks to manage keys. The advantages of using TR-31 Key Blocks are explained further in the TR-31 section below.
TR-31 Key Blocks are described in the ANSI X9.24-1-2017 specification. The key block structure consists of three parts (Header, Encrypted key data, and MAC).
Part
Description
Header
Is the least sensitive part of the key block. It defines the key block type, key usage, and key type.
Encrypted key data
Contains all the key sensitive data, including the actual key value and its size. It can optionally contain the ciphering mode used and data padding options.
MAC
The Message Authentication Code is an integrity check of the Header and Key data and ensures that the key block has not been modified.
TR-31 key blocks are used by Futurex HSMs for external key escrow and key transport. Futurex recommends 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 Atalla Key Block consists of three parts:
- An 8-byte header containing the attributes of the key (header);<
- A 48-byte key field containing the Triple-DES cipher block chaining (CBC) mode ciphertext of the key (encrypted key field);
- A 16-byte field containing the Triple-DES message authentication code (MAC) computed over the header and the encrypted key field.
The International Key Block Structure defines four blocks instead of the three blocks defined by the TR-31:
- Header (16 bytes)
- Optional header
- Encrypted key data
- Authenticator
The main difference lies in adding an optional header block that allows more leeway in the management of the key.
Keys can also be stored with the HSM. These are generated on the internal HSM, wrapped with a major key, and stored on the HSM's internal storage table in one of the 25,000 available key slots. These keys can only be utilized with cryptographic operations on the internal HSM.
It is required to use this method of key storage if utilizing 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 can be managed through the Excrypt and Standard APIs, as well as through Excrypt Manager and Web Portal interfaces.
When considering different key storage methods, two primary variables come into play:
- Whether keys are stored on the HSM or off the HSM
- In what format are encrypted keys stored
These two variables are explained in further detail below.
For most payments-related use cases, keys are stored off the HSM rather than inside the key table on the HSM. When keys are kept off the HSM, they are encrypted with a master key that is stored on the HSM.
Encrypted keys are generally in one of the following two formats:
- Cryptogram
- TR-31 Key Block
Key block formats other than TR-31 exist, but they are generally more proprietary. TR-31 Key Blocks were developed by the American Nation Standards Institute (ANSI) and therefore have more widespread support.
Various options are available for transporting keys from an external source to a Futurex HSM. The process to use depends greatly on the key source (i.e., where you are transferring the keys from), the key type (i.e., symmetric versus asymmetric), and the number of keys that need to be moved.
Typically third-party HSMs and Key Management Servers support exporting keys, including private keys, under a wrapping key (e.g., KEK). In some cases, it is required to put the HSM or Key Management server in a special export mode. Please 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 due to the ability for keys to be transferred in PKCS #12 format. PKCS #12 defines an archive file format for storing many cryptography objects as a single file. It is commonly used to bundle a private key with its X.509 certificate or to bundle all the members of a chain of trust.
A PKCS #12 file can also be generated using OpenSSL if you have the clear private key and its corresponding certificate using the command below:
The following methods are available for importing encrypted keys into a Futurex HSM:
- PKCS #12 import using Futurex Command Line Interface (FXCLI)
- PKCS #8 Import using the RSTE Excrypt command
- Using a Key Exchange Key (KEK)
The PKCS #12 and PKCS #8 import options apply to asymmetric keys, and using a KEK for key import applies to symmetric keys.
The methods listed below are available for importing clear keys into Futurex HSMs.
- Full clear key import using Excrypt Manager: If you have the full clear key value, it can be imported into the Futurex HSM by logging in under dual control through Excrypt Manager and then loading the key using either the Symmetric or Asymmetric Key Loading Wizard.
- Component import using either Excrypt Manager or FXCLI: Clear keys can also be loaded as components. In this scenario, more than one person would possess the clear key values for different parts of a key. Component holders would then need to log in to the Futurex HSM under dual control (using either Excrypt Manager or FXCLI), load each of the key components, and then the key parts would be XOR'd together and stored on the HSM. (Note: This option is most common in the payment space.)
- Converting to KEK for batch import: Another common use case is for a customer to need to import a large number of keys, making logging in under dual control and loading every individual key unfeasible. In this situation, all the keys could be encrypted under a single KEK and then batch imported into the Futurex HSM using the TWKS Excrypt command.
Mutually authenticating to the HSM using client certificates is recommended, but server-side authentication is also supported. To enable server-side authentication, enable the “Allow Anonymous” setting for the Excrypt Port.
In a non-production setting, clear socket can be used for connections to the Excrypt HSM. However, this setting should not be used in production because all traffic is unencrypted and in the clear.