Apple pay

31 October 2014

The recent announcement by Apple that it has incorporated an NFC chip into the latest iPhone (at Last) and that this is supported by a payment service, Apple Pay, is good news. The mobile payment systems seemed to have stalled for a while until this happened. This, combined with the adoption of Chip & PIN by the US, means that US retailers are finally starting to upgrade their POS terminals, and support for NFC is mostly coming along with adoption of chip & PIN.

The main part of the Apple announcement is that the Apple Pay system will support Tokenisation. This is not well understood out there so I will attempt to explain what this actually is and how it works.

Registration process. The first step is to create a token and associate it with an account. On the Apple Pay system you send a photograph of your card. I presume this is then processed by OCR to read the PAN from the card and then Apple servers submit this and request a token for the card. A token looks exactly like a normal card number, the first 6 digits are the Bank ID Number (BID) but this will be from a specific token range for that issuing bank. Apple then stores this token number on the phone.

When a transaction happens the normal NFC protocols are followed, but the token number is presented to the reader, rather than the subscribers’ PAN. This is then processed in the normal way by the retailer, and sent via the acquiring bank to Visa scheme systems for processing. The Visa systems recognise the BIN number as a token range and pass the token number to a tokenisation system. This will ten apply the special token rules to the transaction. In the case of Apple Pay the transaction will only be accepted if it came from an iPhone. It determines this from elements in the transaction record provided by the merchant.

If the transaction passes these tests then the transaction is passed back into the normal processing, but with the customers actual PAN replacing the token. Normal processing then presents this to the issuing bank for authorisation and collection.

The consequence of this is that the retailer will not be able to correlate transactions that happen with the real card and those where a token is presented. Not so much of a problem at the moment when Apple Pay is the only service. But say you had 15 different tokens, and presented different ones, this is going to confuse retailer systems that analyse sales patterns. This is a very important part of large retail operations, and an increasing part of smaller operations.

Then we come to the competition a number of large retailers in the US are launching their own mobile payment system. CurrentC is the brand name of the service offered by Merchant Customer Exchange. This differs from all the above, in that it expressly tries to maximise the identity information that it retains so retailers can analyse the sales patterns. It also bypasses the Card schemes, to minimise transaction processing fees.

For retail operations one of the major expenses is their transaction processing fees. This is an extremely complex area. The fee structures charged by the card schemes run to thousands of pages of rules, exceptions caveats and the like. But basically a retailer will need to spend a percentage of their revenue on these transaction fees. For large retailer this could be as low as 0.1%, but more normally it would be more like 1% to 2% for POS transactions. These will vary depending if the card is a credit or debit card, and every nuance of the processing.

These fees are the main driver behind the CurrentC scheme, as this will connect direct to banks, transaction fees for the retailer owned MCX system will be much lower. But they will have to attract customers to their system. At the moment these retailers seem to be alienating their customers by refusing to accept Apple Pay transactions.

Many Issuers offer various reward schemes, as part of their consumer offering. These are paid for largely out of the processing fees they charge. So a payment transaction for a product will be presented for say $15.00 this will be deducted from the customer’s account, but the issuing bank will only pay 99% of this to the acquiring bank, who will then take their cut before passing onto to the retailers account.

references:
Apply Pay    https://www.apple.com/apple-pay/ https://en.wikipedia.org/wiki/Apple_Pay
CurrentC    http://www.mcx.com/ https://en.wikipedia.org/wiki/Merchant_Customer_Exchange
EMVCo        http://www.emvco.com/
– Tokenisation Standards    http://www.emvco.com/specifications.aspx?id=263
– EMV Contactless            http://www.emvco.com/specifications.aspx?id=21
Google HCE
– SDK        https://developer.android.com/guide/topics/connectivity/nfc/hce.html
– Wikipedia    https://en.wikipedia.org/wiki/Host_card_emulation

Transaction Fees
– Overview: http://www.cardfellow.com/blog/credit-card-processing-fees/
– POS 1%-2% Large retailers 0.5%  http://www.transfirst.com/processing-rates-fees/retail
– Mobile / eCommerce 2% – 3%
– Fraud 0.5% if well managed

Glossary:
Issuing Bank          the bank that gives the card to the customer
Acquiring Bank    the bank that processes the retail transaction
PAN                Primary Account Number, this is the credit card number
BIN                Bank Identification Number this is the first 6 digits of the PAN

