Battle Looms Over Mobile Payments

The lines are drawn. The sides are sizing each other up. Apple is on one side with secure element, and Google and Microsoft are on the other side with host card emulation.

Both are mobile payment systems for smartphones that rely on near-field communication technology. Apple fired the first shot with SE, and Google soon replied with HCE. And now both sides are ramping up after months of delays for what appears to be a protracted battle.

“At the moment, the mobile payment space, of which HCE is one part, is big land grab,” says Simon Blake-Wilson, vice president of products and marketing for Rambus’ Cryptography Research Division. “For a long time, there was a lot of hype surrounding mobile payments, with lots of potential but not a lot of progress.”

HCE 101
HCE is now beginning to gain traction. Also known as cloud-based security, HCE does in software what SE does in hardware (see Figure 1).

Fig. 1: HCE model. Source: Smartcard Alliance

“HCE is a way for the apps processor on the smartphone to talk to the NFC chip integrated into the smartphone,” says Blake-Wilson. It is a virtual representation of identity for payment functions via software, as opposed to SE, which does that with a chip (See Figure 2). [Appendix A is a comparison of both platforms.]

Fig. 2: SE and HCE architectures. Source: Smartcard Alliance

Until HCE appeared on the scene, there was only secure elements. SEs are security chips integrated into operator-issued subscriber identity module (SIM) cards, universal integrated circuit cards (UICCs) or secure digitial (SD) cards. That created a problem because mobile network operators tried to corner the mobile payment market by tying the SE to SIM cards. In fact, Google originally was going to implement the SE, but realized the constraints of being restricted by the carrier industry.

The way the SE model works is that all participants are required to implement contractual agreements with each SE owner. The owner creates a security domain inside the SE for each issuing bank, which grants access to the issuer. While highly secure, this sets up dependencies for issuing banks to the SE owners. “Mobile network operators were trying to muscle in on the mobile payment industry by leveraging their own devices to get a piece of the payment transaction revenue stream,” says Blake-Wilson.

In effect, that requires a rental agreement for the secure element. It also sets up a roadmap-type of dependency all the way from the bank to the customer, including the vendor and the mobile network operator, which gets complicated because service issuers are massively deploying SEs to their customers – SIMs for mobile network operators, embedded SEs for OEMs. They also integrate with the Trusted Service Manager (TSM) infrastructure. As a result, the mobile network operators that issue the SEs control the entire user ecosystem with their own branded wallet application.

On top of this, there are multiple SE owners operating in a worldwide mobile payment ecosystem, each with its own way of implementing SE. That requires mobile network operators to maintain an exclusive business and a technical relationship with each one to make their services available.

That stymied competition and limited the devices that companies such as Google and Microsoft could offer to use with mobile payments. So Google decided to come up with an alternative called HCE, making an end run around the operator. Microsoft soon joined in, and both sidestepped the mobile network operators that control the SE ecosystem.

Because HCE is an independent application and can run on any supported OS, it offers payment and access card solutions independently of third parties. It still leverages nearly the same cryptographic processes of hardware-based secure elements, but without the need for the physical hardware of the SE.

HCE methodology allows vendors to offer payment cards solutions via a mobile, closed-loop contactless payment application. One of its biggest advantages is that it offers real-time allocation of payment cards and doesn’t require modification of the software within the payment terminals. In HCE, the phone OS is the intelligence behind it. In a point-of-sale transaction, for example, the OS will pick one of two possible communication options for NFC commands. The app requests a transaction application identifier and, depending upon the feedback from that identifier, decides which path to use.

The phone OS then takes the application identifier passed from the phone’s NFC controller and routes those NFC commands to either the SE or to the trusted app that manages the HCE. For example, the Android KitKat OS routes it to the HCE service that is called by issuer apps on the phone. When the user presents an HCE-platform card for transaction, NFC uses a mobile application manager to route the client app for authorization and verification, and processes it though a mobile application manager. As part of the process, the mobile application manager connects to the issuer payment system to complete the transaction. The glue here is the cloud server managing the issuance of card data, the cloud account, and the transaction processor.

Details
The major difference between SE and HCE is where the credentials are stored. With SE, the credentials are stored in the chip. With HCE, the credentials can be stored on the device in the form of a static image. But the best solution is to store them in the cloud, which is much more secure than as a static image on the device. SE does not have that issue because it uses cryptography to encode the data.

“You can look at the advantages of one over the other in a lot of different ways – technical vs. business, for example, but from a technical perspective the dedicated SE is more secure because it is dedicated hardware,” says Blake-Wilson. “It is also more complex to deploy. HCE, on the other hand, is much easier because it is quite easy to provision stuff to an app on the main processor, compared to provisioning the same on a stand-alone chip. But it is also less secure.”

