Host-based Card Emulation: the magstripe of mobile payments?

September 6, 2016 - The impact of the Android QuadRooter attack on the security of HCE

The popularity of mobile devices is rising since the last decade. The last few years these mobile devices are also being used for more critical services like mobile banking and mobile payments. This trend exposes these devices as an attractive target for attackers. Statistics show that the number of vulnerabilities found on mobile devices is increasing rapidly. What does this increase in vulnerabilities mean? Should we be worried about the current mobile payment solutions and in particular software based solutions like HCE?

Figure 1 - Statistics from CVE Details on Android vulnerabilities1

QuadRooter

Recently four vulnerabilities were detected by CheckPoint in a GPU driver from Qualcomm. These vulnerabilities allowed for an attacker to gain so called root access to impacted devices. Because there were four vulnerabilities which allowed for this root access the hack was named QuadRooter.

The affected Qualcomm chipset is used in many different and recent handsets, including main stream devices like the Galaxy S7, Nexus 6, and HTC One. QuadRooter potentially affects over 900 million devices. With root access basic security measures from the Android operating system, such as application sandboxing are compromised, which puts data stored within software applications at risk.

Malicious apps claiming to fix the vulnerabilities from QuadRooter actually exploit the vulnerability. These apps popup on numerous un-official app stores and one of them was even detected on the official Google Play store, where it was removed quickly.

Google’s response

Google claims that while devices are technically vulnerable, the impact is limited. This claim is based on the assumption that security features from Android like Verify Apps and SafetyNet scan and remove applications that exploit vulnerabilities like QuadRooter. The VerifyApps feature has been turned on by default since 2012 on Android devices running Android 4.2 or higher and have Google Play Services installed. This should protect at least 90% of all devices according to Google. However, this still leaves 10% of the devices vulnerable.

Android Patch management

Vulnerabilities are detected often and patches including fixes are released on a regular basis. 3 out of the 4 vulnerabilities of QuadRooter have already been fixed, see the table below.

Vulnerability

Fix date

CVE-2016-2503

Fixed in Google's Android Security Bulletin for July 2016

CVE-2016-2504

Fixed in Google's Android Security Bulletin for August 2016

CVE-2016-2059

Fixed in April, though patch status is unknown

CVE-2016-5340

Will be addressed in an upcoming Android security bulletin

However, the availability of a patch doesn’t mean that these fixes are released to all devices. We actually see that Android patch management leaves a lot to be desired. Google publishes the fixes in their security bulletins and applies them to their own Nexus devices. However, for other devices the Original Equipment Manufacturers (OEMs) will need to include the fix in their next firmware release, which usually takes more time. That is, if the device is still actively supported.

If you have a device which runs on a custom firmware adapted by the Mobile Network Operator (MNO), the patch will arrive even later, as these firmware versions first require patching of the OEM after which the MNO will need to apply their branding on the updated firmware before it is being released to the end-users. Recent research showed that due to these reasons around 88% of Android devices remain vulnerable to at least one exploitable vulnerability as a consequence of slow patch management.

The rise of HCE

‘Traditional’ NFC mobile payments rely on a secure element to protect the payment credentials. A secure element protects the data inside the chip from being accessed by the outside world. In the same way that no data, other than what is intended, on an EMV payment card can be read by a terminal, the data inside a secure element cannot be accessed by the operating system of the handset.

While giving excellent security, the use of a secure element has come with its own set of problems.  The two most commonly used secure element types are the embedded secure element, which is controlled by the OEM and the UICC (a secure version of a SIM card), which is controlled by an MNO. The world of a bank and an MNO or OEM seemed too far apart to come to an agreement on e.g. testing, branding strategy and a business case that was acceptable for all parties. Most initiatives have therefore stranded after pilots or roll-out amongst a relatively small user base.

