By Mark Noctor, Director of Sales EMEA, Arxan Technologies
The subject of mobile payments won’t have escaped anyone’s attention over the past few months. It has been predicted by Juniper Research that by 2018 there will be 1.5 billion mobile wallets in use.The July UK launch of Apple Pay and the pending launch of Android Pay has wetted the nation’s appetite for simplified ‘Tap to Pay’ options with their smartphone, tablet device or watch. What may have once seemed like a futuristic concept, after all who would have predicted a decade ago that you could pay for your weekly supermarket shop by hovering your phone over a sensor, has now become a reality for consumers. Whilst these giant leaps in technological advancements are great in terms of giving consumers more options and flexibility, it does not come without challenges.
One of the greatest challenges in mobile payments is security. High-profile, international mobile breaches have brought security to the forefront. Consumers increasingly want to know if the app is secure, how their data is to be used and, more importantly, that they are well-protected against cyber-crime. However, in the race among mobile providers, app developers, banks, retailers and all other parties within the mobile ecosystem to deliver speedier, more convenient mobile payment offerings, security has been pushed down the agenda, meaning the app, the consumer and the data are at risk.
Mobile attacks are on the rise
In the past 12 months there has been an increase in the prevalence of mobile hacks and breaches. What started with the WireLurker malware, which could attack iOS applications in a similar way to a traditional virus, soon moved onto bigger vulnerabilities such as ‘Masque Attack’. This would lure a user to install an app that would replace an authentic app to enable the hacker to obtain user login details.In May this year the Starbucks app, which was used by customers making mobile payments, became the latest target when hackers took advantage of weak passwords and auto-reload functionality to drain customers’ Starbucks accounts and attack the credit cards linked to them.
These attacks represent a growing number of incidents related to the lack of mobile application protection. What is becoming evident is that attackers are using the critical data in a mobile application to motivate attacks not only on the app itself but also the back-end servers. These breaches, and in particular the Starbucks hack, highlight the importance of combining strong cryptography, secure server-side code, and binary-level code protection to create defence-in-depth.
Stopping mobile payment and app breaches
Step one for enabling secure payments is tokenisation. This is a critical piece of the puzzle as it protects transactions by replacing sensitive information, such as an account number, with a limited time substitute code. This one-time use token is a much safer transaction environment as it protects critical data, such as cardholder information and payment credentials, from potential misuse and fraudulent activity. So how do you also secure and protect the tokens?
There are a couple of schools of thought when it comes to mobile payments, which relate to the ongoing debate on ‘software vs hardware-based security.’ A hardware-based approach, as found with Apple Pay, although seen as restrictive and could offer little incentive to merchants due to the proprietary nature of Apple, has for a long time been viewed as stronger in terms of security. However, the software-based, Host Card Emulation (HCE) approach found in Android Pay is hot on its heels. Historically, payment credentials were stored in the Secure Element (SE), which is a restricted part of a smartphone, and typically controlled by mobile operators. However, the more open HCE approach enables mobile payments to be conducted without operator restrictions. We have seen advancements with the HCE approach come a long way in recent times, as it achieves a similar level of security protection as the hardware-based approach, and offers additional advantages of speed and agility. In fact, market longevity resides in the software-based approach’s favour – as long as certain security precautions, such as tamper-proofing software and whitebox cryptography are taken.
Step two is to mitigate the risks of the HCE approach by deploying comprehensive application protection or a Software Secure Element, in order to safeguard the integrity of the application and the cryptographic keys. Unprotected, HCE-based applications are exposed to attacks targeting transactional data, personal account information and the application itself.To strengthen the security in place, developers should look to implement stronger authentication systems by using whitebox cryptography technology, so services will only talk to the authorised app. Whitebox cryptography technology transforms the sensitive data (keys) to ensure transactional data integrity is upheld whether the payment data is at rest or in motion, whilst an automated security solution can simultaneously protect the application by alerting, blocking and defending against tampering attempts or compromises.
Let’s take the Starbucks incident as a case in point, it is one thing for the app to be able to talk to the server but the big problem comes when you can extract information such as logins and use anything to talk to the server. Whilst server-side checks should already be in place to mitigate this, attacks could be prevented and rectified by putting a strong challenge/response in place, such as whitebox cryptography, from server to the mobile app client so only the real client can obtain the data and access requested.
All parties involved in the mobile ecosystem, whether it is the likes of Apple, the banks or retailers, must wake up to the risks of not adequately securing mobile apps and the open payments ecosystem in which they operate. As more consumers start to reap the benefits of mobile payments, the security of them is going to be questioned. Nobody wants to be the first headline-grabbing victim of a mobile payments breach. It is time to take action and lower the chances of a future breach by implementing controls that will safeguard your app and, more importantly, your customers from the risks of hackers.