34

When we talk about securing iOS application we often forget to secure most critically sensitive information such as secret, key, token, encryptionKey. This information is stored in iOS binary. So none of your server side security protocol will help you.

There are lots of suggestion that we should not store such information in the app but store in the server and get it via SSL secured web service call. But this is not possible for all application. E.g. if my application does not need web service at all.

In iOS app we have following option to store information.

  1. UserDefault: Not appropriate for this case
  2. String Constant: Not appropriate for this case. Can be reverse engineer to retrieve or just use strings command
  3. Secure Database: Store in Secure and encrypted Database. But again have responsibility to secure database username and password.
  4. KeyChain: Best to store critical info. But we cannot save information before installing the app. To store in the keychain, we first need to open the app, read from some source and store in the keychain. Not appropriate for our case either.
  5. Custom Hash String Constant: Not to directly use secret, token, key from service provider (mixpanel, paypal), instead use hash version of that information from custom key. This is also not perfect solution. But add complexity during hacking.

Kindly send some awsome solution to this problem.

Unknown
  • 97
  • 1
  • 2
  • 8
Rajan Twanabashu
  • 4,586
  • 5
  • 43
  • 55
  • 1
    I don't know of a solution without a server getting involved. In the end, you'll always need some kind of a secret (private key, secret hash, etc...) to decrypt whatever information you put in your app. The only way I know of ensure this information reaches your app and only your app is using Apple Push Notifications, since that service guarantees only a trusted endpoint can receive your payload. Unfortunately that requires a user to enable push notifications for your app. – dirkgroten Mar 30 '17 at 08:40
  • can be one option. – Rajan Twanabashu Mar 30 '17 at 08:42
  • 1
    It would be good if iOS and Android provide a native facility for this (e.g. an extra encrypted payload that an app fetches from the App store where you as a developer have control) that can only be decrypted by the app itself and can't be accessed via the binary package. – dirkgroten Mar 30 '17 at 08:51
  • That's what I am expecting. Till then we are making un-secure apps by the way. – Rajan Twanabashu Mar 30 '17 at 08:53
  • Maybe this could work? 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. – Lobsterman Apr 07 '17 at 17:26
  • ^ attribution: 1. http://stackoverflow.com/questions/4015163/how-to-securely-include-secret-key-signature-in-ios-cocoa-apps 2. http://stackoverflow.com/questions/36465226/using-in-app-purchases-as-a-means-of-preshared-secret-distribution?rq=1 – Lobsterman Apr 07 '17 at 17:26
  • Also, if you go the obfuscation route this library seems quite effective: https://github.com/UrbanApps/UAObfuscatedString – Lobsterman Apr 07 '17 at 17:39

6 Answers6

31

If you don't want to use your own backend then use Apple. You can configure On Demand Resources and keep data file with your key, token, any secret on Apple server. After first download you can write this data to Keychain which is secure enough. I'm guessing networking between iOS and Apple server is also secure enough.

On-Demand Resources Essentials

Accessing and Downloading On-Demand Resources

Michał Myśliwiec
  • 896
  • 6
  • 10
  • 1
    Would those secrets, say an API key, be protected from an attacker who is operating the app and the secrets are being stored to their keychain? – xref Apr 23 '20 at 18:22
5

1) Internet Connection Required

1.1) Push Notifications Great way to have a secure data exchange could be to use (silent) push services from Apple, those use the apns and send data through https - more Details 3.1

1.2) A more or less similar approach is also used when distributing new user certificates to already deployed applications, if a reinstall of the application is no opportunity AND the application requires a working internet connection anyway.

Downside: working network connection required and basically the information is coming to the application, when it is already being executed => seems not to be appropriate for your case. (see step 4)

2) Static data (as there will be no exchange without network connection / communication partner)

Encryption of data with private key being provided in the bundle itself. Whether it is now a string or a hash, which can be reverse engineered with functions you got emebedded in your application. Since iOS9 it is pretty hard to decompile iOS applications and basically you will mainly have a look into the provided header-files. So if you had such a function, string, hash value or whatever, make sure you got it in your .m-file!

But again: if the information is not device or user specific, just a secret across your own micro environment, valid across all devices, you would have to provide the encrypted data AND the decryption method in the same bundle, if there is no update process / information exchange or something else, you can think of.

Good for encryption: iOS System.Security https://developer.apple.com/reference/security or simply openssl

The difference between your described keychain approach is: You got a value, which WILL be encrypted and stored securely. (2) describes the approach to have an encrypted and stored (in bundle) semi secure value, which WILL be decrypted

3) Information exchange

You describe critical data, which was hashed by another instance. Great! - Make sure, relly make sure, the instance you are talking to is really the instance you expect to be (Network Hooking prevention with ssl certificate pinning etc, but even here you might have intruder (men-in-the-middle)). And you will (probably) have a certificate being provided in your application bundle, to ensure the authenticity of the communication server - here you go again, data that is supposed to ensure a secure process between certain instances of your micro environment. Nevertheless, this data is being provided in your application's bundle.