News reports:

http://www.theverge.com/2014/10/25/7069863/retailers-are-disabling-nfc-readers-to-shut-out-apple-pay

Following Apple’s announcement last month, both Wal-Mart and Best Buy confirmed to The Wall Street Journal that customers would not be able to use the system in their stores. Earlier this week, a leaked internal memo from Rite Aid revealed that the drug store chain was modifying or disabling its NFC readers, preventing access to Apple Pay (and other systems, like Google Wallet and wireless carrier-backed SoftCard, which also depend on the contact-less technology). A representative later confirmed the news to iMore. Today, CVS followed suit and shut out Apple Pay, according to reports. Both will support CurrentC on launch next year. The companies have not immediately returned requests for comment.

http://www.businessweek.com/articles/2014-10-29/currencs-data-breach-adds-to-awful-week-for-apple-pay-rival

From a publicity standpoint, a data security issue is one of the worst things that could happen to CurrentC right now. The app exists only in a private testing mode, but its plans call for a public launch sometime next year. Since CurrentC bypasses credit cards, the system will ask millions of shoppers to upload sensitive banking information to its servers. Users will also be asked to embrace features that allow CurrentC to track their physical location, information about their transactions, and other data.

MCX’s privacy policy says it may make commercial deals to acquire personal data from third parties, combining that with data it is gathering on its own to build its service. Dekkers says that anyone wishing to remain completely anonymous while using the system will be able to do so.

Anonymity is the default setting for Apple Pay, which makes a selling point of its inability to collect information about transactions. It’s a limitation that irks even some of its supporters. Apple also uses a technique called tokenization: temporary codes, rather than credit card numbers, are used to process payments, which can’t go through unless a user also scans a thumb with an iPhone fingerprint reader.


Closing the loop

23 September 2013

I am probably a bit suspicious, but I always keep my credit card receipts, and check these off against the monthly statements. I have been doing this for at least 10 years. Mostly using GNUCash which makes the process of reconciling these pretty quick.

Over that time I have found a few mistakes, some in my favour, things that I have never been charged for, and a couple of things not in my favour. Like double charges for things, or fraudulent transactions, mostly these are easily rectified. Some of these have been identified by the Bank and rectified before I find them, sometimes not.

So the era of pay-wave where you generally don’t get a paper receipt is now coming. I personally have resisted this until I was asked by my employer to trial a new service. This allows me to receive a text message whenever a transaction meeting certain criteria is authorized.

The text messages are a huge peace of mind. This I have a record of every transaction, when it happens, including the place and amount. So I don’t feel the need to keep every receipt, and reconcile it to statements.

I hope this catches on and is used by many more banks.


Add Tracking

26 May 2013

There has been a lot of interest in the way in which advertisers gather the targeting information they use to target ads. The EFF has a detailed investigation into how facebook does this. This shows how your offline activities are used to refine the online advertisements that are shown by facebook. While this just covers facebook, many other sites use these companies and others to do similar things.

Personally I always use add blockers, back from the day when advertisers use animations and flashing to draw you eye, making it hard to read the content of the site. While this doesn’t prevent tracking it just cleans up my screen and makes the content readable.

I also came across this info-graphic that explains much of the on net tracking technology in a fairly understandable manner.

Internet Day Infographic
From InternetServiceProviders.org


Linix demand for support

21 May 2013

If you talk to the Mobile operators they don’t support Linux. They say there is no demand. Well the interesting case in point is giffgaff. This MVNO network relies on the public to crowd source their support information on their network.

So with a bit of Goolge hacking we can see the number of support pages that mention Linix on the various networks:

So the level of Linux support provided by a small UK MVNO beats the mighty giants of the world mobile.


Internet Survey

27 March 2013

You may have heard of this elsewhere. This is a Grey Hat report from a anonymous individual, that has used a botnet to survey the entire IPV4 address space and perform a port scan on every one of those IP addresses.

In summary he delivered his scanning software to 30 thousand machines that provided a telnet port (23) that accepted a logon of either root/root root/(blank) admin/admin admin/(blank) or even (blank)/(blank). There were many more of these devices, but this was sufficient to his requirement to scan the entire IPv4 range in about 3 hours.

