How to securely include secret key/signature in iOS/Cocoa apps

Question

a long time ago I learned that this is a bad idea. Please don't try what I'm asking below

I want to include a secret key into an iOS app so that the app can "prove" to a certain server that a request is coming from the app itself and not some other system. I know that simply hardcoding a secret key into the code itself is very vulnerable as anyone can jailbreak their phone and attach GDB to my app's process to get the key. Are there any more secure ways of doing this? Is it possible of sufficiently obfuscate the key as to make this near impossible?

I believe that this is a similar problem to serial number validation. Unfortunately, that seems to get cracked regularly and easily. Are there any solutions to this?

All communication with my server will be done with HTTPS so at least sniffing/man in the middle attacks shouldn't be a concern.

Thanks, M

Answer 1

I have been wondering about this, too, and several potential solutions come to mind based around the premise that what you want is to get a user/pass secret key into your app's KeyChain (which is quite strongly secured by iOS and the hardware) and pull it for use as-needed:

1. distribute the secret to your app using an app-specific iCloud ubiquity-container. this data should be excluded from backup to the local computer and is purportedly securely transmitted using hardware-level security to only non-jailbroken applications. pro's: it's not in your application at initial distribution, so harder to uncover, iCloud requires a non-jailbroken device, you can update your secret and it will synchronize to all your apps. con's: it's not really in the secure KeyChain, which means that it can likely be sniffed out on the filesystem if iCloud syncs and then the device is jailbroken.

2. deliver the secret to your app as a piece of free app-store-hosted in-app purchase content. when it is delivered (securely by the app-store, only to non-jailbroken devices) to the app, transfer it into the keychain. pro's: it's not in your application at initial distribution, so harder to uncover, app-store requires a non-jailbroken device. con's: harder to change the secret for all of your installs quickly, even a free app-store purchase may require user authentication, which is troublesome UX.

An ideal solution would be if we could somehow bundle secrets (a KeyChain key/value dictionary) right into the app when we submit it for distribution, the app-store would strip these and deliver them securely to the OS for injection into the KeyChain during install, but out-of-band from the normal app bundle sync'd with your desktop machine and iTunes, and they would not appear in the binaries. Barring Apple adding such a feature, I think there is no truly solid solution, though.

• Update Jun'15: Until the astonishingly bad flaws in the security of the iOS (and OS X) keychain are resolved (see Unauthorized Cross-App Resource Access on MAC OS X and iOS) you can not use the Keychain to secure anything reasonably. Don't use it.

Answer 2

I'm afraid it's not possible to do that. But as far as I know apple will make sure no other app is spoofing your app's secret. If it's a jailbroken phone, then the user is in a way taking full responsibility, and possible damage should be limited only to the jailbroken phone user's data.

Answer 3

Since the attacker would be in complete control of the client, the only method would be security through obscurity. You can implement a challenge/response model, but you must make it impervious to many other factors (replay attacks, etc).

This question contains one approach to hide a secret key in binary code.

Don't assume that by simply using https you can't have packet sniffing. What if the attacker changed their URLs inside your executable to point to their server? Then they can act as a relay.

A better way would be to provide some identity management inside the app (user picks a username, password is user/machine generated), and use those credentials for your service calls.