Contactless, Cardless or Cashless? (part 3)

Cardless

Here we are for third and final part of this post. In it, we will address the cardless payment systems. Although there are many, like, for example, the wristbands used in the festival Lollapalooza 2014 (http://tinyurl.com/l362zdn) we, will focus on the ones that are design to be used with smartphones. From these, the most famous ones are Google Wallet and more recent Apple Pay.

Google Wallet

In 2011, Google has lunched the Google Wallet (http://tinyurl.com/kxgvmtx) service for the Android users. This service was designed to enable users to buy goods using their NFC enabled Android devices, by emulating the credit card behaviour.

In order for the service to work, Google required users to introduce on the device their credit card information. This information, was then stored in the secure element of the device. This element, is practically isolated from the rest of the system and, each time the device is used to buy something, it requires the user to introduce a four-digit PIN before transmitting its information to the terminal.

In order for third-party app developers to take advantage of the capabilities of NFC enabled devices, in 2014, Google introduced the Host Card Emulation. This new feature emulates the behaviour of the secure element and makes it easier for the developers to use the NFC capabilities.

Currently, Google doesn’t store the users credit card information on the device. Each time a user wants to associate a credit card to the Google Wallet service, a Google Wallet Virtual Card is emitted by Bancorp Bank (associated with Google). The information related to this new virtual card is then stored on the device using the Host Card Emulation feature. The users credit card information is stored on Google servers as is the users virtual card information.

Google Wallet registration sequence

When a user makes a payment using the device, it procedes as a normal credit card payment, meaning that it follows the EMV protocol (check part 1 of this article for the EMV protocol). The difference is that the money that is transferred from the acquirer to the merchant is provided by Google banking entity. At a latter time, the funds are discounted by Google from the user credit card.

Google Wallet payment sequence

If we take into account that each payment that goes through the EMV network has a fee that is charged to the merchant, we can see that Google may be losing money with Google Wallet. This is due to the fact that Google acts as both the Acquirers Bank to the Merchants Bank, but at a latter time, acts as a Merchants Bank to the Acquirers Bank.

So, one has to ask, how is Google profiting from Google Wallet because, no one enters a business to lose money?

Apple Pay

With the launch of iPhone 6, Apple has introduced Apple Pay (http://tinyurl.com/pjkatel). This is a new functionality that, allows users to pay for goods using some of Apple devices. Apple Pay relies on a tweaked tokenization technique that doesn’t store any information about credit cards on the device or on Apple servers.

When a user wants to configure Apple Pay, he introduces its credit card information (either by typing the card information or, taking a picture). The information is encrypted and sent over to Apple. Once received, it is decrypted and the card issuer identified. Apple will then generate a new encrypted packet containing the credit card information, the device information and iTunes history and send it to the card issuer.

When the packet is received by the issuer, it will evaluate the information and generate a DAN (Device Account Number) that is specific for the user’s device. The DAN is then encrypted using a key that only the card issuer can decrypt (leaving Apple incapable of decrypting it) and sent back to Apple along with a key used to generate dynamic codes unique to each transaction that is going to be performed. The encrypted packet is then forwarded to the user’s device where, it is stored in the secure element.

Apple Pay tokenization sequence

From this point on, each time that a user wants to make a purchase, the secure element will request the user to authenticate by using the touch id. After, a one-time-number is generated and sent to the the merchants terminal. The rest of the payment operation procedes has a normal EMV transaction.

By employing tokenization, Apple was able to convince the card issuer entities that it actually deserves a fee for each payment that is made using Apple Pay. This is due to the argument that  by employing this technique, Apple is actually reducing the probability of fraud (thus reducing the costs of the issuing entities) and, that users will spend more by using Apple Pay (http://tinyurl.com/lh67hyl).

But how secure is Apple Pay? Well, until now, direct attacks haven’t been reported (http://tinyurl.com/k28s7g5). However, the way that users authenticate to the devices may be vulnerable to attacks.

In late 2014, a member of CCC (Chaos Computer Club) has demonstrated how to clone a fingerprint from pictures (http://tinyurl.com/q5rdnfp). This allows another user to clone a fingerprint and personificate the owner to the device.

So Apple has based Apple Pay security on two distinct things, tokenization (that until the time of writing remains “safe”), and biometric information that, has demonstrated, can be hacked. Actually the same member of CCC in March 2015 has demonstrated how to clone an iris pattern from high resolution pictures (http://tinyurl.com/q3qlmg4).

Although Google Wallet and Apple Pay are the major players on the market, there are several new ones arising.

For example, SEQR (http://tinyurl.com/pvjvl9e) connects the users phone to the bank and relies on QR codes to read payment information from the terminal. As we stated in a previous post (http://tinyurl.com/o7lgj3c), depending on how these QR codes are generated, they may pose a security risk.

Another mobile payment system is Meo Wallet (www.wallet.pt). Apart from the “traditional” credit card association, it brings an interesting feature, it allows users to charge the wallet as needed. This way, a user is able to clearly separate their bank account from the device running the digital wallet.

SIBS has also announced MB Way (http://tinyurl.com/o9xttvs), but unfortunately is not yet available and little or no information is available of how it works.

From a curiosity point of view, we questioned one of these companies about how they are abe to guarantee the security of their system and the clients information and, we were very surprised with the answer. Citing from the reply email: “ We can assure that the use of * is secure, however, and how you should comprehend, for security reasons, we cannot answer your questions”. This answer actually makes one wonder if they are trying to do security by obscurity and, how secure is my information?

In this three part post we have covered the “state of the art” payment systems. We have showed that all have flaws an can be exploited in a malicious way. So how do you feel about the security of your money?