Ruby reflections, 40 years of technology change at work

silver and gold coins

At this time of year my colleague, Dave Birch looks forward, his annual “Live Five” started as a bit of fun, but over the years has become a thought provoking look at what might impact our industry in the coming year, if you haven’t read it yet, please follow this link.

As we come to the holiday season, we know that we will be bombarded with reviews of 2020 on television, in our newspapers and online. A conversation with some colleagues about how long they had worked in the payments industry, prompted my own review when I realised that on the 8th December, I clocked up 40 years in the industry, how technology has changed our lives in that time.

Contact-Free: the backdrop to Payments, Ticketing & Identity in 2021

pexels-photo-5408689.jpeg

It’s that time of year again: where’s it’s traditional to take stock and look to the future. At Consult Hyperion, we do that through our ‘Live 5’ process; where we look at major trends in business, technology and consumer attitudes and project them onto our areas of business focus, with twists of our own. This is more than a marketing exercise. It informs our advisory services, but also sets our own strategy, for example by determining what technologies are investigated, and protypes built, by our Hyperlab unit.

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

4+4 | Strategic thinking for post-pandemic payments

mountains nature arrow guide

Early on in the pandemic my colleagues at Consult Hyperion and I did a lot of research to explore how it might impact our customers and our customers’ customers, just as I am sure every other organisation in the payments sector did. We looked at a lot of speculative forecasts, we looked at research and analysis from quite a wide range of organisations in the financial sector and beyond, we spoke to a number of people in the industry and we took part in a fair few discussions and debates on the topic. As a result of this, we identified a number of strategic areas where stakeholders in the payment space should be developing or at least preparing their strategies and where they should be planning for some changes to take them through and beyond the COVID-19 crisis.

Travel Broke and Broken

The ongoing COVID-19 crisis has been ruthlessly exposing fragile business models and weak balance sheets across a whole range of industries but perhaps never more so than in the travel business. In fairness, no one could have anticipated a global, government dictated total shutdown and no business models could ever be flexible enough to support such an improbable scenario. Still, it’s become clear that many travel industry companies are effectively broke and that the payments model they rely on is broken. Going forward we need a better and more sustainable approach to payments in the industry.

Most travel industry payments rely on payments cards so it’s worth starting by recapping on how most card payment models work. When a cardholder makes a payment to a merchant – either in store or, increasingly, on-line, this is routed to the merchant’s card acquirer. The acquirer has a direct relationship with the merchant in the same way that a card issuer has a direct relationship with cardholders and the acquirer will route the payment request to the relevant issuer – usually by sending the request to a payment scheme who uses the card number to identify the correct issuer. If the issuer approves the transaction then the response is routed back through the same path and the purchase completed. This is no different from any other card payment, although there are hidden complexities where the merchant is an online travel agent sourcing flights, hotels, etc from multiple underlying vendors. However, that’s a detail.

What does Apple’s purchase of Mobeewave mean for SoftPOS?

Apple acquires Mobeewave

Using mobile devices for securing payments has been, and continues to be, a key area of interest for Consult Hyperion and our customers.  We have helped many of our clients in this space from: providing advice on the market landscape, advising on security, testing security, developing security architectures, and building solutions.  Apple’s purchase of Mobeewave a couple of weeks ago has caught our, and everyone else’s, attention.  This gives us some time to reflect on this and consider what it means for the SoftPOS industry and ecosystems.

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.

The Challenge of Delivering mPOS Services through Off-The-Shelf Mobile Devices

 

The last few months have been exciting if, like Consult Hyperion, you are attracted by the mobile POS (mPOS) sector. We’ve seen significant announcements from Mastercard and Worldpay and heard interesting rumours about the current work within the PCI Security Council, suggesting that the use of off-the-shelf mobile devices as card acceptance devices is likely to happen in the near future.

Targeted at small to medium sized and mobile merchants who do most of their business in cash or cheques, but have the occasional customer who prefers to transact by card, the mPOS dongle (card reading device) has been seen by these merchants as their first venture into the “expensive” world of credit and debit cards. However, the cost of the dongle and the power required to run it are often cited as barriers to the adoption of mPOS services.

