Android Pay

I’m sure you’re already thinking of it, but I just discovered my ‘normal’ bank has support for Android pay, so I registered today. It must be quite new, I’ve not seen Android pay being advertised yet. Hopefully it’s in the works!

4 Likes

It launched in the UK today.

Oh, didn’t realise it was today! That would explain why the first person at my bank didn’t know how to register my card for it!

“When do we want first?”

I worry about some people on the internet. On a serious note I would like to see the “security” for Android Pay.

2 Likes

The security is pretty funny. Everything is done on the main CPU, RAM and flash storage passing through untrusted NFC chipsets. The phone will respond with a device+card identifier and <£30 transaction tokens to any reader that gets close (remember, no NFC shielding wallets for your phone!) even when the device is locked (>£30 requires unlock for CDCVM) while Apple Pay requires some kind of intent (either through Touch ID on the phone or a double side-press on the Watch) for ANY transaction.

I understand why these decisions were made (lots of different Android devices out there, not all with secure elements and fast fingerprint readers! TfL also has their speed requirements.) and I’m not normally one for OS wars but it’s still funny that the banks just allowed this.

4 Likes

Aww man, never noticed that mistake :frowning:

Used it this morning anyway on the tube in London. Worked ok, as for security is it any worse than current contactless? It does say for some transaction that I will need to unlock my phone.

The banks wouldn’t allow it if it was insecure. Also, Android Pay uses a virtual account setup between the Android pay system and your bank, this means no one can grab your account details via nfc making it far more secure than a normal contactless card. Also, where a normal contactless card is “always on” in your pocket, advertising your actual account details, nfc on Android is off when your phone is off, making it even more secure.

All transactions appear in your notification area as soon as they’re made, with a full list of transactions in the app so you can keep an eye on what’s happening too.

It works very well, I use it all the time.

Jin

1 Like

All a game of risk and insurance. The reported £100 limit on Android Pay purchases is part of this. Consider why Barclays, RBS, Natwest, TSB, Santander and American Express are not supporting it when all the major players except Barclays were so quick to jump on Apple Pay as soon as they could build the back ends to support it.

When dealing with security on these platforms, you have to think a little outside of the norm of trying to clone a card. Why is it that Android Pay disables itself when you root your phone? All your information is stored and protected by the system, as is all of the authentication. From what I’ve disassembled, if some malware has root, there’s little stopping it from potentially interacting with parts of the Android Pay process and suppressing any evidence of it. I also don’t see protection against simply stealing the various numbers and generating tokens elsewhere from them either.

Compare that to the Apple Watch and iPhone where jailbreaking is not the norm (at least not anymore) and if someone did jailbreak, the actual local card information is on the secure element and protected by the SEP. These are dedicated pieces of hardware that deal with the secure parts of Apple Pay and system protection away from the main CPU and OS. With the NFC controller wired directly to this dedicated hardware and that wired directly with the Touch ID sensor (for in-app Apple Pay, by the time iOS receives anything, it’s in a form that needs Apple Pay services to unwrap it), there is no point where any sensitive data is kept in main storage or even touches system RAM to be accessed by the CPU. All iOS itself has is this JSON and some images to display in the Wallet App.

Apologies for the information dump and for constantly bringing up Apple Pay in an Android thread but it is the other implementation of the same mobile tokenized payment system and I have access to a lot more engineers at Apple than I do at Google. :sweat_smile:

3 Likes

It may be different from Apple Pay, that doesn’t mean it’s any less secure…

This is exactly why rooted phones and phones prior to when SE Linux was introduced can’t run it. Every app and process is sandboxed, this in combination with the fact that the only account info is a virtual account linked at your bank not on the phone means your account can’t be hacked.

And with SE Linux enforcing the mandatory access control policies in Android, applications do not have any access to other applications files and cannot infect or gain any information from them, as stated on the Android developer source pages. SE Linux has no concept of a root user, so MAC is still enforced even for root, and even on a rooted phone the user has to expressly and manually grant root access to each app, it’s not something that’s just given by the system.

Barclays has its own competitive system for Android phones and wan’ts to concentrate on that rather than adding a rival product. American Express in the US does support Android Pay, it’s RBS who control American Express and Natwest (and others) over here that don’t support it it - yet - they have made statements saying they will support is as soon as possible.

As a Linux/Android/security enthusiast I researched extensively before I installed and started using it, and I have no concerns from anything I have found so far…

The main problem here is that Android Pay is still working with thousands of OS builds over hundreds of devices and several companies in the chain of hardware and software to deliver it all to you. From the perspective of the banks and their insurers, the possibility, uncertainty and fear is there. Something they really do not like.

The device account number and various things that go in to generating tokens. There’s nothing really there to hack but you can still either steal them or fool the device in to fraudulently generating you tokens to give to a payment network. That’s just attacking the already added card too. Consider how you might fraudulently add a card that isn’t yours as this happened a lot around Apple Pay’s launch in the US where at least one bank wasn’t actually verifying their users properly.

