A simple explanation of Bitcoin “Sidechains”

Could sidechains be the enabler of “semi-decentralised” Bitcoin products and services?

An important paper was published this week:

Sidechains

If you’ve followed Bitcoin for any time, you’ll know this is a seriously eminent group of authors

It describes a way to build “pegged sidechains”. Sidechains themselves are not new – the idea, and how to build them, has been discussed for some time and the key breakthrough was outlined earlier in the year. But this paper gives more detail on the concept and has attracted a lot of comment.

But what are they? And why should anybody care?

A mental model for Bitcoin

The key to understanding most innovations in the Bitcoin space is to make sure you have the right mental model for how Bitcoin itself works. It turns out that most people I speak to don’t really understand how it works and, as a result, have a faulty mental model.

To help with this, I came up with an analogy for Bitcoin earlier in the year, based on thinking of Bitcoin “unspent transaction outputs” as parcels of land. Some people hated the analogy but I still think it has value :)

But in this piece, I’ll skip the analogy and net it down to the basics.

First, clear your head of anything related to money, currency or payments. And clear your head of the word ledger, too. The mind-bending secret of Bitcoin is that there actually isn’t a ledger! The only data structures that matter are transactions and blocks of transactions. And it’s important to get this clear in your head if sidechains are going to make sense.

When you “move” Bitcoins, what you’re saying is:

  • Hello everybody… I’d like to move these specific Bitcoins, please.
  • Here is the proof that I am entitled to move them
  • And here is how the recipient will, in turn, prove that they are entitled to move them.

three pictures

The critical three parts of a Bitcoin transaction

There are several important points here:

  1. Bitcoins are not perfectly fungible… when you move (or spend) them, you’re spending some specific bitcoins
  2. In order to spend them, you have to prove you’re entitled to do so. And you do that by providing the solution to a challenge that was laid down when they were sent to you in the first place. This challenge is usually just: “prove to the world that you know the public key that corresponds to a particular Bitcoin address and are in possession of the corresponding private key”. But it can be more sophisticated than that.
  3. When you send Bitcoins somewhere, you lay down the challenge for the next owner. Usually, you’ll simply specify that they need to know the public and private keypair that correspond to the Bitcoin address the coins were sent to. But it can be more complicated than that. In the general case, you don’t even know who the next owner is… it’s just whoever can satisfy the condition.

Keep saying the three steps to yourself until they’re etched on your memory!

Fine. So the “grammar” of a Bitcoin transaction is clear:   “Here are the coins I want to move, here’s the proof I’m entitled to and here’s what the recipient must do, in turn, if they want to spend them”.

This transaction is published into the network, it will eventually find its way into a block and, after other blocks have been built on top, everybody can be pretty sure it won’t be reversed and the world moves on.   What more do you need?

The core Bitcoin “grammar” works just fine, mostly…

This three-part structure to a Bitcoin transaction works well and it turns out that you can do some really interesting things with it.   For example, you can use the “not-entirely fungible” feature to “tag” coins. This is the basis of the “Colored Coins” and “Smart Property” worlds.

But there are problems, such as:

Block interval

Bitcoin’s block interval is ten minutes so it takes about five ten minutes on average for a new transaction to find its way into a block, even if it pays a high fee. This is too slow for some people so they have experimented with alternative cryptocurrencies, based on the Bitcoin code-base, which employ quicker block intervals   [UPDATED 2014-10-27 to correct my embarrassing misunderstanding of mathematics...]

Transaction Structure

The “three-part” transaction structure is very general but it only allows you to transfer ownership of Bitcoins. Some people would like to transmit richer forms of information across these sorts of systems. For example, a decentralized exchange needs a way for participants to place orders. Projects such as Mastercoin, Counterparty, NXT and others either build layers on top of Bitcoin or use entirely different codebases to achieve their goals.

Transaction Transfer Conditions

I said above that you can build sophisticated rules into Bitcoin transactions to specify how ownership is proved. However, the Bitcoin scripting language is deliberately limited and many ideas in the Smart Contracts space are difficult or impossible to implement. So projects such as Ethereum are building an entirely new infrastructure to explore these ideas

One-size-fits-all security model

It doesn’t matter if you’re moving $1bn or 0.01c across the Bitcoin network, you get the same security guarantees.   And you pay for this in fees and time.   What if you were prepared to trade safety for speed?   Today, your only real option is to send the coins to a centralized wallet provider, whom you must trust not to lose or steal your coins. You can then do all the transactions you like on their books, with their other customers and you never need touch the Bitcoin blockchain. But now you lose all the benefits of a decentralized value-transfer network.

One-size fits all doesn’t help if the size doesn’t fit you!

Now, making experimental or rapid changes to Bitcoin is very risky and so change happens slowly. So if the one-size-fits-all architecture of Bitcoin doesn’t suit a particular use-case, you have a problem. You either have to use an entirely different cryptocurrency (or build one!). Or you have to use (or build) a centralized service, which brings new risks.

This is very inconvenient. It creates risk and fragmentation and slows the build-out of products, services and infrastructure.

Centralised Wallet Providers as a “poor-man’s sidechain”?

But there’s an interesting observation we can make. Think about what happens if you send Bitcoins to a centralized wallet such as circle.com for safekeeping.

  • You send your coins to a particular Bitcoin address
  • They appear inside your circle wallet and are out of your control on the blockchain.
  • At some point in the future, you might send your coins back out of your circle wallet to a Bitcoin address you own
  • You now have control of some coins on the Bitcoin blockchain again!

From the perspective of the Bitcoin network, Circle is a black box.   You had some coins… you sent them to a specific address…   some stuff happened that Bitcoin couldn’t see…. And at some point later, you had control of some coins again.   It’s as if those coins had been moved from Bitcoin to somewhere else and then back again.

Here’s the Sidechains insight

The key idea behind the sidechains concept is:

What if you could send Bitcoins not only to individuals, addresses and centralized services but to other blockchains?

Imagine there is a Bitcoin-like system out there that you’d like to use. Perhaps it’s litecoin or ethereum or perhaps it’s something brand new.   Maybe it has a faster block confirmation interval and a richer scripting language. It doesn’t matter.   The point is: you’d like to use it but would rather not have to go through the risk and effort of buying the native tokens for that platform. You have Bitcoins already. Why can’t you use them?

