Financial Remote Key Loading

The financial remote key loading landscape

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, PKI-authenticated connection with each device and remotely distribute 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.

Automated Teller Machines (ATM)

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 (1). 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. The rate of ATM growth is still swelling, with 4 million installations worldwide predicted by 2020 (2).

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.

Point of Sale (POS) Terminals

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.

Cryptographic Techniques for Financial Remote Key Loading

In order for the endpoint device (whether an ATM, Point of Sale terminal, or IoT device) to receive symmetric encryption keys for PAN or PIN encryption, it must first establish a secure connection with the remote key platform. PKI is a form of asymmetric cryptography where the sender and receiver use public and private keys to both decrypt messages and verify each other’s identity. PKI allows the endpoint device and the RKL platform to verify each other’s identities and securely exchange keys.

Certificate-Based RKL (Using RSA Key Exchange)

Certificate-based RSA PKI is the most common and accepted method of RKL communication. Unlike symmetric cryptography where a single encryption key can be used to encrypt and decrypt a message, asymmetric cryptography requires two keys to communicate. A public key is used to encrypt and send the message by the sender, and a private key is used to decrypt the message by the recipient. This adds another layer of security in that not only is the message encrypted, but the recipient’s identity is verified and authenticated by possessing the appropriate private key.

PKI is the cryptographic backbone of RKL. For ATMs and POS terminals to receive and decrypt the keys sent to them by the RKL service, they must first be possession of a private key, which is known as a certificate. This certificate is injected into the POS terminal or ATM, usually at the time of manufacture by a certificate authority. Once the endpoint device receives its unique certificate, it can be deployed in the field where it can establish a secure connection. This facilitates the exchange of keys with the RKL platform.

The Accredited Standards Committee (ASC) X9, the component of the American National Standards Institute (ANSI) responsible for developing consensus standards for the financial services industry, has established Technical Report 34 (TR-34), which outlines the methods for remote distribution of symmetric keys using asymmetric encryption. TR-34 establishes the certificate-based RKL protocol as the preferred method of delivering encryption keys to POS and ATMs.

Signature-Based RKL

Another cryptographic technique used to establish a secure connected for RKL is signature-based. This method is primarily in use among older ATM networks. While similar to certificate-based RKL in some ways, it uses a digital signature that encrypts the key before being sent to the ATM. Signature-based protocols are more simplistic and require less data being sent, which may make them more suitable for older ATM networks based on dial-up connections.

Symmetric Key RKL

Some manufacturers inject keys into their own devices before deployment. In this symmetric key RKL model, the certificate establishment is skipped by integrating the initial symmetric key injection into the manufacturing process. While its not as prevalent as certificate-based RKL, it is still in use by many organizations.

Futurex and VirtuCrypt’s Solutions for Remote Key Loading

Futurex and VirtuCrypt are the industry’s only single-vendor providers of complete cryptographic infrastructures for payment security. Many of Futurex’s most important services, like PIN encryption and validation, P2PE, and tokenization, rely on secure and compliant key management.

In response to the growing demand for RKL with the financial services industry, Futurex and VirtuCrypt have developed the most robust RKL solutions in the industry. Whether choosing cloud functionality through VirtuCrypt, on-premises hardware through Futurex, or a combination of both, each solution has the functionality needed to build a comprehensive, single-vendor solution for all cryptographic processes related to financial services and payment processing.

On-Premises Hardware Solution: the Futurex Hardened Enterprise Security Platform

Futurex’s Hardened Enterprise Encryption Platform is an advanced product line of HSMs, key management servers, and payment data security solutions.Within the Hardened Enterprise Security Platform, the primary RKL platform is the Remote Key Management Server (RKMS) Series 3. The RKMS is a complete key management solution for generating, distributing, and injecting POS and ATM encryption keys. The RKMS was designed from the outset with RKL as its primary purpose. It is a sophisticated single-device solution for organizations seeking to transition from direct key distribution to RKL. The RKMS is equipped with an internal Secure Cryptographic Device (SCD) for key storage. It is fully compliant with Federal Information Processing Standards (FIPS) 140-2 Level 3, PCI HSM, and all other major industry standards for security.

The flexibility of the RKMS Series 3 allows individual customers to choose how automated, or how much user interaction is required, which is typically predefined by the customer’s security policy. The RKMS Series 3 can be fully automated after initial setup and loading of the major keys. For the RKMS Series 3 to be fully automated, it requires integration by incorporating the RKMS Series 3’s application programming interface (API) into the host system. The integration application can be written in any language that allows for basic TCP/IP support (Java, C, C++, etc.). The RKMS Series 3 uses the Futurex proprietary interface with a fully-functioning GUI.

Cloud Solution: the VirtuCrypt Cloud Payments Platform

For clients who prefer “as-a-service” cryptographic functionality, Futurex key loading solutions are available through the VirtuCrypt Hardened Enterprise Security Cloud. VirtuCrypt is best-suited for organizations who prefer hosted cryptographic services as opposed to maintaining their own on-premises hardware. With the VirtuCrypt Elements RKL Service, VirtuCrypt will act as a key distribution host by securely automating the manual key replacement process by managing and loading keys from one central location over a secure IP network. VirtuCrypt is powered by Futurex hardware, which means that VirtuCrypt clients will receive the same security and compliance benefits that would come from owning Futurex hardware, in particular FIPS 140-2 Level 3 and PCI HSM compliance.

Security concerns about the cloud usually revolve around the idea that sensitive data being transferred or stored within the cloud may be viewed by unauthorized people. However, VirtuCrypt’s innovative approach to the cloud alleviates these concerns, with all sensitive data being encrypted, decrypted, and authenticated in FIPS 140-2 Level 3 compliant Secure Cryptographic Devices located within SSAE 16 (SOC 1, 2, and 3), PCI, TIA-942 Tier 4, and HIPAA-compliant data centers.

The VirtuCrypt Intelligence Portal (VIP) Dashboard gives customers this centralized management platform for all their VirtuCrypt hosted services. With the VIP Dashboard, users can securely communicate directly with the Futurex device performing the service at the VirtuCrypt data centers. This allows users to import keys and manage key receiving devices. Additionally, users can view and export audit logs detailing past key injections and various other individual user actions.