The main implication from this is the availability of these hosts could be used for DDoS and other botnet activities. One would speculate that they may be an increase in this type of activity going forward.

http://internetcensus2012.bitbucket.org/paper.html


The Nexus 7 and Open Street Maps

26 October 2012

So with the launch of the mini iPad that is a lot of comparisons between this and the Goggle Nexus 7. I don’t have a iPad of any size and so don’t have any way of offering any sort of objective comparison. But what I do have is a Nexus 7 and the experience of using this while traveling around Europe.

We recently drove through Europe for a 2 week holiday. We skipped through France, Belgium, and Germany fairly quickly, as we wanted to visit Prague, and then go on down through Austria to Hungary. So Maps were very important for this.

We have a TomTom, not sure of the model, but has all of Europe in it. I have tried to update the maps in this but am not able to keep both sides of Europe as the size of the maps has expanded. TomTom only allow broad groups of countries to be loaded, so western Europe (UK, Germany, France, Spain, Portugal,…) or Eastern Europe (Czech Republic, Poland, Hungary,…). Not much use to us as we Live in the UK and often visit Hungary.

We also had paper map book, Michilln whole of Europe, OK for motorways, and getting a sense of the general direction, useless in cities and towns.

I also had the OSMAnd application on my Nexus 7. This is an open source application for viewing maps from Openstreetmap.org The crucial feature needed when traveling is offline maps. OSMAND allows maps from each individual country to be downloaded, and can operate completely with no data connection.

Given the expense of GSM roaming in Europe, this is a feature that makes all the competition unusable. Goggle maps dose now allow downloaded data, but to use this feature you need to be in the location and then save the map tiles for that location. No pre-loading by country, and no offline searching, or route finding.

Here are a couple of scenarios where OSMAnd proved invaluable. First find the hotel we had booked. We had the address, and were in the approximate place, just needed to find the place. Putting the street name into Tom Tom showed a number of entries for the same street name, in different districts. This had no indication as to how far away and our limited knowledge of the city meant we didn’t know the districts. Searching for a street name in OSMAnd the matches are listed ordered by distance, either from the current location, or a location can be set. There is also a arrow giving an indication of direction.

Remember where we parked the car, not always easy if you are exploring. OK so I had a favorite location called Car, that I updated when we parked in a back street. Just get the nexus to get a fix, long tap on the current location, and save as a favorite. Then it was easy to find our way back to the backstreet where we parked.

Fancy a coffee? search from the current location for restaurants, add a filter “cafe”. This gives a nice list, showing direction and distance. Tap the map icon and the locations are highlighted on the map display. We found some wonderful breakfast cafes this way.

Traveling on some back roads we came to a line of traffic, it transpired that there was a major crash up ahead and we were not going to get through for quite a while. OSMAnd came out to find an alternative route, by taking some even more back road roads, that didn’t have any useful roadsigns.

This all relies on the quality and freshness of the data. generally this seemed to be pretty good. The listings of shops and businesses are pretty good in the larger towns, but small villages generally only had the street data there. The street data however was remarkably accurate.


USSD Code dialling exploits

28 September 2012

The recent disclosure of the finding that many phones respond to USSD dial strings in a tel: html markup without requiring any user input has recently been demonstrated.

The issue comes from the tel: html markup, that the phone will automatically execute a USSD command embedded in a tel link.

The Samsung S series has some powerful hidden codes, including one that will reset the phone to factory default *2767*3855#

The html string <iframe src=”tel:*%2306%23″/>  will display the IMEI, but if the code above is used this resets the phone. My experience suggests that most phones have secret codes that perform these sorts of actions. It only remains for these to be discovered for much wider exploitation.

Normally when a tel: prompt is encountered this just populates the dial number field and the user would then need to hit call to initiate the call. Some USSD codes do not require this, all phones should respond to the *#06# string with the IMEI of the phone.

Video of the presentation: http://www.youtube.com/watch?v=Q2-0B04HPhs

There is a test page: http://mobilephonesecurity.org/tel/ This is safe to go to as it only has the code to display your IMEI. If you visit this page on a phone browser, this page should open the dialler and pre-fill the dial string with *#06# ready for you to hit send. If your phone is vulnerable you will just see the IMEI displayed, that is the phone has immediately dialled this string.


Follow

Get every new post delivered to your Inbox.

Join 422 other followers