As new types of fraud emerge in the modern payment processing industry, the concept of point-to-point encryption (sometimes referred to as end-to-end encryption) becomes more and more relevant as an additional protection mechanism. The purpose of this article is to provide an overview of what the concept is and how it can be implemented in your payment system.
So, we are talking about an additional protection mechanism for the cardholder’s data, transmitted between the point of entry (usually, payment terminal) and the point of processing (usually, payment gateway or a processor). While SSL encryption is always used at the communication level, point-to-point encryption provides yet another protection layer to secure the information further (since under certain circumstances SSL communication can be compromised).
There is no consensus on the best encryption methodology or algorithm to use for this process. Some people choose to use symmetric encryption keys and triple-DES algorithm, as it is done for PIN encryption. Others choose to use asymmetric encryption keys and algorithms, such as PGP.
There are several reasons why people choose one algorithm over another. Sometimes, the choice is dictated by the performance of a particular encryption algorithm (limitations of the device), sometimes – by limitations of the HSM system used to eventually decrypt the data.
When choosing the algorithm that you want to use, you have to consider the requirements around your encryption process and requirements around your decryption process.
Decryption
The first thing is where and how the decryption algorithm is going to be implemented.
Decryption can be performed in one of the two ways: either using software, or using hardware (hardware security module (HSM), which is, basically, a hardware implementation of a particular decryption algorithm). It should be noted that only a solution with HSM can be certified as a PCI-compliant point-to-point solution.
The advantage of HSM solution is that the key is stored within the hardware device and never exposed to the outside world. Therefore, the device is capable of decrypting any value, without ever exposing the key, stored within it.
When a non-HSM solution is used, a decryption key is, generally, stored in some secure fashion. However, it has to be extracted from this location, and loaded into the memory of the server, executing the decryption code. Potentially, the key can be intercepted during this process, and, to prevent this, HSM solutions exist.
Encryption
The other fundamental thing to consider is: at which point the encryption is going to take place.
In the ideal world, the hardware that you use would encrypt the data at the point of card insertion, or at the point of swipe. However, there are a lot of terminals that do not have this capability.
The next obvious location to place your encryption logic would be within the terminal itself (as this reduces the path that unencrypted data has to travel, and it is more difficult to penetrate a terminal, than it is to hack a regular workstation). However, this approach can be used only in conjunction with an embedded terminal solution. Besides, embedded terminal developers are somewhat difficult to find.
On the other hand, there are many solutions today, which are not embedded, and which implement terminal-controlling logic outside of the terminal as a form of DLL library.
Consequently, unencrypted data has to travel between the terminal and the DLL library (usually, through a serial or USB port). At the same time, a piece of code running on a workstation is exposed to unencrypted card data, which might have additional PCI audit consequences.
Theoretically, you could still implement a decent point-to-point encryption solution, using this approach. However, you will, likely, have to go through separate PA-DSS certification of the code, handling the encryption of the card. The reason is because it is deployed into a merchant’s network that cannot be managed by security personnel of the payment company which provided the solution, and, therefore, cannot be covered by the PCI audit of the company.
It should be stressed that one of the key reasons why point-to-point encryption procedures are used and independently certified is that they enhance the security and reduce the possibility of problems, emerging on the merchant’s end. However, point-to-point solutions can also be separately PCI-certified as a solution, taking the merchant out of PCI scope. The premise is that encryption is performed at the point of swipe (or somewhere close to it) and decryption is only possible at the gateway or processor level, so that the software, that falls in between, has no ability to access card data in any way.
Point-to-point encryption and tokenization
An important thing to consider is that point-to-point encryption often comes in conjunction with tokenization. For straight retail businesses that only do one-time purchases (such as grocery stores and supermarkets) the storage of card data for repeat purchases may not be relevant, and, therefore, tokenization will not be required. However, many companies have use cases that require them to reuse cards at some point in the future for on-account purchasing or recurring billing. Health clubs provide a classical example.
In a traditional scenario, when an unencrypted swiper is used, the account number can be extracted from track data by any intermediary software components, including POS systems. However, when point-to-point encryption is used, the decryption capability, usually, resides somewhere at the very end of the “path”, i.e. either with a gateway, or with a processor, and, therefore, no intermediary parties have access to the card data. Because of that, they will, generally, expect some form of token to come back from the processor, associated with the card, allowing to use the card again for repeat purchases or recurring billing.
Conclusion
Point-to-point encryption is a useful practice, which may prove handy for your business, but it has a lot of important aspects associated with it, and each of these aspects must be carefully considered (particularly, from budgeting viewpoint) prior to implementation of some specific solution.
Visit the UniPayGateway website if you are interested in the diagram illustrating this topic.
Recommended to you
