News & Commentary
9/2/2014
12:00 PM
Pat Carroll
Pat Carroll
Commentary
Connect Directly
Twitter
RSS
E-Mail
50%
50%

“Contactless” HCE Payments Promise Simplicity But Is It Secure?

Host Card Emulation is a powerful and flexible technology, but like most software-dependent solutions, it can be hacked and exploited.

I’ve long written about the accelerating revolution in payments, whereby the mobile device is our wallet, our doorway to mobile commerce. Today, millions of us use our mobile phones for everyday purchases, paying our bills and trading stocks. Over the next few years that number is predicted to swell into the billions, according to a report from Juniper Research.

One of the key enabling technologies driving this adoption is “contactless” payments, or NFC (Near Field Communications), because it offers the ultimate in user convenience -- it’s fast and there are no pesky passwords to remember. Recently, we have witnessed the deployment of a NFC technology called Host Card Emulation (HCE) at select banks in the UK and elsewhere. HCE is an NFC software technology that promises simplicity and low deployment costs, in part due to its reliance on software-based security.

(Image: BellID)
(Image: BellID)

But, like all payment technologies, we must ask, is the technology truly ready? Will relentless cybercrime exploit this new payment technology just as it has managed to compromise other payment technologies?

NFC payments allow for quick and convenient mobile payments. Simply wave your NFC-enabled mobile device within a few centimeters of a payment terminal and your transaction ‘works.’ Behind the scenes, a number of authentication steps and security checks are performed with “traditional” NFC enabled by specialized hardware on the device called a Secure Element (“SE”), a chip which performs cryptography and stores sensitive data in a secure and trusted environment.

With the introduction of Google’s Android 4.4 (“KitKat”) mobile operating system, Google enabled HCE, allowing developers to perform NFC card emulation without using that “chip” found in all NFC-enabled mobile handsets. Many in the payment industry see this as a way to quickly deploy NFC while conveniently bypassing the Mobile Network Operators (MNOs), traditionally seen as the gatekeepers of mobile commerce. In my opinion however, this is yet another example of disintermediation caused by the power of innovative technology, friendly or not. When it comes to securing payments, I fear that there are those in the industry willing to make the trade-off between speed and convenience at the expense of strong security and authentication. It doesn’t have to be that way.

The trouble with HCE
HCE is indeed a powerful and flexible technology, but like most software-dependent solutions, it can be hacked and exploited. In fact, one of the greatest security risks associated with HCE is the ability to exploit a “rooted” device. Rooting allows users of handsets, tablets, and other devices to attain privileged control. Whether done by the legitimate user or even malware that can root the device itself, once full access to all application data stored on the device is accessible, it is ripe for exploitation (see Android Fake ID Vulnerability).

Given the momentum building with HCE, questions remains about what we can do to secure this promising new payment technology? What do the security layers look like, and how do we authentic users and transactions in a world where mobile payments and commerce are in the cloud?

There is no single answer or solution to securing transactions in a mobile world. However, I believe we must first recognize that the notion of a user ID and password equating to “good security” is fundamentally wrong. We need real-time, multi-factor, multi-layer, low or no friction authentication security. Contactless NFC payment technology, irrespective of whether it is SE or HCE enabled, can be combined with technology such as real-time, privacy-sensitive, proximity/geo-location technologies to determine that the genuine customer is at the place of the transaction.

If further user/transaction verification is required, an automated conversation utilizing voice biometrics can be conducted through the mobile phone (without even the need for a call) providing the highest level of transaction authentication/verification, but in a totally low friction format. The audit trail resulting from such an approach provides the greatest assurance in the event that there is repudiation of the transaction, the bane of the payments industry today for both the consumer and the service provider.

Invisible security
This approach recognizes that authentication is not just for the initiation of a transaction, but must persist through to completion via true transaction verification. Underpinning such an implementation lies the trusted device, established during the low-friction enrollment/registration process, and a strong contributor to the “invisible” security process.

With significant market forces generating momentum behind both SE-based NFC and HCE-based NFC, it’s clear that both methods will be pervasive, and competition will be intense. For consumers there is little apparent difference. But behind the scenes there are serious security issues to be addressed. Finding the right level of security commensurate with the risk of loss ultimately is the critical factor facing the payments industry, and the approach I’ve outlined provides a high-level blueprint for achieving such a goal.

It would be wrong to step in the way of innovation, but as consumers we should expect that any new form of payment security has been well thought through, and with it should come the highest levels of assurance that our payments are secure and our credentials are protected. Given the vulnerabilities and breaches affecting the traditional payment ecosystem that generate daily headlines, it would be an indictment that new payment technologies are allowed to generate market share once again at the consumer’s expense. Time for the relevant authorities to stand up and be counted.

