Monthly Archives: September 2014

Standard

Posted by

Posted on

September 22, 2014

Posted under

Bitcoin, Internet of Things

Comments

5 Comments

“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

 

Standard

Posted by

Posted on

September 10, 2014

Posted under

Payment Cards, Payments

Comments

73 Comments

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?