Black Friday, Cyber Christmas, and a Contact-Free New Year

paper bags near wall

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.

Future-Ready Payments Processing

abstract aluminum architectural architecture

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). 

Malware Wolves in Developer Sheep’s Clothing

internet screen security protection

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.

Internet voting – challenging but necessary

i voted sticker lot

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.

Is your mobile banking app exposed by someone else’s software?

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.

TLS, DSS, and NCS(C)

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.

Who would have ex-Spectre-d this?

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:

1. You must have a vulnerable processor (highly likely)
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:

• 0.5% of devices are running the latest version of Android – Oreo (v8.0, released August 2017)
• 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.

The final requirement is Point 3 – getting malicious code onto your device. This could be via a malicious application installed on a device, however, the malicious code could also come via a website as it’s been shown that even JavaScript sandboxed in a browser can exploit these vulnerabilities. As its not unheard of for legitimate websites to unwittingly serve up 3rd-party adverts which contain malicious code, a user doesn’t have to be accessing malicious websites for the problem to occur. Several browsers are receiving patches to try and prevent Meltdown and Spectre working via this route. Regarding malicious applications, we’d always recommend that applications are only ever installed from legitimate sources, however malicious apps still regularly appear in legitimate app stores, so this is not fool-proof.

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.

China’s PSD2 SCA

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.’”

From “How Chinese Mobile Payments Are Quietly Conquering the World“.

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.”

From “China’s central bank tightens security“.

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.

At last, NDEF

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.

From A quick response to the problem | Consult Hyperion

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.

From Never mind the last mile, what about the last millimetre? | Consult Hyperion

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

From Quick response | Consult Hyperion

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”

You don’t know ‘jack | Consult Hyperion

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).”

via Apple adds support for NFC tags to iPhone 7 and Apple Watch • NFC World

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.

NFC Example

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.

Don’t bogart that iPhone

Over the years, I’ve often tried to persuade clients that the time will come when privacy will be part of the upfront consumer proposition rather than a back office hygiene factor.

privacy should be an integral part of the customer proposition that sways the choice of product or service

From The business of privacy | Consult Hyperion

This means that organisations should plan for investments in more sophisticated security infrastructure (you can’t have privacy without security) and that these should be on a roadmap that exploits this transition. I think we may be getting closer to this transition time, because I notice that Apple appear to taking quite a big step forward to improve the privacy of individuals in a networked, hyper-connected world by introducing “differential privacy” in its products.

Differential privacy provides a way to mathematically guarantee that statistics about a pool of data collected from many people can’t be used to reveal much about the contribution of any one individual. Apple has built it into the new version of its mobile operating system, iOS, for iPhones and iPads to be released this fall.

From Apple’s New Privacy Technology May Pressure Competitors to Better Protect Our Data

If you’re wondering what this means, and can’t understand the wikipedia article (I couldn’t), let me give you an example from some software that I wrote many, many years ago. I’ll use the example of recreational drug use, although this isn’t what the project I worked on was about (well, not during daylight hours, anyway).

Suppose for some reason — e.g., public health planning — the government wants to know how many people smoke dope. Imagine that there’s an app on your phone that asks you if you smoke dope. So it asks you “Do you smoke dope?”. The app sends your answer back to some survey database big data cloud thing. Now the big data cloud thing can tell other people (e.g., the government) that you smoke dope but that means that the police will know and also if hackers get into the survey database big data cloud thing they could blackmail you (or sell you dope).

But there is another privacy-enhancing way to do this.

The app asks you if you smoke dope. You answer. Then the app tosses a coin. If the coin comes down heads, then the app tells the big data cloud thing “yes”. If the coin comes down tails, then the app tells the big data cloud thing whatever your real answer was.

Let’s say 10 million people answer. In the big data cloud thing, there are seven million yes answers and three million no answers. Remember, because the coin toss is fair, then five million of the answers will be a yes anyway. So you know that five million of the yes answers were there because of the coin coming down heads, and you can ignore them because they are not the real answer. You can take away five million of the yes answers as down to random chance.

Now you are left with the remaining five million real answers. There are the two million yes answers and three million no answers that are not down to random chance. You can therefore deduce that 40% of the population smoke dope.

Now, if hackers or the police get into the database and discover a yes answer next to your phone number, they cannot tell whether it is a real yes or a yes because of the coin toss. And you don’t want to reveal that you smoke dope, you can say that’s because of the coin toss.

Thus, the statistics for the population are correct and you know that 40% of the population smoke dope but you cannot tell whether any individual person smokes dope.

Now the differential privacy used by Apple is more complex than this simple example, but you get the point, and good on them for taking practical privacy-enhancing action whether it is to advance the sum total of human privacy or to put pressure on Facebook and Google. Either way, making privacy part of the proposition that might sway the customer’s choice is a very good thing.


Subscribe to our newsletter

You have successfully subscribed to the newsletter

There was an error while trying to send your request. Please try again.

By accepting the Terms, you consent to Consult Hyperion communicating with you regarding our events, reports and services through our regular newsletter. You can unsubscribe anytime through our newsletters or by emailing us.