Pat Carroll is the executive chairman and founder of ValidSoft, a global supplier of cybersecurity and transaction authentication solutions utilized by banks, financial services companies, and governments to secure and authorize payment transactions. He has more than 25 years ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
pcarrollvs
50%
50%
pcarrollvs,
User Rank: Author
9/5/2014 | 12:02:49 PM
Re: SecureKey Briidge.net Connect
Hello JoshuaR663. I don't know enough about SecureKey Bridge.net Connect to offer an opinion, and this would probably not be the right forum in any event :)

You mention the subject of Tokenization and you are correct that we can expect to see Tokenization being implemented alongside not just HCE but also EMV. However it's worth remembering that a primary objective of tokenization is to eliminate the need for sensitive card data to be stored at the merchant side. It can't prevent cards being cloned (skimmed) and doesn't add any additional validation on the legitimacy of the transaction. The card data still needs to be stored (by the processor/tokenization provider) and held for merchant payment purposes (matching of token with card data) at settlement.

Whilst tokenization is definitely a step forward as it does reduce sensitive payment data proliferation, there are a number of issues that are recognised by the industry. I intend to write a more detailed note on the subject of Tokenization in the near future. 
aws0513
50%
50%
aws0513,
User Rank: Ninja
9/4/2014 | 11:53:25 AM
Re: Just a silly thought > fuzzy math of fraud
As Pat related, it is very difficult to identify how risk acceptance of fraud is implement within the financial industry.  I am sure there are documented formulas out there, but nobody seems to be willing to share that information readily.  Less so try to explain the reasoning behind the formulas.

My silly idea was basically because of this fact.  From all that I have encountered and observed, the financial industry has already accepted risk before they even begin to hand out money.  So all of the repercussions that could be developed in terms of fines and/or administrative action would also be rolled into that equation.

So why not make it profitable for someone to mitigate risk right out of the gate?  Establish a model where the governance body behind a security control that is widely implemented can actually benefit if the solution they provide is proven to have a high amount of risk mitigation while still providing a reasonable user experience.  I have a feeling that if this is done, there may be a huge opportunity for a governance body and a technology solution.

And that is the challenge...  the reasonable user experience.

Many financial organizations seem to view security controls as a barrier to obtaining new business.  This of course is partially due to public disdain for those activities that seem combersome or complicated...  and I get that.  But the other side of this equation is due to the rampant pressure for financial organizations to generate business... to make money while accepting a certain level of risk. 
To me it is like trying to prevent teens from engaging in sex.  The hormonal pressures are enormous.  Both sides of the equation want what the other has...  greatly.

 

 
pcarrollvs
50%
50%
pcarrollvs,
User Rank: Author
9/3/2014 | 7:15:45 PM
Re: Just a silly thought > fuzzy math of fraud
Hi Marilyn, trying to get a handle on the true cost of fraud in any industry segement is notoriously difficult. Mention fraud losses to any financial institution and it's as though you have said a bad word... The industry is paranoid about the reputational damage that could ensue, and makes a concerted effort to downplay the impact on their institution. The problem is that unless you can measure it, you can't manage it. And measurement is all about understanding and knowledge. It the industry can't own up to its failings, what chance is there of solving the problem? In terms of your specific question, in the recent past some good studies have been carried out by research companies that have helped quantity the question around the true cost of fraud, and have highlighted that with card present fraud (eg ATM/POS), actual fraud losses make up about 30% of the total cost of fraud, whilst with card not present fraud (eg online), actual fraud losses make up approx 25% of the total cost of fraud.
Marilyn Cohodas
50%
50%
Marilyn Cohodas,
User Rank: Strategist
9/3/2014 | 9:21:47 AM
Re: Just a silly thought > fuzzy math of fraud
Thanks, Pat. What you say makes perfect sense to me. Are there any industry estimates about how off the mark organizations are in their estimates of the true costs of fraud? For example, are they in the ball park of  2x higher? Does it depend on the industry? 
pcarrollvs
50%
50%
pcarrollvs,
User Rank: Author
9/3/2014 | 9:06:41 AM
Re: Just a silly thought > fuzzy math of fraud
It's an unfortunate fact Marilyn, and not without reason. Establishing the true cost of fraud to an organization is a complex process that spans many departments, since it's not just fraud losses that need to be taken into account, but also the cost of investigation and administration of fraud. Fraud can also affect legal fees and regulatory and compliance budgets, IT and Security as well, although in many cases it's highly likely that such costs are not classified as "fraud" in the budget, for obvious reasons. Not alone does this make the true cost of fraud to an organization difficult to calculate, but it also means that fraud costs may be under-reported as a consequence and create a misleading impression as to the level of fraud in any market. The implication of all of this is that it's ultimately only the fraudsters that benefit and the shocking truth is that it is the industry that is unwittingly assisting them. I believe that it is time for the relevant governing bodies to stand up and be counted. The only losers will be the fraudsters.
Marilyn Cohodas
50%
50%
Marilyn Cohodas,
User Rank: Strategist
9/3/2014 | 7:58:10 AM
Re: Just a silly thought > fuzzy math of fraud
Interesting point about tying together the cost of fraud and the cost of a fraud solution. It seems like such an obvious connection. Are organizations really so balkanized that they can't put these basic facts together?
pcarrollvs
50%
50%
pcarrollvs,
User Rank: Author
9/3/2014 | 6:03:34 AM
Re: Just a silly thought
You raise a very interesting point aws0513. It's quite amazing that in today's world we actually budget for fraud! What incentive is there to get rid of fraud when it's in the budget? I like your value proposition, ie make good security profitable. The sad fact is that every one of us pay the price of poor security when we use our payment cards or our mobile at the checkout. And it's a significant cost indeed, as high as 160 basis points (1.6%) of the transaction value (and in some cases even higher). It's even sadder to know that that the technology exists today to virtually eliminate fraud at the checkout due to the ability to accurately place the legitimate cardholder/mobile user at the place of the transaction, in real-time, but in a totally privacy sensitive manner, yet there is reluctance by the industry to adopt/deploy such technologies. The big problem is that in big organizations, the silo effect kicks in, and the folk who budget for fraud are not aligned with with the division who could implement such technology, and unless you can reliably aggregate cost of fraud and cost of solution, the business value proposition becomes blurred. I for one would love to see the governing bodies take more action to force the industry to deploy such solutions, afterall, it is in all our interests, and the only individuals to benefit from industry procrastination are the fraudsters!
aws0513
50%
50%
aws0513,
User Rank: Ninja
9/2/2014 | 2:21:31 PM
Just a silly thought
As I was reading this article, I began to wonder if things would change if the governance bodies behind HCE and/or SE technologies standards were to be billed for any transactions where non-repudiation could not be fully established.

