Futurex payment HSMs

this section covers the following payment hsm topics the excrypt plus and excrypt ssp enterprise v 2 supported application programming interfaces (api) 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 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 supported apis 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 excrypt the excrypt universal interface (ui) is an 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 apis because it can interpret a range of different command syntaxes used in host applications with the following benfits extensible design simple command syntax wide spread compatibility standard and international 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 restful (json) 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 supported key blocks we support the following key blocks, described in this section variant or modifier based cryptograms tr 31 akb international key block key table variant or modifier based cryptograms 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 tr 31 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)) 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 is an integrity check of the header and key data and ensures that the key block is unmodified 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 akb a key that is secured by the akb 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 international key block 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 adding the optional extra header block provides more leeway in the management of the key key table 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 key storage methods when considering different key storage methods, the following considerations come into play consideration description do you store keys on or off the hsm? for most payments related use cases, you store keys off the hsm rather than inside the key table on the hsm when you keep keys off the hsm, you encrypt them with a master key that is stored on the hsm in what format do you store encrypted keys? generally, you store encrypted keys 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 the american nation standards institute (ansi) developed tr 31 key blocks, so they have more widespread support than the alternatives key transport methods various options are available for transporting keys from an external source to a {{futurex}} 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 exporting keys from third party hsms or key management servers typically, third party (non {{futurex}} ) 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 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 openssl pkcs12 export out bundle p12 inkey mykey pem in cert pem encrypted key import use the following methods to import 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 clear key import use the following methods to import clear keys into our hsms full clear key import using excrypt manager if you have the full clear key value, you can import it into the {{futurex}} hsm by logging in under dual control through excrypt manager and then loading the key by using either the symmetric or asymmetric key loading wizard component import with either excrypt manager or fxcli you can load clear keys as components in this scenario, more than one person possesses the clear key values for different parts of a key component holders must log in to the hsm under dual control (by using either excrypt manager or fxcli) and load each of the key components then, the system xors the key parts together and stores them on the hsm this option is most common in the payment space convert to kek for batch import if you need to import a large number of keys, making logging in under dual control and loading every individual key unfeasible, you can encrypt all the keys under a single kek and then batch import them into the hsm by using the twks excrypt command tls (server side authentication), mutual tls (mtls), and clear socket 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