With all of the large data breaches we saw over the last year at Home Depot, Staples and Target, it’s time to rethink payment methods and mitigate the risk of such breaches occurring again.
Much of the risk boils down to transactions producing reusable data.
Tokenization emerged as one of the most important solutions for enabling secure payments. Tokenization protects transactions by replacing account information with a substitute code. By replacing something of high value, the secure personal account number (PAN), with something of lower value, the limited-time use card data or token, tokenization protects the original and unique PAN number from misuse.
This approach creates a much safer transaction for consumers and merchants because the data is created for a one-time transaction-specific use case.
However, tokenization alone is not enough to enable secure mobile payments. Tokens issued to phone memory must be protected by robust on-device software and the dynamic management of tokens (or card data) is managed by network-based software.
The Future of Payments
As time goes on, it will be increasingly important for on-device software to take on even more roles. Legacy risk management systems are not designed to handle dynamic, contextual data from connected devices. The on-device software needs to be adaptable to leverage a variety of security solutions. It should also be extensible to new solutions such as host card emulation (HCE).
HCE offers the ability to bypass a hardware-based mobile payment system. Prior to HCE, payment credentials needed to be stored in a highly restricted part of the smartphone, the secure element (SE), which is typically controlled by mobile carriers. Carriers were the gatekeepers to who and what gets access to a phone’s secure element, and typically charged for these access rights. Now, with HCE, phones can conduct mobile payments without a carrier’s control and constraints.
When account parameters are provisioned to the device, a limited-use key (LUK) protects access to sensitive information. The key can be used to allow payment transactions that are in accordance with the threshold parameters of the device, such as transaction count or time-to-live value.
Not without its Threats
Although HCE made provisioning credentials easier for a more open mobile payments ecosystem, security implications of bypassing the hardware-based SE need to be considered. Without further security of cryptographic keys, it leaves the credentials on the device prone to various kinds of attacks:
- Attackers could gain access to sensitive information such as payment credentials and cardholder information.
- Malware applications could attack the operating system (OS), and exploit the device and mobile payment app.
- Malicious users could gain access to information stored within the mobile payment application and use it to make fraudulent payments.
In order to mitigate the key security risks inherent to HCE, a comprehensive application protection solution or software secure element is needed to safeguard the integrity and confidentiality of both the application and cryptographic keys.
Robust white-box cryptography can protect sensitive cardholder and payment information in the token. White-box cryptography ensures the keys are never present either in the static form or in run-time memory, while an automated security solution comprised of unique guarding technology can protect the confidentiality of the application and combat application tampering by:
- Defending applications against compromise.
- Detecting attacks at runtime.
- Reacting to attacks with self-repair, custom responses and/or alerts.
As a result, such protection can provide the risk mitigation techniques and software-based security mechanisms. These protections provide robust security in place of hardware-based security for HCE-based near-field communication (NFC) applications.
With these advances in secure open payments ecosystems, mobile app payment providers are given more options and control to lower the risk of future breaches from occurring.