The sidechains ideas is this:

  • Send your Bitcoins to a specially formed Bitcoin address. The address is specially designed so that the coins will now be out of your control… and out of the control of anybody else either. They’re completely immobilized and can only be unlocked if somebody can prove they’re no longer being used elsewhere (I’ll explain what I mean by this in a minute).   In other words, you’ve used the core bitcoin transaction rules I described above to lay down a specific condition that the future owner – whoever it ends up being – needs to fulfil in order to take control
  • Once this immobilisation transaction is sufficiently confirmed, you send a message to the other blockchain – the one you were wanting to use. This message contains a proof that the coins were sent to that special address on the Bitcoin network, that they are therefore now immobilized and, crucially, that you were the one who did it
  • If the second blockchain has agreed to be a Bitcoin sidechain, it now does something really special… it creates the exact same number of tokens on its own network and gives you control of them.
  • So it’s as if your Bitcoins have been transferred to this second chain. And remember: they’re immobilized on the Bitcoin network… so we haven’t created or destroyed any…. Just “moved” them.
  • You can now transact with those coins on that second chain, under whatever rules that chain chooses to implement.
  • Perhaps blocks are created faster on that sidechain. Perhaps transaction scripts are “turing complete”. Perhaps you have to pay fees to incent those securing that sidechain. Who knows. The rules can be whatever those running that sidechain want them to be. The only rule that matters is that the sidechain agrees to follow the convention that if you can prove you put some Bitcoins out of reach on the Bitcoin network, the same number will pop into existence on the sidechain.
  • And now for the second clever part. The logic above is symmetric. So, at any point, whoever is holding these coins on the sidechain can send them back to the Bitcoin network by creating a special transaction on the sidechain that immobilises the bitcoins on the sidechain. They’ll disappear from the sidechain and become available again on the Bitcoin network, under the control of whoever last owned them on the sidechain.

sidehcains_ex

Sidechains use the standard bitcoin “three-step” transaction to immobilise bitcoins whilst they’re “on” the sidechain

So, to repeat, we’ve used standard Bitcoin transaction functionality to move coins out of reach and we then prove to a second, unrelated chain, that we’ve done this.  And when we’re done, whoever owns them on the sidechain can do the same thing and send them back to the bitcoin network.

So developers get the opportunity to experiment with different types of cryptocurrency rules without needing to create their own currency.

And it now becomes possible to do some very interesting things in the Bitcoin space.

Step back from the details for moment and consider what’s been described.  We now have a way to move coins from Bitcoin onto another platform (a sidechain) and move them back again.   That’s pretty much what we do when we move them to a wallet platform or an exchange.  The difference is that the “platform” they’ve been moved to is also a blockchain… so it has the possibility of decentralised security, visibility and to gain from other innovation in this space.

For example, one could imagine a sidechain that is “mined” only by one company. That would be identical to a single-company wallet, but with full visibility of transactions.

Going further, you could imagine a sidechain that is mined by 100 different companies in a loose federation. Not totally decentralized, but harder to censor or subvert than if it were just one.

And there are lots of other possibilities. The key is that you can build these experiments and products and services without also needing to create a new currency or fall back into the old centralised style.

So when I look at sidechains, I’m looking at them as an architecture for building semi-decentralised products and services for Bitcoin that were simply impossible before.

Now there are some serious issues with the scheme. Peter Todd has raised doubts about how secure it might be and it might require a one-off change to Bitcoin.

But it’s early days.  I’m looking forward to watching this space develop

Cryptocurrency products and services will determine adoption of the currency – not the other way round

The critics of Bitcoin-the-currency are right… but only in the sense that the motor-car was a poor imitation of a horse…

I had a light-bulb moment this week. It was triggered by a panel I sat on at Sibos, hosted by the wonderful Adam Shapiro from Promontory Financial Group.

My argument to the audience was the one I usually give: they should simply ignore the currency use-case: it’s the least interesting thing about Bitcoin. They should, instead, look at it as a platform for decentralized value-exchange and focus on the opportunities this enables.

Sibos TV

The panel discussion isn’t online but you can see us debate the issues on Sibos TV.

I then returned to the warm embrace of the Innotribe room and thought little more of it.

I thought little more, that is, until I returned home on Friday and went for a run. I took the opportunity to catch up with a few podcasts, one of which was Dave Birch’s interview with Jeffrey Robinson, author of BitCon. (Aside: everybody I know thinks I’m weird for listening to economics and FinTech podcasts when I run. I can’t be alone… surely?!)

It is fair to say that Jeffrey is not a fan of cryptocurrencies. And he makes some well-aimed shots at the heart of the “Bitcoin is a useful currency” argument in the podcast. For example, he points out that vanishingly few retailers actually accept it, despite the hype (they, instead, receive dollars from BitPay or Coinbase instead).

Now, one could take issue with Robinson’s arguments (he’s very confused on some technical aspects and the Boston Fed does see some evidence that consumers pay marginally less when using Bitcoin rather than payment cards).

But surely this is to miss the point. Whether or not cryptocurrencies are superior than today’s currencies for today’s payment problems isn’t really interesting.

It’s like saying that the automobile is a terrible way of pulling a plough.

Cryptocurrency technology will succeed only to the extent that it enables new products and services that were previously impossible or unimaginable.

And here’s the light-bulb moment: most of the really interesting use-cases turn out to need a payment mechanism – and having a currency and payment mechanism built into the platform turns out to be really, really useful.

Causation runs in the opposite direction to what everybody seems to think: it is new products and services that will drive adoption of the underlying currency. Not the other way around.

Two interesting viewpoints

Perhaps you think I’m setting up a strawman…? Happily, there have been two separate posts this weekend describing what some of these applications might be. So let’s check…

First, Chris Dixon offers some ideas for native Bitcoin apps. If I’m being critical, I thought they were somewhat pedestrian – they all seem to be answers to the question: “if Bitcoin the currency was widely deployed, what could you do with it?” – which I think is the wrong way to look at this. It has causation in the wrong direction.

But Adam Ludwin at Chain.com also blogged on this topic. And his argument is more compelling to me. He acknowledged that we really can’t anticipate where this will go – but he highlights ideas like smart assets and so forth as promising areas of research.

So can we flesh this out some more and identify additional examples?

When the audience takes photos and makes notes, you know they’re excited by the topic…

I hosted five startup CEOs on the Innotribe stage at Sibos on Monday and it’s interesting to me that the demo that created the most excitement was Yoni Assia’s demo of colored coins. He showed the (fake!) example of a large US bank issuing IBM stock on the blockchain so that it could be traded and transferred without the need for the plumbing we take for granted in the securities processing world. I think he used the CoinPrism platform. And it’s worth also checking out ChromaWallet.

coloredcoins

Using the Colored Coins concept to issue, track and transfer securities on a blockchain.

I spoke to various attendees over the following days and this topic clearly excited them. The demo had helped them move from an intellectual, but shallow, understanding of the concept to one that helped them envision a future where custodians, clearing houses, exchanges and brokers work in a completely different way. I’ve written about decentralized securities processing here and seeing it in a live demo made it real for people.

Now the interesting thing is: this use-case has nothing to do with currency. The Bitcoins are just being used as a transport layer. All the intelligence and disruptive power is at higher layers of the stack.

The key insight: what is the best payment mechanism for colored coins?

But now… ask yourself a question: imagine this platform gained adoption. In what currency – and using what mechanism – would participants pay each other?

Sure – you could use whatever you like. But the interesting thing is: if you paid in the native currency of the platform – Bitcoin in this case – some very special possibilities arise. For example, you can use the Bitcoin scripting system to make binding bids and offers without needing a central exchange. And you can achieve atomic swaps of currency for securities – delivery versus payment – without needing a custodian.

So suddenly, a “currency” which may indeed have limited utility for today’s developed markets for today’s problems suddenly becomes utterly superior for this new use-case of decentralized asset exchange.

Now, I should point out that not all of this infrastructure yet exists so I’d advise readers to read an interesting paper by Mark Friedenbach and Jorge Timón on how to modify the underlying Bitcoin system to support it. (My thanks to Ian Grigg for the pointer). In passing, I think these systems also need two other critical pieces of infrastructure:

  • An identity and reputation system: how do I know an issuer of IBM “stock” really is who they say they are? And how do I know they are authorized to make the statement? The complexity here goes beyond narrow concepts of corporate identity
  • What rules are needed to underpin this? Which legal precedents?

But I think it’s examples such as this will lead us to a world of 1) unanticipatable products and services, for which 2) the optimum payment mechanism is the native token of the platform.

To repeat: new apps will drive cryptocurrency usage… not the other way round.

So what are some other potential use-cases?

I’d classify the example above as Smart Property.   I think there are at least two others:

The Economy of Things

I wrote recently about the work we at IBM are doing around the economic model of the Internet of Things. The work is focused on the underlying architecture through which trillions of devices can discover, connect and collaborate. But what would happen if these “things” needed to transact with each other? Wouldn’t the most obvious payment vehicle to use be the native token for the platform? (Usual disclaimer: I raise this as an open question… it’s not a statement of direction or intent by IBM)

Indeed, one potential example of this has already been studied in Switzerland. A recent paper by Dominic Worner and Thomas von Bomhard examines “Exchanging Data for Cash with Bitcoin” – one could easily imagine “things” paying each other for access to trusted data feeds in other scenarios too.

Smart Contracts

Vitalik Buterin’s presentation on Ethereum was a highlight of the first day at Innotribe this week. And I thought his host, Dan Marovitz, showed excellent judgement in allowing him to talk at length and in significant technical depth about his vision. The audience of senior bankers seemed to be completely rapt.

etherscript

Using Ethereum in a world where the there’s been a breakdown in trust between children and the tooth-fairy

At the core of the Ethereum concept is the idea that real-world relationships and contracts can often be reduced to deterministic rules that can be executed by a neutral, unimpeachable platform. And these contracts often (not always) involve the exchange of economic value, usually in the form of the native currency of the platform.

Now… I have some reservations about Ethereum… it is so ambitious and so audacious that I worry that it might prove to be unbuildable – and I note that real-life isn’t always reducible to deterministic rules….   But, as Gavin Andresen has argued, it might be possible to achieve much of what Ethereum aims to do on top of the Bitcoin platform itself. At which point, the world of smart contracts would drive usage of Bitcoin-the-currency.

And I’m sure there are more…

So where next…?

It’s still early days, of course. But the lesson I learned this week was that we need to get away from the sterile “Bitcoin the currency” versus “Bitcoin the platform” debate. Instead, we should consider how one drives the other… and how it’s the platform that is likely to drive the currency, not the other way round.

 

“Device Democracy”: IBM’s IoT Paper – Or “on the blockchain, nobody knows you’re a fridge – made real”

The IBM “Device Democracy” paper is another example of how blockchain technologies could have impacts well beyond currency

I recorded an interview for Finextra last year, where I argued that we should view Bitcoin and cryptocurrencies as far more than just currency and payment systems: they’re enablers for whole new classes of innovation.

One of the example I gave was how they could provide an economic underpinning for the Internet of Things (IoT) and pointed out that if devices in your home each had their own Bitcoin wallet, the Internet of Things could rapidly become the Economy of Things

On the blockchain, nobody knows you’re a fridge (Buy it from teespring.com!)

But talk is cheap. Implementation and delivery is what counts.

So I have been enormously privileged to contribute, in a very small way, to a fascinating project being led by Paul Brody, IBM’s Vice President for our Mobile and Internet of Things consulting team. It has been well-covered by CoinDesk, GigaOm and “Two Bit Idiot” but, as Two Bit Idiot observes, I think its true significance has yet to be understood.

Here’s my simplified take on what this project is all about:

Imagine the predictions of the futurists come true and the Internet of Things becomes a reality: wireless locks controlling our houses, wifi-enabled lightbulbs and internet toasters, all that stuff.

Think about the economics from the manufacturer’s perspective.

My elderly iPhone 4 has finally reached end-of-life: it’s getting slow, iOS 8 will not run on it and I can expect apps to start failing one-by-one as their developers stop updating them for iOS 7. And yet the phone is only four years old. Most other phone manufacturers abandon their customers far more quickly, which means Apple’s four-year support for my phone is industry-leading.

My iPhone 4 served me well – even serving as a prototype for Apple Pay (Not really).  But, after four years, it is obsolete and the latest version of iOS won’t run on it

But, for the internet of things, a four-year old device is barely a child! These devices could last for far longer than anybody expects. How often do you change the locks on your door? When did you last replace your toaster? Some observers claim LED lightbulbs could last for twenty years.

Now imagine what the world would be like if Apple had to support the iPhone 4 for twenty years.  That is a long time to support, maintain and upgrade an internet-connected device.   As Paul and the team write in their very readable whitepaper, we can’t assume that the data produced by these devices will somehow create enough value to fund the ongoing costs.  Consumers seem to be in no mood to give away ever more data in exchange for “free” services… and it’s entirely unclear that this data has as much value as people think, in any case.

Technology Principles for internet-connected devices that could run for decades

So we need to make it as easy as possible for manufacturers and others to support these devices in the field. And part of the answer is surely that we need to make it as easy, cheap and sustainable as possible for manufacturers to do the “right” thing. And the argument that Paul’s paper makes is that the key to doing this is to decentralize as much logic as possible – so that what’s left at the centre is as small as possible.   They capture this intuition in the form of three key “technology principles”:

  • think “peer-to-peer” wherever possible… if two devices can find each other and communicate directly, why route it through a central point?
  • assume you’re operating in a “trustless” world: if you can’t be sure that everything is running perfectly all the time (because it won’t be), then choose a design that needs as little trust as possible
  • decentralize autonomy to the greatest extent possible – if something doesn’t need to be decided at the centre, decide it at the edges. Build on the insight that those with the greatest ongoing incentive to keep these systems running are those closest to them and who depend on them the most.

Device Democracy

This concept inspires the title of the paper: “Device Democracy”. They call the resulting architecture an “Internet of Decentralized, Autonomous Things”. The project’s IBM landing page explains more.

The paper explains the reasoning in more depth but the intriguing result is that the principles above are well-matched to concepts well-understood by the crypto and cryptocurrency worlds. A secure point-to-point messaging system like Telehash is a good candidate for direct device-to-device messaging, for example. Similarly, a trustless decentralized contract platform like Ethereum (a second-generation blockchain technology) could be a way to encode agreements between devices and to enforce rules.

Indeed, the team’s prototype (which has real locks opening and closing – I so wish I had been in the room when they demonstrated it) is based on Ethereum, Telehash and BitTorrent (you need something to distribute billions of firmware updates, after all)

But it’s important to realize that this isn’t a break from the past; it’s incremental. Existing protocols will still be needed and manufacturers will still need a way of communicating with their devices. This is all about making it as easy and secure as possible and to give end-users as much control as possible – hence “Device democracy”.

It’s perhaps likely that we’ll see hybrid models emerge where these peer-to-peer technologies are coupled with centralized services (cloud-based to hit cost objectives).

This is why I say Bitcoin and Cryptocurrencies are about so much more than currency…

For me, this project gives me further reason to believe that the impact of blockchain technologies and cryptocurrencies will be far greater than anybody expects: their applications go beyond the imaginations of any one of us.

We first saw this with Bitcoin. You needed good knowledge of economics, finance, cryptography and computer science to understand the Bitcoin concept in its full breadth. Indeed, I think this is why may academic economists, central bankers and computer scientists were amongst the slowest to grasp its importance: they were, in general, just too specialised and narrow.

So it is with this project: it has taken a team with knowledge of electronics, engineering, manufacturing, decentralized protocols and economics to devise this prototype platform.

The future belongs to the versatilists?

I wonder if this could be further evidence that the future will be owned not by the specialists or the generalists – but by the versatilists?

 

Disclaimer and Notes

1) I know there’s a lot of interest about this project so a quick reminder that this blog contains my views and analyses… not IBM’s.  I am not an official spokesman on IoT or anything else. 

2) I have lost the contact details of the clever person who created the excellent t-shirt design above. Please do get back in touch so I can credit you

 

A simple explanation of how Apple Pay works (probably): It’s all about tokenization

Forget contactless point-of-payment… that’s a solved problem. Apple’s use of tokenization is the interesting part

[USUAL DISCLAIMER: I have no inside info, these are personal views]

I’ve been using a beta version of ApplePay on my iPhone 4 for some time now…

ApplePayBeta

My very old, but very effective, Barclaycard contactless PayTag, stuck to my iPhone 4

The interesting question is how Apple chose to embed the card details inside the phone

To understand why, we have to rewind to March, when something curious happened: a body called “EMVCo” released a technical specification document for something called “tokenization”.

It was curious because it seemed to solve a problem that was already being solved by other players in the card industry. Make no mistake, however: the problem is a big one. Here’s what I mean.

I’ve written extensively about how Payment Cards implement the “pull model”.  When you want to pay for something, you hand over your card details to the merchant and then hope that those details don’t get into the wrong hands as they pass from merchant to their acquirer to the switch and finally to the bank that issued the card in the first place.

PushPull

In particular, the big problem is what happens when companies with millions of cards on file get hacked. Think of major online retailers who save your card details for you. It’s very convenient for you but it only works because they’ve stored your card details on their servers. If they get hacked, then millions of people are at risk of theft and card issuers will have to reissue millions of new cards. It’s a huge pain.

PushPull2

When you allow a merchant to keep your card details on file, you have to trust all the actors in the blue oval not to mess up…

However, there’s a really cool thing you can do to make this system much safer. It’s called tokenization. Here’s the idea:

  • When you enter your card details on a merchant’s website for the first time and tick the “save my details for next time” button, the merchant doesn’t store your card details right way.
  • Instead, they send the details to their merchant acquirer – e.g. Elavon – and ask them to issue a token.
  • The acquirer creates a random number that might look like a credit card number in some cases – the token – and returns it to the merchant.
  • The acquirer records all this information in its own database (i.e. the real card details, the token they issued and which merchant they issued the token to, etc).
  • The merchant stores only the token in their database, not the real card number.

Now, next time you try to buy something from that merchant, they send the token they’ve stored to the acquirer. The acquirer checks that the token is valid and that it came from the right merchant. And, if so, they convert it back to the real card number and process the transaction as normal.

The really important point here is that we no longer really care as much about the merchant’s security. If they get hacked, it’s not as much of a problem: the tokens are useless to anybody else. The acquirer will only accept them if they’re presented by the original merchant. If the hacker tries to use them somewhere else, they simply won’t work.

Excellent! A really simple system that dramatically reduces the risk of fraud and lowers risk and cost for merchants. You can think of it as if the “circle of trust” has been shrunk:

PushPull3

If merchants use tokenization services, the implications if they get hacked are far less serious. (TSP stands for “Token Service Provider”)

And this is nothing new. Acquirers have offered this service for ages for merchants who wanted to use it.

Great. Problem solved?

Not so quick….

Now think about Apple Pay and think about the challenges Apple faced in getting this to work.

Here’s how contactless payments are supposed to work when you pay for goods in store: the cashier rings up the price and activates the contactless pad so you can pay. You tap your contactless card and you’re done. This piece is completely normal: anybody with a contactless (“PayWave” or “PayPass”) card can do that today. It’s what I’ve done with the PayTag on my iPhone 4 for ages.

But how do you get a phone to pretend to be a contactless card? Well that’s a solved problem too. Android devices have done it in various ways for years, for example.

So what’s the problem? The answer is: security. Sure… you can put somebody’s card details into the “Secure Element” of a phone (or do something clever with Host Card Emulation) but if you’re putting the real card number in there then you face all the same risks a merchant faces… if somebody were to figure out how to hack into your system, you’ve got a big problem on your hands… And in Apple’s case, imagine if almost 1 billion payment cards were compromised!

