Software- vs. Hardware-based Encryption in the POS
A few years ago, I saw a video on the Internet about ‘lock bumping’ and ‘bump keys’. For those that don’t know, lock bumping is a frightening technique that can open almost any standard lock in seconds and requires practically zero skill (http://en.wikipedia.org/wiki/Lock_bumping). Even worse, it is non-destructive, and almost impossible to detect that it has occurred.
As someone who prides myself on being security-conscious, I did some investigation into how lock-bumping worked, the ease of access to the tools, and ways I could defend myself against the risk. At the time, there were very few bump-resistant locks available, and they were all fairly expensive. So I weighed the risk, measured my tolerance for that risk, and ultimately decided to do nothing. I concluded that protecting my house with my existing locks was a reasonable balance of security and cost.
I listen to the conversations going on within the payment security space about the methods for delivering “end-to-end encryption” between merchants and processors, and can’t help but be reminded of the first time I heard about lock-bumping. Specifically, I am talking about encryption performed within tamper-resistant hardware vs. encryption delivered in software.
Recently, First Data and RSA started customer tests of our payment security solution, TransArmor. The TransArmor solution is made up of two components: end-to-end encryption and tokenization. We made the decision to use public-key encryption and to perform the encryption in software that is installed on a merchant’s existing credit card terminals or point-of-sale systems. Given some debate in the marketplace, I thought that this week I would explain how one of the world’s leading encryption vendors came to make a decision seemingly counter to ‘best in class’ encryption methodologies.
Fundamentally, encryption is all about secrets. It protects data by obscuring it mathematically, and safeguarding the keys that can reverse the transformation. If a key is compromised, it is a safe assumption that any data encrypted with that key is compromised as well. So we try to find ways to protect the keys as best we can.
In our case with payment card transactions, one way to protect keys is to perform the encryption in a tamper-resistant credit card terminal. The idea is that the keys are kept safe in a piece of hardware that, if manipulated by an attacker, will self-destruct and keep the keys and data safe. From a purely technical viewpoint, we thought this was a pretty good idea, and considered requiring a tamper-resistant terminal for delivery of our encryption solution.
The problem we kept running into was that merchants really didn’t like the idea of having to buy all new terminals, and in many cases expressed that they would choose to not use encryption at all until their normal capital depreciation led them to replace their terminal infrastructure. Merchants who had recently done an infrastructure upgrade surely didn’t like the idea of ripping out their new terminals. And many of those who hadn’t are considering the possibility of a forced migration to EMV-capable hardware at some point in the future. Without knowing exactly what that might entail, the prospect of multiple rounds of infrastructure upgrades wasn’t the most attractive proposition.
To make our solution available to the majority of merchants (not just the ones willing to do a hardware rip-and-replace) we chose to utilize public-key encryption delivered in software. Most encryption solutions use symmetric key encryption, which utilizes the same key to perform both the encryption and decryption functions. Tamper-resistant hardware is almost essential to protect symmetric keys. Public key cryptography breaks that key into a key-pair: a public key that performs the encryption, and a private key that performs the decryption. In our TransArmor solution, the merchant only has access to the public key, which means they can encrypt data but not decrypt it. The private key is kept locked away in once place, the First Data datacenter.
Since the encryption uses software-based cryptography, it can be installed on practically any terminal new enough to be PCI-compliant, including many tamper-resistant terminals. It means card data can be encrypted immediately after swipe, before the data leaves the terminal. It also means that if a merchant wants to do in-store analysis of card numbers (such as fleet fuel cards where some customers can only buy fuel while others can also shop in the convenience store), they can do the encryption at the store controller. Yes, this means that the card data might not be encrypted immediately after swipe, but that is the merchant’s decision about acceptable risk in their business process.
And frankly, isn’t that what all of this boils down to? Balancing acceptable risk in support of the business? If a merchant chooses to encrypt at the terminal immediately after swipe or within the point-of-sale or in the store controller to support business processes, the solution should support that. If a merchant wants to utilize end-to-end encryption, they can choose their risk tolerance compared to costs and decide to use hardware or software. We made implementation of the TransArmor solution flexible enough to support whatever encryption choice makes sense to the merchant to secure the card data and protect it until it can be tokenized. Saying that there is only one way to do things is about as constructive as if I had decided that the existence of bump keys meant I shouldn’t bother locking my doors anymore.
True end-to-end encryption
A couple points: The statement “encryption is all about secrets” runs against the current accepted notion that you don’t achieve security through obscurity. Although a software solution is undeniably more convenient, a simple sniffer could catch the data before we encrypt it. Yes, security is expensive and it’s all about trade-offs. In this sense, this solution seems a good option, but certainly not where we want to end.
Response to True end-to-end encryption
Sorry if I was unclear above. I completely agree that security through obscurity is not a workable model. When I said encryption is about secrets, I meant that encryption only works when the encryption keys are held safely.
In the solution we have designed, a sniffer would be unable to capture the data before encryption, because card data is encrypted at the point of capture. The risk of the software approach is that someone could tamper with the physical terminal itself. However, if we successfully reduce the point of exposure to terminal-tampering, we have significantly improved a merchant’s threat profile.
- Robert McMillon