Magnetic stripe dongles are effectively given away; their cost refunded through reductions in the fees levied against the initial transactions; their power derived from the phone, when inserted in the audio port. Chip & PIN dongles are more complex and so more expensive requiring their own power supply or battery. The business case to subsidize the additional cost of these devices through reductions in transaction fees is more challenging.

The higher cost and more power-hungry elements of a Chip & PIN dongle are the display and keypad. If we can replace these components with the capabilities of an off-the-shelf smartphone, can we bring down the cost and power requirements of the Chip & PIN dongle closer to that of the magnetic stripe version? If we can deliver the service entirely through a mobile application, can we simplify our distribution channels? These are the sort of questions that get the team at Consult Hyperion excited as they present big information security challenges, which we like.

Generic, off-the-shelf mobile devices have none of the physical and electronic countermeasures designed into a payment terminal to secure the personal and account information in the payment transaction. Nor do they have the specific assets required by the payment scheme such as the secure PIN entry capabilities. Equally, the Acquirer doesn’t have any control over the other applications loaded onto the phone or tablet, which could include malware designed to impact the performance of their mPOS service or monitor any communications to or from it.

So, the challenge is; can we develop applications for generic off-the-shelf mobile devices that deliver, as far as practical, similar levels of security to the hardware in the payment terminal, whilst withstanding repeated attack from hackers interested in capturing assets that they could use to attack the payment schemes’ international networks?

There are many companies delivering solutions which could protect the mPOS application against some of these threats and/or give the Acquirer a level of assurance about the identity of the individuals involved in the transaction. However, no one solution is likely to deliver against all of the PCI’s security standards, should they be published, and not every solution works on every mobile device.

So, the team designing your mPOS solution for off-the-shelf mobile devices must understand in detail the threats to which the application will be exposed, the most cost-effective countermeasures against those threats, how they work together and how they need to evolve in response to new fraudulent attacks. Experience would suggest that they will need to understand in detail the operation of the EMV payment application, transaction security and the smartphone operating system, whilst having considerable experience of implementing the best-of-breed information security tools.

People with such experience are few and far between. Many are my friends and colleagues, which makes my job interesting, exciting and rewarding. It looks like a busy end to the year!

Payments and passports

The new administrations in the UK and USA are apparently planning to work together to create a new transatlantic America First / Buy British trade alliance. This will, it seems, include financial services. 

A deal to reduce barriers between American and British banks through a new “passporting” system was being considered by Mr Trump’s team

From Donald Trump plans new deal for Britain as Theresa May becomes first foreign leader to meet new president since inauguration

Now what this passporting might mean is anyone’s guess, since this is just a newspaper story based on gossip, but I think it might be a little more complex to arrange than it seems at first because of the nature of banking regulation in the United States. If a British bank were to get a US banking passport this would presumably be equivalent to the implicit granting of a national bank charter and state regulators do not seem enthusiastic about the granting of more national bank charters. We know this, because at the end of 2016 the US Office of the Comptroller of the Currency (OCC) said that it was going provide a new national bank charter for fintech companies.

“The OCC will move forward with chartering financial technology companies that offer bank products and services and meet our high standards and chartering requirements,” said Comptroller of the Currency Thomas Curry

From OCC Grants New Charter to Fintech Firms — with Strings Attached | American Banker

The reason for wanting to do this is obvious: right now, if I want to create a competitor to Venmo or Zelle, I have to either have to be regulated as a payment processor and have regulated banks involved or go and get regulated by 50 different state regulators under 50 different regulatory regimes, most of which remain rooted in a previous, pre-internet age. This seems anachronistic. Surely an American company should be able to a get a licence and get going. Well, the OCC’s proposal is attracting a lot of negative comment.

A turf war is brewing between US state and federal regulators over oversight of the financial technology sector after New York’s top watchdog sent a stinging letter to the Office of the Comptroller of the Currency (OCC), telling it to back off plans for a national bank charter for fintech firms.

