Hackers target the weak link and in the case of mobile payments, this is rarely the payment provider. Incorporating mobile payments into wearable devices is desirable, but security is paramount.
Payment providers such as Visa and Mastercard build in many security features (as part of the Payment Card Industry Data Security Standard- PCI DSS) to facilitate electronic transactions whilst keeping users’ information and, most importantly money, safe from hackers and fraudsters.
Hackers will always attack the weakest link in any chain and, in terms of mobile payments, this is rarely the providers themselves. If you’re implementing or incorporating mobile payments into your product then you need to build on the providers’ security systems to implement a system that is fully secure overall.
The most basic system is to store the card details and customer credentials on the device. This is the riskiest way of handling data but it can be sufficient if the risks are mitigated by using strong access control methods to the device and its data.
Pre-paid systems can also be implemented using a more basic level of security as the rewards of hacking are strictly limited, making it a less attractive target. The more value that can be extracted, the more time and money hackers are prepared to spend attempting to break the system.
Tokenization is proving to be one of the most important techniques in the safeguarding of mobile payments. Instead of using a customer’s real card details, a token is generated and used instead. That way, if the system comes under attack, the only information that a hacker can obtain is a useless token rather than a usable card number. Apple Pay and Android Pay both implement tokenization as do virtually all other mobile payment systems.
Read more: Mobile payments technology explained
Mobile payment systems generally use one of two different systems to handle the storage and access of tokenized payment details.
Host-Card Emulation (HCE) payment applications handling the tokens reside in the handset host, or in the cloud. Although easier to implement, it can be less secure as the wearable relies on the HCE in smartphones and the connection to it. The weak link is the connection between the wearable and the mobile device, or even a poorly implemented HCE in the smartphone.
Android Pay uses HCE, and stores pre-generated tokens for use when the network is unavailable. The Wirecard Smart Band also uses HCE, together with Bluetooth low energy to communicate with the smartphone.
Secure Element (SE) is a tamper-resistant hardware component that stores the payment application and tokenized payment data. The payment is not network-dependent so there’s no transmission of any details to be intercepted and if the handset is compromised there is no way of card data being exposed. Even if someone did manage to hack a Secure Element, it’s a single user’s credentials so a hacker would need physical access to a large number of handsets before they managed to obtain a useable amount of data.
Ultimately the decision on which system to implement will come down to how easily you can include a Secure Element into your product. If you can then you probably should, if not then you can base it on an existing smartphone HCE, with appropriate security considerations.
Both of these approaches have their benefits depending upon the application and whether the technology meets the level of security required to protect the payment credentials.
Apple Pay uses aspects of both SE and HCE in a hybrid system. By including the Secure Element chip on the phone but also using the cloud Apple has built a system that both includes the security and mitigates the risks of each technology. In doing this they have shown that rather than focusing on one technology against another, often the best system is to look at what is needed and work out the best way to achieve it.
Read more: Usability of mobile payments
Whether you implement HCE, SE or a mix of both, your solution will need to be EMVCo certified before payment providers will allow you to integrate with their systems.
EMVCo established the Contactless Mobile Payment (CMP) Product Type Approval process to create a mechanism to test compliance with the EMV specifications. It's designed to increase confidence for consumers, payment providers and device manufacturers, by ensuring adequate security is in place.
No matter what systems you implement for your mobile payment solution you will need to ensure that you build in robust security and don’t rely on the security of payment providers.