Traditionally, payment terminals have included some sort of security processing capability, a secure operating environment, used to protect keys, perform cryptographic operations and to act a as root of trust, enabling host systems to trust the device is genuine. POS terminals are also designed to be physically secure, and include all sorts of sophisticated tamper protection and tamper detection capabilities built into them, designed to render them useless and to delete the keys should any sort of tampering occur.

With the move to SoftPos, where a standard Android mobile phone becomes the POS terminal things are very different. Android phones are open general-purpose computers, running what has to be treated as a rather insecure operating system, designed to simultaneously run all sorts of unrelated applications. Android had a reputation as being highly insecure, however it has improved a lot since the early days. As long as you are using a recent version, and perform a bunch of additional checks to ensure it’s a legitimate device and hasn’t been rooted, PCI, pcisecuritystandards.org, the standards body that is responsible for ensuring that payment card details are safe, provides its blessing to deploy SoftPos applications on it.

How is it possible to develop a secure SoftPos solution?

I have to be honest with you, it’s not easy. There are many challenges and hurdles to overcome, and there are several approaches that can be taken. There are two broad protection mechanisms that have to be deployed into SoftPos solutions; a method of for protecting the cryptographic keys and an application shielding solution to prevent the apps from being reverse engineered or tampered with. In this piece, I’m only discussing the key-protection needs, as whatever you do, when you deploy SoftPos solutions, you will need to implement application shielding measures to protect from reverse engineering, rooted devices and tampering. As for the keys, there’s a few ways to ensure those keys remain protected. So, lets discuss the options.

Hardware-backed key protection, the gold standard?

Hardware-backed protection has always been the gold standard, its what’s used by the operating system keystore to hold keys used for applications such as DRM, protecting the biometric sensor or payment apps such as Samsung Pay. The operating systems generally rely on one of two methods to achieve this security, a dedicated cryptographic processor or a Trusted Execution Environment (TEE). A TEE is a mode of operation available on the microprocessors found in the heart of mobile phones that enables a secure operating system to run alongside the normal Android operating system. Whichever method the device uses, hardware protection is very secure. But gaining access to it for a third-party application to make use of isn’t so simple. There is no standard open hardware-based mechanism available to third party developers on the vast majority of devices. So, if you wish to achieve mass scale SoftPos deployments, hardware backed protection probably isn’t the option for you.

Software security, the white-box approach.

The next method is to use software-based protection mechanisms. These typically make use of special security software called white-box cryptography, there are other methods also, but this is by far the most used. White-box cryptography uses special methods to implement a cryptographic algorithm in software in such a way that the cryptographic keys and data always remain secure even when the algorithm is in use. White-box cryptography is designed to deal with the assumption that an attacker has full access to the application, and therefore it has to ensure the keys are never

leaked. However, the reality is that white-box cryptography is a software-based mechanism, and a highly determined and skilled attacker, given enough time, will likely eventually gain access to the keys. To mitigate against that risk, PCI mandate that the keys and white-boxes used in SoftPos applications are replaced at least monthly. This however isn’t an insignificant task, as it means all apps need to be re-built monthly, including new keys and new white-boxes, and they also need to be distributed to customers handsets. To be honest, it’s a big administrative challenge for big SoftPos deployments, and it’s very hard to manage.

No device-based key protection, yes you read that right!

There’s another approach that’s starting to gain traction in the industry, and this one that isn’t reliant on any sort of key protection on the device. PCI have stated that as long as applications are deployed on recent Android versions, and that sufficient steps are taken to assure that the device is the one it claims to be and that it isn’t rooted, keys resident in the device memory are out of risk. The standard states that the keys can never be stored on the device, which brings its own challenges. But if you can overcome this and design a solution that requires no local key storage, you have massively reduced your risk, while also removing the need for the challenging monthly white-box updates.

So how is this possible?

Well, that’s a conversation for another time. Again, it’s not easy, some would say it’s harder to deploy than the current systems and brings its own special challenges, but there are also lots of benefits. I expect to see multiple different approaches on the market in the coming years, and it’s great to be pushing the boundaries of what’s possible. I would love to hear your comments, and if you would like to learn more about SoftPos solutions, just get in touch.