3.1 Secure Information Exchange extended - Silent Push Make use of Apple's servers to exchange your secrets for this purpose. If you just need to exchange small data chunks. I would recommend to use silent push notifications to the user, those do even work without explicit permission from the user. Huge advantage: In case your secrets or keys change, you can inform users as soon as possible about the change. They will likely only need the change, when they receive new data, which should reliably work in most cases. Exception: Data exchange in local networks or via bluetooth, in this case I would recommend to provide a notification to the user to have the requirement to update a local decryption key. Or exchange the key in this format as well. Once again: I am leaking some detailed information about your environment architecture. Downside: You don't know, whether a user just used your app for the first time, until the user "tells" you so. https://developer.apple.com/library/content/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/APNSOverview.html#//apple_ref/doc/uid/TP40008194-CH8-SW1

3.1 Secure Information Exchange extended - In App Purchase Use a frree In-App Purchase for the user to get the data to your phone. Good point here: you can provide larger data chunks easily, as this should be an active request by the user, the user does expect certain processing time and should also be aware of the fact to require a working internet connection. Downside: User would have to select this on purpose. Up until then the app would not work accordinly. https://developer.apple.com/library/content/documentation/NetworkingInternet/Conceptual/StoreKitGuide/Introduction.html#//apple_ref/doc/uid/TP40008267

So, it just slightly differs from the approach (2) in its basic idea.

In short: Can you provide additional information, what kind of data you need to encrypt/want to store securely and whether you will have a network exchange or not?

Would need some more information here :-)

I would like to emphasize once again that an application on iOS is not that easy to decrypt anymore, even decompiling would not get everything, you expect it to get. For instance decryption tools like dumpdecrypt were only working properly up until iOS 8.4

Lepidopteron
  • 6,056
  • 5
  • 41
  • 53
5

It seems to me that the best way to do this is using the built in CloudKit. You can save your secrets in the CloudKit Dashboard and then fetch them on startup. Since CloudKit is only a transport layer you'll have to store the app secrets in the KeyChain.

I know you mentioned the KeyChain not being ideal for your use case (not sure why), but this is a good way of not including the secrets in your app. You can't get around fetching your app secrets from another source.

CloudKit access is secured using the system iCloud account and if there is no iCloud account you still access the iCloud servers securely. Another added benefit of this is that you can change your app secrets at any time, so if you want to be even more secure you can implement a rotation schedule.

Learn more about CloudKit

derickito
  • 695
  • 7
  • 25
  • Is it safe to save it in public database in CloudKit Dashboard ?, I notice I cannot access private database in my code ! or is there a better way ? – Basel Jan 30 '23 at 12:31
  • 1
    Only your app has access to the "public" database. No one other than your app can query the container. You should not use the private database because you as a developer don't have access to write the initial secret in the private database. Only the app has access to the private database, so you would have to some how provide the secret to the app in order to write it to the private database and then you're right back where you started. – derickito Feb 02 '23 at 03:19
2

I agree with @Lobsterman and believe that the best way will be to use a combination of these.

  • Don't include the secret information in the app initially.
  • Deliver the secret key either as in-App purchase content ,on-demand resource or send it through push notification. This will add the benefit of changing the key periodically if you want and the change will take effect without any additional effort.
  • Add the entry to keychain access once the content is delivered.
JIthin
  • 1,413
  • 1
  • 13
  • 29
2

Cocoapods-keys might be a best option.

From cocoapods-keys doc's

Key names are stored in ~/.cocoapods/keys/ and key values in the OS X keychain. When you run pod install or pod update, an Objective-C class is created with scrambled versions of the keys, making it difficult to just dump the contents of the decrypted binary and extract the keys. At runtime, the keys are unscrambled for use in your app.

The generated Objective-C classes are stored in the Pods/CocoaPodsKeys directory, so if you're checking in your Pods folder, just add Pods/CocoaPodsKeys to your .gitignore file. CocoaPods-Keys supports integration in Swift or Objective-C projects.

Check out this link for installation, usage and more info : https://github.com/orta/cocoapods-keys

Ravi
  • 2,441
  • 1
  • 11
  • 30
0

If the data is extremely sensitive then it should never be stored offline on device because all devices are crackable. If you still want to store on device then keychain is one option for storing data securely, However it's encryption is based on the pin code of the device. User's are not forced to set a pin, so in some situations the data may not even be encrypted. In addition the users pin code may be easily hacked.

A better solution is to use something like SQLCipher which is a fully encrypted SQLite database. The encryption key can be enforced by the application and separate from the user's pin code.

msmq
  • 1,298
  • 16
  • 28