Apple's iPhone bonk to 'Pay' app launches on Monday Cupertino's plans to dominate the world of pay-by-bonk have been exposed following the leak of what appears to be a TOP-SECRET Apple Pay training manual. All Apple staffers will apparently take part in an hour's training on the new bonk-to-pay system, which is expected to be launched later this month following an event on 16 …
If I lose my wallet, I still have my phone to contact the bank and cancel the cards.
If I lose my phone.....
Seriously though, if you put everything on your phone, photos, credit cards, contacts, appointments, etc all in one place, it's a one stop shop of loss. Yes you can back it up if you remember, yes you can get another phone and download the back up but for the 24-48 hours your life will be on hold.
You've just lost your entire life and someone is working hard to find a way in to it.
There is something to be said for keeping things separate, using pen and paper and having an old fashioned diary.
One final point, what if your battery runs out?
Basic flows:
1) Customer uses iPhone to register new card.
a) Registration consists sending "add to vault" message to Network i.e. VISA or MC.
b) If institution has agreed to iPay, then they are charged $1 (and $1 per month or so) for storing
this card on VISA servers.
c) VISA stores the Token value and the account number (PAN) Note that the Token value is
routable (new BIN range) and begins with the correct first digit of the PAN.
d) A single PAN can have many tokens. Either PAN or Token can be replaced at VISA server if
either is compromised.
e) Token (encrypted) is stored on iPhone's SE (secure element) not the SIM's secure element.
2) At BONK time, Token is sent on EMV rails to appropriate network (VISA in this case)
3) VISA looks up token, and replaces it with the correct PAN.
4) PAN gets sent in message to issuing bank (i.e. customer's bank).
5) Issuer essentially processes it as a normal transaction.
This allows non EMV cards to essentially behave as EMV cards, making make stripe a little more secure assuming the mag was never used at a terminal.
Thus, merchant never sees funding PAN, Issues never sees Token. Apple makes .15% on credit ($.05 on debit). VISA charges $1 per PAN (or maybe Token, not sure which) to issuer.
C.
Apple don't know or need to know any of the users credit card details. They get a token from the card operator which they store on a user's phone and send, with other cryptographic details, to the vendor on request. The vendor attaches a price and forwards the combination to the credit card company, who look up the token to find the account details and subtracts the amount. No need for the phone to know the card number, expiry date or what have you. They don't even need to send a new token if a card expires, just update the details against the existing token. If a token is comprised in some way they can invalidate it and issue a new one without changing the card.
It sounds like a pretty clever and secure solution to the problem.
The initial registration of your card does need the credit card number and CC code (suitably encryted, etc) to be sent via Apple to the credit card company, so they can associate the token with your credit card account. After that, Apple don't need to store what was sent via iTunes and their servers. Even better, the data could go direct from iTunes to the credit card company servers and Apple would never see even the encrypted version of your data.
Not going to happen. Despite the BBC's best efforts to downplay the iCloud hack (even going as far as trying to invent counter Android stories), consumers are wary of Apple security. If they can't be trusted to store you nudy pics, how can they be trusted to store your creditcard details.
Scammers round the globe must be running their hands with glee, at the prospect of i-idiots with too much money and no intelligence setting weak passwords and ignoring Apple's (poorly implemented) 2-factor authentication.
You seem to have confused iTunes with Pay. iTunes needs either a registered credit card or a gift card to make purchases through the store. "Pay" OCRs one or more cards and sends the details to the issuer in order to request a token. Once the phone has a token then it needs not hold the OCRed data and can throw it away. The two sets of cards need not overlap.
@AC
Your phone knows about your card details.
Those details (which end up being stored in a 'secure element' of the phone) may be gleaned initially by scanning the card optically with its camera. Or - if you happen to have already registered a card for iTunes payments - that card is known to your phone.
You can't just go around photographing anyone's card and expect to be able to make payments with it. There's an authorisation process that must happen first - details not yet divulged. In the case of a card registered against your iTunes account, that's already authorised.
When your card gets a new expiry date, the card company will push that info out to your phone via some kind of message. Probably automatically. Details sketchy at this time.
Because your latest updated credit and debit cards still show your name and account number - which, when lost/stolen, still provide a hacker valuable information. Your TouchID protected phone, when lost/stolen won't be easy to break in. But even if it is, there is no account numbers stored on it.
You must not live in the US. I have a half dozen cards, none of which are EMV compliant.
But when I do, I agree that using a phone to pay is rather pointless, assuming the merchant gets the same data (i.e. lacking my name or anything else unique to link me to a purchase) from the card they do from Apple Pay.
It would be nice as a backup if I ever forget to my wallet, but that might happen maybe once a year. On the other hand when I go out for some "serious" drinking when my college friends come for a visit I specifically leave my wallet at home so I can only pay with the cash I carry. That limits unintentional overspend as well as reducing the size of the hangover the following morning. I guess I'll have to remember to delete the card from Apple Pay before I leave to preserve the efficacy of this strategy :)
But that's the point - the merchant DOES NOT get the same data - every transaction you make using ApplePay uses a unique token (aka fake CC number). The merchant doesn't know your "real" card number. If they have an attack (hello Dairy Queen, Target, Home Depot, KMart, and others) then whatever information they have on you is USELESS and can't be used.
You're actually better protected using ApplePay than a regular swipe and sign CC in the US or an NFC or chip-and-PIN card in the rest of the world, partly because of these unique tokens, and partly because the CC number can't be read from the phone if it's stolen (like a CC) and there's no way it can be used (like a CC with copying the signature / looking over your shoulder at your PIN at an ATM and then nicking the card for chip-and-PIN).
You don't even have to trust Apple with your CC information - you only have to trust that they are being honest when they say they don't store it in the phone. Which if it turned out they were lying about, would cause massive outrage, so I think we can be pretty sure they're being honest.
Every transaction uses an encrypted version of a fixed PAN (the CC number) using a one time key. This PAN/token is created when you register the card. The EMV crypto data produced when you tap this card is equivalent to what it would be for a normal card with this PAN. It seems to be similar to those contactless cards where the contactless and embossed PANs are different.
Apple doesn't reatin this PAN after it's transferred to your phone, but it is in your phone. You would still need get around the EMV crypto were someone to figure out how to get at this PAN as it's only useable for contactless transactions.
I like the idea of a card token stored for NFC payment. Saves me carrying 2 or 3 cards - wonder if they are planning on expanding the usefulness by making it compatible with other card types such as TFL Oyster system - food for thought.??. As for risk....what the hell - someone has to use it to prove it...Yep I remember that it's been tried before but maybe these Apple bods will just make it work with their bendy phone fnarr fnarr
The token technology is not Apple specific, and others will offer similar payment systems. Whether they are as frictionless as Apple's with Touchid remains to be seen. Apple also remain as arms-length to the transaction as they can be, which pleases all the interested parties, unlike, for example, Google wallet. If the potential to more or less eliminate fraud is realised, there will be strong motivation for people to adopt it.
It seems ApplePay's defining feature is the integration with the 5S and 6(+) fingerprint scanner. Few (any?) other systems will have this additional security capability. I imagine the transaction processors were crawling all over each other to be on board, as the reduced fraud and fraud insurance costs will be substantial I (and they) expect.
I see no reason or use for bonking my iPhone to pay for anything. It takes the same amount of time to pull out my wallet and swipe my card. What's the real benefit to the end user, other than having one more thing that makes your iPhone attractive to a thief? And as it's been already pointed out, Apple had a hard enough time securing celebrity newd selfies with iCloud. I heard a long list of businesses that have no current plans to deploy bonk to pay services for the iPhone.
Do try to keep up. When Apple Pay is activated in the UK, you'll be able to use it anywhere you see the NFC payment symbol. If, as you say, a long list of businesses 'have no current plans to deploy bonk to pay services for the iPhone', they must also have zero plans for handling NFC card payments. Which kind of flies in the face of what's actually happening in the UK.
You mention card swipe. Which is shit technology. Any thief can clone a magnetic stripe and use your card. Or they just lift your card and start buying stuff with it.
Apple Pay will require your fingerprint, which is much much harder to clone, in addition to your phone. That does not make it an attractive target for thieves.
The real benefit to the user, since you ask, is that your card information cannot be stolen from the phone, your purchases are authorised by your fingerprint, nobody can look over your shoulder to see you entering a PIN, and there's no magnetic stripe to clone.
"When Apple Pay is activated in..." Why wait? I can use my credit card at any vendor with an NFC reader. Better, I'm not limitted to just those vendors that make special arrangements with Apple. Especially important is that I'm not limitted to just buying 2nd grade phones to do it. You know they'll never licence anyone else that makes phones, don't you.
Oh, and this bizaro fingerprint stuff? Just read the literature to see how easy it is to clone a fingerprint. Not counting the lazy thieves that just hack off the finger as they steal your phone.
"Just read the literature to see how easy it is to clone a fingerprint"
I've read the 'literature', and there seems to be a consensus that's it's non trivial to do so sufficiently well to fool the iphone reader, at least unless you're being specifically targetted by someone who cares enough to invest a good deal of effort into gaining access.
In my part of London, lazy muggers are far more likely that tech literate ones.
This sounds like the Visa Account Updater service (and presumably the Mastercard equivalent) which in the case of you arranging a recurring payment with a merchant (e.g. for a magazine subscription), provides that merchant with your new card number and expiry dates when your old card is replaced because of expiry, loss or theft. See http://usa.visa.com/merchants/grow-your-business/processing-solutions/account-updater.jsp for details...
I'm not an iPhone user because I don't care for the constraints imposed by Apple's infrastructure and business model.
However, if I did have an iPhone, I'd prefer to use it to make purchases with a fingerprint than use a card with no security at all.
I'd still worry about it being hacked though. Extracting and re-using encrypted credentials is already common currency in the iPhone jailbreaking world.
Currently using a contact-less card you are limited to a max of £20 per transaction and after so many transactions you are asked to use chip and pin. Does the iPhone have a similar method to stop someone clearing out your bank account if they take your phone?
Also it is the banks that are responsible for any dodgy payments taken with contactless cards, who is responsible when it comes to buying with the phone?
Spending limit enforcement: it's likely to work the same way that it does for contactless payments. For me, a more pertinent question is: will terminal equipment be upgraded so that higher spending limits can be agreed when a more secure (i.e. fingerprint) means of authentication is provided.
The banks will assume liability, as they do now for card payments.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
