It is probably the most unlikely advert ever aired on British radio. “Do I take cash and cheques?” asks the chirpy cockney geezer playing the “honest as the day is long” tradesman. “Nah. Payment, yes; ‘assle, no”.
Contrary to everything you ever thought you knew about tradesmen, this one would only take payment by a debit or credit card, using the mobile payment system that plugs into his Android or Apple iOS smartphone.
It’s enough to make anyone sit up and take notice.
The idea of a tradesman refusing to take cash might sound absurd, but the sudden proliferation of such payment devices is very real. In addition to the much-hyped Square in the US, a number of well-funded start-ups have arrived in Europe too - companies such as mPowa, iZettle and Payleven.
Their basic concept is the same. Instead of signing up with a bank for payment services, with all the cost that entails, users of m-payment services can buy a package, including an app for their smartphone and the hardware device, from an m-payment company instead.
This enables them to take payment via cards on their smartphones, with either the phones’ keypads used by customers to tap in their PIN numbers, or a keypad on the payment device itself. The phones’ 3G wireless connectivity, meanwhile, is then used to authenticate the transaction with the bank, while the m-payment company takes a small percentage in a payment processing fee when the transaction is completed.
What could possibly go wrong?
The trouble, says professor of information security at Royal Holloway University of London Keith Mayes, is that when customers pay by debit or credit cards on a closed terminal in a shop there are certain security requirements that it will comply with. However, these are absent from mobile phone operating systems, which weren’t designed to provide an environment for taking payments, and are still highly immature platforms.
“Mobile phones should not be regarded as secure platforms in any way,” says Mayes. “They can have all the same problems that your PC has. We have had students put root kits on them such that they cannot be detected by normal anti-virus protection. They are also proprietary. A lot of it is not published; they have not been evaluated independently for security.”
Indeed, with m-payment it is not just the phone that presents potential security challenges, but that such challenges could arise at almost any stage, from the security of the card-reading device to the mobile signal used to communicate with the back-end systems of the m-payment company.
Equally, if the user is inputting their PIN on the vendor’s device, it may be much harder to shield their number, or it may have a key-stroke logger surreptitiously placed on the device, either by a dishonest vendor or by a third-party attacker. Because of the nature of the device, the cardholder can never be too sure of security.
But the most astonishing mobile card-payment system is the US offering called Square. Because the US was late to implement chip-and-PIN security, Square’s payment device reads the unguarded, unencoded information contained on the card’s magnetic stripe. This makes such a device a potential front for card skimming.
Mayes is scathing about Square’s basic design:
“There’s lots of things that could go wrong here, for example:
• it is generally easy to clone mag-stripe cards;
• it has the transaction display, and PIN entry issues, discussed in the chip-and-PIN case;
• the vendor’s phone could collect card details (and PINs) for later use - or transmission across to criminal chums for clone creation;
• the payer may not know that the hardware/software is legitimate - potentially any software could be running;
• these cards usually have an online verification, which means the terminal needs to talk to the acquiring bank, which requires some cryptographic credentials that would now be stored on the user device(s).”
However, while Square’s system in the US might be approved by Visa - where chip-and-PIN has yet to take off - in Europe it would be roundly rejected by the same payments service.
This paper seeks to provide education and technical insight to beacons, in addition to providing insight to Apple's iBeacon specification
Focus on cost efficiency, simplicity, performance, scalability and future-readiness when architecting your data protection strategy