'Host Card Emulation' Vs 'Secure Element': Which Is More Secure?

Although Apple is using a Secure Element to safeguard Apple Pay credit card transactions, competitors such as Google and Microsoft have decided on Host Card Emulation (HCE) as an easier way to bring secure mobile payments to whole ranges of devices. Although HCE is easier to implement, it may not have been the best choice in terms of security.

Host Card Emulation (or Cloud-Based Secure Element)

Google implemented the host card emulation feature more than a year ago in Android 4.4 as a way to get around carriers' requirement for a SIM-based Secure Element. Secure Elements are hardware components in which the credit card number can be stored, with limited interaction with the operating system other than to be used for mobile payments.

The secure elements can exist either on the chip (embedded), or in SIMs, so it's like using a smart card in your smartphone. Google adopted a chip-based Secure Element initially, but the carriers demanded that the Secure Element be tied to their SIM cards, presumably as a way to control the mobile payments market, and to delay Google Wallet from taking off.

HCE is essentially a cloud-based Secure Element, where the emulation of the card happens on the device while using a virtual credit card number. Then, that number is verified on the mobile payments provider's servers. After that, the real credit card number is sent to the merchant to authorize and complete the transaction.

HCE - More Scalable, But Less Secure

HCE is considered both less private and less secure than using a Secure Element on the device. For example, in Apple Pay's case, Apple doesn't even keep the real credit card data in the Secure Element, but only a token, or virtual number, as per the EMVco tokenization standard.

Thus, even if the security of a device is compromised, the attackers can't get the real credit card data. Apple has also paired its iPhones with the Touch ID fingerprint authentication and the "Activation Lock" system, which further prevent the use of the phone for unauthorized purchases, even with a stolen iPhone.

On the other hand, cloud-based solutions can benefit from multiple ways of securing the credit card data, although they ultimately depend on how much those companies are willing to invest in securing that data.

Perhaps a company such as Google or Microsoft can take all the steps they can to secure data by using limited-use keys, tokens, device fingerprinting, and transaction risk analysis. However, not all mobile payment providers, or even banks, are going to do that. Even today, most banks don't use the most secure possible settings for HTTPS connections, for instance.

As we've seen in the last year, companies that store credit card data are also targets of sophisticated attacks, and many of them can leave tens of millions of customers' credit cards exposed.

Less Privacy With HCE, As Well

In terms of privacy, HCE can also receive a smaller grade than Secure Elements. The mobile payment providers can see who uses a certain credit card number, and then they can even choose to share that data further with merchants or other companies for commercial and advertising purposes. This is something Google has already done with Google Wallet.

With a Secure Element, that data cannot leave the device itself. Even the merchant can't see the real credit card number if the EMVco tokenization standard is implemented, just like in Apple Pay.

So Why Host Card Emulation?

The main advantage of host card emulation is not security, but scalability. For an OS vendor such as Google or Microsoft, it may make more sense to do Host Card Emulation, because their operating systems work on other companies' hardware, and it's more difficult to require them to support certain hardware. It also ends up making low-end phones more expensive, and low-end hardware is what drives the bulk of OS market share for Google and Microsoft.

Unless that extra hardware is highly critical for the future of the platform, OS vendors will try to find a different solution that works for everyone without any extra effort from their partners. However, in this case, it can be argued that the Secure Element is indeed critical for mobile operating systems, because mobile payments themselves are an important service the operating systems need to support.

That doesn't necessarily mean we won't still see embedded Secure Elements being adopted in Android devices, or even in Windows 10 handsets. However, in the latter's case, Microsoft decides what works with the operating system and what doesn't. On Android, Samsung or some other OEM could decide to adopt it, regardless of Google's default solution.

Ultimately, it boils down to the decision to make security device-centric or cloud-centric. If devices tend to be unsecure in general, then it may make more sense to adopt cloud-centric security. However, that means putting all the trust, privacy and security into the service provider's hands. It also means that if that provider ever gets hacked, it could leave millions of people's sensitive data exposed at once.

On the other hand, even if individual devices can be hacked, device-centric security can be made strong enough if OS vendors decide to use strong defaults. The OS vendors could require Secure Elements from the device makers, using strong authentication mechanisms and remote capabilities that can render the devices useless to thieves.

Follow us @tomshardware, on Facebook and on Google+.