The EBA’s recent Opinion on the elements of strong customer
authentication under PSD2 was, apart from moving the goalposts on when SCA will
be enforced, full of interesting information about what constitutes a valid SCA
element. It closes some doors, opens others and ends any notion that merchants
can take liability and not do SCA themselves.
Taking the final point first, there’s been a view that Article 74(2) of PSD2 permits merchants to carry on without implementing SCA as long as they take liability. We at Consult Hyperion have long argued that that is an optimistic and overly legalistic reading of the regulations and this has now been confirmed. The EBA states:
In addition, even if there were a liability shift to the payee or the payee’s PSP for failing to accept SCA, as articulated in Article74(2) of PSD2, this could not be considered an alleviation of PSPs’ obligation to apply SCA in accordance with and as specified in Article 97 of PSD2.
Basically, Article 97 takes precedence – PSPs (aka Issuers)
must apply SCA so if the merchant chooses not to then rather than end up with a
payment for which they’re liable they’ll end up with no payment at all. Which,
you’d imagine, would rather miss the point of being a merchant.
Beyond this point the Opinion has lots of interest to say
about inherence, possession and knowledge elements.
On inherence two points stand out. Firstly the
Opinion unambiguously states that behavioural biometrics can be a valid factor:
this opens up a world of possible low friction SCA, and we expect to see lots
of innovation in this area. Secondly it states that 3DS-2 does not support
inherence as none of the data points being gathered relate to biological or
behavioural biometrics but – and we view this as important – 3DS-2 is a valid
means of supporting SCA.
This is critical because the dynamic linking process behind
3DS-2 is not straightforward and there have been differences of opinion over
whether this is compliant. Given that 3DS-2 appears to be the only game in town
for CNP transactions having a statement that it’s OK is mighty important.
On possession, the EBA clarifies that OTP SMS is
valid and also that mobile app based approaches can be – but only if the app is
linked to the device. We’ve been arguing that this is obviously the case for a
while, so it’s good to see this confirmed: although there are going to be a few
app developers out there that need to revise their approaches pdq (we can help,
Also on possession the EBA has stated something that really
should have been obvious to anyone taking more than a moderate interest in the
topic – printed card details such as PAN and CVV or user ids and email
addresses are not valid possession or knowledge elements. As a number of
prominent industry players have been taking the opposite approach this could
lead to some interesting developments in the coming weeks, particularly as the
Opinion states that if the CVV is not printed on the card and is instead sent
on a separate channel, then it is a valid knowledge element.
Overall, the analysis and discussion in the Opinion on valid
SCA elements is welcome, if a trifle tardy. To be fair to the EBA, we don’t see
anything in their analysis that a proper reading of the RTS wouldn’t have
produced. However, it’s been clear for some time that many industry players
have been making a highly liberal interpretation of the requirements usually
based on a legal opinion. But PSD2 and the RTS are about principles, not rules:
if you need advice on this you need to talk to the people who understand this
stuff. Which, by the way, is us, not law firms.
The reasons behind the presence of mag stripe on cards alongside chip (and PIN) has long been a debate at Consult Hyperion. Especially for the US where things were different for years – of course now the US has introduced chip and PIN as well.
numbers and signatures on cards helps criminals. There’s no need for it.
A couple of years later, in “Tired: Banks that store money. Wired: Banks that store identity” we asked why banks didn’t put a token in Apple Pay that didn’t disclose the name or personal information of the holder, a “stealth card” that could be used to buy adult services online using the new Safari in-browser Apple Pay experience. This would be a simple win-win: good for the merchants as it would remove CNP fraud and good for the customers as it would prevent the next Ashley-Madison catastrophe. Keep my real identity safe in the vault, give the customer a blank card to go shopping with.
Some years ago, we were testing Static Data Authentication (SDA) “chip and PIN” cards in the UK, we used to make our own EMV cards. To do this, we took valid card data and loaded it onto our own Java cards. These are what we in the business call “white plastic”, because they are a white plastic card with a chip on it but otherwise completely blank. Since our white plastic do-it-yourself EMV cards could not generate the correct cryptogram (because you can’t get the necessary key out of the chip on the real card, which is why you can’t make clones of EMV cards), we just set the cryptogram value to be “SDA ANTICS” or whatever (in hex). Now, if the card issuer is checking the cryptograms properly, they will spot the invalid cryptogram and reject the transaction. But if they are not checking the cryptograms, then the transaction will go through.
You might call
these cards pseudo-clones. They acted like clones in that they worked correctly
in the terminals, but they were not real clones. They didn’t have the right
keys inside them. Naturally, if you made one of these pseudo-clones, you didn’t
want to be bothered with PIN management so you made it into a “yes card” –
instead of programming the chip to check that the correct PIN is entered, you
programmed it to respond “yes” to whatever PIN is entered. We used these
pseudo-clone cards in a number of shops in Guildford as part of our testing
processes to make sure that issuers were checking the cryptograms properly. Not
once did any of the Guildford shopkeepers bat an eyelid about us putting these
strange blank white cards into their terminals. Of course it’s worth noting
things have progressed and fortunately this wouldn’t work now as the schemes
have moved on from SDA.
I heard a different story from a Brazilian contact. He discovered that a Brazilian bank was issuing SDA cards and he wanted to find out whether the bank was actually checking cryptograms properly (they weren’t). In order to determine this, he made a similar white plastic pseudo-clone card and went into a shop to try it out.
When he put
the completely white card into the terminal, the Brazilian shopkeeper stopped
him and asked him what he was doing and what this completely blank white card
was, clearly suspecting some misbehaviour.
thinking quickly, told him that it was one of the new Apple credit cards!
“Cool” said the shopkeeper, “How can I get one?”.
story was written back
in 2014! There was no white Apple credit card at that time but it
was interesting that the shopkeeper expected an Apple credit card to be all
white and with no personal data on display, just as we had suggested in our
ancient ruminations on card security. Imagine the total lack of surprise when
the internet tubes delivered the news of the new actual Apple credit card
launched in California a couple of weeks ago. Apple CEO Tim Cook said that
the new Apple Card would be the biggest card innovation “in 50 years” [FT].
This seems a little rough on the magnetic stripe, online authorisation,
chip and PIN, debit cards, contactless interfaces and so on, but it is
certainly an interesting development for people like us at Consult
gathered the usual media interest. A number of reports on the web reporting on
“Apple going into banking” which, obviously, they are not. Far from it. The
Apple Card issuer is Goldman Sachs (it’s their first credit card product) and
the card product is wholly unremarkable. The card looks pretty cool though, no
doubt about that. I still don’t know why they put the cardholder name on the
front (instead of their Apple ID).
Apple Card is launching into an interesting environment. The US POS is a confusing place but Apple know their stuff and I am sure that they think they can use the 2% cash back on ApplePay purchases vs. the 1% on chip/stripe to push people toward the habit of using their phones at POS instead of cards. Judging by the sign I saw in an Austin gas station, they may be right.
The Apple Card adds security, there’s no doubt about that. The card-not-present PAN and CVV displayed by the app (which can be refreshed) are not the same as the PAN and CVV on the stripe, so you can’t make counterfeit stripe cards with data from the app and Apple uses the Mastercard token Account Update service, so if you give (say) Spotify the CNP PAN/CVV and then refresh it, you don’t need to tell Spotify that you’ve changed anything because Mastercard will sort it out with Spotify. That’s security for the infrastructure and convenience for the customer.
Now You See It
While I was jotting down some notes about Apple Card, I was thinking about David Kwong, the illusionist. He gave an entertaining talk at Know 2019 in Las Vegas and I was privileged to MC his session. I was sitting feet away from him and I couldn’t figure out how he did it. That’s because he is a master of misdirection!
I can’t help
feeling that there’s a bit of misdirection going on with Apple Card. The press
are reporting about the card product, but it’s really not that earth
shattering. It seems to me that what is really important in the
announcement isn’t extending Goldman Sachs’ consumer credit business or that
bribe to persuade apparently reluctant consumers to use Apple Pay at
contactless terminals instead of swiping their card, but the attempt to get
people to use Apple Cash. Cognisant of how Starbucks makes out by persuading
citizens to exchange their US dollars that are good anywhere into Starbucks
Dollars that are not, and of Facebook’s likely launch of some kind of Facebook
Money, Apple are hoping to kick-start an Apple Cash ecosystem.
You may have
noticed that as of now, you can no longer fund person-to-person Apple
payments (in Messages) using
a credit card. You can still fund your Apple Cash via a debit card.
You can pay out from your Apple Cash to a Visa debit card for a 1% fee or via
ACH to a bank account for free. They want to reduce the costs of getting volume
into Apple Cash and make it possible for you to get it out with jumping through
hoops. Given that you can do this, you’ll be more relaxed about holding an
Apple Cash balance and that means that next time you go to buy a game or a song
or whatever, Apple can knock it off of your Apple Cash balance rather than
feeding transactions through the card rails.
And why not?
In this ecosystem Apple would carry the float, which might well run into
millions of dollars (Starbucks’ float is over a billion dollars), and if it
could persuade consumers to fund app, music and movie purchases from Apple Cash
instead of cards it would not only save money, but anchor an ecosystem that
could become valuable to third-party providers as well. With Facebook’s
electronic money play on the horizon, I think Apple are making a play not for a
new kind of card to compete with my Amex Platinum and my John Lewis MasterCard
but for a new kind of money to compete with BezosBucks, ZuckDollas an Google
I was a panellist discussing the barriers to mobility as a service (MaaS) at the Transport Ticketing Global (TTG19) conference in London in January. In fact, many of the presentations over the two-day conference were about MaaS and reasons why it is proving very hard to deliver. Perhaps one of the most mature MaaS offerings is the one from MaaS Global branded as ‘Whim’ which launched in the UK in the West Midlands but, by their own admission, has struggled to gain a foothold.
Until recently, MaaS providers have avoided London. We have seen some excellent journey planning apps exploiting Transport for London’s (TfL) open APIs, but nobody was going that extra mile and actually proving a complete MaaS solution in a single app that allow both planning journeys together with payment and ticketing (i.e. proving authority to travel when entering the transit network). TfL has been very clear that they will not provide any cut of the fares to MaaS providers, so they will have to find other ways to make a profit.
So, the announcement from CityMapper that they are about to launch a MaaS solution in London surely doesn’t make any sense? Given the above barriers to MaaS and the high complexity of London’s public transport network, why on earth would you start there?
The answer is payments and identity, two of our favourite topics. These are services needed in order to offer account-based ticketing (ABT) and ABT is a corner-stone of MaaS. Passengers need to identify themselves to their customer account so that their journey charges can be calculated. Payment for the journeys needs to be handled in a way that is suitable to the particular customer.
One of the barriers I suggested on the TTG19 panel is that payment and identity are too ‘closely coupled’ in modern account-based ticketing offerings. I am old enough to remember the emergence of service oriented architectures in the ‘noughties’. The idea was that by ensuring services are ‘loosely coupled’, they can freely evolve without affecting consumers or implementations. I argued that if everyone rushes to implement the open-loop payment models with the payment networks like TfL has done, then we will be left with fare collection services that are highly dependent on the payment schemes and constrained from evolution. The identifier the passenger uses at the gate is their bank card (or its emulation on mobile or wearable devices). This identifies them to their ABT travel account but it also identifies their means of payment. Some would say this is convenient, I am suggesting it is too closely coupled and will stifle innovation.
Open banking APIs are a subject close to our hearts at the moment. The APIs are very new and they seem not to be thinking about transit payments at this stage. However, one could imagine that there could be future open banking APIs that would allow passengers to consent to transit payments from their bank to their MaaS provider without the need for the payment networks in between. I expect this will be subject of future blogs or white papers from Chyp.
The reason CityMapper is launching in London is that all the public transport modes accept open-loop payments and the CityMapper solution to payments and identity is to provide their MaaS customers with a Mastercard-branded prepaid card, ‘Pass’. CityMapper will offer a subscription model at a discount on TfL prices and any travel on TfL modes outside of this will simply use the prepaid bank card like any other.
This works for all London public transport modes, but there are very few other cities that have committed so totally to the open-loop models. It will be interesting to see whether CityMapper can make a profit and if they do, whether they can replicate it outside of London. Right now, it looks like they are using investment funding and planning on taking a loss to start with since they are offering to undercut the TfL fares and as stated above TfL has said they will not offer discounts to Maas providers. Or perhaps city mapper is planning on selling advertising space or plans to sell anonymised travel data to make up the shortfall? Only time will tell.
Meanwhile, may all your transit tokens be loosely coupled and your payment instruments plentiful.
The last year has seen a lot of activity in the mobile payment ecosystem with regards to the risk associated with Consumer Off The Shelf (COTS) devices becoming not only a payment method (Google Pay, Samsung Pay etc) but more significantly becoming payment terminals ready to accept payments. A ‘COTS device’ is a mobile device (e.g. phones & wearables) intended for distribution and use by the mass-market, and traditionally were not designed exclusively for making or accepting payments.
Historically, COTS devices have been viewed with caution. Insecure and too risky to handle sensitive payment data, unless of course, they have a hardware tamper-proof Secure Element (SE). However, there was a significant shift in 2013 when Host Card Emulation (HCE) became mainstream, which meant an NFC enabled COTS device with no SE could be used to make payments. A combination of Tokenisation and software security techniques such as White-Box Cryptography meant the risk of exposure associated with COTS devices (with no SE) could be managed to levels acceptable to the stakeholders, hence Google Pay.
Whilst HCE was a big deal, something even more interesting and consequential is happening with regards to the use COTS devices for payment acceptance. In January of 2018, the Payment Card Industry Security Standards Council (PCI SSC) published a new standard – Software-Based PIN Entry on COTS Security Requirements (SPoC). This standard set out the security requirements for a payment acceptance solution where PIN entry is performed on a COTS device. This standard will be the first, in a series of software-based security standards published by PCI SSC. With the industry specifications becoming available, we are beginning to see a flavour of how these solutions will emerge. Square have deployed a “SPoC like” solution and both Worlpday and Mobeewave are deploying solutions which use the mobile device to accept NFC contactless payments.
A few weeks ago, PCI SSC published the PCI Software Security Framework – a collection independent standards and their associated validation processes that address the security of payment software. The standards within the framework thus far are: the PCI Secure Software Standard (PCI SSS) and the PCI Secure Software Lifecycle Standard (PCI Secure SLC), just what our world needs; more acronyms to remember.
The PCI SSS addresses the design, development and maintenance of payment software in a way that provides protection and minimises the risk of exposure to the payment data. The standard sets out requirements that ensures the integrity of sensitive data at rest, during processing and in transit. PCI Secure SLC in a similar vein provides baseline requirements that ensures software vendors integrate security at every stage of the Software Lifecycle. So, whilst PCI SSS is about specific payment software(s), PCI Secure SLC addresses security in the processes of payment software vendors.
Finally, in what has been a relentless churn of exciting standards over past year, PCI SSC has recently announced it is working on the PCI Contactless Payments on COTS Standard, to be published by the end of the year. The goal of the standard will be to define the security requirements that will allow the use of COTS mobile devices to accept payments, without the need for an additional hardware adaptor or dongle. Similarly, EMVCo also established the Software-Based Mobile Payment (SBMP) Approval Process, which checks that software payment solutions meet the minimum levels of security to protect against known attacks.
The implications of these developments could be profound,
potentially turning every mobile device into a POS for payment acceptance. No
more need for the small or mobile merchant to purchase dongles which they need
to pair with their mobiles and keep charged up in order to accept card
payments, just download the app and start taking payments.
Will this mean the end of traditional POS? Not in the near
term. Software mobile POS is more about enabling more merchants to accept card
At Consult Hyperion we’ve worked with Standards bodies, software and hardware vendors and the mobile industry for over three decades to ensure our clients design and product aspirations are met to the highest levels of security. We interrogate architecture, we assess risk and identify vulnerabilities before our Clients reputations are put at risk.
around on Twitter, I noticed an interesting question:
can’t I use Apple Pay for everything online? Shouldn’t there be some way
for me to hold my phone up to the screen when I get to an order page online and
scan a QR code and hold my thumbprint or something? — Joe Weisenthal
(@TheStalwart) January 2, 2019
Joe has a point. Apple Pay is far more secure, and far more convenient, than messing around typing card numbers in to web pages as we did back in 1998. And globally, merchants lose some $20-$30 billion per annum in card-not-present fraud, so why aren’t we using our (secure) mobile payment systems to pay for things we buy on the (insecure) web already?
first of all you can use Apple Pay to pay for things on the web but only if you
are using Safari and only if the merchant has implemented Apple Pay. The
merchants, however, don’t want to implement a solution that only works for a
small proportion of their customers (ie, people who use iPhone, Safari on the
web and have Apple Pay configured correctly). Merchants would prefer a more
universal solution such as W3C or SRC.
however, may be just around the corner.
Equity Research put out an interesting note on payments in November. Called
“Sleepwalking into 3DS2.0 and PSD2”, it kicks off by saying that “the mandated
3-D Secure 2.0 and the requirement for two-factor Secure Customer
Authentication (SCA) are around the corner, but the industry does not seem
ready for this major change in transaction processing protocols”.
quite. I’m glad to see they agree with our decision to make SCA the highest
priority of our “Live 5” areas for our clients to focus on
in the coming year.
this note, Barclays say that an unintended consequence of PSD2 will be a
better e-commerce experience on mobile, where biometrics are a convenience
technology, rather than the desktop, and this should benefit digital wallets
(again as we note in our Live 5). In the store too, mobile may have the
advantage. Contactless payments will require a PIN entry every five
transactions or €150 (depending which the issuer mandates), unless an online
transaction in the interim authenticates the card and restarts the counter.
an Apple Pay or Google Pay mobile transaction would be authenticated every time
and because of CDCVM, can ignore the contactless limit (currently £30 in the
UK). While a card is arguably marginally easier than mobile wallets today for
contactless, this may be enough to shift the advantage to mobile.
the future of secure retail transactions will converge on the smartphone,
irrespective of whether those transactions are physical or virtual.
It’s that time of year again. I’ve had a chat with my colleagues at Consult Hyperion, gone back over my notes from the year’s events, taken a look at our most interesting projects around the world and brought together our “live five” for 2019. Now, as in previous years, I don’t expect you to pay any attention to our prognostications without first reviewing our previous attempts, otherwise you won’t have any basis for taking us seriously! So, let’s begin by looking back over the past year and then we’ll take a shot at the future.
As we start to wind down 2018, let’s see how we did…
1. Open Banking. Well, it was hardly a tough call and we were bang on with this one. We’ve been working on open banking projects in the UK, on the continent and beyond. What seems to be an obviously European issue, is of course a global one and we’ve been helping the global payment brands understand the opportunities. Helping existing market participants and new market entrants to develop and implement responses to open banking has turned out to be intellectually challenging and complex, and we continue to build our expertise in the field. Planning for the unintended consequences of open banking and the potentially un-level playing field that’s been created by the asymmetry of data, was not the obvious angle of opportunity for traditional tier one banks.
2. Conversational Transactions. Yes, we were spot on with this one and not only in financial services. Many organisations are shifting to messaging channels for customer support and for transactions, in both the banking and retail sectors. The opportunity for this continues with the advancements of new messaging enablers, such as the GSMA backed RCS. But as new channels for support and service are introduced to the customer experience, so are new points of vulnerability.
3. The Internet of Cars. This is evolving although the security concerns that we spoke about before, continue to add friction to the development of new products and services in this area. Vulnerabilities to card payments or building entry systems are security threats, vulnerabilities to connected or autonomous vehicles are potentially public safety threats.
4. Artificial Intelligence. Again, this was an easy prediction because many of our clients were already active. Where we did add to thinking this past year, it was about the interactive landscape of the future (i.e. bots interacting with bots) and how the identity infrastructure needs to evolve to support this.
5. Tokens/ICOs. Well, we were right to highlight the importance of “tokens” (the basis of Initial Coin Offerings, or ICOs) and our prediction that once the craziness is out of the way, then regulated token markets will become significant looks to be borne out by mainstream commentary. At Money2020 Asia in Singapore, I had the privilege of interviewing Jonathan Larsen, Corporate Venture Capital Manager at Ping An and CEO of their Global Voyager Fund (which has a $billion or so under management). When I put to him that the tokenisation of assets will be a revolution, he said that “tokenisation is a really massive trend… a much bigger story than cryptocurrencies, initial coin offerings (ICOs), and even blockchain”.
As we said, 2018 has seen disruption because the shift to open banking, starting in the UK,has meant the reshaping of financial services while at the same time the advance of AI into the transaction flow (transactions of all types, from buying a train ticket to selling corporate bonds) begins to reshape the way we do business.
This year we are organising our “live five” in a slightly different way, listing them by priority to our clients rather than as a simple list. So here are the four key technologies that we think will be hot throughout the coming year together with the new technology that we are looking at out of the corner of our eyes, so to speak. The mainstream technologies are authentication,cross-sector digital identity, digital wallets for ticketing and secure IoT in the insurance sector. The one coming up on the outside is post-quantum cryptography.
So here we go…
1. With our financial services customers we are moving from developing strategies about open banking to developing implementation plans and supporting the development of new systems and services. The most important technology at the customer interface from the secure transactions perspective is going to be the technology of Strong Customer Authentication (SCA). Understanding the rules around which transactions need SCA or not is complicated enough, and that’s before you even start working out which technologies have the right balance of security and convenience for the relevant customer journeys. Luckily, we know how to help on both counts!
As it happens, better authentication technology is going to make life easier for clients in a number of ways, not only because of PSD2. We are already planning 3D Secure v2 (3DSv2) and Secure Remote Commerce (SRC) implementations for customers. Preventing “authentication friction” (using e.g. FIDO) is central to the new customer journeys.
2. Forward thinking jurisdictions such as Canada and Australia have already started to deliver cross-sector digital identity (where in both cases we’ve been advising stakeholders). New technologies such as machine learning, shared ledgers and self-sovereign identity, if implemented correctly, will start to address the real issues and improvements in know your customer (KYC), anti-money laundering (AML), counter-terrorist financing (CTF) and the management of a politically-exposed person (PEP). The skewed cost-benefit around regtech and the friction that flawed digitised identity systems cause, mean that there is considerable pressure to shift the balance and in the coming year I think more organisations around the world will look at models adopted and take action.
3. In our work on ticketing around the world, we see a renewed focus on the deployment of real digital wallets. Transit and other forms of ticketing (such as for
sporting events) are the effective anchor tenants of the digital wallet, not payments. In the UK and in some other countries there has been little traction for the smartphone digital wallet because of the effectiveness of the deployment and use of contactless cards. If you look in your real wallets, most of what your find isn’t really about payments. In our markets, payments alone do not drive consumers to digital wallets, but take-up might be about to accelerate. It’s one thing to have xPay put cards into a digital wallet but putting your train tickets, your sports rights and your concert passes into a digital wallet makes all the difference to take-up and means serious traction. Our expertise in using the digital wallets for applications beyond payments will give our clients confidence in setting their strategies.
4. In the insurance world we see the business cases building around the Internet of Things (IoT). The recent landmark decision of John Hancock, one of the oldest and largest North American life insurers, to stop selling traditional life insurance and instead sell only “interactive” policies that track fitness and health data through wearable devices and smartphones is a significant step both in terms of business model and security infrastructure. We think more organisations in the insurance sector will develop similar new services. Securing IoT systems becomes a priority. Fortunately, our very structured
risk analysis for IoT and considerable experience in the
practical assessment of countermeasures, deliver a cost-effective
5. In our core field of security, we think it’s time to start taking post-quantum cryptography (PQC) seriously not as a research topic but as a strategic imperative around the development and deployment of new transaction systems. As many of you will know, Consult Hyperion’s reputation has been founded on the mass-market deployments of new transactions systems and services and this means we understand the long-term planning of secure platforms. We’re proud to say that we have helped to develop the security infrastructure for services ranging from the Hong Kong smart identity card, to the Euroclear settlement system and from contactless payments to open loop ticketing in major cities. Systems going into service now may well find themselves overlapping with the first practical quantum computer systems that render certain kinds of cryptography worthless, so it’s time to add PQC to strategies for the mass market.
And there you have it! Consult Hyperion’s Live 5 for 2019. Brexit does not mean the end of SCA in the UK (since PSD2 has already been transcribed into UK law) and SCA means that secure digital identities can support transactions conducted from digital wallets, and those digital wallets will contain things other than payment instruments. They might also start to store transit tickets or your right to travel, health and fitness data for your insurance company. Oh, and all of that data will end up in the public sphere unless the organisations charged with protecting it start thinking about post-quantum cryptography or,as Adi Shamir (one of the inventors of public key cryptography) said five years ago, post-cryptographysecurity.
What an interesting experience the first Money2020 in China was. It was held in Hangzhou, the home of AliPay, and I was delighted to have been invited along to share some of our experiences in the payments and to learn first hand about the Chinese approach to the sector.
Money2020 China gets underway
The event was well-staged and with simultaneous translation from Chinese it provided an opportunity to hear about the wide variety of fintech activities in China. It was, as you might imagine, very different from the Las Vegas event last month. There was no discussion of cryptocurrency because of the Chinese regulatory context and while I did see one presentation on the use of digital signatures in smart contracts, there was little discussion of blockchain and related technologies.
Ron Kalifa talking about value-added merchant services
I particularly enjoyed Worldpay vice-chairman Ron Kalifa’s fireside chat (in which he said that people were underestimating the impact of open banking) and presentation of their annual world payments report. To a payments nerd like me this was a great opportunity to look at key trends in payments on a country-by-country basis and try to work out which trends are relevant to our clients around the world as they formulate strategies for the always-on, mobile-centric, open-banking future. Key to these strategies is, of course, security and so I always pay attention to the big picture presentations around fraud. In China, these have scary numbers attached to them, but you have to take into account the size of the Chinese economy (I think the Chinese cybercrime losses are lower than in many other countries).
Real, and scary, fraud numbers
Given the widespread use of scores of one form or another to determine trustworthiness it is no coincidence that China sees a rise in frauds relating to the manipulation of these scores. Without commenting on the benefits or otherwise of such models (most Brits, myself included, can only think of Black Mirror when social scores are discussed) it is worth making the point that preventing “gaming” of these scores while preserving individual privacy means dealing with paradoxes that might well be resolved through the use of cryptographic techniques that have no conventional analogues and are therefore difficult for policymakers to bear in mind.
Reputation fraud in action
Most of what I found thought-provoking, both in the presentations and the water cooler discussions, was to do with business models rather than new technologies. The new business models emerging in a regulated, platform-centric, dynamic market are what we should be studying. We might choose to implement some of these models in a slightly different way taking into account the varying cultural norms around security and privacy, but the idea of separating payments from banking and then turning payments into platforms, and then using these platforms to acquire customers at scale for other businesses is certainly very interesting.
These new models, of course, centre on data and value-adding using that data. When people pay for everything with their mobile phone, they lay down a seam of data that is waiting to be mined. Despite this, the convenience of the mobile-centre platforms is so great that people are clearly willing to put privacy concerns to one side. I chaired a great session on privacy with CashShield, Symphony and eCreditPal with, I think, gave out a very comforting message: if you build services with privacy in the first place, then actually complying with GDPR and other global regulations is actually not that much of a problem.
One more thing that struck me about the context for these developments that it seems to me that China is making its e-money regulation more like the EU’s. With an EU electronic money licence, the organisations holding the funds must keep them in Tier 1 capital and are not allowed to gamble the customer’s money, whereas in China there was no such restriction. Now the People’s Bank has said that from January 2019 the Chinese operators will have to hold a 100% reserve in non-interest bearing deposits at a commercial banks, a decision that will likely cost the main players (Tencent and Alipay) a billion dollars or so in revenue.
It was interesting spend a few days inside the mobile-centric, QR-everywhere, always-on, app and pay world of the future and picking up some useful lessons for our clients. A very interesting week.
The launch of PCI’s SPoC specification, Software PIN on COTS – Commercially Off The Shelf (thats PIN on mobile / PIN on Glass, to you and me) raised an eyebrow or two at Consult Hyperion. Could PIN on mobile actually be secure? The researchers at Newcastle University produced a paper stating that PINs entered on mobiles can be recovered by capturing the mobiles sensor data.
We’re well versed in building the security architectures and systems needed to secure payment cards on mobile devices using software only solutions, think Google Pay / Barclaycard Contactless Mobile, or Worldpay’s fabulous My Business Mobile card reader, all of which protect card PANs in one way or another. As well as building security, we are just as adept at testing such architectures and implementations to validate their security. This leads us to ask the question; is securing a cardholders’ PIN the same as securing a card PAN?
Gut instinct would suggest that exposing a PIN is more risky than exposing a PAN, however one is of no use without the other. A PIN cannot be used without the PAN whereas a PAN can be used without the PIN. Indeed the PAN could be used for online payments, the PIN is only of use if the physical card is present.
PCI SPoC sets out a comprehensive architecture to protect the cardholders’ PIN involving the mobile device, card reader and host system, which is all very sensible. From a business point of view, reducing the cost of the card reader device by removing the physical keyboard, may make accepting payment cards a more attractive option from a cost perspective. Equally from a customer experience point of view, it appears quick and easy and less cumbersome than interactions with a different PED.
However, what if you could use the mobile devices own sensors to steal the PIN? Is this possible? Can you use a mobiles sensor data to recreate a PIN? Even if it were possible surely a PIN entry application would ensure the sensor data was blocked? Researchers at Newcastle University published a paper on “Stealing PINs via Mobile Sensors: Actual Risk versus User Perception.” In this paper the team of researchers claim an accuracy of 80% on obtaining PINs from mobile sensors, which if true, would significantly compromise PIN on Glass solutions as set out in the PCI SPoC standard.
We set our Hyperlab team the task of recreating the research to fully understand the proposed attack and if it did indeed translate into a realistic attack, and if so could we counter it. We contacted the researchers at Newcastle University who were very helpful in setting us on the right path to recreate their work. We built the PIN Logger App and the AI engine which would process the data to attempt to “guess the PIN”. The attack works by feeding mobile sensor data into an AI / Machine Learning engine, actually it’s a Neural Network, which is then able to determine the PIN number pressed. However in order for the AI Engine to correctly guess the PIN number, it needs to learn the patterns of sensor data associated with the PIN number. This takes data, lots of data, and lots of processing power.
In their paper, the researchers at Newcastle University used 1.4million data points (that’s 140,000 per PIN digit) to train their Neural Network over 10million iterations, after which they were then able to achieve a 70-80% accuracy on a restricted number of PINs (just 50 PINs from ~10,000 possible PINs).
Our Hyperlab team worked their magic, and by applying a few restrictions and limitations (i.e. using fewer data points and restricting the mobile PIN entry to a single plane) we were able to reproduce the attack with a 30% accuracy. We were able to adjust the accuracy level by feeding fewer or more data points when training the Neural Network, which leads us to believe that the results obtained by the Newcastle researchers are achievable. What’s more it’s not possible to block a background app in Android from obtaining the sensor data whilst PIN entry (as defined in PCI SPoC) is taking place. Surely this is a disaster for software PIN on Glass?
There are several things to consider here. In order to mount the attack you need 1.4million data points, and plenty of processing power to train the Neural Network, and that’s just for a single mobile device. Plus the training app needs to use the same keypad layout as the keypad you are trying to steal PINs from. A malicious data gathering app then needs to be present and active on a PCI SPoC device. However even then it does not know when a PIN will be entered, and will have to find the PIN entry within the rest of the screen taps, e-mails, SMS, rounds of Candy Crush that a merchant may use their mobile for on a normal day. This amount of entropy itself would render the attack method futile.
Hats off to the researchers at Newcastle University their paper and attack vector is enlightening and should be taken seriously. Whilst we do not believe it is a scalable attack it will certainly be taken into consideration when we build our next clients security architectures to support PCI SPoC PIN entry.
Consult Hyperion is known for robust architecture designs and rigorous test plans, making sure our clients launch products and services that protect their customers financial and personal data, and the brand reputation of the client. If you would like to talk to us, please do get in touch – firstname.lastname@example.org.
The (real) news over the past couple of years has been full of reports of fake news. Well now we have fake apps too.
Last week this report from ESET  highlighted fake mobile banking apps on the Google Play store. According to the article ESET discovered and reported a set of fake banking apps that were published and remained on Google Play between June and July 2018. These apps offered lucrative deals to the unwitting banking consumer, one for instance claiming to increase your credit card limit if you installed them. They are of course nothing more than a phishing scam – collecting account and card payment details allowing the scammer to empty your bank account.
Fake apps displaying forms to phish consumer’s bank login details (source ).
As you can see some effort was put into making the apps look authentic in order to fool the customer. But how is it that they managed to fool Google into allowing those apps onto the app store in the first place?
Ironically, Google has a “Safe Browsing” initiative to protect consumers from phishing and malware. Play Protect (rebranded Google Bouncer) is used to protect the store and its consumers from malware, spyware and trojans. Google also employs automated scans to detect known threats, heuristics and data analytics on metadata, big data, to monitor downloads, usage and detect anomalies.
So whilst Google does try to spot the technical threats that might compromise the person’s device, for example, it appears they are not always able to spot the blatantly obvious – one of the app says it’s ICICI, but the developer is not ICICI.
In fact, by the time the fake app was reported to Google and they removed it from the store, the damage had already been done to several thousands of trusting consumers!
What can banks do about this to protect their customers? Quite a lot actually. In a robust digital banking solution, the bank will employ numerous measures to establish the authenticity of the device, access channel and customer. A bank should be able to detect when there is a man-in-the-middle and when information captured on one device or channel is replayed into another device or channel. The technology to do this exists and we have been helping banks employ it for years. Unfortunately, until all banks do the same consumers will need to be extra vigilant about the financial apps they load onto their devices.
Host Card Emulation (HCE) is the technology in mobile phones that enables them to emulate contactless smartcards, but more about that later. The above question about HCE security was posed by a member of the Transport Card Forum committee when deciding the agenda for the June event in London. I was asked to speak on the subject and this blog is a summary of the presentation I gave.
Cryptography on smart cards
Smart card chips are tamper-resistant hardware running secure operating systems (OSs). They are expensive to design and certify as being secure. However, the design and certification is done once and they are manufactured in high volumes in order to drive the price down.
The cryptographic algorithms execute on the smart chip in order that the secrets they use need not be revealed to the outside world. Only the results of the cryptographic calculations emerge to be used by others within the scheme to achieve authentication, confidentiality and non-repudiation.
Typically, the secrets are loaded to the card before it is issued. Thereafter, it is assumed that the secrets cannot be compromised within the lifetime of the card (e.g. bank cards typically have a 3-year life). Therefore, the cards are not typically designed to allow the secrets to be changed after they have been issued.
Cryptography on mobile devices
As mobile phones became popular and began to be able to emulate contactless smart cards in the noughties, it was at first assumed that a smart chip (or secure element (SE) as they are sometimes known) within the mobile device would be needed to securely hold the secrets and execute the cryptographic algorithms without revealing the secrets. However, the smart card within the phone was typically the SIM card owned by the MNO and not convenient for third parties (e.g. transit operators and banks) to use.
One of the reasons clients like to engage with Chyp is that we have our own lab where we can put leading-edge technologies together in new and interesting ways.
The trial was considered a success and the trialists did not want to give up their phones. However, the need to load tickets to apps residing on the SIM remained a big inconvenience in the real world. And this factor stopped any such proposals from advancing into production beyond trial.
What is HCE?
Host Card Emulation (HCE) is an alternative to SE-based contactless smart card emulation. The ‘Host’ is the main processor within the mobile device. Typically, SEs within the mobile device are not used and clever software solutions are found instead to allow cryptographic algorithms to execute using secrets without revealing the secrets and without using secure hardware.
Our work in the field of HCE began before the term was coined. We used to call it ‘NOSE’ which stood for ‘No Secure Element’.
2007: We built prototypes in our lab using standard NFC controller chipsets found in mobile phones that allowed us to perform EMV transactions with contactless readers without using an SE. We were unable to implement this on mobile phones at the time since the mobile device operating systems did not allow it.
2008: Our ITSO mobile ticket trial at NowCard showed that users liked the experience once the phone was provisioned, but provisioning to the SE remained a big barrier, so ‘NOSE’ could be popular in the future.
2012: The term ‘HCE’ was coined by SimplyTapp who used an open-source Android OS called ‘CyanogenMod’ with extensions to allow HCE software implementations to work on mobile devices.
2013: Bankinter (Spain) made an HCE implementation on Blackberry for Visa.
2013: Google decided to allow HCE on the official Android OS release v4.4 known as ‘Kitkat’.
2014: At the World Congress, both MasterCard and Visa made public announcements supporting HCE.
2015: Android Pay launches using HCE on Android.
2015 Chyp designs ‘ITSO with HCE’ for ITSO with the requirement to minimise changes to the existing ITSO infrastructure.
2016: Chyp advise on the Barclays contactless mobile first UK bank HCE solution.
2016: Amex Pay launches with HCE on Android.
2017: Transport for the North trial of ‘ITSO with HCE’ between Leeds and Huddersfield.
2017: ITSO announces working with Nexus (Newcastle) and a ‘global digital distributor’ to bring HCE to the North East.
2018: ITSO on Mobile HCE trials start with Google Pay using the Google wallet on Android phones. Trials are taking place in the West Midlands (TfWM) and the North East (Nexus).
Rambus and ACT both currently have working HCE solutions for ITSO on mobile devices and are waiting for ITSO to carry out the testing and certification before they can be deployed on live ITSO schemes.
While HCE implementations free us from the inconvenience of provisioning apps to SEs within the mobile device, they are not without their challenges. In addition to the provisioning of short-life secrets described above, there are the following challenges:
Each HCE implementation is unique and will have aspects of its implementation that are not off-the-shelf and already certified as secure. Typically, penetration testing will be needed to show that the HCE transit app is secure enough and that tickets cannot be easily faked or cloned. This is bespoke testing carried out by specialists.
Mobile handsets are constantly evolving. Typical customers replace them every two years with a newer generation. HCE apps should be maintained to ensure they are available to use on as many of the handsets in use as practical.
Mobile OS updates mean that you need to allow for all the possible combinations of handset running all the possible OS versions.
Security is an arms race. Regular reviews of the latest known attacks are needed and potential updates made to the HCE app in order to remain secure.
So, can HCE be secure enough for transit ticketing? Well, yes, you can imagine, if it can be secure enough for banking, it can be secure enough for ticketing. But HCE implementations are difficult to implement and deploy. They require a dedicated and experienced team and constant maintenance as attacks and handsets and OSs evolve. So, it will be interesting to see how many HCE transit implementations appear and remain on the scene to displace the traditional smart card or whether yet other mobile ticketing solutions replace them altogether.
Subscribe to our newsletter
You have successfully subscribed to the newsletter
There was an error while trying to send your request. Please try again.