It was made to enable contactless to work on systems that only can handle magstripe (no EMV). It just transfers the card number and expiration date in the clear with a rotating CVV1 value.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Apple Rejects 'Samsung Pay Mini' on App Store Ahead of January Launch
- Thread starter MacRumors
- Start date
- Sort by reaction score
It was made to enable contactless to work on systems that only can handle magstripe (no EMV). It just transfers the card number and expiration date in the clear with a rotating CVV1 value.
Even if Samsung knew it would get rejected, the story here is Apple can reject for any reason and while some Apple fans or developers know that, not everyone in the world does.
Not everyone knows that once you go full Apple, you get locked in.
Not everyone knows that once you go full Apple, you get locked in.
Like I said before, we need some universal pay system available on both Android and iOS. What will happen if iPhone market share in Europe and elsewhere goes down to levels where retailers will question the need to offer Apple Pay, leaving iPhone users out in the cold (or forced to take out the old credit card). Apple should be more focused on hardware than collecting this and collecting that.
Last edited:
[doublepost=1481580911][/doublepost]
With Samsung pal there's no need to update terminals.
[doublepost=1481581244][/doublepost]
Samsung have been using NFC long before apple. Samsung pay doesn't only use NFC it also user's MTP magnetic transfer payment which means it can be used any were unlike apple pay.
Whoa.
Back up there buddy. Source on the iPhone having an MST style hardware capability. That hardware difference was the differentiator that was supposed to make Samsung Pay the new kid on the block when it was launched. That was their own PR materials.
http://nfctimes.com/news/besides-ms...-itself-apple-more-flexible-architecture-sams
Attachments
Read CAREFULLY. I did not say the iPhone communicates over a magnetic field. I said the contactless specification, whether implemented in a phone or physical card, has a mode in which the data transferred is identical to a magnetic stripe. The only security difference between an actual stripe and this mode, MSD, is that the CVV on the "stripe" changes every transaction. That way the contactless reader just feeds it into the POS system exactly like a magnetic stripe, so that the POS and backend does not need any changes. This means unless the terminal knows how to talk EMV over contactless, there is no security difference in Samsung MST and Apple Pay.
https://www.visa.com/chip/merchants...ast7/story_content/external_files/AI04336.pdf
This is a common misconception. Contactless does NOT mean EMV. If the store does not use chip cards (McDonalds), then the contactless system is using MSD.
Last edited:
So, again, is that to say it can do the same type of
But there is a difference between pretty much all terminals that Samsung Pay can communicate with (using MST, etc.) and the ones that Apple Pay can communicate with--as in there are those basic terminals where Samsung Pay can work just like a mag stripe card would work, while Apple Pay couldn't. Right?
Which is the point. Samsung Pay can be used at all terminals at the same security level as Apple Pay.
Apple thought everybody would switch to EMV and put in contactless terminals right around the liability shift deadline. We're T+1 year and it hasn't happened. The hardware is there, they haven't been activated. A big factor being that major merchants (Wal-Mart) wanted to hold technology hostage for lower interchange rates. And overseas, banks didn't want to give Apple any control of their cards.
The Apple Pay hack involves the wonderful flaw that some banks seem willing to authorize the provisioning of the device without any authentication. (http://info.rippleshot.com/blog/apple-pay-and-fraud-what-you-need-to-know)
That's just bad juju right there. If Samsung Pay is using a similar provisioning system and leaving it up to the banks to authenticate, it's not really any more secure. Since I could then provision either system with stolen CC information, depending on the bank. But it does sound like they probably do have some better guards in place to make it harder to provision from incomplete CC information (i.e. when missing the CVV), via rate limiting that Apple has yet to implement themselves.
So, I'm not really sure I'd call it "hacked" when it sounds like some banks aren't even bothering to lock the door. And other attempts to get CC info from users are social engineering attacks. But it should concern folks all the same. Now I'm curious how Samsung does provisioning...
Which is interesting. Good to know. I'm also seeing some interesting discussion on the format of the token itself though that then suggests it is not quite as random as expected (https://media.defcon.org/DEF CON 24/DEF CON 24 presentations/DEFCON-24-Salvador-Mendoza-Samsung-Pay-Tokenized-Numbers-WP.pdf). That, and some questions about how the token DB is stored on the device raise some interesting concerns.
Ignoring for the moment, that both technologies rely on inductive coupling, this argument could still be true. Except it assumes that NFC doesn't include its own encryption for the communication channel, which it does. This would be in addition to the actual encryption modes of the protocol using it. The EMV encryption is primarily to secure the datagram from the payment terminal itself. While the NFC encryption, which is separate, is aimed to protect against the eavesdroppers you mention.
But the problem with interacting with the stripe reader is that you cannot layer any encryption between it and the phone. You are entirely dependent on the tokenization system to protect you if someone has a means to skim the data. And if a skimmer can read a physical card, they will get your token as well. The bigger question is if the token scheme is good enough.
In the case of someone not actively watching the skimmer, meaning they miss the window to take advantage of the skimmed token to guess new ones, the answer is probably yes, it is good enough. But it is a chink in the armor. And you can't layer EMV into MST to guard against it. So there's simply fewer layers to deal with.
But going back to the original point where this started some posts ago, an app on iOS or even an iOS update won't be able to give an iOS device capabilities to work with these older terminals that the device doesn't have hardware abilities to communicate with.
Unsure what the point of this app is. Apple doesn't allow NFC privileges to their apps so this app couldn't of done much.
Sure: Apple Pay is not available in my country and won't be for years (if ever, with sub 5% iPhone market share). Samsung Pay is coming in a couple of weeks.
What you are saying is wrong. Payments for things that will appear on your phone and that are made on your phone have to go through Apple. "Samsung Pay" would not be affected by this whatsoever, as long as it is used to buy things that don't appear on your phone.
But there is a long list of guidelines that every app developer has to meet. Some might be "no mentioning of other operating systems". For example, if my "About" screen says that there is a version available for Android, that's rejected. The article says that Apple didn't state the reason for rejection which is clearly false; they stated the reasons for rejection _to Samsung_ because it is nobody else's business. I would be bloody annoyed if Apple told the world if and why _my_ app was rejected.
You make a totally unwarranted assumption here. The App Store has rules that any developer needs to follow to have their app accepted. Break any of these rules, and your app is rejected. Some breaches can be fixed easily, some are harder. Apple tells what rules were breached to the developer of the app, not to the world. So Samsung knows what the problem is. You don't.
[doublepost=1481638038][/doublepost]
Highly misleading what you are saying there, and you probably know it. Of course if I send you a message and say "burn after reading", that _is_ secure; I'll admit that.
[doublepost=1481638116][/doublepost]
Apple has less than 5% of the iPhone market share? Wow. Do you mean over 95% of iPhones are stolen from tourists?
[doublepost=1481638636][/doublepost]
No, that is wrong. Apple Pay always uses contactless payment. There _are_ indeed two modes: If the terminal is not clever enough, but accepts contactless payment with debit / credit cards, it works exactly the same with Apple Pay. Contactless payment has rather low limits: In the UK I think £30 per payment, £100 per pay. That's necessary because I could just pull your card out of your pocket and use it without having a PIN or anything. Apple Pay is more secure, but the terminal doesn't know that, so you have the same low limit. There is _no_ magnetic communication. And Apple Pay does _not_ give out your credit card number. The terminal sees it is a valid number, and the merchant gets their money, but nobody learns your credit card number.
If the terminal is clever, it can recognise your phone as an Apple Pay device, talk to the server, and allow you higher payment limits because it _knows_ the phone is more secure than a plain contactless card. The difference isn't that one is secure and one insecure, the difference is that in one case the terminal _knows_ it is secure and in the other case it _doesn't know_.
[doublepost=1481638829][/doublepost]
That is between Apple and Samsung. I think Samsung is free to publish the app rejection reasons, Apple isn't. It would be a huge violation of Samsung's privacy if Apple published this information. Maybe the reason is "crashed twice on three launch attempts". That's not something Apple is supposed to tell the world, only to Samsung.
Of course they do, at least in the same sense that Samsung Pau Mini would have, as various examples that have been provided throughout the thread have shown.
I'm not sure what you're trying to say here, but yes, where I live iPhone has sub 5% of smartphone market share.
Nope, the NFC payment comms are not encrypted. They're in the clear. That's why anyone can listen in on them.
But it doesn't matter, because the info is useless without knowing the secret key to recreate the per-transaction code. Only the Secure Element and the back end systems know this key.
(Ignoring extremely rare man-in-the-middle attacks, of course.)
True, but he's also right. There are two contactless transaction DATA formats. EMV and backward compatible MSD (Magnetic Stripe Data) mode.
Both modes are transmitted over NFC.
MSD transmits data similar to a card's magnetic stripe info, while EMV uses a later standard format. Both send dynamic verification codes to prevent replay attacks.
That's on top of the above modes, and is not limited to Apple Pay.
You're talking about the standard On Device Cardholder Verification flag, which any device can send during a transaction to tell an updated terminal that the device itself has verified the user's identity.
Remember, contactless Apple Pay is simply a rebranding of standard contactless card emulation. The actual transaction code is written and owned by the various credit card companies, not Apple. Terminals have no idea if they're being used by an iPhone.
Last edited:
I don't remember a court case that would generate any income for Samsung. Which one was that and how much did they gain?
That's not really how a legal system works. You either have a case and seek it through, and if you're right the court will confirm that. And if not, well, the opposite will happen. Legal departments don't save in legitimate claims until they talk to a competitor the next time.
Easy you are using common sense there again
. Since Apple didn't disclose why, we have no idea why or what caused it to be rejected.