This is if the user has rooted through “normal” means. If malware has rooted your device, it can skip all of this. Something like SuperSU wouldn’t even be there and the malware will elect itself as the Superuser manager. Additionally, if mildly inconvenienced XDA-Dev users can bypass the (often pretty lame) root checks, you can bet a determined attacker can evade them.

In theory, you are mostly correct on all the SE Linux stuff. In practice, I’ve seen some VERY questionable things done by handset makers and carriers on real devices.

Barclays is doing very strange things on Android, I do enjoy watching friends with their app fail to connect and authorise payments within the timeout. RBS side I’m not exactly hearing confidence inspiring things.

Again, it’s all the game of risk and insurance (I should specify, insurance against loss through fraud), the more companies involved and the more software and hardware variants, the greater the perceived risk. You’re relying on things like a vendor customised fork of Android with carrier software and Google services running on chipsets that were never built for payments from years ago and you can’t audit or certify every variation of even just the kernel. The insurers just feel a lot better about “dedicated, audited hardware away from user software” than they do about “well, we have these protections in software but can’t guarantee that it’ll even exist, work or be unmodified on all devices”.

1 Like

Hmmm, this is not what I’m finding.

The sandboxed app is still sandboxed (all it’s processes whether in RAM or otherwise), the MAC is still enforced by SE which is why the NSA and various other US and UK security agencies use Android.

Since the NSA injected their SE code into Android (4.3, although not fully implemented until 4.4) initially on Samsung and HTC devices but then baked into the OS as standard and updated on a regular basis separately from the OS, nothing can circumvent the MAC and so has no access to Android Pay or any other app on the device for that matter.

If the banks are all so frightened of the prospect, why are so many taking it on, both in the US and over here, with the others saying they want to take it on soon? It’s been through due diligence, a bank wouldn’t risk a sudden massive influx of fraud (which would be the result of millions of devices being so at risk)…

When I added my cards the system made me actually call the bank and go through their usual security checks before it created a virtual dummy account which is then sent to Android Pay on my device. I’m not sure how this could be replicated fraudulently, but if it could be then everything I do would be just as susceptible, and I wouldn’t do any online banking, or online purchasing.

The bottom line is, I’m satisfied as is my bank that the system is secure enough for me to use with confidence…

Android Pay and MasterCard offer free travel on London’s public transport

The only MasterCards I have are not compatible with Android Pay. Do you know if the fare free Monday’s actually work on any MasterCard with contactless?

I believe the free travel offer in October is specifically for Android Pay users. A similar offer ran in November last year for Apple Pay users.

It’s a shame I don’t have a MasterCard that lets me add to Android Pay. I took advantage of the Apple Pay one before.

For those with a suitable card for Android Pay remember that this applies to anything that uses the TFL system for contactless payments. As well as the tube, buses, trams, Overground and TfL Rail it’s valid on any National Rail services in the Oyster area (now includes Gatwick Airport), the Emirates Air Line cable car and the MBNA river bus services (when paying for boat travel using the Oyster readers on the pier). It’s also valid on the high speed trains from St Pancras to Stratford (but not beyond that)

Any TfL fares up to the maximum stated in the article are covered. During the Apple Pay promotion I made a trip on the cable car and used the high speed services and can confirm they are covered.

I hear the latter will soon be known as the Thames Cable bar! :wine_glass::cocktail::tropical_drink::beers:

1 Like

EDIT: I see you said Thames Cable BAR :grinning: The autocorrect in my head thought you said cable car!
:beers:
The article doesn’t say anything about the sponsorship being dropped as it refers to Emirates Air Line throughout. I believe the sponsorship has quite a few years left to run. No problem with alcohol and the Emirates association as they serve alcohol on their flights.

Are there any prepaid MasterCards that support Android Pay I can get my hands on fairly quickly?

:grinning: Yep, the Emirates sponsorship contract ties TfL into operating the line until 2021 (with a break clause in 2017) but it is apparently costing £5 million a year in subsidies. So the new licence is just an attempt to generate extra revenue from alcohol, films, live music and events such as karaoke and disco nights.

I like the service and would welcome a drink but can understand why not everyone would agree as expressed by local resident Tony Vaughan:

“The music will probably be the usual cretinous cacophony. We don’t want roaring stag nights and shrieking hen parties, particularly not in the early hours.

“I’m 69 and will be in hell soon enough. I don’t want a foretaste.”

:joy:

Unfortunately, I don’t think so:

https://support.google.com/androidpay/answer/6314169?hl=en-GB

But perhaps someone can correct me if I’m wrong.

Will there be plans to monzo to NFC paynents with phones that have tap to pay? Such as Samsung s7e etc etc

Hey, I moved your post here in to the Android Pay thread (Samsung Pay is fairly similar though).

Mobile NFC payments are on the transparent roadmap for the medium term currently. I wouldn’t expect it on the current prepaid card though, this is a post-current account and debit card thing! :slight_smile: