Push or Pull?

At the heart of the Bitcoin system is the idea of a transaction: at its simplest, this is a transfer of value from one Bitcoin user to another—in essence a credit transfer.

Consider what this isn’t. This isn’t a direct debit. It isn’t a credit card authorization. Nor is it the creation of a debt or a precursor to a subsequent billing cycle.  This is, rather, the closest analog we have in the digital world to a person-to-person cash payment. Graphically, we could depict this as the consumer pushing value directly to the merchant, just like with cash:

Now, consider how that differs to most other forms of electronic payments in the retail space.  They are, almost invariably, achieved through the use of one or more card schemes.

The customer thinks they’re paying.  But, really, they’re not. Instead, when they sign or enter their PIN, they are initiating a supremely sophisticated choreography of immense complexity. They are, in reality, authorising the merchant to pull the payment from their account, with the request being routed through several intermediaries. Graphically, it looks something like this:

Problems with Pull

This model has its advantages but it also suffers from severe problems: Conceptually, it’s really not that different than giving three parties the password to your online banking service and trusting them to log in and take what they need. 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:

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

Therefore,  if you’re moving payment authorizations around, you need to be maniacally focussed on security. Firms have found it necessary to devise elaborate safeguards:

• The signature (or EMV PIN) gives the customer a way to prove or repudiate their intent after the fact.
• The PCI-DSS standards set rules for how sensitive customer data is protected.
• Retailers are subject to scheme rules to ensure consistency and fairness.
• New technologies such as “tokenization” replace the PAN with a restricted-use “token” for certain transaction types

But this system is not foolproof.  And nor can it ever be given an architecture that does not require so many independent parties to be scrupulously honest and rigorous in their handling of sensitive data. Even with EMV standards for chip-and-pin payment cards, the consumer must still trust theintegrity of the reading device.

It’s easy to understand why the system was built this way:  what else would you have done with 1960s technology?  The pull model employed by the card processors is a wonder of the world.  But it’s also an artefact of its time.

A Bitcoin transaction, by contrast, is a push payment. It is the consumer who instructs a payment from their wallet.  The picture of trust to have in mind for push-payments is this one:

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.

By substantially reducing the number of parties that the consumer must trust, Bitcoin can mitigate the danger of identity theft and fraudulent charges.  Despite being a substantial improvement in data security, push payments are not without their own vulnerabilities.

Problems with Push

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

Circumstances change if a device gets hacked in the push scenario. The only device in the circle-of-trust this time is the consumer’s smartphone. These devices are, quite frequently, riddled with malware, but how exactly would this endanger a consumer paying with Bitcoin?

Bitcoins can only be stolen in so much as either (A) the user’s private keys can be obtained or (B) the user can be deceived into sending their bitcoins to a malefactor rather than the legitimate payment requestor.

Multi-signature wallets, for example BitGo, could mitigate the first risk. These systems divide the authority to transfer Bitcoins amongst multiple keys for any given wallet. One key may reside on the user’s phone, another offline in a safe deposit box, and a third held by the wallet provider or a service monitoring the account for suspicious activity. Transactions from a multi-signature wallet require assent from a majority of the keys to go forward. The key on the user’s phone could be vulnerable if the device is compromised, but without access to one of the other keys the thief is out of luck.

The second risk is akin to an email phishing scam. The consumer is presented by a hacker with an interface that looks like a legitimate request for her credentials or payment. When the consumer pays or gives her sensitive information, she unknowingly rewards the hacker. This risk can be mitigated by the creation of more reliable and verifiable payment requests, as found in a recent proposal to improve the Bitcoin protocol, BIP70. Alternatively, consumers can be educated to ignore malicious requests by being alert for tell-tale imperfections in a fraudulent interface. A variation on this attack arises if scammers are able to hack the victim’s phone to replace a genuine payment address with a fake one. Well-designed multi-signature systems could be an effective antidote here as well. The scammer would have to hack the devices of all signers for this attack to work in a multi-sig world

Irrespective of these vulnerabilities and their fixes, Bitcoin provides a model of improved data security within the payments ecosystem. It simplifies the risk calculus by dramatically culling the number of involved parties that you have to trust. Any system that doesn’t need PCI-DSS and reduces the complexity for everybody else has much to commend it.

Richard Gendal Brown is Executive Architect, Industry Innovation, Banking and Financial Markets for IBM UK. The views shared here don’t necessarily represent IBM’s positions, strategies or opinions.