So it would be much safer if you stored a token on the phone, rather than the card details themselves. That way, if the system is broken, you can just invalidate all the Apple tokens and you’re done.

But there’s a really subtle problem

How does a firm like Apple get the tokens? Remember: they want to emulate a contactless card so that the customer can use the phone to pay at a merchant. You don’t know which merchant acquirer any given merchant uses so an acquirer-specific token is useless!

So Apple can’t use the merchant acquirer services to get its tokens… imagine it put a First Data token on its phones. What happens if you try to pay for something at a merchant who uses Elavon? It isn’t going to work…

And this is where the EMVCo spec comes in. In short, the EMVCo spec proposes is that tokenization be standardized and it implies strongly that it should be the schemes (or maybe issuers) who perform the work, not the acquirers.

Effectively, they’re proposing the circle of trust be tightened even further:

PushPull4

I scratched my head at first… apart from perhaps being a power grab, why would anybody bother change this simple model?

The answer was on page 26, section 3.8 and the introduction of the idea of a “token requestor”. What the EMVCo spec highlighted – and what I missed at the time – was that it isn’t only merchants who might want to create tokens… other players might need to as well… players like telcos and Apple:

“Payment Token Requestors may be traditional participants within the payments industry or newly emerging participants. Potential Token Requestors include, but are not limited to Card-on-file Merchants, Acquirers, Acquirer Processors, and payment gateways on behalf of Merchants, Payment enablers, such as original equipment manufacturer (OEM) device manufacturers, Digital wallet providers, Card Issuers”

(EMVCo Tokenisation Spec, page 26-27, my emphasis)

Of course!

Imagine you were trying to build something like Apple Pay. This is exactly what you would need. You’re faced with consumers with cards from thousands of issuers and you want to create tokens that can be processed by merchants who use one of tens of acquirers.

You need a system that gives you a token that all acquirers can process and which the schemes can route to the right issuers… it makes sense that it be the schemes who provide such a services. Indeed, Visa Inc have written about their service here.

And so I think that’s what’s going on. Apple is acting as a “Token Requestor” in the EMVCo model. When you enter your card details or take a picture of your card with your iPhone 6, Apple will call the Token Service for the appropriate network – let’s assume Visa. Visa will check the details (maybe your postal code, CVV2, etc) and perhaps authorize with the issuer.

And Visa will then issue Apple with a token. This token will only work for contactless payments and it will be associated with Apple so it can be revoked in the event of a problem. But it will look just like an ordinary card number so acquirers will be able to process it without even realizing it’s a token.

And it’s this token that will be stored on the phone’s secure element and passed to merchants every time you use it.   So, in many ways, Apple Pay could turn out to be astonishingly standard-compliant.

In summary, my take on the interesting aspects of the Apple Pay announcement are:

  • It’s looks like a really nice use of the EMVCo “Token Requestor” concept
  • It relies on schemes having Token Service Providers up and running so don’t expect it to roll out everywhere, for all schemes, any time soon.
  • It’s surprisingly vanilla.
  • It’s conceivable that Apple is taking zero cut from any of this. They’re certainly not in the transaction flow in any meaningful way
  • But notice how much leverage it gives them over issuers. It would be easy to refuse to include an issuer’s cards on the platform unless the issuer pays up. That has the interesting property that deals could be done on a case-by-case basis and different issuers may have different deals.

 

This is, of course, just my analysis from public information. I have no inside knowledge and I could be completely wrong. In particular, I’m struggling to reconcile my analysis with some claims that Apple Pay will use a different token for every purchase. I don’t understand how that would work, unless we assume the phone is online at point of purchase? Anybody know for sure? Am I way off the mark?

What happens if Bitcoin mining companies vertically integrate?

Creeping centralization can come in many forms – are the Web Application Server wars a lesson from the past?!

First some history of the IT industry (you can skip this bit if you just want the meat…)

Travel back in time with me to the late nineties…. I started my career during the Web Application Server wars. The web was taking off in the late nineties and companies like WebLogic (quickly acquired by BEA) spotted a need in the marked for a Web Application Server.

They were solving an obvious problem: it was a real pain to write proper applications. Sure: you could write HTML and run it on Apache. And you could use the CGI interface to have scripts run to generate basic dynamic content. But it was painful to do anything more sophisticated

If you were a bank that wanted to build an online banking service that interfaced with your core banking system, it needed a huge amount of effort and care… and you were wholly responsible for figuring out how to manage session state, failover, transactionality and everything else. And what we quickly found was that everybody needed a similar set of code “middleware” services – and were building for themselves each time.

And one solution to this problem was the web application server. This was a server, usually written in Java, that provided a defined set of APIs and an execution environment for web applications.    You could think of it as having two faces: one face spoke “web” – it sent and received HTTP. The other face spoke “enterprise” – it provided a set of APIs, SLAs and common behaviours that app developers could rely on to build their applications.

Products like BEA WebLogic, as it became, Netscape Enterprise Server, IBM WebSphere Application Server and Microsoft’s Internet Information Services platform were all designed to solve this problem… and it became a billion-dollar industry.

Sure – somebody still had to buy, configure, install and manage these platforms (usually in corporate datacenters, running on expensive hardware) but at least there was now a clear separation: and a division of labour emerged: J2EE developers, App Server administrators, infrastructure engineers and so on.

Today is different but not that different!

Fast-forward to today and the world is different: we take a rich execution environment for granted and the state-of-the-art consists of cloud offerings that protect the developer from worrying about anything apart from their code: infrastructure, connectivity, bandwidth, middleware configuration is all delegated to the platform. (IBM’s BlueMix is a recent example of such a service)

But the insight is the same: in any field, we see lower levels of the stack become standardized and commoditized. A small number of specialized players, with economies of scale and benefitting from experience-curve effects, begin to dominate.

So I’ve often wondered if we’ll see something similar in the Bitcoin space.   Are there any parallels we can draw and, if so, what can we learn from them?

Can we see any parallels with Bitcoin infrastructure?

Look back a few years and anybody wanting to build a product or service on Bitcoin had to do it all for themselves.

For example, it seems that Mt.Gox wrote their own custom implementation of the Bitcoin protocol – which is not, perhaps, surprising given the nature of its business and the maturity of the ecosystem when it was founded. I guess that’s similar to people who wrote their own HTTP servers or implemented custom schemes for producing dynamic content back in the nineties.

More recently, APIs like BitcoinJ and platforms like BitsOfProof have emerged as credible abstraction layers upon which interesting products and services can be built. In both cases, developers typically run and maintain their own instance(s) of  Bitcoinj or BitsOfProof, etc. So one could argue this is a parallel to the on-premise app-server days of the web.  