When credentials are stored in the cloud, it can be done with or without tokens. If a token-less transaction is made, it is authenticated by the cloud, via the credentials entered from the mobile applications. Credentials are then sent to the mobile device, where it is transferred to the payee. The major downside to this process is that it is relatively insecure.

With tokenized transaction, the process becomes more secure. Essentially the payer app gets provisioned with some payment tokens. Such tokens vary in validity, and are bounded by the issuers policy. They can be limited to amounts, use age (single or multiple), have time constraints, can be used only for certain types of contactless transactions, or be limited to certain payees. At the same time, the mobile app provides specific tokenized credentials to the payee, via the NFC connection. The payee’s system then routes the transaction to the issuer, where authorization takes place.

Both of these are presented as examples of transaction methods. However, these are not exclusive. There are others. Moreover, added security for these types of transactions can be had in the form of white box cryptography or adding some layers to make the software tamper proof. Another emerging option is biometrics, which can be used in conjunction with these methods.

Flavors
Today, there are basically two HCE models. The first is what is called pure HCE. This finds applicability in what is often called low-value applications. Such applications are usually defined by low risk or low complexity. These include low-value payments, coupons, loyalty rewards, access control, transportation, and other applications where security and complexity are low. Typically, these applications would be on the ones where SE isn’t necessary. It simply simulates SE without the hardware.

The second is called Hybrid HCE. This is the gold standard of the platform and offers everything HCE does, but is coupled with a physical secure element. However, this doesn’t mean that it has the restrictions of the SE, specifically the business relationships required for SE OEMs. In this case, the SE is used for authentication purposes only.

What makes this so attractive is there is the no reliance on the mobile network operator, which means it can be implemented on wide range of mobile devices. It also contains some of the security properties of the SE, and in this case the SE owner is responsible for loading the mobile device applet into the SE.

Management of the applet is done in the cloud, so the mobile network operator is only involved peripherally as the link provider. Furthermore, this removes the reliance on the SIM, so if the SIM is replaced, near-field communications functionality is not affected.

There is also something that was developed back in 2012 called HCEplus (HCE+). This particular implementation was designed to tackle circumstances such as tokenization for online transactions with credit cards. However, there are few details on this at present. It was mainly used in the Asian Pacific region.

Security
Securing software, in general, is more difficult that securing hardware. That is more true with limited resource devices than large enterprise systems.

“Software is less secure and it requires more power,” says Kevin Krewell, principal analyst at Tirias Research. “Hardware makes it work better, which is why you’re seeing crypto processors with keys that are being kept in a secure location. More recently we’re seeing secure memory, too. Kilopass is doing one-time programmable. Winbond is doing secure flash, too.”

While there has been much focus on “root of trust,” the increasing connectedness of devices is escalating that to a “chain of trust,” according to Zining Wu, chief technology officer at Marvell. He explains that includes everything from encrypted communication to more secure connections on chip and between chips.

What helps in the mobile payment world is that both the OS and the HCE client app are relatively intelligent. They have to be in order to support the multi-level security methods, which have been developed and implemented by both Visa and MasterCard in their HCE specifications.

The main challenge to security in HCE is that it is in software. But there are four key metrics that work to keep that HCE transaction secure in today’s HCE software solutions. They are:

• Tokenization. This is a way to reduce the risk for banks by replacement of the primary account number. Tokens replace that number with a tokenized, pseudo-primary account number, which is then used in the payment system without any impact on the acquiring side.
• Limited use keys. These are metrics set up by the issuer and the cloud card management vendor. They are a derivative of the master domain key shared by the issuer and vendor. Such keys have limited use, as discussed in the details section.
• Dynamic risk analysis. This involves real-time assessment of user/device/account data. Dynamic risk analysis is done via the client app, mobile application manager, and the issuer’s back-end systems. It involves implementing algorithms that asses the environmental variables of the three element to derive a risk profile that is applied at the time of the transaction.
• Device fingerprinting. Fingerprints, or device profiles, are stored data that help to ensure the mobile device and point of sale system are authorized and recognized entities. This helps prevent rogue devices in these systems, such as card duplicators inserted in vendor’s devices, and stolen or cloned mobile devices.

Missive
While HCE technically may not be as totally secure as SE, it is secure enough for major banks and credit card companies are getting on the bandwagon. There are attractive reasons for going with HCE over SE from a business perspective, or major players wouldn’t be adopting it.

HCE frees the banks and others in the ecosystem from mobile network operator control. Mobile payments are here to stay and will only ramp up, so it makes sense that there should be competition in mobile payment space. Today, it seems the small compromise in security is worth the gain in cost savings and multiple vendor choices to bring ubiquitous NFC mobile payment technology to the forefront.

Appendix A

Source: Smart Card Alliance