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.
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:
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:
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.
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.
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?
Richard Gendal Brown 
Regarding bitcoin, a multisig wallet is well capable of implementing those “sophisticated heuristics to block suspicious transactions”. With multisig, 2FA, and some creativity, in the future we will pretty much guarantee every payment authorization really has the true intent of the user. The right balance between hassle and security will be a choice of the user – she could set up the rules behind her multisig wallet. Bitcoin push-payments can be far superior to anything we have nowadays.
Hi Alex – agree re multisig… but you still have to implement it carefully. A multisig wallet isn’t going to help you if malware in your browser/device silently replaces the output address of your multisig transaction with the address of the attacker before the multi-signature process begins. BIP70, implemented correctly, should help protect against this but note that it just introduces a new threat, albeit more difficult to perform. This second attack works as follows: the merchant colludes with the malware author such that the payment request is for an insanely high value. However, the malware ensures that, whenever the wallet attempts to show the payment details to the user, the value is reduced to the lower, correct value – so the consumer perceives no problem. So now we have a situation where the payment protocol isn’t attacked at all – the payment request is the payment that is instructed… its just that collusion between the merchant (payment requestor) and malware author hides the fact that the payment is for more than the consumer expects. Now this is far harder to perform, of course… and hardware wallets would be immune I assume?
This is the kind of problem a multisig wallet will be able to address very well. The more suspicious a payment is – e.g. amount too large – the harder it would be to release the funds – e.g. requiring 3FA, or a signature from a key stored in another device.
The beautiful thing about Bitcoin is that it’s an OPEN payment platform, so there will be many wallet providers competing for users, figuring out new cool and effective ways to ensure the user is not being stolen by malware or other threats. We’ll be able to even combine wallet services of our choice, each one of them providing a unique signature to the same payment.
Alex – completely agree. Lots of opportunities to innovate and differentiate here!
Outside of the Bitcoin world, this problem is already with us in the form of Sofort, Trustly and so on, and will get a whole lot worse when PSD2 mandates all online banking providers to support payment initiation by Third Party Providers (TPPs). There are ways that push systems can be made more secure, for example by passing the payment request via a central scheme so that only bona fide merchants can create requests, and by passing only a request identifier from merchant to smartphone to paying institution. It’s then up to the PI to retrieve the request from the central scheme and display it to the consumer. That seals up most of the loopholes mentioned, but it does require a central scheme (along the lines of Visa or Faster Payments) so is contrary to Bitcoin’s open philosophy. And it scores low on the coolness scale …
Thanks for the comment, Tom 🙂 Does the approach you describe (passing the request via a central scheme) protect against collusion between a rogue merchant and a malware author? Would it not still be possible to create an absurdly high payment request that the malware displays to the user as a smaller value? I guess the size might trigger alarms – but a more subtle attack (e.g. where each payment request is inflated only by a few percent) may go unnoticed for some time, perhaps? My sense is that this threat is more theoretical than anything else…. it requires a lot of moving parts and, once discovered, the merchant’s guilt would be easy to prove – but perhaps there are more sinister variants?
By itself, passing via a central scheme doesn’t fix everything, but in the Zapp model for example the payment is presented to and authorised by the customer via their bank-supplied mobile banking app. So as you say, collusion between merchant and malware author becomes very difficult – the merchant has no idea whether the consumer’s phone is compromised, so would be taking a risk every time they submitted a payment request for a different amount from the “sticker” price. The malware author would have to know what the “sticker” price was to display to the consumer instead of the actual amount submitted by the merchant. If the merchant requested £1,000 there would be no way for the malware to determine the “sticker” price, but if both merchant and malware author use a simple algorithm of inflating by 1p or 1%, it might go unnoticed for a while. As you say it’s a lot of moving parts and a lot of effort for a small reward (unlike the Boleto fraud).
Indeed – thanks Tom; very helpful.
In case you’d like to expand on the possibilities of multisig on future articles, I definitely recommend these sources:
* Multisig for recourse, arbitration, escrow & risk management (Andreas) – https://www.youtube.com/watch?v=8Ud3IHbdobo#t=164 @2’42” to 13’17”
* Multisig: A Revolution Incomplete (Vitalik) – http://bitcoinmagazine.com/15290/multisig-revolution-incomplete/
* Bitrated: You Can No Longer Say Bitcoin Has No Consumer Protection (Vitalik) – http://bitcoinmagazine.com/8834/bitrated-you-can-no-longer-say-bitcoin-has-no-consumer-protection/
on this last article, Vitalik points to three properties of multisig escrow which I find REVOLUTIONARY:
“First, in all cases where there is no dispute Trent [the escrow] is not involved at all. As a result, nearly all transactions will have no fee. If Trent gets involved, he will likely charge a fee, but the fact that fees are charged only when the escrow agent is actually brought in ensures that the system is paid for primarily by the very same people who make the heaviest use of it – a drastic change from the credit card system, where the fallout from fraud is evenly spread across everyone in the form of a 2.9% fee charged to every merchant and ultimately passed on to every consumer, regardless of how much due diligence each individual consumer does to deal with reputable merchants. Second, even if Alice and Bob bitterly disagree over whether or not Bob adequately fulfilled the conditions to receive the payment, if they both agree that Trent is doing a bad job of adjudicating, or is charging excessive fees, the two can sign a transaction together to send the funds directly into another escrow with another escrow agent. Finally, Trent himself has no opportunity to run away with the funds.”
Cheers!
Thanks Alex – good links.
You’re right that I’ve not blogged much about multisig – and it’s definitely a topic that deserves a wider airing.
There is no over the counter cure for wrinkles and fine lines.
About 2 months ago, I told the doctor that after the accident
I had an x-ray on my back, but none of my neck.
There won’t be any equipment that will tell
what the right size is.