So it’s tempting to ask… are the parallels with the web appropriate? If so, what happens if cloud-based services for Bitcoin developers emerge?

And, of course, we don’t need to imagine. These services already exist. chain.com is one such example.

Chain.com is a cloud-based Bitcoin API for developers. From their website, it appears that they maintain a set of Bitcoin nodes and ensure they are well-run and well-connected, perhaps in the way that Amazon or IBM might maintain app servers, infrastructure, routers and connectivity to major peering points on the internet.

And developers simply write their Bitcoin product or service in a language of their choice, calling the Chain APIs as and when they need to interface with the Bitcoin network.  One can imagine that coding against Chain.com makes it an order of magnitude more easy to get a new Bitcoin company up and running. You don’t need to worry about any of the infrastructure detail: Bitcoin is abstracted away to a set of easy-to-use, well-documented, high-level APIs.  

You might hardly even know you were even using Bitcoin!

And that’s a really important subtlety: if you are not running your own Bitcoin nodes, how do you know the information your service provider is giving you is accurate? How do you know you’re connected to the “real” network and seeing the real blockchain and that your transactions are making it across the network?

Now I’m sure the chain.com team are hugely competent and ethical people. This post is emphatically not a criticism of them or their service. But one does need to be open-eyed about the tradeoffs one is making as an engineer.  And one approach app developers could take might simply be to maintain their own independent copy of Bitcoin core to act as a monitor/sentinel.  It’s probably not a show-stopper.

And I can see this sort of service being immensely popular: it is a lot of effort to install and maintain Bitcoin network infrastructure… keeping it patched, making sure you really are well-connected to the Bitcoin network and so on… and if your business has latency dependencies (mining? Exchanges?) then you also need to worry about making sure your nodes are “close” to other major nodes. And so on and so forth.

Figuring out how to do this sort of stuff well has good scale effects and there will be big learning/experience curves. Just as cloud vendors can run web infrastructure better and cheaper than most companies could do themselves, we should probably expect to see small startups outsourcing their Bitcoin network integration to firms like chain.com – and maybe even hosting providers who include Bitcoin APIs and network abstraction as a core part of their service offering.

So, leaving aside the concerns this might raise around decentralization and ask yourself:

if a cloud-based Bitcoin API/application platform were to become really popular, who is best placed to deliver it?

Until a few weeks ago, I would have said I expected more firms like chain.com to be founded over the coming months and for a handful of them to gain critical mass and become the dominant application platform players of the future.

And then CoinTerra bought BitsOfProof

It was one of those lightbulb moments for me when I heard about it. Of course! How Obvious!

It makes perfect sense. Think about the capabilities and advantages that big mining firms have that they could use to build a powerful hosting proposition for developers:

  • Hosting in low-cost locations
    • They already maintain massive farms of servers, usually in locations with cheap power. They could easily offer colocation to their clients
  • Massive hashing power
    • They could commit SLAs to application clients that nobody else could make – “At this SLA, we will guarantee your transactions make it into a block within x hours”, perhaps?
  • Optimised network connectivity
    • The mining firms must surely have deep knowledge of the Bitcoin network topology so I suspect they could make promises about transaction propagation times and other time-critical requirements that would measure to some clients – “You will see transactions from other people faster on our platform than if you ran your own node”, perhaps?
  • 100% Virgin coins on tap
    • Mining companies can offer businesses who use their APIs access to freshly-minted coins… no taint, no need to ask where they came from
    • … and I’m sure there are more

Many observers, myself included, have tended to ignore mining, regarding it as an infrastructure function, with the main debate being around the threat of concentration of hashing power. What I missed until now is that a well-run mining platform is also a phenomenally powerful platform from which to build up the stack to middleware/APIs and beyond.

So the question for me is: what happens if (when?) one of the mining firms offers a hosted application environment for Bitcoin companies with a really easy-to-use abstraction API over the Bitcoin network?   Commentators such as Tim Swanson have written extensively about the incentive structure of Bitcoin mining but I’ve not yet seen an analysis that thinks through the implications of vertical integration of the sort I outline here – and what it would mean for any security analysis of the system as a whole.  

If anybody’s aware of one, I’d love to read a copy.

Disclaimer: I’ve not spoken to any of the firms named in this post and I have no insight into their product plans

A simple explanation of fees in the payment card industry

I wrote a piece last month explaining how the payment card industry works.  I talked about the various actors (acquirers, issuers, schemes, merchants, etc) and pointed out how weird it is that everybody knows the Mastercard and Visa brand names yet nobody actually has a relationship with them. One of the questions I didn’t address there was fees.  Who makes all the money? Why does it seem so expensive?

Let’s start with the standard four-party model: Merchants, Acquirers, Issuers and Schemes:

Four Party Model Fees 1

The four-party model: Merchants obtain card processing services from Acquirers, who route transactions via Schemes to Issuers, who debit Consumers’ accounts.

A Worked Example

The key point is that one firm from each category is going to be involved in every payment card transaction.  So it’s interesting to ask: how much do they get paid?

Let’s take a concrete example and work it through.  Bear in mind: this is just an example. As you’ll see, there are almost infinite variations and some merchants will pay fees considerably higher than the ones I discuss below.  Also, note: this information all comes from public sources.  I use company names below for clarity but I have no private insight or information into their fee structures

The Scenario

Let’s imagine I’m using a Visa Debit card, issued by a US bank (let’s say Bank of America) to buy $100 of goods from an online retailer.   What happens?  From my perspective, of course, it’s obvious: I’m paying $100!

Four Party Model Fees 2

Imagine I am using my Visa Debit Card, issued by Bank of America to pay for $100 goods from an online retailer.

The Merchant’s Perspective: The Merchant Discount Fee

What does the merchant see?  Well, the merchant will have a contract with an acquirer.  What does that look like?  Let’s take an example.  Costco have a page on their website that refers small merchants to Elavon for acquiring services.  Let’s use the pricing displayed on that page for Online transactions:

1.99% plus 25c per transaction (plus some other recurring/monthly fees, etc)

Many readers will be thinking that seems low but let’s go with it for now.

So, for our $100 transaction, we can calculate how much money the merchant will actually receive from Elavon/Costco:

  • Transaction value: $100
  • Elavon/Costco takes 1.99% + 25c = $2.24. This is often called the “merchant discount fee
  • So merchant gets $97.76

So our picture now looks like the one below:

Four Party Model Fees 3

Merchant receives $97.76 from the $100 transaction. Elavon gets $2.24.  But how is the $2.24 distributed between the acquirer, issuer and scheme?

The Issuer’s Perspective: The Interchange Fee

