Excrypt Plus & Excrypt SSP Enterprise v.2 Integration Guide
In this document, we will describe the various payment applications and their use cases and how Futurex Payment HSMs can be utilized in multiple capacities throughout the payment process.
In the payment space, there are two primary high-level types of applications: Issuing and Acquiring. Issuing focuses on issuing payment cards and provisioning mobile payment tokens. Acquiring focuses on the steps carried out between merchants and banks for processing credit and debit transactions, either through traditional card-based transactions or mobile payments.
Note: Due to regulatory requirements, payment acquiring and payment issuing processes are typically carried out inside separate HSMs.
This section provides instructions for performing the minimum initial setup tasks required for all payment-related use cases on Futurex HSMs. These configurations can be made using either Excrypt Manager or Futurex Client Tools (FXCLI).
The following sections cover FXCLI installation and Excrypt Manager installation, along with the minimal setup tasks required, which are network configuration and loading major keys.
Note: Install FXCLI on the workstation you will use to configure the HSM.
On Windows, the easiest way to install Futurex Command Line Interface (FXCLI) on Windows is by installing the FXTools application, which includes FXCLI. You can download FXTools from the Futurex Portal.
To install FXCLI, run the Futurex Tools installer as an administrator and follow the prompts in the setup wizard to complete the installation.
The setup wizard installs all tools on the system by default. You can override the defaults and choose not to install certain modules. The installation provides the following services:
You can download the appropriate FXCLI package files for your system from the Futurex Portal.
If the system is 64-bit, select from the files marked amd64. If the system is 32-bit, select from the files marked i386.
If running an OpenSSL version in the 1.0.x branch, select from the files marked ssl1.0. If running an OpenSSL version in the 1.1.x branch, select from the files marked ssl1.1.
Futurex offers the following features for FXCLI:
To install an rpm package, run the following command in a terminal:
$ sudo rpm -ivh [fxcl-xxxx.rpm]
To install a deb package, run the following command in a terminal:
$ sudo dpkg -i [fxcl-xxxx.deb]
To enter the HSM FXCLI prompt, run the following command in a terminal:
After entering the FXCLI prompt, you can run help to list all of the available FXCLI commands.
Note: Install Excrypt Manager on the workstation you will use to configure the HSM. Sections 3 and 4 of this integration guide cover the installation of Futurex Command Line Interface (FXCLI) and Excrypt Manager. Excrypt Manager is a Windows application that provides a GUI-based method for configuring the HSM, while FXCLI provides a command-line-based method for configuring the HSM and can be installed on all platforms.
Note: If you will be configuring the HSM from a Linux computer, you can skip this section. If you will be configuring the HSM from a Windows computer, installing FXCLI in the next section is still required because FXCLI is the only method that can be used to configure TLS mutual authentication between the HSM and the payment application you are integrating.
Note: If you plan to use a Virtual HSM for the integration, all configurations will need to be performed using either FXCLI, the Excrypt Touch, or the Guardian Series 3.
Note: The Excrypt Manager version must be from the 4.4.x branch or later to be compatible with the HSM firmware, which must be 6.7.x.x or later.
To install Excrypt Manager, run the Excrypt Manager installer as an administrator and follow the prompts in the setup wizard to complete the installation.
The installation wizard prompts you to specify where you want to install Excrypt Manager. The default location is C:\Program Files\Futurex\Excrypt Manager\. After choosing a location, select [ Install ].
For both Excrypt Manager and FXCLI, you must connect your laptop to the front USB port on the HSM. The initial login process described in this section uses the default Admin identities to log in under dual control.
|User #1||User #2|
|User ID: Admin1||User ID: Admin2|
|Password: safe||Password: safe|
$ connect usb $ login user
Note: The login user command prompts for the username and password. You need to run it twice because you must log in under dual control with both default Admin identities.
$ user change-password -u Admin1 $ user change-password -u Admin2
Note: The preceding user change-password commands prompt you to enter the old and new passwords for the identity you are updating.
$ network interface modify --interface Ethernet1 -–ip 10.221.0.10 -–netmask 255.255.255.0 –-gateway 10.221.0.1
The HSM requires you to load an MFK (Master File Key) before use. Depending on the intended use, you can also load a PMK (Platform Master Key), KEK (Key Encryption Key), and FTK (Futurex Token Key) at this point. The HSM allows you to load certain major keys through M of N fragmentation or a key wizard. With M of N key fragmentation, organizations can define a number of required key officers for a key ceremony that is less than the total number of key officers available. This allows organizations to maintain security while dramatically reducing the inconvenience of coordinating busy schedules around key ceremonies.
The following sections show how to load major keys through Excrypt Manager, and how to load major keys through FXCLI.
$ majorkey random --mfk -m [number_from_2_to_9] -n [number_from_2_to_9]
$ majorkey recombine --key mfk
Issuing focuses on issuing payment cards and provisioning mobile payment tokens.
For both PIN generation methods described below, PINs are associated with an algorithm based on a particular key at the issuing bank. That key is a 3DES encryption key and is referred to as a PIN Verification Key (PVK). A PIN is generated based on the customer’s account/card number and the PIN Verification Key. This is referred to as the natural PIN.
In the past, issuers did not give customers the option to select their PIN. Instead, the bank would send the natural PIN to the customer in the mail, and they were forced to use the designated PIN. Now, most banks allow customers to select their own PIN. This is done by taking the PIN Verification Key, customer account number, and the chosen PIN, then sending that to an HSM to compare the natural PIN against the customer-selected PIN and determine the difference. The difference is referred to as the PIN Verification Value for the VISA PVV method and the offset for the IBM 3624 method.
The VISA PIN Verification Value algorithm performs a multiple encipherment of a value, called the transformed security parameter (TSP), and a extraction of a 4-digit PIN verification value (PVV) from the ciphertext.
Note: Excrypt command GVWW can be used to generate a random VISA Working Key for use in the VISA Network.
The IBM 3624 algorithm generates a n-digit PIN based on an account-related data or person-related data, namely the validation data. The assigned PIN length parameter specifies the length of the generated PIN.
Note: Excrypt command GOFF can be used to generate a PIN Offset for use in the IBM 3624 Network.
EMV stands for Europay, Mastercard, and Visa, the three companies that created the standard, and it is a payment method based on a technical standard for smart payment cards, payment terminals, and ATMs that can accept them.
EMV cards are smart cards, also called chip cards, which store their data on integrated circuit chips (ICCs), in addition to magnetic stripes for backward compatibility. These include cards that must be physically inserted (i.e., “dipped”) into a reader and contactless cards that can be read over a short distance using near-field communication technology.
Payment cards that comply with the EMV standard are often called chip and PIN or chip and signature cards, depending on the authentication methods employed by the card issuer, such as a personal identification number (PIN) or digital signature. Outside the United States, the chip and PIN process is more common. It requires a secret four-digit PIN code known only by the cardholder to validate the EMV payment, making it significantly more secure. In the U.S., companies have opted for issuing chip and signature cards, weighing the risk of fraudulent transactions against the desire to make the purchasing process as seamless as possible for consumers.
Mobile payment tokens are governed by the pay brands (i.e., Google Pay, Apple Pay, Samsung Pay, etc.). For mobile payment tokens to be issued to a device, the card issuer (e.g., Wells Fargo, Chase, Bank of America, etc.) must have a relationship with the particular pay brand to which the mobile payment token will be issued. Each pay brand has specific data structures and encryption methods they require to communicate a token to a device, so the card issuer must support those methods for it to work.
Note: Mobile payment token issuance is not supported for the Standard and International command sets.
A Card Verification Value (CVV) is similar to a PIN, except it is not a secret value. A CVV is generated based on a Card Verification Key (CVK). So the CVK is the base key, and the CVV value is based on that key and the customer account/card number.
Originally, CVV was meant to validate that a user has the card that’s being used is not a cloned card.
Note: There is CVV generation and verification, but not translation because it is not encrypted between the hops.
Acquiring focuses on the steps carried out between merchants and banks for processing credit and debit transactions, either through traditional card-based transactions or mobile payments.
When a user enters their card’s personal identification number (PIN) on a device (i.e., an ATM or a payment terminal), the entered PIN is encrypted and then sent to an HSM in the bank’s datacenter, along with the account/card number and the PVV or offset (depending on which method is used). The HSM then decrypts the PIN that the user entered, takes the account/card number, the bank’s PIN Verification (PVK), and the PVV or offset and derives the actual PIN, then compares it to what the user entered and says, “yes” or “no” to the transaction.
The data structure for an encrypted PIN is called a PIN block. PINs are typically four characters, but you cannot encrypt only four characters with the DES algorithm. Instead, it must be an 8-byte block of data. This is one of the reasons why the concept of PIN blocks was created.
Embedded in a PIN block are the length of the PIN, the PIN itself, and padding. Then, all of that data is XORed with a portion of the account number. The result is the clear value of the PIN block. The clear PIN block value is then encrypted with a PIN Encryption Key (PEK).
Different standards exist for PIN blocks. ISO format 0 and ISO format 3 are currently supported. The new ISO format 4 standard supports an AES PIN encryption key. AES pin blocks were previously not supported due to issues with AES requiring a 16-byte block of data to encrypt.
When an EMV card is “dipped” at a terminal, the terminal performs a few validations, such as the type of product (i.e., debit/credit) and the cardholder verification method (i.e., chip and PIN/chip and signature).
After validations, the terminal requests an Authorization Request Cryptogram (ARQC) from the card’s integrated circuit chip (ICC).
The chip generates an 8-byte Application Cryptogram (AC) using an Application Cryptogram Master Key (MKAC). The chip performs the following actions to generate the Application Cryptogram (AC):
In the case of an online transaction, this authorization cryptogram is called an Authorization Request Cryptogram (ARQC). The chip sends the ARQC to the terminal, which in turn sends ARQC in the authorization message to the issuer host for authorization.
Upon receiving the ARQC in the authorization request, the issuer system validates the ARQC and generates an Application Response Cryptogram (ARPC) using a hardware security module (HSM).
If the ARQC verification is successful, an ARPC is generated using ARQC as one of the inputs. If the ARQC verification is unsuccessful, then the ARQC should not be used as input for ARPC generation.
There are two methods that can be used to generate the ARPC. Method 1 generates an 8-byte ARPC using an 8-byte ARQC and a 2-byte Authorization Response Code (ARC) as input. Method 2 generates a 4-byte ARPC using an 8-byte ARQC, a 4-byte Card Status Update (CSU), and a 0–8 byte Proprietary Authentication Data as input.
The ARPC is sent in an authorization response message from the issuer to the terminal via the acquirer.
Mobile payments work using a combination of specialty hardware and a mobile wallet (i.e., Google Pay, Apple Pay, Samsung Pay, etc.). Users hold their mobile devices up to the contactless payment terminal. This allows the two devices to communicate over a specific radio frequency, passing encrypted payment information back and forth to complete the transaction. The funds then leave the user’s digital wallet and enter the business’s point of sale system.
Tokenization is another critical piece in enabling mobile transactions and payments. When a user sets up a mobile wallet, details are sent to their issuing bank. The bank replaces these details with a token, a set of randomly generated numbers. This keeps your account details completely encrypted and protected from fraud.
Note: Mobile payment acceptance is not supported for the Standard and International command sets.
Card issuers and banks use card verification values (CVV) to determine when a forged card is used in a card-notpresent transaction. Using the card’s expiration date, PAN data, and PIN, a hardware security module can cryptographically validate CVV (in its many forms, including CVC, CID, CSC, CVC2, and CVV2) and determine if the card data presented is authentic for online or contact-free payments.
Card Verification Codes (CVC) accelerate the process of verifying card data in card present transactions. The CVC is found within the magnetic stripe, and these codes are processed anytime a card is inserted into a cardreading point of sale terminal.
CVV and CVC2 are commonly referenced for card-not-present transactions. They are usually in the form of a three or four-digit code on the back of the card, and they are often used in place of CVC for card-not-present transactions. The two terms are often used interchangeably.
In online transactions, CVV validation is one of two ways of verifying if cards are authentic (the other method is XML-based authentication). Storage of CVVs in any database is expressly prohibited, but businesses need to have access to the card’s public key to decrypt and verify transactions. To secure the CVV, hardware security modules (HSMs) are used to validate and encrypt it.
Note: There is CVV generation and verification, but not translation because it is not encrypted between the hops.
Message Authentication Code (MAC), also referred to as a tag, is used to authenticate messages. In other words, MAC ensures that the message came from the stated sender (its authenticity) and has not been changed. The MAC value protects a message’s data integrity by allowing verifiers (who also possess the secret key) to detect any changes to the message content, thus preventing man-in-the middle attacks and fraudulent hosts or ATMs.
Currently, MACing is not very common in the U.S. for payment transactions. However, in Canada, a government-owned interbank network called Interac forces participating banks to MAC all payment transactions.
We all depend on encryption keys in one way or another. While few people outside the payments industry are aware of this, anytime you present your payment card at a Point of Sale (POS) terminal or use an ATM, an encryption key quickly goes to work to encrypt the PIN or the primary account number (PAN) associated with your card. This encryption obscures the data and protects against information theft as the transaction is sent back to the card issuer for validation. For this process to work, an encryption key must be securely loaded into that endpoint device, whether it be an ATM, a POS terminal, or even a commercial off-the-shelf device used for payment acceptance.
How does that encryption key find its way onto those devices? This has traditionally been done manually through a process known as direct key injection. For POS terminals and PIN entry devices, this involves bringing the devices to a key injection facility where key administrators manually inject each device. This can be time consuming and expensive. It requires the upfront cost of maintaining a validated Payment Card Industry (PCI) Level 3 key injection facility (KIF), and the operational costs of shipping devices to the KIF anytime they need to be rekeyed. For larger devices, like ATMs and gas station payment terminals, key administrators will often have to travel to each device in the field to load the necessary encryption keys. For organizations with widespread ATM or POS networks, this can be a significant operational expense with a high susceptibility to human error.
While the direct injection model has been sufficient for many organizations, others will find a remote key loading (RKL) solution more cost effective and efficient. With RKL, a remote key server establishes a secure, PKIauthenticated connection with each device and remotely distributes encryption keys without having to physically access the device. The ability to remotely rekey the device in the field without extended downtime is a powerful time and money saver for many organizations. RKL allows organizations to manage keys for an entire infrastructure by sending cryptographically secure key exchanges from a centralized location. Better yet, devices can be rekeyed instantaneously with an absolute minimum of down time. Gone are the costs associated with maintaining an injection facility and manual injection.
Successful remote key loading (RKL) operations require collaboration and standardized communication protocols between the device manufacturer and the RKL provider. The backbone of RKL is trust at both ends of the key exchange, one end being the RKL provider and the other being the field-level device. This trust is established by a certificate authority, which provides both the endpoint terminal and the RKL platform with a digital certificate. This certificate serves as a private key in the public key infrastructure (PKI) used to facilitate secure key exchanges. The manufacturer’s role is to ensure that their devices have this certificate before deployment.
Furthermore, the endpoint devices and the RKL provider must use the same communication and encryption protocols, which furthers the manufacturer’s role in the process. While the most common and accepted encryption standard for RKL is TR-34, which was developed by ASC X9, there are many others in use depending on manufacturers, geographic location, and other factors. It is important for RKL providers to be accommodating in their platform design to allow integration with multiple manufacturers.
ATMs are used by millions of people withdrawing cash every year. In 2016, the United States Federal Reserve noted that of the 91% of Americans with a credit, debit or other bank account, 75% use ATMs for cash withdrawals. With so many people depending on ATMs functioning properly, security is a major concern. ATMs rely on network protection and PIN encryption techniques to keep the customer customer’s PINs safe.
The encryption keys used to encrypt and validate PINs must be rotated on a regular basis to meet compliance mandates and maintain security. Before remote key loading became a viable option, key holders were required to visit each ATM in person to rotate keys across the network. This process was cumbersome and has grown increasingly infeasible as the number of ATMs continues to grow.
Furthermore, Payment Card Industry Data Security Standard (PCI DSS) regulations require that all PINs be encrypted upon capture at the terminal. RKL provides a secure, efficient, and cost-effective method for loading and managing ATM encryption keys across entire ATM networks.
POS terminals have double the encryption work. Like ATMs, they encrypt PINs for debit card transactions, but many merchants also require primary account numbers, commonly known as PANs, which are the account number associated with credit card payments, to also be encrypted. While PCI DSS regulations do to not currently require PAN encryption, its rapidly becoming the norm in the payments landscape. Recent years have seen high-profile data breaches that were traced back to a lack of PAN encryption. PAN encryption works similar to PIN encryption, but the technology surrounding PAN encryption is typically referred to as Point-to-Point Encryption (P2PE). Like PIN encryption, P2PE encrypts the PAN at the moment of capture in the POS device.
The encryption mechanisms behind PIN and PAN encryption differ slightly on the payment processing end, but they are the same for the purposes of RKL. Both processes require reliable access to encryption keys. Most POS terminals will have at least 2 key slots, with separate keys for both PIN and PAN encryption.
Note: Remote Key Loading (RKL) is not supported for the Standard and International command sets.
An ATM network, also known as an interbank network, is a computer network that enables ATM cards issued by a financial institution that is a member of the network to be used to perform ATM transactions through ATMs that belong to another member of the network.
Every active ATM has a PIN Encryption Key (PEK), Master Key, and Key Encryption Key (KEK) loaded on it through Remote Key Loading (RKL). The way this is accomplished is, on the backend, the payment application sends a request to an HSM to generate a random KEK, encrypt it under the ATMs public key/certificate, and send it to the ATM. The ATM then decrypts the KEK using the private key associated with the public key/certificate that encrypted it. This key management scheme is called Master/Session.
On the ATM, the KEK (the “Master” key) is then used to encrypt a randomly generated Working Key (called the “Session” key). In this case, the session key is the PIN Encryption Key (PEK).
The KEK (the “Master key) is not changed out infrequently. In some cases, it is once a year, while in others, it is the life of the ATM. The PEK (the “Session” key) is changed out regularly. In some cases, once a day or once every 1,000 transactions.
Note: For this example, we will assume that an IBC Bank card is being used at a Chase Bank ATM to withdraw funds.
An IBC Bank customer goes to a Chase Bank ATM and inserts their IBC debit card in the card reader. They enter their PIN, which the ATM encrypts under its PIN Encryption Key (PEK) and sends to First Data Corporation. First Data hosts their STAR Network, which provides debit acceptance at more than 2 million retail POS, ATM, and Online outlets for nearly a third of all U.S. debit cards (Note: First Data is used in this example, but many other networks exist to provide debit acceptance services.)
Because First Data also has a relationship with IBC, they know that IBCs processor is Visa Debit Processing Services (DPS), and therefore forwards the request to Visa DPS to process the request and send the response back to First Data, which delivers the response to the Chase ATM.
Note: You may be wondering why Chase can’t just send the request directly to IBC or Visa DPS. This is because it’s not feasible for Chase to have relationships with every processor. So they go to a network, which is First Data in this case. First Data has relationships with all banks and processors or with other networks that do have a relationship with the issuing bank.
PIN translation plays a crucial role in all ATM foreign transactions. Between each of the hops in the example above, a PIN translation takes place using the TPIN Excrypt command. Each involved entity has its own PIN Encryption Key (PEK). In addition, between each link in the network chain, a shared PEK is established between the two entities. For example, between Chase and First Data, they have a shared PEK, which we’ll call “CFDPEK”. This shared PEK is stored on an HSM in both companies’ datacenters. So, after the IBC cardholder enters their PIN, the Chase ATM encrypts it under its PEK and sends it to the Chase HSM, requesting that it perform a PIN translation from the ATM PEK to the “CFD-PEK” and then send it to First Data. First Data then performs a PIN translation from the PIN being encrypted under the “CFD-PEK” to being encrypted under its own PEK. Then, the encrypted PIN is translated again to being encrypted under the PEK established between Visa DPS and them, and the process continues. To reiterate, a shared key must be established between each link in the chain for PIN translation to occur.
Note: Typically, it’s not just a PEK that is involved. Most likely, there would also be an “MFK-CFD-KEK” key established, and the KEK would be used to share other keys so that the PEK could be swapped out periodically.
Point-to-point encryption (P2PE) is an encryption standard established by the PCI Security Standards Council in 2012. It stipulates that cardholder information is encrypted immediately after the card is used with the merchant’s point-of-sale terminal and is not decrypted until the payment processor has processed it.
P2PE encryption is not required by PCI-DSS, which is for a few reasons. First, PCI states that if you have a network where clear cardholder data is transmitted, you are within the scope of DSS compliance requirements. Because of this, when companies started encrypting cardholder data, they correctly assumed that they no longer fell within the scope of DSS. However, PCI caught wind of this and considered that if these companies were encrypting cardholder data, then they must need to securely manage encryption keys. This was when they came out with the PCI-P2PE security standard, making its requirements even more stringent than PCI-DSS.
In reality, there are primarily two types of companies that deploy P2PE in their payment processing transactions: 1) Retailers that want to reduce risk and don’t want to be in the news, or 2) Acquirers that are trying to add value to their service.
Note: Before P2PE, there was no need for HSMs for acquirers because the only transactions going through an HSM were PIN-based transactions. Now, if an acquirer uses P2PE, every transaction goes through an HSM.
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:
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).
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:
The International Key Block Structure defines four blocks instead of the three blocks defined by the TR-31:
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:
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:
Note: 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:
openssl pkcs12 -export -out bundle.p12 -inkey myKey.pem -in cert.pem
The following methods are available for importing encrypted keys into a Futurex HSM:
Note: 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.
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.