I have an iOS application that will be distributed to multiple customers, each using their own network infrastructure. I would like to add some certificate pinning capabilities, but I need to do it in a dynamic fashion since I cannot ship the app with the cert/pubkey bundled, as doing so would require a different build for each customer.
My idea is to query the per-client configured HTTPS server on app startup, get the certificate, potentially extract the public key and then pin it.
Is it possible to do this in Swift or Objective-C? I have not been able to find relevant code samples or documentation.
Operationally, it will be a lot easier to manage and recover from misconfigurations if you embed the certificates or keys in the App. If you just pin whatever certificate the server sent to the App the first time, you have no mechanism to support a new certificate once the current one expires or gets rotated. If that's still what you would like to do, I would recommend looking at the HPKP specification, which implements the same mechanism but for browsers: https://www.rfc-editor.org/rfc/rfc7469
Also, if the App servers are not directly under your control, there is a high change that pinning will end up bricking the App, if the server's certificate unexpectedly changes. Will the team building the App be informed about infrastructure/certificate changes on the App/customer servers, so they can release an update just in time? If not, you should not do it.
Its possible. I haven't tried myself, but I think you are looking for something like this.
https://github.com/wultra/ssl-pinning-ios
Related
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.
UserDefault: Not appropriate for this case
String Constant: Not appropriate for this case. Can be reverse
engineer to retrieve or just use strings command
Secure Database: Store in Secure and encrypted Database. But again have responsibility to secure database username and password.
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.
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.
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
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
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
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
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.
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.
I have a requirement to remove all API keys and app secrets from the source code of the app we are building. Ideally the keys and app secrets should be sent to the app out of band as a configuration file, through an MDM solution.
Is this possible, and if so how? If not, what is the recommended approach to store this kind of information, such that it cannot be viewed in the source or extracted from the binary?
EDIT: Update
It is possible to send NSUserDefaults to the app via the MDM solution using Managed App Configuration. However, NSUserDefaults is not secure, easily viewed and modified by a casual user.
My plan is to encrypt the NSUserDefaults to prevent this using the common crypto library included in iOS. Is this the best approach to this problem? Should I also be sending a certificate as part of the MDM config?
Any thoughts, comments, and recommendations appreciated before I go too far down this route.
I know it's been a while, but I recently looked into this (not for an MDM application). I don't have any experience with MDM and that may have another solution. The route I chose to go was using CloudKit. It's a 1st party solution, always available whether the user is logged in to iCloud or not and you communicate securely with Apple's servers and only your App can access these keys.
Also depending how you set it up you can easily rotate out keys.
See more info here
We have an IOS app which connects to API/server through SSL connection. The SSL keys have been hard coded in the APP, the SSL certificate has expired and now the app is not functioning.
Q1. We want to avoid submitting the APP to the store as it takes upto 2 weeks to update the app.
Q2. We also want to get the SSL keys from CDN/store so that we dont hard-code it. But when we make the call to the store how do we ensure that its a secured connection?
What is the best way to get out of this situation?
I am sorry to say, but there is probably no way to do it except to upload new app. Here you can see how long it takes on average for users to get App approved - it is not as bad as 2 weeks, it can be much shorter (especially if it is update, those usually take less time from my experience)
So for the second question, I would advice you not to do it. Those keys should be present on the device, and you would have to update the App with new codebase anyway.
You can as well update the key and then, later, update the key in advance if you need to (it does not expire every month, and if you have production application, you will probably update it from time to time).
If you really need to download the key, then probably most secure way how to do it would be to encrypt the key on server side, send it to device and decrypt on device (possibly using AES128, 256 or something similar). You can also use signed download links with expiration time to add extra layer of security (fe. amazon S3 buckets provide that functionality).
Hope it helps!
I think you can use Google Tag Manager. You can publish new certificate through GTM instead of resubmit new ipa.
I am trying to implement SSL mutual authentication in an iOS app.
In most of the examples that I have seen, the client certificate is bundled with the application package. But in my case, I need to load the client certificate remotely (i.e, from a link or via email).
If I try to load a certificate from an external source (i.e, mail app), it navigates to settings app and install it to the apple's keychain. So this certificate is not accessible with my app.
So anyone please suggest an idea for this ?
I built a system like this in our internal iPad app.
Forget the System preferences, profiles, etc. All certificates installed in this way are inaccessible to third party apps but only to the system apps, probably because are installed into the Apple keychain.
I have explored these three methods to load the certificate and used the last one:
Bundle into the app, as you have already seen is impractical
Send a file from another app (e.g. email)
Use a link to download (what I did)
FOREWORD
I think you have built your simil-PKI, with a CA, an automatic/manual way to issue/revoke certificates, etc.
So the problem is the delivery to devices.
For all the solutions I suggest to save the private key and cert in PKCS #12 format with a strong password.
Use an MDM to manage the devices and if your app is internal and will be used with company's devices supervise them for added options
(e.g. Meraki, is free but do not handle the ManagedAppConfiguration)
SOLUTIONS
Solution 1)
Impractical because is very hard (to impossible) to generate different versions of the app with specific certificates. Not to mention that will be nearly impossible to handle the distribution of a specific version on every single device of the users.
Solution 2)
Save the .p12 file
change the file extension to a custom one
register that extension to open with your app, so in the "Open in..." will be listed your app
"Open in" for specific document type
The safest way should be that the user can select the password to encrypt the .p12 file so when the p12 will be opened the user must enter his password but this lead to other work to make it work.
A less safe but working method is to use a single strong password embedded in the app and use that for all .p12 files
Solution 3)
Similar to 2) but you download the file directly from a specific URI of your web application, this allow some automatic configuration because the app can identify himself.
Basically these are the steps:
the app connects to a specific URL of our application via HTTPS.
checks that the server certificate is correct (trusted origin).
send something to authenticate.
In our case I use the device name that I set up during device preparation and I can change it remotely using MDM.
download the configuration bundle with the certificate in it
I use a JSON payload to send the PKCS #12 file base64 encoded and other data to config the app.
If your MDM supports ManagedAppConfiguration you can change a bit these operations to build a more flexible behavior:
With ManagedAppConfiguration you can send a specific string inside every app NSUserDefaults remotely, so you can use a different or temporary URLs/tokens to download the config bundle and ditch completely the use of devices name for authentication.
WWDC 2014 #704 - Building Apps for Enterprise and Education ~13:00
Apple Developer - ManagedConfig Sample App
ADDED PARANOIA
log everything! Everything that this part of the app does (failed/wrong requests, not existent device names requests, etc)
the configuration URL is activated/deactivated only when we need to configure new devices.
You can done this a lot of ways, my webapp checks for the presence of a specific file so I can do something like touch APP_CERTIFICATES_CONFIG_ENABLED to activate the auto-configuration service and disable everything deleting the file.
Just to be sure that no certificate will go around without my supervision.
We are developing an iPhone application as well as an iPad application.
Both of them do have different Bundle Identifieres but should receive Push Notifications.
The certificates are generated like documented in apples programming guide.
So, due to the fact that we do have four ceriticates (APNS-Dev-iPhone, APNS-Prod-iPhone, APNS-Dev-iPad, APNS-Prod-iPad) I am wondering how to combine those certificates into one file?
The problem is, that on the backend side we are only storing the device token of a user. It is easy to decide whether we are working in development mode or not,but how should I decide which certificate to use - the ipad one or the iphone one?
Due to the fact, that we only have the device token, we do not know if the user is using the iPad application or the iPhone one, so we cannot assume which certificate to use when connecting to the apns apple server.
Any suggestions on how to handle this issue? Should we store more information - for example the device the user was sending the device token from? Or is there any easier way to combine all the certificates into one file and send it over to the apns apple server?
Thanks in advance, I would appreciate any help!
I have a similar issue and have not found a solution that I find satisfactory.
The way that we handle it is similar to what tGilani described. We have to store some kind of identifier that distinguishes which certificate to send a notification through for a particular device token.
Our issue goes further in that we might possibly have to send notifications to different applications altogether. These applications will probably be on a per tenant basis. Thus creating a universal application and one certificate will not work for us.
It would be terribly convenient if I could find a way to combine multiple p12 files into one jks and continue to use one of the Java PNS or Java APNS projects to send notifications.