The silly model in my head is for every transaction, the governance body would get a small cut (the carrot).  But for every proven false transaction, the governance body would pay the full remediation cost for the transaction (the stick).  In other words, make good security profitable, but risk of fraud seem unpalatable to the organization responsible for validating the standard.

At the same time, allow the governance body to bill/fine those vendors that implement the technology standard in a manner that introduces vulnerabilities.

I know...  just plain silly.  Maybe I need to get another caffiene drink.

Good article, but I fear the industry till adopt HCE with the attitude that "What worse could happen compared to the current card based system?"
JoshuaR663
50%
50%
JoshuaR663,
User Rank: Apprentice
9/2/2014 | 1:40:58 PM
SecureKey Briidge.net Connect
Is this technology (utilizing tokenization, it seems) a true viable option to secure HCE, even on a rooted phone? I see tokenization being part of the answer if it is done at the vendor/bank level, but I'm not sure how or where in the process SecureKey tokenizes data. Thoughts?
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Dark Reading Tech Digest, Dec. 19, 2014
Software-defined networking can be a net plus for security. The key: Work with the network team to implement gradually, test as you go, and take the opportunity to overhaul your security strategy.
Flash Poll
10 Recommendations for Outsourcing Security
10 Recommendations for Outsourcing Security
Enterprises today have a wide range of third-party options to help improve their defenses, including MSSPs, auditing and penetration testing, and DDoS protection. But are there situations in which a service provider might actually increase risk?
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-8142
Published: 2014-12-20
Use-after-free vulnerability in the process_nested_data function in ext/standard/var_unserializer.re in PHP before 5.4.36, 5.5.x before 5.5.20, and 5.6.x before 5.6.4 allows remote attackers to execute arbitrary code via a crafted unserialize call that leverages improper handling of duplicate keys w...

CVE-2013-4440
Published: 2014-12-19
Password Generator (aka Pwgen) before 2.07 generates weak non-tty passwords, which makes it easier for context-dependent attackers to guess the password via a brute-force attack.

CVE-2013-4442
Published: 2014-12-19
Password Generator (aka Pwgen) before 2.07 uses weak pseudo generated numbers when /dev/urandom is unavailable, which makes it easier for context-dependent attackers to guess the numbers.

CVE-2013-7401
Published: 2014-12-19
The parse_request function in request.c in c-icap 0.2.x allows remote attackers to cause a denial of service (crash) via a URI without a " " or "?" character in an ICAP request, as demonstrated by use of the OPTIONS method.

CVE-2014-2026
Published: 2014-12-19
Cross-site scripting (XSS) vulnerability in the search functionality in United Planet Intrexx Professional before 5.2 Online Update 0905 and 6.x before 6.0 Online Update 10 allows remote attackers to inject arbitrary web script or HTML via the request parameter.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Join us Wednesday, Dec. 17 at 1 p.m. Eastern Time to hear what employers are really looking for in a chief information security officer -- it may not be what you think.