From New York regulator blasts OCC over bank charter plan for fintech fi…

Now I saw a few comments about this and other responses from state regulators that cast them in the role of Luddites standing in the way of progress but I have to say I agree with them. I mean, I am not a lawyer or anything, I don’t really understand US banking regulation and I couldn’t make any sensible comments on the proposals myself, but I think that the US regulatory environment is broadly speaking unfit for purpose and might benefit from at least a cursory examination of the direction of regulation in one or two other jurisdictions including Europe, for example and India.

Saycanyousee

The fundamental problem with the OCC proposals to my mind is that they are about a national charter for banking as a whole. They do not distinguish between the payments business and other parts of the banking business. Hence the charter means extending systemically risky credit creation activities in new directions. I don’t see any immediate problem that this solves. And the state regulators may well be right that it potentially makes the problems associated with banking regulation much worse.

Connected to this is the worry that a national charter would encourage large ‘too big to fail’ institutions – a small number of tech-savvy firms that dominate different types of financial services simply because they are able to get a national charter.

From New York regulator blasts OCC over bank charter plan for fintech fi…

Whatever you think about Facebook they are not too big to fail. If Facebook screw up and lose a ton of money and go out of business then that is tough luck on their employees and their shareholders but it’s nobody else’s problem. That’s how capitalism is supposed to work. But if Facebook obtained a national banking charter they would immediately become too big to fail and no matter the greed or incompetence of their management, the government will be on the hook to bail them out just as the Roman senate was forced to bail out the banks there two millennia hence.

Romani

(In case you are curious, in 33BCE the emperor had to create 100 million sesterces of credit (a trifling couple of billion dollars in today’s money) through the banks to save them from collapse. Plus ca change, as they didn’t say in Ancient Rome).

If you look at what is happening in other jurisdictions, what you see is a separation of payments and banking so that the systemically less risky payment activities, which many people see as somewhat less than optimal in the world’s largest economy, can be reinvigorated while the systemically more risky credit business and investment banking business are left alone. In the European Union there is the regulatory category of the payment institution (PI). In Europe, Facebook is therefore a payment institution and not a bank.  They don’t want to lend people money, they want to facilitate buying and selling and for that they need access to core payment systems and that’s all to the well and good. Similarly, in India, the regulator created the new category of payment bank (PB) so that mobile operators and others could start providing electronic payment services to what will soon be the world’s most populous nation.

The reasons for going down this path are entirely logical. If you leave innovation to the banking system then you end up in the situation of India as was or Nigeria as it is. A huge population, phones everywhere, talented and entrepreneurial people, huge and unfulfilled demand and… Nothing happening. I’m sure you’re all utterly bored with me reminding you, but the key innovations in technology in banking do not originate in banks. That’s the nature of the beast. The four digit PIN code was invented by a Scottish engineer. The payment card was invented by New York lawyer. M-PESA was invented by a telco. Bitcoin was invented by… Well, for all I know, it may well have been the head of Citibank or programmer number 2216 in the North Korean army, but you get my point.

This is why I think that the OCC should leave the regulation of credit institutions where it is now and propose instead a new national charter for payment institutions amalgamating the European PI and Electronic Money Institution (ELMI). Allow these American Payment Institutions (let’s shorten this to APIs to avoid confusion) to issue electronic money but not to provide credit, allow membership of payment schemes (e.g., the UK’s Faster Payment Service, Visa and so on), ensure customer balances are held in Tier 1 capital and so on.  This way, Apple and Verizon can apply for a national charter and start providing competitive payment services that will benefit businesses and consumers and the existing banks will just have to suck up the loss of payment revenues for the greater good.

The passporting of such institutions should be much less controversial than the passporting of credit institutions. Surely it will be to everyone’s benefit if the “fintech” passporting agreements give UK and EU payment institutions the right to operate nationally in the United States, in return giving recipients of my proposed American Payment Institution charter the right to operate in the UK and EU? This would allow innovation and competition in the fintech space without creating yet another financial time bomb that bankers will inevitably trigger.

 


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.