Host Card Emulation (HCE) is getting a lot of attention, since it offers virtual payment card issuers the promise of removing dependencies on secure element issuers such as mobile network operators (MNOs).
HCE allows issuers to run the payment application in the operating system (OS) environment of the smart phone, so the issuing bank does not depend on a secure element issuer. This means lower barriers to entry and potentially a boost to the NFC ecosystem in general. This combined with
So, great news for the issuer? Yes at least, at first sight. Naturally, the issuer will have to deal with the absence of a hardware secure element, since the OS environment itself cannot offer equivalent security. In other words, the issuer must mitigate risk using software based techniques, to reduce the risk of an attack. Considering that the risk is based on probability of an attack times the impact of an attack, mitigation measures will generally be geared towards minimizing either one of those.
To reduce the probability of an attack, various software based methods are available. The most obvious one in this category is to move part of the (hardware) secure elements functionality from the device to the cloud (thus creating a cloud based secure element). This effectively means that valuable assets are not stored in the easily accessible device, but in the cloud. Secondly, user and hardware verification methods can be implemented, leveraging the famous something the user knows / has / is. Finally, the mobile application itself
Should an attack occur, several approaches exist for mitigating the Impact of such an attack. On an application level, it is straightforward to impose transaction constraints (think of only allowing low value and/or a limited number of transactions per timeframe, geographical limitations, etc.). But the most characteristic risk mitigation method associated with HCE is to devaluate the assets that are contained by the mobile app, i.e. to tokenize such assets. Tokenization is based on replacing valuable assets with something that has no value to an attacker, and for which the relation to the valuable asset is established only in the cloud. Since the token itself has no value to the attacker it may be stored in the mobile app. The principle of tokenization is leveraged in the cloud based payments specifications which are (or will soon be) issued by the different card schemes such as Visa and MasterCard.
What does this mean for the Issuer? On one hand, HCE gives the issuer complete autonomy in defining and implementing the payment application and required risk mitigations (of course within the boundaries set by the schemes). However, the hardware based security approach allowed for a strict separation between the issuance of the mobile payment application on one hand, and the transactions performed with that application on the other hand. For the technology and operations related to the issuance, a bank had the option of outsourcing it to a third party (a Trusted Service Manager). From the payment transaction processing perspective, there would be negligible impact and it would practically be business as usual for the bank.
This is quite different for HCE-based approaches. As a consequence of tokenization, the issuance and transaction domains become entangled. The platform involved in generating the tokens, which constitute payment credentials and are therefore related to the issuance domain, is also involved in the transaction authorization.
HCE is offering autonomy to the banks because it brings independence of secure element issuers. But this comes at a cost, namely the full insourcing of all related technologies and systems. Outsourcing becomes less of an option, largely due to the entanglement of the issuance and transaction validation processes, as a result of tokenization.
Peter Helderman a Principal Consultant at UL's Transaction Security division.
