For the third year running, my colleague Gary Munro facilitated a thought-provoking debate around the use of mobile phones and tablets as contactless payment terminals during last week’s virtual Merchant Payments Ecosystem (MPE) conference. For the last three years, Gary and his panellists have tracked the progress of the SoftPOS technology and standards. The three key messages that I took away from this year’s conversation were that:
For most of us 2020 isn’t going to be a year to linger fondly in the memory. It’s been a monumental slog in the face of grim news and little cheer but from a payments perspective we’ve seen an unsurprising surge in interest in all things payment related.
People have moved from cash to electronic payments – contactless transaction numbers have soared. People moved from face to face purchases to online. And, there’s been a ton of stress on payment systems as people have demanded refunds for holidays and flights they couldn’t take due to various travel restrictions. It’s been a year like never before.
We can expect this to be exacerbated over what will likely be an extended Black Friday and Christmas holiday shopping period. Online payments are expected to grow even though economies are in recession. For us in Europe it’s the last hurrah before PSD2 requirements on strong customer authentication come into force on January 1st. Merchants and payment companies will be well staffed on News Year Eve as they wait and see how the systems will hold up, and what sort of abandonment figures they’ll see as puzzled customers are presented with confusing authentication screens. We can probably expect a flood of concerned calls about phishing which are actually Strong Customer Authentication requests.
Payment Processing Platforms
At Consult Hyperion we spend a lot of our time looking into payments processing platforms for our clients. Over recent months we’ve delivered;
- technical due diligence, assessing their capabilities
- security and vulnerability analysis on networks and products
- designed fundamental security architectures for new payments solutions
- advised clients on the selection of payment platform solutions
- and helped design new platforms or extended the capability of their existing platforms
It’s fair to say we have a comprehensive understanding of payments processing. The products and solutions offered by Fintechs, Banks, Neobanks etc. rely on the capabilities of the underlying payments platform(s).
When consumers install software on their devices, they often perform some sort of risk evaluation, even if they don’t consciously realise it. They might consider who provides the software, whether it is from an app-store, what social media says, and whether they have seen any reviews. But what if once a piece of software had been installed, the goalposts moved, and something that was a genuine software tool at the time of installation turned into a piece of malware overnight.
This is what happened to approximately 300,000 active users of Chrome ad blocking extension Nano Adblocker. You see, at the beginning of October, the developer of Nano Adblocker sold it to another developer who promptly deployed malware into it that issued likes to hundreds of Instagram posts without user interaction. There is some suspicion that it may have also been uploading session cookies.
What did you think of the US election? I don’t mean the candidates and the outcome. What did you think of the election process? Should it be possible for national elections of this type to be done online? Last week the IET published a paper on internet voting in the UK, led by our good friend at the University of Surrey, Professor Steve Schneider. It’s well worth a read. As the paper explains, internet voting for statutory political elections is a uniquely challenging problem. Firstly voting systems have exacting requirements and secondly, the stakes are high with the threat of state level interference.
This post was written in collaboration with Neal Michie, Director, Product Management, Verimatrix.
Banks are facing massive disruption and change from many directions. The rise of app-only banks has made the need for traditional banks to have compelling app services an imperative. Banks have of course been building mobile apps for several years. If not already, they will soon be the most important channel for engaging with and serving customers. However, mobile banking apps will also become the primary focus of hackers, intent on getting access to other people’s information and money.
As I was scanning my list of security-related posts and articles recently, my eye was drawn by the first sentence of an article on (Google security engineer) Adam Langley’s blog, indicating that Her Majesty’s Government does not understand TLS 1.3. Of course, my first thought was that since HMG doesn’t seem to understand the principles of encryption itself, it’s hardly surprising that they don’t understand TLS. However, these aren’t the thoughts of an understandably non-technical politician but instead those of Ian Levy, the Technical Director of the National Cyber Security Centre at GCHQ – someone you’d hope does understand encryption and TLS. Now normally, I would read this type of article without feeling the need to comment. So what’s different?
Well, following the bulk of the article discussing how proxies are currently used by enterprises to examine and control the data leaving their organisation, by in effect masquerading as the intended server and intercepting the TLS connection, is the following throwaway line:
For example, it looks like TLS 1.3 services are probably incompatible with the payment industry standard PCI-DSS…
Could this be true? Why would it be true? The author provided no rationale for this claim. So, again in the spirit of Adam Langley, “it is necessary to write something, if only to have a pointer ready for when people start citing it as evidence.”
Adam’s own response – again following a discussion about how the problem with proxies is their implementation, not with TLS – is that
…the PCI-DSS requirements are general enough to adapt to new versions of TLS and, if TLS 1.2 is sufficient, then TLS 1.3 is better. (Even those misunderstanding aspects of TLS 1.3 are saying it’s stronger than 1.2.)
which would seem to make sense. Not only that, but
[TLS 1.3] is a major improvement in TLS and lets us eliminate session-ticket encryption keys as a mass-decryption threat, which both PCI-DSS- and HIPAA-compliance experts should take great interest in.
In turn, Ian follows up to clarify that it’s not TLS itself that could present problems, but the audit process employed by organisations
The reference to regulatory standards wasn’t intended to call into question the ability of TLS 1.3 to meet the data protection standards. It was all about the potential to affect (badly) audit regimes that regulated industries have to perform. Right or wrong, many of them rely on TLS proxies as part of this, and this will get harder for them.
So that’s alright. TLS 1.3 is not incompatible with PCI DSS. So what is the problem? Well, helpfully, Simon Gibson outlined this in 2016:
…regulated industries like healthcare and financial services, which have to comply with HIPAA or PCI-DSS, may face certain challenges when moving to TLS 1.3 if they have controls that say, “None of this data will have X, Y, or Z in it” or “This data will never leave this confine and we can prove it by inspecting it.” In order to prove compliance with those controls, they have to look inside the SSL traffic. However, if their infrastructure can’t see traffic or is not set up to be inline with everything that is out of band in their PCI-DSS, they can’t show that their controls are working. And if they’re out of compliance, they might also be out of business.
So the problem is not that TLS 1.3 is incompatible with PCI DSS. It’s that some organisations may have defined controls with which they will no longer be able to show compliance. They may still be compliant with PCI DSS – especially if the only change is to upgrade to TLS 1.3 and keep all else equal – but cannot demonstrate this. So what’s to be done?
Well, you could redefine the controls if necessary. If your control requires you to potentially degrade, if not break, the very security that you’re using to achieve compliance in the first place, is it really suitable? In the case of the two example controls above, however, neither of them should actually require inspection of SSL traffic.
For the organisation to be compliant in the first place, access to the data must only be possible to authorised personnel on authorised (i.e. controlled) systems. If you control the system, you can stop that data leaving the organisation more effectively by prohibiting its access to arbitrary machines in the external world. After all, you have presumably restricted access to any USB and other physical storage connectors, and you hopefully also have controls around visual and other recording devices in the secured area. It is difficult in today’s electronic world to think of a situation where a human (other than the cardholder) absolutely must have access to a full card number without (PCI DSS-compliant) alternatives being available.
So TLS 1.3 is a challenge to organisations who are using faulty proxies and/or inadequate controls already. It certainly doesn’t make you instantly non-compliant with PCI DSS.
Given this, we, as humble international payments security consultants, are left puzzled by the NCSC’s line about TLS 1.3 and PCI DSS compatibility. At worst, organisations need to redefine their audit processes to use the enhanced security of TLS 1.3, rather than degrade their security to meet out of date compliance procedures. But, of course, this is the type of problem we deal with all the time, as we’re frequently called in to help payment institutions address security risks and compliance issues. TLS 1.3 is just another tool in a complex security landscape, but it’s a valuable one that we’re adding to our toolkit in order to help our clients proactively manage their cyber defences.
At Consult Hyperion we’re always interested in the latest news in cyber security and in case you haven’t heard, 2018 has started with the news that the most processors found inside current computers, tablets, phones and cloud servers are vulnerable to a new class of attack. These attacks have been named Meltdown and Spectre, and are caused by common optimisations built into modern processors. Processors designed by Intel, AMD and ARM are all affected to varying degrees and, as it is a hardware issue (possibly dating back to 1995 if some reports are correct), it could affect any operating system. It’s likely the machine you’re reading this on is affected – whether it’s running Windows, Macs, iOS, Android or is in “the cloud”!!
At a basic level, these vulnerabilities break down the fundamental security barriers between an application and the operating system (OS). This means that a malicious application running on your processor may be able to read your, or your OS’s, secrets which may include passwords, keys or possibly payment data, present in processor caches or memory.
I’m not going to discuss how the vulnerabilities achieve what they do (there’s plenty of sites which attempt to do this), however I’d rather consider its impact on people, such as our clients, who may be handling sensitive data on mobile devices – e.g. payments, banking information. If you do want to understand the low-level details of the vulnerabilities and how they work, I suggest looking at https://spectreattack.com/ which has links to the original papers on both Spectre and Meltdown.
So, what can be done about it? The good news is that whilst the current processors cannot be fixed, several operating system patches have already been released to try and mitigate these problems.
However, my concern is that as this is a new class of attack, Spectre and Meltdown may be the tip of a new iceberg. Even over the last week, the issue has changed from it only affecting Intel processors, to now including AMD and ARM to some extent. I suspect that over the coming weeks and months, as more security researchers (and probably less savoury characters as well) start looking into this class of attack, there may be additional vulnerabilities discovered. Whether they would already be mitigated by the patches coming out now, we’ll have to see.
It should also be understood that for the vulnerability to be exploited, there are a few conditions which must be met:
2. You must have a vulnerable OS (i.e. unpatched)
3. An attacker must be able to execute their malicious code on your device
For point 1, most modern devices will be vulnerable to some extent, so we can probably assume the condition is always met.
Point 2 highlights two perennial problems, a.) getting people to apply software updates to their devices and b.) getting access to appropriate software updates.
For many devices, software updates are frequent, reliable and easy to install (often automatic) and there are very few legitimate reasons for consumers to not just take the latest updates whenever they are made available. We would always recommend that consumers apply security updates as soon as possible.
A bigger problem for some platforms is the availability of updates in the first place. Within the mobile space, Microsoft, Apple and Google all regularly release software updates; however, many Android OEMs can be slow to release updates for their devices (if they release them at all). Android devices are notorious for not running the latest version of Android – for example, Google’s latest information (https://developer.android.com/about/dashboards/index.html – obtained 5th January 2018 and represents devices accessing the Google Play Store in the prior 7 days) shows that for the top 81% of devices in use:
• 25% are running Nougat (v7.x, released August 2016)
• 30% running Marshmallow (v6.0, released October 2015)
• 26% running Lollipop (v5.x, released November 2014).
It should be noted that Google’s Nexus and Pixel devices have a commitment to receiving updates for a set period of time, and Google is very keen to encourage OEMs to improve their support for prompt and frequent updates – for example, the Android One (https://www.android.com/one/) programme highlights that these devices get regular software updates.
If you compare to iOS, it’s estimated (https://data.apteligent.com/ios/) that less than a month after it was released in December 2017, over 75% of iOS devices are already running iOS 11.
Thinking specifically about mobile banking and HCE payment applications, which is what interests many of our customers – these applications should already be including protections to prevent, or at least detect, malicious attacks. These protections typically include numerous measures such as root/jailbreak detection, code obfuscation, data minimisation, white-box cryptography and so on.
If anything, these latest vulnerabilities are a useful reminder that security is not a single task within a project plan, ticked off when complete before moving onto the next sprint or task. Rather, it is an ongoing concern for the lifetime of the system – something that Consult Hyperion quietly helps its customers with. A year ago, few would have considered this class of attack to either have been possible, let alone something which needs to be actively mitigated.
QR codes are everywhere because anyone can read them, anyone can use them, anyone can write them. This is in part because there is no security infrastructure. The result in China, where there was little card infrastructure in place beforehand, was the near-ubiquity of QR in the world’s biggest mobile payments market.
“Ogilvy & Mather and Ipsos concluded in a survey of China’s mobile payment market that ‘[Chinese] mobile payment has permeated all aspects of life and changed basic, everyday habits.’”
It seemed to us that fraud would be an inevitable consequence of this QR-centric approach, that is indeed what happened. Last year, for example, the South China Morning Post reported that in March 2017 some 90m Yuan were stolen via QR code scams in Guangdong alone (a suspect in one case was found to have replaced merchants legitimate bar codes with fake ones that embedded a virus to steal personal information) and that in China as a whole, a quarter of viruses and trojans were coming in via QR.
Now, while even the man who invented QR codes says that they are an interim technology, there’s no denying that they are here to stay. Hence it makes sense to find a way to make them more secure, and the obvious way to do this is two-factor authentication (2FA). It turns out that the Chinese regulators have come to the same conclusion and have implemented the equivalent of the European Union (EU) Second Payment Services Directive (PSD2) Regulatory Technical Standards (RTS) on Secure Customer Authentication (SCA).
“Under new rules released by the People’s Bank of China [in December 2017], all transactions over 500 yuan (US$76) will be subject to additional levels of verification. As the transaction value passes each trigger point – 1,000 yuan, 5,000 yuan and unlimited – so the security checks will increase.”
Introducing further authentication methods makes obvious sense. Just as in the UK we have contactless for low-value payments but 2FA for higher-value payments (ie, chip and PIN for cards or CDCVM for mobile), QR will be used for low-value payments but 2FA will be required for higher-value payments. Of course, in the Chinese system, QR works just as well on-line as in-person whereas in our system we don’t use chip and PIN online.
This is where we (ie, the industry) should focus our efforts in 2018, since card-not-present fraud is currently growing at 9% per annum in the UK. So what is the way to use chip and PIN online? Well, we already know – it’s the combination of web and mobile browsing with mobile wallets for transactions. When I see a web form asking me to type in my card details – in 2018 already! – my heart sinks. I’ve used ApplePay in-browser a couple of times now (which is the equivalent of using chip and PIN online, as it uses the token in the wallet on the iPhone to complete a web transactions) and I’m already frustrated that more web sites don’t use this kind of solution. If we put our minds to it, we can have online payments that are as ubiquitous as in China, but more secure.
A decade ago I remember writing that one of the problems with QR codes is that there is no security. Some years later I wrote an article pointing out that NFC ought to be safer than QR codes because NFC included a standard for digitally-signing tags (although I did also note that no-one used it) whereas anyone could easily create bogus QR codes.
Well, I might not go so far as to call [QR codes] evil, but they certainly have the potential to enable person or persons unknown to act with evil intent.
I suggested, in connection with a couple of projects we were working on at the time, that the mobile operators do something about this by creating a digital signature standard for QR codes so that phones could be set by default to ignore unsigned codes. None of this happened, as I’m sure you are aware and QR codes became popular precisely because any app could read any code anywhere.
The security problem never went away though. I notice in the South China Morning Post that in March 2017 some 90m Yuan was stolen via QR code scams in Guangdong alone (a suspect in the case replaced merchants’ legitimate bar codes with fake ones that embedded a virus to steal personal information) and that in China as a whole, a quarter of viruses and trojans come in via QR. Despite the incredible success of QR there, we need to do better.
Even the man who invented QR codes says that they are an interim technology.
Now, also back in the day, I had originally assumed that Apple would add NFC to the iPhone. I was wrong about this for years, so eventually I assumed that they were going to bypass the technology and go to Bluetooth. Yet what I said at the time still holds: NFC is undeniably convenient.
NFC is a convenience technology, and Apple loves convenience
I wasn’t just guessing about this, I was drawing on Consult Hyperion’s early experiences with NFC (remember the Nokia 6131?) of tag reading and writing, including not only the usual payments and ticketing stuff but also such fun applications as getting information about clothes at London Fashion Week. I also noted surveys at the time that showed that NFC generated better results for merchants, but only once consumers could get it working. As my good friend Osama Bedier, then head of Google Wallet, pointed out, this is was some barrier because of the amount of “futz” it took to get NFC working.
But there was another reason that I was so interested in NFC as QR alternative back in this days. To go back to the security point, I was interested in thestandard for adding digital signatures to NDEFs (the “NFC Signature RTD Technical Specification”) to build a safe tag infrastructure. After hawking this around a few different projects, to general disinterest, I figured that the telcos weren’t interested in using it to deliver secure infrastructure, so I said…
“Someone else will build this business (Apple? They seem to be getting all sorts of NFC-related patents at the moment) and then the operators will once again complain about being pipes. Is Tom Noyes right to say that “…Apple and Google will be further ahead in coordinating value in new networks”
Well, well. Tom was right as usual, even if it took a few years for the hand to play out. At WWDC, Apple announced that IOS11 will indeed include the ability to read NDEF data from tags.
“Using Core NFC, you can read Near Field Communication (NFC) tags of types 1 through 5 that contain data in the NFC Data Exchange Format (NDEF).”
So now, more than a decade after our first NFC experiments, both IOS and Android can read standard tags and action them. I want to make a couple of quick points about this before I head off down to our Hyperlab and see what our developers make of the new toolkit.
First of all, this technology will inevitable be used for triggering in-app payments that work in a very convenient way for consumers. Instead of having to open your Tesco Payqwiq app and then scan a code from the POS, the POS will function as a tag (and remember it can potentially rewrite a dynamic tag on the fly): you can just tap the phone on the POS and the operating system will automatically open the Payqwiq app and route the data to it.
Secondly, since tags are inexpensive, they will be used for a variety of different applications. Tickets for pop concerts, information about products, name badges, all sorts of things that can be read by a phone rather than by a specialist reader, Therefore I expect new standards for NDEF content to spring up. One of my favourite apps, back in the day, was a phone number tag that men could put in their back pocket at a nightclub: admirers could wave their phone in an appropriate area to get the number and send a text message. Here we are trying experiments with different types of clothing (which turned out to have very different NFC-friendly characteristics!) a decade ago.
Lastly, note that NFC tags can be read through packaging. Unlike QR codes that need to be printed on the outside of a box, tags can be inside. Where would this matter? Well, take a current UK example. Cigarettes now have to be in plain packaging. Tobacco companies don’t like this – for obvious brand reasons – but they do have a point: plain packaging makes like easier for counterfeiters. So suppose packs had a cheap tag inside: then your phone could tell you whether you’ve got real Marlboro or a knock off. You download the Marlboro app, then from then on when you tap a pack if the app doesn’t pop up with a big green tick you know you’ve been done. I’ve written about this sort of thing before ( for example, wine and whiskey) so it’s hardly a new idea.
Note, however, that IOS11 also includes ARKit to add augmented reality. So, when you look at your pack of plain cigarettes through your app (after you’ve tapped, so the phone reads the tag and knows that they are real Marlboro) you don’t see plain packaging any more you see… well whatever.
All in all, Apple’s announcement – whether the culmination of a clever plan or a response to Android market share – is a big deal. I found a whole bunch of blank NFC tags in my desk drawer so I’m off to start programming them now.