So we know how much money the merchant has paid to the “credit card industry”. But how is that money allocated between all the participants?   Visa Inc has a very helpful document on their website, which tells us part of the story: Visa U.S.A. Interchange Reimbursement Fees.

The key word here is “Interchange”.  Interchange is the fee that gets paid to whoever issued the card – and it’s set by the scheme (Visa in this case).   You’ll see in that document that this is not straightforward… there are pages and pages of rates:  the interchange fees vary based on whether the card was present or not – and on the type of good or service being bought, whether it was a debit or credit card, whether it was a corporate card, whether it was an international transaction and lots of other criteria…

So let’s just pick a simple example.  We’ll go with page 2 – “CPS/e-Commerce Basic, Debit” (Card not present).

Aside: CPS means that the merchant has complied with various Visa rules (such as validating customer address to reduce fraud risk, etc) and has thus qualified for a low cost option.  

So the issuer is entitled to 1.65% + 15c

  • Transaction value: $100
  • Issuer receives 1.65% + 15c = $1.80.  This is the interchange fee
  • So issuer owes $98.20 to the other participants (Visa, Elavon and the Merchant)

And we already know that the merchant only gets $97.76 of that money (their merchant discount fee was $2.24, remember?).  So that means there is 44c left to share between Visa and Elavon.

The diagram below shows the current state of the calculation:

Four Party Model Fees 4

Interchange Fee (what the issuer gets) is $1.80

So how is the remaining 44c allocated?

We’ve assumed the switch is Visa so we need to know much they charge.  CardFellow.com has a good explanation.

We’ve assumed a Visa Debit card so, according to that site, Visa’s fee, which we call the “Assessment” is 0.11%.   There is a menu of other charges that might apply but we’ve assumed this is a low-risk “CPS” transaction so we’ll assume none of them apply.  (In reality, the 1.55c “Acquirer Processing Fee” probably applies)

  • Transaction value: $100
  • Visa assessment is 0.11% so Visa charges 11c. 
  • So there is $98.09 to pass on to the acquirer.

And if there is $98.09 to pass on to the acquirer and we know that the merchant receives $97.76, that must mean there is 33c left for Elavon.

So there we have it… in this VERY SIMPLE, highly contrived – and probably unrepresentative – example, we end up with the result in the diagram below:

  • Consumer pays $100
  • Issuer receives $1.80
  • Visa receives $0.11
  • Acquirer receives $0.33
  • Merchant receives $97.76 – overall fee $2.24

Four Party Model Fees 6

Final picture showing how the merchant’s $2.24 fee is allocated

As I’ve stressed above, this is just a simple example but it shows two key points:

1) It is the issuer who receives the bulk of the fees (this is, in part, how they fund their loyalty schemes, etc)

2) The schemes actually earn the least, per transaction, of any of the participants.  This underlines, again, how powerful their business model is:  by being at the centre of a very sticky network, they can earn a lot of money overall by charging very low per-transaction fees.   [Edit 2013-08-10 10:35 : it's also worth noting that the acquirers and schemes have pretty much fixed-cost infrastructures - unlike issuers, who need to hire customer service and debt collection staff in proportion to number of cards issued. So the schemes and acquirers also benefit disproportionately from rising volumes.  So: low fees for schemes/acquirers for sure... but HUGE volume is what enables them to make big profits]

[Note: I use blog posts like this to help clarify my own thinking and understanding - as well as to share knowledge...  and there are one or two pieces here where I'm not 100% confident I got it totally correct... so please do tell me where I'm wrong if you spot something]

[Update 2014-08-09 18:47 Minor typos and replaced last diagram]

Think Payment Cards are Insecure? Just Wait Until Push-Payments Hit Primetime…

What Brazil’s Boleto Fraud Tells Us About Bitcoin and other Push Solutions

When I explain to people how payment cards work, they are usually aghast. I point out that when you hand your card to a merchant and sign your name or enter your PIN, you’re authorising them to suck funds out of your account and the only thing that stops somebody draining all your money is trust. The picture below shows the standard “four-party” model for payment cards and I stress that the consumer is merely authorising payment; it’s the merchant and all the other actors who actually move the money.

PushSecurity1 

The Payment Card “Four-Party” Model: Consumers authorise merchants to pull money out of their account.

(Aside: I’ve never understood why this is called the four-party model. I count at least five parties on that picture…)

Online, the problem is more stark: you type your card details, including your CVV2 “secret number on the back” into your browser and hope for the best: you have to trust the merchant, their IT supplier, the acquiring bank, their third-party processor, the card network and your own card issuer – and everybody who works for them and has access to their systems. If a bad guy gets hold of your card details at any point in this process, they could drain your account. The picture below shows the scope of all the entities with access to your critical card information:

PushSecurity2

Your Primary Account Number – PAN – passes through the hands of pretty much everybody involved in processing the transaction.

It seems mad: why would you spray such sensitive information all over the place willy-nilly? Whoever thought it was a good idea to build the system this way?!  Except… the system works.

Fraud is surprisingly low given the design – and consumers get compensated if something goes wrong. And the design isn’t actually as mad as it seems: how else would you build a consumer payment network in a world where you can’t assume the consumer has a smart device with guaranteed network connectivity?

Payment card networks also have the advantage of decades of experience and refinement. For example, the Payment Card Industry Data Security Standards (PCI-DSS) lay down rules and guidance on how to protect the sensitive card data. The EMV smartcard standards make it harder to clone cards. Issuers have sophisticated heuristics to block suspicious transactions. And forthcoming moves to standardise “tokenisation” (something I should blog about one day) will further mitigate the risk of card details getting into the wrong hands. So an underlying architecture that appears wholly unsuited to the web age has actually been patched up to be good enough (but not perfect – and it still has lots of problems)

The Push Pay Revolution – a better way to do retail payments?

As I’ve written often, there is an entirely different way to design a retail payment system, one where the consumer doesn’t have to trust nearly as many people. I call these sort of payments push payments.  Bitcoin follows this model, as does M-Pesa, iDEAL, ZAPP and the Boleto system in Brazil. The defining characteristic of push-payments is that the consumer is in the driving seat.

With Push, it is the consumer who instructs a payment – from their bank or telco or Bitcoin wallet

This is unlike pull-payments, where the consumer merely authorises the merchant to pull the funds from their account.   The difference may seem subtle but it turns out to be hugely important. The picture to have in mind for push-payments is this one:

PushSecurity4

Push payments have a very different threat model to pull payments. Now the consumer only has to trust their payment provider and their own device.

In previous articles, I talked about the benefits of push payments in terms of innovation and the reduced need to trust quite so many people.   In this post, I look at one of the downsides: push payments can be compromised in hard-to-detect ways if they are not implemented really carefully.

So what’s the problem with push payments?

First, let’s remind ourselves about what we do have to trust and what we don’t have to trust in the pull world.

In the pull world, the consumer has to trust everybody else – and, as I’ve discussed above, there are various safeguards in place to fix things when they inevitably go wrong. One might argue that the safeguards don’t always work and that they come at a cost. Both arguments are, of course, valid but let’s leave them to one side for now.

In the push world, it’s different. The way it’s supposed to work is like this:

  • Step 1: The merchant “tells” the consumer how much they’d like to be paid and to where the payment should be sent. Examples:
    • With M-Pesa, this is usually done in-person, verbally
    • With Bitcoin, it is either done ad-hoc or via a QR-code displayed by the merchant or via the emerging BIP70

To illustrate the point, here is a picture of me in Shoreditch trying to tell a Bitcoin ATM where to send some Bitcoins I’d bought. On my laptop screen is a QR code that represents my Bitcoin wallet address. Note how it’s me as the Bitcoin receiver who is telling the sender (the ATM) where to send the coins.     In the more common case, where I am paying Bitcoins, this means it is the merchant who has to show the QR code to me. I need to know where to send the money to.

PushSecurity5

This is me using a QR code on my laptop to tell a Bitcoin ATM where to send my Bitcoins. (The Apple Bitcoin ban was still in force when we took this photo… so I had to use my laptop rather than my iPhone…)

  • Step 2: Once the consumer has the payment request, they use a program or app on their smart device (laptop, smartphone, whatever) to instruct the payment. Examples:
    • An M-Pesa user launches the M-Pesa SIM app and instructs the payment
    • A Bitcoin user pastes the destination address and value into their Bitcoin wallet
    • … or uses their wallet to read the recipient’s QR code
    • … or opens the BIP70 Payment Request with their wallet)

