My iOS app needs to store a pre-shared secret. It cannot embedded within the App Bundle itself because it could be extracted by statically analysing the bundle.

Apple's In-App-Purchase system allows an app to make a request to Apple. iOS should verify the authenticity of the app (as all apps are signed) - I realize that I could use this system to verify that the app is mine (and not an imposter trying to get the secret).

My app would make an IAP request to Apple, Apple then generates a cryptographically signed receipt and gives it back to my app, who then passes the receipt to my server which verifies Apple's signature and issues a new per-app-instance secret and returns it to the client (for storage in the iPhone Secure Enclave) where no other app can read it.

This system would break if an attacker could send their own receipts to my service. I understand the receipt contains the App Package/Bundle name which Apple asserts is correct, but I don't know how I would protect against an attacker performing a kind-of replay attack where they would get my app to make the IAP so the receipt is valid, but capture the receipt, pause my app process, then send the recipe from their app to my service (thus getting the secret).

What's a good solution to this problem, and could a jailbroken phone allow another app to masquerade itself as my app to Apple for IAPs?

  • Remember receipts and refuse identical ones repeating?
    – Natanael
    Commented Apr 7, 2016 at 20:12
  • @Natanael That doesn't help if a receipt is captured (and blocked) between my app and the webservice and then replayed by the malicious entity - my webservice would see it as a brand new receipt.
    – Dai
    Commented Apr 7, 2016 at 20:51

2 Answers 2


Your scenario where an attacker exchanges a valid receipt for secret data can be mitigated if instead of the server sending the secret in reply to a receipt, it delivers the secret to your app through other means. Apple's Push Notification services are a good solution, as they tie your server to your own apps (no other apps can receive your notifications, and your server can't send notifications to other developer's apps even if it wanted to, because the client certificate it uses to talk to Apple only allows it to send messages addressed to your own apps).

When your requests the secret data from the server, it sends the receipt as well as its unique device token that allows you to send push notifications back to it. The server then sends the secret data as a push notification. If size is an issue it can send a secret key that fits in the notification's payload, and the app then downloads the actual secret data by presenting that key in a subsequent request. An imposter app would not be able to receive the push notification because even if it submits its own token, Apple will not allow your server to send a notification to that app since it's from a different developer.

Finally, one question comes to mind, why are you doing this? If the secret data contains info about other users, then this is your main problem. Instead of trying to protect that secret data (which you can't from someone who has physical access to the device), just make sure that data doesn't contain anything sensitive about other people, and let the user do whatever they want with their data. If it's for DRM, keep in mind that tons of people have tried and failed, and no matter how smart you are, you cannot do the impossible. Why not focus your efforts on delivering an awesome experience to encourage people to pay instead of copying your content?


Any such system worth its salt (sic) will have a time based MAC (or at least an option to add one) for exactly this reason.

I can't comment specifically on Apple's service, but I know it's something which, for example, Azure offers for token based access to its cloud storage system... I even wrote a similar mechanism for protecting RTSP streaming commands for pre-release audio about fifteen years ago :)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .