Four key NFC security questions

Are contactless payments safe? What is HCE? How does tokenisation work?

These are just some of the questions around NFC – the technology that enables the bulk of today’s contactless payments – addressed in a new whitepaper that seeks to address the key issues around payment security.

What are the risks to NFC services?

The short answer is a lot, but perhaps the greatest risk is that a security breach could discourage adoption by end users. Apple Pay and Android Pay are perhaps the two most important mobile wallets that use NFC and neither one is completely safe. Apple recently disclosed a major hack on its app store, while malware attacks on Android are too common to even mention.

Key risks are around the data stored on the handset, such as card details, and access to mobile banking logins. However – in the case of Apple Pay, Android Pay and others like them, tokenisation is used so credit and debit card numbers are not stored on any device, shared with a merchant or held on the servers of the payment system operator.

What security does a mobile device offer?

There are three areas within a mobile device that deliver different levels of security. A rich operating system – such as Android or Windows – is an open environment that boasts little in the way of in-built security.

Next is the trusted execution environment (TEE), which comprises software and hardware and offers “protection, confidentiality, integrity, isolation and data access control to applications known as ‘trusted applications’ “.

Thirdly, there is the secure element (SE). For payments, this controls the interactions between the issuing bank, mobile payment app and the merchant. It emulates the secure chip on the payment card and is found in the SIM or in a chip embedded in the phone handset.

According to the whitepaper, the TEE and the SE can work “in tandem” to improve security. “For example, entering a PIN that will authorise a transaction. This user-interaction becomes a weakness in the security chain, since the Rich OS is prone to be infected by keyloggers. By combining the capabilities of the SE and TEE, a more robust and user-friendly level of security can be achieved.”

What about HCE and tokenisation?

HCE – Host Card Emulation – means it’s possible to make a payment without accessing the SE. So transaction requests are sent to a mobile application, not to the SE. In the case of Android phones, payment apps are protected by Android system permission controls that prevent anything but the operating system from binding to, and communicating with, the app.

Google says in its note to developers: “The core remaining piece is where you get your data that your app sends to the NFC reader. This is intentionally decoupled in the HCE design: it does not care where the data comes from, it just makes sure that it is safely transported to the NFC controller and out to the NFC reader.”

Tokenisation is crucial for HCE as it removes the static PAN from the transaction and replaces it with a dynamic one, or token, that is useless if compromised.

“These security measures will drastically limit the impact of any hacking attempt so, from a risk management perspective, HCE can be trusted as a payment method,” says the report.

Who’s responsible for security?

For an SE-based model (ie, not HCE), then it is the SE issuer. “It has ultimate responsibility for the security of the applications residing on the platform,” the whitepaper says, adding that it can “therefore stipulate security requirements and authorise any applications to be loaded onto the SE”.

In HCE models, the paper suggests there is no clearly defined “chain of trust”, but notes that there is one for provisioning tokens and keys to the application.

“For sensitive application providers, such as mobile payments, there are many procedures and requirements that must be adhered to,” it says. “For basic application developers, a risk assessment will reveal limited dangers to their businesses or the end-user if the application is corrupted. As such, there are no formal security certifications.”

The whitepaper, The NFC Security Quiz v2.0, goes on to list three more questions around certification requirements, security evaluations and the future role of NFC security certification.

Written by David Divitt