When you put it like this, push payments are obviously superior, right? The consumer is in control, they don’t have to trust all those people and there’s no danger of a rogue agent sucking all their money out of their account!

Not so fast…

The analysis above neglects one small, but rather important, fact: devices get hacked.

In the pull model, the only devices that can get hacked are those inside the “circle of trust” – your plastic card is pretty impregnable.  And as the utterly disastrous Target breach suggests, consumers were made whole when the disaster happened. It was the big firms who messed up who suffered the consequences.  

Yes… I know this is counterintuitive… you must be asking yourselves: “is this guy seriously arguing that the Target disaster is an argument in favour of the current payment card model?!” Obviously, no…. the episode was clearly a catastrophe and it was really, really bad.   But… it did eventually get sorted out and the roll-out of EMV, tokenisation and better enforcement of PCI-DSS should reduce the risks of something similar in the future.   So I raise this merely as prelude to the push scenario.

Now ask yourself what happens if a device gets hacked in the push scenario.  The obvious question is: which device?   Well… the only device in the circle-of-trust this time is the consumer’s smartphone. Uh-oh.

This is the device from which we’re instructing real-time payments, right? The one that could be riddled with malware?

This might have been merely a theoretical risk…. And then the Brazilian Boleto fraud happened.

RSA have a great write-up of a country-scale real-life example of what can go wrong when push-payment systems get breached… and it’s really scary.

The Brazilian Boleto system is very cool.   At core, it is a way for fund requestors (utility firms, etc) to send a payment request to consumers. The request is known as a Boleto and they can be physical or electronic.

PushSecurity7

A Brazilian Boleto. Think of it as a mainstream equivalent of a Bitcoin BIP70 Payment Request…

The idea is this: the Boleto has details of the payment request and includes details of how much to pay and to where.   This is in coded text format and a bar code… basically, something that a consumer can take and feed into their banking app: scan the code with your mobile banking app, approve and you’re done. Or you could take it to a bank branch. And if you’re online, you could copy and paste the code into your online banking website and achieve the same end.

Except… the RSA paper shows all the ways it can and has gone wrong.

First, there’s a simple problem of authentication. How do you know the Boleto really did come from who it says it’s from?   The RSA paper documents examples of people receiving Boletos via email that look convincingly genuine but which have the fraudster’s payment account details in place of the firm from which they purport to come.

This is a real problem but it’s nothing new… it’s not really any different to fake websites that masquerade as real ones. We solved it in the pull world with SSL certificates and the like for websites. And the Bitcoin Payment Protocol includes the option to use the same PKI system, for precisely these reasons.

However, the RSA paper also discusses another attack – and this one’s scarier.

This second attack comes in the form of malware that runs in the consumer’s browser.   When it sees a document that looks like a Boleto, it silently changes the details that the consumer sees on their screen: the payment details are changed from the genuine recipient to the attacker. So when the consumer copies and pastes the details into their banking app, it’s the attacker’s account they’re sending the money to.

Variations on this theme are included in the paper but they all amount to the same thing: if the consumer’s device is compromised then it’s game over. And you don’t even need to compromise the whole device or get root-access… you just need to compromise the browser in this scenario.

There are various mitigation mechanisms one can implement (e.g. tying the payment instruction to a signed representation of the payment request and so forth) but the underlying problem remains: if you’re using the consumer device to instruct payments, you have an issue if that device is compromised.

Now, this risk is perhaps over-blown: the risks identified here apply equally to standalone mobile banking apps and we happily run these on mobile devices today, albeit with the belief that their bank will bail them out if something goes wrong. (It’s no surprise that banks are big users of technology like IBM Trusteer).

Similarly, Bitcoin users run their wallets on their devices, in the full knowledge that there is nobody who will bail them out if malware runs amok on the device.  

But I think the two-step dance of an end-to-end push payment request/instruction – where the device is responsible for turning the request into the instruction – is something new that needs deeper study.  So I think the Boleto story tells us is that we need to think very hard about things like:

  • User experience: how is the linkage between Step 1 (receive and authenticate request) and Step 2 (populate and instruct payment) executed and communicated to the user? If step 1 is done by a different app to step 2, what is the hand-off? What security assumptions are being msde?
  • Validation and Reconciliation: what work should (can?) the “network” do to validate that a payment instruction purporting to be in response to a payment request, really is traceable to that request?
  • Malware detection systems: what new behaviours should anti-virus and other technologies be looking out for?
  • Wallet providers: which scenarios are you willing and able to protect your consumers against?

It is possible that this is just a variation on the age-old theme that end-point security is hard – but when things like the Boleto fraud happen, we should use it as an opportunity to look at the other systems being built along similar lines and ask: are there any lessons we can learn and apply?