Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
While the Device Account Number is not particularly sensitive, the keys that are used to generate the one-time security codes and encrypt the NFC cryptograms absolutely are.
Nobody was talking about NFC, obviously a chip is required for this and the 5s doesn't have one. However, for in-app Apple Pay, Apple didn't have to conform to any standard, they could have developed any mechanism they wanted, including one that stores encrypted keys or tokens in the regular key chain. It would still be PCI compliant, which is all that matters for such payment processes.

No they could not. The Secure Element is a specialized certified chip that meets the requirements of payment industry standards. It actually does a lot more than just store credentials. It is also a secure execution environment for Java Card-based payment applets and performs various cryptographic functions.
Which is completely irrelevant and also circular reasoning. You cannot dismiss an option because it lacks some obsolete features (like a Java execution environment) of another option. Instead you have to judge by initial requirements, and a certified cryptographic processor is definitely not a requirement for in-app payment.
 
Nobody was talking about NFC, obviously a chip is required for this and the 5s doesn't have one. However, for in-app Apple Pay, Apple didn't have to conform to any standard
I don't think the banks would have agreed to support the system and grant Apple Pay the lower card-present rates if it did not support the payment industry standards. And it does not matter if you are talking about NFC or in-app transactions. In both cases the Secure Element makes sure that the sensitive key material cannot be tampered with by the host CPU. Just the transmission channel for the cryptogram is different.
Which is completely irrelevant and also circular reasoning. You cannot dismiss an option because it lacks some obsolete features (like a Java execution environment)
Uhm, the banks' payment applets that Apple Pay uses run in that "obsolete" environment.
Instead you have to judge by initial requirements, and a certified cryptographic processor is definitely not a requirement for in-app payment.
Says who? What you are proposing is essentially something like HCE, and we know this is less secure and hasn't been granted the same low fees.
 
I don't think the banks would have agreed to support the system and grant Apple Pay the lower card-present rates if it did not support the payment industry standards.
I don't know what you're talking about. There are no payment industry standards for in-app payments. Besides, rates don't matter for Apple, they can pass them along to the merchant. They could have acted as PSP and killed Stripe etc. because they can easily negotiate better conditions, and, at the same time, provide easier integration for app developers on all iOS devices.

----------

Uhm, the banks' payment applets that Apple Pay uses run in that "obsolete" environment.

They do? With what kind of secure input for authentication? (PIN)
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.