Article on IMSI Catchers and Stingrays

24 April 2015

I have been helping a proper journalist, Brady Dale, write a article on the use and abuse of Stingrays and other IMSI catchers. It turned out quite well. It is up on Motherboard.


Mobile banking apps

29 January 2015
I have been getting slowly frustrated with my bank, First Direct who I joined soon after they launched, because they were then offering the latest technology in telephone banking. Removing the frustration of having then to go physically to the bank to get anything done. Back then this was quite revolutionary. But they have not kept that zeal going and everyone else has caught up with them, and overtaken them. Time to find a new bank.

Well now we have moved on from that position through the internet to mobile banking. My idea was to evaluate the various banks that I could move to in terms of their mobile offerings, and choose the one with the best mobile presence.

Lets define what I am looking for here. The mobile app should be fast, and integrate well with the Android user experience. I have seen many apps transferred from iOS that don’t adapt to the way Android works. I don’t care about the Apple app as I will never use that. My bag is security so it needs to have good security. Preferably integrate with Lastpass so I can have a password that is too complicated to remember.

I have no interest in offers, cash-back, or other gimmicks, just a business like interface that presents clear information and allows simple actions.

Here is a list of the main contenders and their current rating on the Google store:

First direct   3.3
first direct Banking on the go - screenshot thumbnail

This one I know well, it works OK but is essentially a iOS app transported to Android. It is slow and clunky, every menu item or back button involves some spinning icon wait time. Getting to the login screen takes about 20 seconds. They do some funny stuff to stop me using Laspass to log on. I cannot paste my password in, password for the mobile app is limited to 8 characters. If you change focus to another app it may log you out. The menu button just shows the about page, you have to use the iOS style menu button at the top of the screen to navigate. and the back button only works sometimes. I am sure that all the apps here have these sorts of problems, but many of these aspects I can’t evaluate without signing up for an account.

HSBC   3.8
HSBC Mobile Banking - screenshot thumbnail

This is clearly the same as the First Direct app, and this is to be expected as they are the same banking group. They have these offers and rewards on the front screen, this just says to me our service is so bad we have to offer you stuff to use it.

Lloyds Bank   4.2
Lloyds Bank Mobile Banking - screenshot thumbnail

This is clearly better, but why have an ATM finder in there, I can get that from my mapping app (I use osmand which is based on the Open Street Map data, so better than Google. The login is through convoluted letter selection from a password, so I have to have a password that I can remember and can’t use Lastpass to store it in, thus reducing my security.

 

 Nationwide  4.1

Nationwide Mobile Banking - screenshot thumbnail

This feels like I am in kindergarten. and there is a login by the selection of digits from a pass number. Even harder to remember a complex number, and reduced entropy of only providing 3 digits. I have enough stupid PIN number to remember I don’t want any more. This feels like the best so far though.

Metro Bank    3.9
Metro Bank Personal Banking - screenshot thumbnail

Well what about the new comers to the banking market, perhaps they can produce a decent mobile app. Looking through the comments it seems that setting this up is a pain, lost of PINs and pass-codes before you can start. Summarising the comments they say it is a workable app, clunky, but functional.
Well at this point I cam across a news item on the BBC http://www.bbc.co.uk/news/business-30849322 saying that two new banks offering internet only service were starting up. Atom bank have a website, and are recruiting people but there is nothing to see in the way of a mobile app to look at yet. The other is a German bank Fidor. So let us have a look at their German offering.

Fidor.de   4.6
Fidor Bewegungsmelder - screenshot thumbnail

This looks much more professional. They have widgets so show current status, so you can see these without opening the app. The app itself uses the Android 9 dot pattern for authentication, easy to remember and enter on a mobile, hard to guess. There are not many reviews there, only one describing issues. The news article says that this is launching in the UK in March, so not long to wait.

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.


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.


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.