Our team is developing a payment infrastructure that provides for payment via smartphone with NFC technology.
For Android no problem as we used HCE; while as far as iOS is concerned we have come to the conclusion that the best solution, given the strong limits on NFC technology imposed by Apple, is the use of NFC-enabled Passes.
We have collected several information unfortunately very fragmented as on the net and on the Apple documentation itself not there is a lot of space on the deepening of this type of Pass. I know the implementation is under NDA, but we need to understand which way follow in order to at least start the tests.
With regard to the above, I list the points that are vital for the continuation of the work:
We have already requested the NFC certificate through the
appropriate form but we have not received any response yet. There is
a way, a particular form that the request must have or a sum to be
paid so that the request for the certificate can be processed
faster?
When the certificate is obtained, how should it be used? As already
mentioned, the implementation is protected by NDA, in fact I was
interested understand who I should talk to or how to get Apple's
documentation.
I thank in advance to those who know how to answer these doubts.
You are right, the entire process is under NDA.
I applied, like yourself and also reached out to a Developer Evangilist in Apple. I was told that the process was outside of their control and that you just had to be patient.
When you get the certificate from Apple, it will include an entitlement that enables the NFC support. I believe you just use the cert as normal when creating the pkpass bundle.
As I understand it, Apple will provide all the instructions to you if they approve your NFC request.
You can embed information within the pass that is sent via the NFC tag.
I’m afraid I can’t be more helpful.
Related
I understand that Apple Pay is not supported in India right now.
But my question is that is it still possible to buy a payment terminal machine (from link 1) and :
Use it in VAS terminal mode (see DETAILS) so as to only accept NFC enabled Reward pass and not card based payments(as card based Apple payment is not supported in India). NFC based Reward passes are stored in your Wallet App.
The actual use case would be:
I received a NFC enabled Reward Pass from a link and I added it to my Wallet App.
I went to shopping and I found a payment machine which process Apple NFC enabled reward passes. (Is this point possible in India??)
Once I go near to payment machine, I get a popup to redeem points from my reward pass and payment processed successfully.
So is above mentioned points valid for locations where Apple pay is not available??
DETAILS:
The value added service (VAS) protocol was designed by Apple to facilitate reward transaction via NFC between Apple devices and your NFC-enabled payment terminals.
Link - 1
https://www.apple.com/shop/product/HJG42LL/A/groovv-terminal-one-for-emv-nfc-credit-card-processing?fnode=23b4a7a08c47611ff86f9981ac0098a185f7e6472777fa7b19d5eafc4dc8d6a600744123b6171a9a429fc1270993dc691e1e83cfd59327246cdcb7b5ff4d676a65dab4b9c428b2152ce6c5556729815278037d2998fde0331cfcdd7230fcbab6e0c16a3fe76de671f2388b0af2769020
Yes, what you describe is possible, but there are many many hurdles to overcome before it could be realised.
Firstly, you need to obtain an NFC pass type certificate. These are issued at Apple's discretion and have proven to be a little difficult to get, especially in territories where Apple Pay is not yet available.
Next, you will need a terminal that can communicate with the device using Apple's proprietary VAS protocol. Obtaining the protocol is even trickier than obtaining a certificate, but it is possible. However, the Merchant's existing NFC terminals would need to have their firmware replaced which in many cases is impractical as the hardware is often owned by the banks and may require PCI re-certification after the firmware is changed.
Alternatively, you may build your own dedicated terminal but then you may need to bear the cost of providing merchants with your hardware and they may be reluctant to have another device on their countertop and to provide staff training to be able to use it.
Finally, whatever hardware you implement will need to have an API to hook into the merchant's point of sale system (PoS), and the PoS will require a reciprocal API and functionality to conduct the loyalty transaction.
So, in summary, it is technically possible but practically close to impossible to implement without the cooperation and commitment of a major player in the retail, banking, or merchant acquiring sector.
We currently have both VAS capable hardware and access to NFC certificates but are facing the above challenges in several territories, both with and without Apple Pay.
Apple's iOS in-app purchase system has been attacked in the past by people who have tricked apps into giving them content for free. They have since improved the systems involved to try to limit this kind of thing.
I've read through the StoreKit reference documents available from Apple and I have a general idea of the workflow and the checks that need to be done, and so on. However, there may be security issues that I'm not aware of.
Can anyone provide a full list of theft-attacks that can be attempted against In-App purchase mechanisms, how developers might mistakenly allow these attacks, and what are best practices for preventing them?
These are the attacks that I am aware of, past and present:
Fake App Store
Made famous by the Russian programmer Alexey Borodin, this attack only affects apps that verify purchase receipts directly with the App Store. By modifying the DNS settings of the device, and installing forged security certificates, the verification requests are sent to a fake App Store server, which automatically returns that the purchase is valid. Unsuspecting apps will accept these verification calls and deliver the content to the user.
Commentary
After this exploit was made known in July of 2012, Apple issued updated documentation and advice for developers to ensure this kind of attack would not continue to occur. Borodin has been quoted in various web articles as stating that the "game is over" based on Apple's updated APIs and best practices guidelines.
Prevention
Apple has an entire document dedicated to this loophole here. (EDIT: Link is down, Wayback if you want...although the document covered iOS 5.1 and earlier.) The biggest point they bring up is having your app send the receipt to an external server that you own, and then having your server verify the receipt with Apple. However, if you do send the receipt directly from the app to the App Store, they recommend the following checks:
Check that the SSL certificate used to connect to the App Store server is an EV certificate.
Check that the information returned from validation matches the information in the SKPayment object.
Check that the receipt has a valid signature.
Check that new transactions have a unique transaction ID.
Fake Verification Server
If your app sends the transaction receipts to your server, which then forwards them to the App Store, one option is for the attacker to fake your verification server. By some method (altering the DNS table, changing the URL, etc.) the receipt is sent to an alternate location and a "successful verification" is returned. In this way the receipt never reaches your server and you never have a chance to check it with the App Store.
Commentary
Apparently there are a variety of apps in the Cydia store that serve to run in the background, monitor receipt traffic, and redirect it for this purpose. Source: Hussulinux Blog
Prevention
If you immediately deliver content as soon as a receipt is verified, there is no known way to prevent this kind of attack. However, take this scenario: you have a user account system managed on your own server. If the purpose of the In-App Purchase is to notify your server that a particular user account has purchased an item, and the app downloads that item from your server, you are immune to the attack. Redirecting the receipt to another server will accomplish nothing for the attacker, because your server will never mark the user account as owning an item, as it never sees the receipt.
Fake Receipts
An attacker can fake the purchase process and then send a forged receipt to your verification server. Unlike the previous attack, the receipt's outbound location is not changed, but it is replaced with an imposter. This spoofed receipt is, in fact, a valid receipt from a previous App Store transaction, and the App Store will verify it as such. By faking the purchase process and then sending a spoofed receipt to your server, the content is never actually paid for.
Commentary
Apparently there are a variety of Cydia apps that do this sort of thing. You can spot fake receipts because their product_id is totally different from anything you use in your app. Apparently the most famous spoofed id is com.zeptolab.ctrbonus.superpower1. Source: Hussulinux Blog.
Prevention
In the link where I found this attack, the blogger recommended that you unpack the receipt at your verification server (base64_decode) and check the product_id before sending the receipt to the App Store. However, in this article Apple recommends that you first send the receipt to the App Store, and then read the returned information to be certain that the receipt is valid.
(Also, correct me if I'm wrong, but Apple's recommended technique could also be used to prevent this kind of attack even if you don't have a verification server. If your app sends the receipt directly to the App Store, it could examine the contents of the JSON response to ensure it's valid. But this goes against Apple's recommended best practices of using an external verification server, so I wouldn't advocate it.)
In Closing
These are the attacks that I'm aware of, feel free to correct me if I'm wrong on any point or to put forth additional attacks and fixes.
As a note, there's this website: http://www.in-appstore.com/ which claims to allow in-app purchases for free, either on iOS 5 or with a jailbroken iOS 6 device, and is active as of July 5th, 2013. While I'm not 100% sure how they are doing it, it definitely seems to involve DNS rerouting and faked security certificates, which would imply Fake App Store or Fake Verification Server, which would additionally imply that there are still apps out there that are not secured against these attacks.
Resources
Apple iOS in-app purchase hacking
My Experiences With Verifying In-App Purchase Receipts
How to detect "IAP Crackers"?
EDIT:
Additional
It seems like one or two people have swung by here and found this post useful, and I'm glad.
There's more information that can be had on this subject, either in other posts, books, or, if you're up to it, scouring the underbelly of the internet. Here's just a couple of websites and posts and so forth that I want to look into, but haven't had a chance yet. I'll add more links later when I find interesting tidbits.
http://www.se7ensins.com/forums/threads/tut-how-to-hack-ios-games-and-apps.701845/
http://www.iapphacks.com/
A couple of immediate takeaways: don't store your player's data in a simple plist unless you want it to be edited by some teenager. People don't have to hack your IAP system if they can just give themselves gold or something similar by editing the files on the disk. Perhaps by encrypting these files, you could discourage a certain segment of attackers.
Based on the se7ensins link, it seems as though an attacker can also pry apart your binary and mess with it to achieve the same ends as editing a plist file, or even more, but this will require a slightly higher skill level. Perhaps setting up jailbreak detection would suffice to deter most people who would resort to this.
Again, this section is mostly speculation, but it may help someone. Really, the level of protection you have depends on how far a developer is willing to go (down the rabbit hole of security and encryption) to protect their bottom line.
I have a requirement in which we need to programmatically set the date and time (or sync the time) from a server.
How is it done in iOS?
Is there any Apple documentation which says we cannot do this?
You can't set the date and/or time on iPhone/iPad programmatically. Those APIs are considered protected by Apple. In other words if you were to use those APIs and submit an app using them it would be rejected.
Edit:
To get documentation on this you can contact Apple Developer Technical Support using one of your free tech support incidents included with your developer program. LINK
As the comments to your posters are saying, you can't, because although there is an API to do that, it is "private" and can only be used by Apple. Thus, if you do this, Apple will reject your app because the use of private APIs is verboten on the App Store.
There is no alternative solution. You'll have to explain to your client that as a third party developer, you cannot change system settings, end of story.
Back last year, that russian hacker created a way to validate in-app purchases without payment and this guy created a class to verify each purchase.
As far as I know, this technique exposed by the hacker does not work on iOS 6 anymore, but I am not sure about that.
I am creating a new app for iOS 6 and trying to minimize the code to a minimum and even better than that, my in-apps involved hosted content with Apple, so I wonder if this added validation is really necessary for my case.
Remember that
I am developing for iOS 6 and up;
my in-apps have hosted content with apple, so even if the hacking technique works the person will never get the content hosted with apple.
any thoughts?
thanks.
The vulnerability should be addressed in iOS6, but that does not mean you should deviate from Receipt Validation best practices in general. See Verifying Store Receipts and
In-App Purchase Receipt Validation on iOS for more information.
As mentioned in the links above, Apple recommend you follow their best practices for receipt validation, be it on iOS 5 or iOS 6. "Simplicity of code" is not a good enough excuse to deviate from these guidelines. If you structure your code into well defined classes, you can abstract away all the receipt validation logic to its own class, making the code that uses it a lot cleaner anyway.
If you connect to the App Store directly from the App for validation, the measures they explicitly state (see "My app performs validation by connecting to the App Store server directly. How am I affected?") should help. If you implement them in an abstracted way (in a category or class), then it should still keep your code clean.
Even if your content is hosted by Apple, you're still giving yourself an extra safeguard against fraud. Apple are not perfect; they could slip up themselves leaving your app open.
Ultimately, when you're dealing with your own revenue, you better play it safe than be sorry afterwards.
I read (almost) all the answers on verifying in-app purchase, and actually I already implement it in a server-side fashion. But managing a server sometimes could be too much expensive, and in theory you could do the verify from your app: basically is just sending a json to Apple and get the answer back.
Of course I know that on jailbroken devices the receipts may be fake (that's why you verify them) but (I beg pardon my ignorance) why I can't trust an https connection to the Apple server?
I mean if the user hack my app, there's no real way to be sure of anything, but if the hack is a general method to provide fake receipts testing with Apple could be enough right?
To be clear, what is the security level of an in-app verify of recipts? Can it add some degree of protection os is useless?
This answer explains quite well why you must use server side checking to limit the effect of some "general purpose" crackers, like "IAP cracker"; besides chaining the iTunes json request in your content delivery API is quite convenient and the answer is fast.
Of course if your aim is to provide some content already in the app but locked, you may feel it is not convenient to setup a server specifically for this, but I will ask you to do this experiment:
make an app with some good content and this content already locked in the app (so no content server need)
add some analytics just to track the usage of this locked feature
after some month, compare the number of purchases with the number of new users using the paid feature.
at this point it will be clear for you that adding a server script just for receipt validation is a good investment; besides there are some services, which are very cheap (e.g.: urban airship) we already do this for you, so you don't need to setup an hardware for this.
I hack inapp cracker and discover a way to block it client side: the receipts and transaction IDs it creates have a predictable scheme that's easy to spot. I put all the details here:
spot fake receipts client side
update
hope this helps