With combined projects with MNOs or OEMs progressing slowly, banks were yearning for independence in rolling out their mobile payment solution. However, the only remaining alternative: using an NFC capable micro SD-card as a secure element, was an even less attractive solution. The main selling point of mobile payments is that, eventually, the mobile handset can replace a customer’s entire physical wallet. This goal can only be met if cards from all Issuers can be loaded onto that handset. A handset only has one micro SD-slot. If each bank does issue its’ own micro SD-card a consumer will have to carry a set of micro SD-cards instead of a set of ‘normal’ plastic cards. That does not add any value for that consumer.

With each secure element type having its own difficulties to get implemented, NFC mobile payments had quite a tough time taking off. That was until Google announced Host-based Card Emulation in Android KitKat 4.4 and Visa and MasterCard published their Cloud-Based Payments specifications in 2014. All of a sudden, Issuers could issue NFC mobile payments in a scalable manner while having full control over the issuance cycle. Needless to say that Issuers embraced this opportunity for independence, leaving MNOs and OEMs empty handed. With the vast majority of new mobile payment deployments on Android using HCE, the question rises whether the introduction of HCE killed the secure element.

Impact of Android vulnerabilities on HCE mobile payments

The almost exponential rise in exposed Android vulnerabilities, culminating in the QuadRooter root exploit, raises the concern whether highly fraud sensitive applications such as mobile payments have a place as a software based solution, or if this poses too big a risk. A root exploit being discovered is a serious security concern. If a hacker manages to remotely root a device via the QuadRooter exploit, many inherent Android security features, such as sandboxing, are lost. A hacker with these capabilities, can easily install malware at the same time to try and extract the payment keys.

The good news is that security tests and certifications by the major payment schemes for Cloud-Based Payment solutions always assumed a rooted device and thus have measures prescribed against extracting the payment keys. In that sense the current prescribed local measures such as single or limited use keys, white-box cryptography, code obfuscation and anti-tampering should still be sufficient to minimize the risk of a software solution to an acceptable level, as they either ensure that a fraudster needs to invest a significant amount of time to hack a single instance of an HCE implementation or make sure the gain of such a hack is limited.

However, Issuers should be very careful to just consider HCE solutions secure without knowing the full extent of the associated risks. With HCE implementations now becoming common ground, there is the pitfall of considering them secure enough just because everybody is using it. The magnetic stripe has been considered secure enough by a many Issuers. And for many it actually was. However, this was only the case for those who realized what risks they were taking with a magstripe and build sufficient security measures in their back-ends, such as real-time fraud detection.

The same goes for HCE: security can be arranged in more than one place. Without a secure element, anything loaded in software on a customer device should always be considered as easily compromised. It is not secure to deploy a cloud-based payment app once and then no longer look at it, until new business features are required. It requires constant monitoring, both on the app and server side. Essential measures include, but are not minimized to:

  • On the app side new developments on the security, should be monitored closely. E.g., the current solutions rely heavily on whitebox cryptography. Whitebox cryptography typically uses proprietary algorithms. If such an algorithm gets compromised it is essential that the payment applications in the field can be patched within a matter of days.
  • Regular security evaluations and pentests of the entire ecosystem (app and server), scanning for both vulnerabilities that have been introduced due to changes in the application, as well as newly discovered zero-day vulnerabilities are essential to make sure the application is still secure enough.
  • Additional server side measures, are essential. The system must have ways to detect an application instance showing fraudulent behaviour. This implies that a real time fraud engines should monitor the transactions.
  • Make sure that the employees implementing and maintaining the mobile payments solution are knowledgeable in the security measures taken. That way they are able to spot (mass) fraudulent behaviour.

For Issuers where the necessary updates to the server would be too big or for Issuers who don’t have the means or skills to enforce the security server side, HCE is a dangerous road. Those Issuers should seriously consider leveraging the other benefit that HCE has brought: bring the MNOs and OEMs back to the discussion table for a more compelling offer to use the build-in security of a UICC or embedded secure element.

 

Disclaimer

These are the personal opinions of UL’s employees and its guests and should not be misunderstood as representing the opinion of UL's clients, suppliers or other relations.