I'm building an iphone app that needs to access a web service over https using client certificates. If I put the client cert (in pkcs12 format) in the app bundle, I'm able to load it into the app and make the https call (largely thanks to stackoverflow.com).
However, I need a way to distribute the app without any certs and leave it to the user to provide his own certificate. I thought I would just do that by instructing the user to import the certificate in iphone's profiles (settings->general->profiles), which is what you get by opening a .p12 file in Mail.app and then I would access that item in my app. I would expect that the certificates in profiles are available through the keychain API, but I guess I'm wrong on that.
1) Is there a way to access a certificate that I've already loaded in iphone's profile in my app?
2) What other options I have for loading a user specified certificate in my app? The only thing I can come up with is providing some interface where the user can give an URL to his .p12 cerificate, which I can then load into the app's keychain for later use, but thats not exactly user-friednly. I'm looking for something that would allow the user to put the cert on phone (email it to himself) and then load it in my app.
I've tried with this:
NSString *thePath = [[NSBundle mainBundle] pathForResource:#"certificate" ofType:#"p12"];
NSData *PKCS12Data = [[NSData alloc] initWithContentsOfFile:thePath];
CFDataRef inPKCS12Data = (CFDataRef)PKCS12Data;
CFStringRef password = CFSTR("pass");
const void *keys[] = { kSecImportExportPassphrase };
const void *values[] = { password };
CFDictionaryRef optionsDictionary = CFDictionaryCreate(NULL, keys, values, 1, NULL, NULL);
CFArrayRef items = CFArrayCreate(NULL, 0, 0, NULL);
SecPKCS12Import(inPKCS12Data, optionsDictionary, &items);
inPKCS12Data is correct but items is empty. What is happening?
I've done this for a recent app by making the documents folder for the app accessible via itunes. Our users are then instructed to drag their generated key (in a p12 format file) into the documents panel for our app in iTunes. When the app is started, it checks for the existence of the p12 file and, if it exists, imports the file into the keychain.
It's not the simplest procedure, but it is the most secure because you don't have a private key file being sent around via email.
If a .p12 file isn't too big you could encode it using Base64 and then embed a link in an email with a custom url scheme, e.g.:
myapp://certificate/<base 64 data>
User clicks the link, your app saves the certificate somewhere for future use. Just make sure that Mail.app on the iPhone won't mangle the email.
Apple does restrict the use of device-wide keys/certificates to it's own applications/services, such as WiFi, VPN, Mail, etc. Third-party applications are not able to use any of these keys/certs (without jailbreaking). However, applications are able to import, store, and use keys and certificates in a in-app keychain. In addition, you can share keys/certs across multiple applications with the keychain-access-group feature in iOS.
I recently published a blog post titled In-App Mobile Certificates Made Easy with mCMS, which may have helped you out. Our company is developing an API that makes it easy to support in-app certificates, obtained directly from your Microsoft-based PKI. Our solution also offers on-device key generation, instead of generating a P12 on another machine and trying to import it into your app.
If you're using AirWatch for app distribution, their SDK provides the ability to provision certificates from your Certificate Authority to your registered devices. This allows you to provision your certs, and then access them from your app's code.
Does the code suggested in Finding a Certificate In the Keychain work for you?
Oh man, this brings up painful memories from October/November 2009. I was able to successfully get client-side certs to work but I had to port libcurl to the iPhone (which wasn't easy since the NDA was still in effect at the time).
I haven't done iPhone app development in over a year so I don't know how much is changed, but if I were you I'd first try to get by without client-side certs and if you absolutely must have them you can use libcurl with PEM formatted certs.
Related
I am creating an application which is like a template where every service provide can enter their details in the setting on the web and just change the app name ,app icon, new bundle identifier and upload the app on app store.
Till here it was good, But the problem for me is that I have a push notification services in this app.
And I have read on the apple document that every bundle identifier should contain a unique push certificate. And from there we create a .pem file, so that means every app will have a different- different pem file.
But I want a single pem file which will work for all app.
Can anybody please suggest me what should I do, or what is the proper way to go about it?
Unfortunately, what you are asking for is not currently possible with Apple Push Notifications Service. Though you could conceptually use several of the optional arguments in openssl to generate a Certificate Signing Request (CSR) using the exact same keypair, the root issue comes from the 'Certificates, Identifiers, and Profiles' tool in the very first step in creating a new APNS certificate:
As the supplemental instructional text reads: "Note that only explicit App IDs with a specific Bundle Identifier can be used to create an [sic] Push SSL Certificate", which means that we can neither provision a Wildcard App ID for push notifications, nor can we specify 'All App IDs'.
If we briefly step into a hypothetical world where the "Which App ID would you like to use?" question doesn't exist and instead went directly to the step where we upload our CSR, the certificate we would get back from Apple would do exactly what you want -- It would authenticate the server you use to construct APNS payloads as one legitimately belonging to you and authorized to send pushes to the APNS Gateway. It does, however, open an important security concern -- If you can use this one server (or 'provider' in APNS parlance) to send pushes to any of your apps (so long as you know the device's APNS token), what prevents you from using your provider to send pushes to my apps? Or if we turn the concern around -- what would prevent me from using my authorized APNS provider to send your apps push notifications? Or to send pushes to your customers with misinformation (ex. 'Regrettably MyApp is closing its doors and exiting the App Store. MyApp recommends customers purchase CompetitorApp to maintain your service!'). This slimy, scam-prone world we thankfully don't live in...
Instead, Apple requires 3rd-party developers to select the AppId for which payloads from a particular APNS certificate will be honored. Then even if I somehow manage to acquire your customer's app's device token, I won't have your server's private key and thus could not successfully deliver a scam, spam, or otherwise rogue APNS payload to your customers.
Ok, I got it already! Since I can't use a single certificate for multiple App IDs, what can I do?
Given some of the background in your question, it sounds like you've put in the effort to make your app highly configurable. In your own words "[it] is like a template" - which would suggest that on the server-side of your app, you have some mechanism in place to be able to be able to identify what app is making data requests and which provider's data to send back. Your APNS Provider logic would need to have similar intelligence built in. Depending on how you are currently making these server-side distinctions, you may be able to reuse some of the existing logic; you are the one who will have to make that call. The remainder of this answer will offer a high-level approach to how you might choose to setup your provider owing to the one-pem-per-app requirement APNS imposes. In general:
Place a copy of the signed .pem in a secure location on your APNS Provider
Update your Provider's 'register device token' API to accept both the device token as well as some way to uniquely identify the app for which this token is valid (...maybe as simple as just the App ID itself!)
Update the iOS App to pass both it's APNS device token and that App Identifier to the freshly updated 'register device token' API on your provider.
Update your Provider's logic to use the correct .pem when delivering a payload to the APNS Gateway.
For the sake of good process, ensure that you have a procedure to update or retire an application's .pem, data, and relevant tokens.
For each app that you make from your template, you already have to generate a unique App ID and App Store Distribution provisioning profile. When doing this initial setup, you can also request the APNS certificate and treat all three pieces of data as app-specific settings. Install the APNS certificate into your provider along side the .pem file for your other apps so that you can grab it when it comes time to send an APNS payload to Apple.
If you've done APNS work before, you know that your provider is responsible for tracking app-specific device push tokens, generating and transmitting the APNS payload to Apple, and optionally using information from the APNS Feedback API. When your app connects to your provider to register its token, you'll also need to know for which app that token is valid so that you can select the right .pem for sending APNS payloads. This is key; if you don't have a way to know which tokens go with which App IDs then you will be unable to select the right .pem file during payload generation and dispatch.
Updating and retiring software is a key part of all software, but is one that doesn't always get the attention it should. Make sure you've considered how you'd go about refreshing the .pem file (which you'll have to do each year before the current one expires) as well as how you'd go about retiring an application without disrupting the other apps your provider services.
The answers to each of these questions is very much dependent on how you've architected the various components of your app, Xcode project configurations, server-side technologies, and server-side logic. Only you, or your team, can make the right call based on the details that make up your software. Best of luck and let us know how things go.
Can 3rd party application access iPhone's keychain in order to add X509 certificate to it? If yes, how can it be done?
If not, can it access keychain just to read certificates from it?
Basically, what I need is:
1) my application needs to access https site which uses certificate not signed by any trusted CA. when trying to connect via https, I get an exception.
2) it would be great If I could programmatically add the root's certificate to the keychain; it would be sufficient if the user could access the site via Safari, accept its certificate, and then access the site using my application.
So far, I've been using the following interface to surpass https:
#interface NSURLRequest (DummyInterface)
+ (BOOL)allowsAnyHTTPSCertificateForHost:(NSString*)host;
+ (void)setAllowsAnyHTTPSCertificate:(BOOL)allow forHost:(NSString*)host;
#end
but this is not exactly what I want.
Any suggestions?
This Apple document should document enough stuff to permit adding self-signed certificate (or a self-signed certificate authority) into the keychain, and make it trusted. I didn't test it, though. Source
See also the top answer on this question. It, however, doesn't seem to actually verify the validity of the certificate. Cocoanetics has also documented how to use NSURLConnection with self-signed certificates, and similarly also doesn't seem to verify the validity.
So, you almost certainly want to follow Apple's instructions. The "Extracting and Evaluating an Identity From a *.P12 file" section appears to contain a complete example on how to import a certificate, even one protected with a passphrase.
Combine that with "AdvancedURLConnections" sample code and the ServerTrustChallengeHandler class and you should be good to go.
Here's also a more complete example by Vanja Komadinović.
I am planning to store a password in my Native app (Android and iPhone). Should I store them after encrypting it ? or can I store it without any encryption? Are they really secure?
Any jailbroken iPhone will give any user access to the application's Documents folder. So, yes, it's insecure.
Additionally, if you put the password inside the code, you're still weak, as someone can decompile the program and find the key. What I'd recommend is a proxy.
For example, we have an application that connects to Facebook's API on the phone. However, we don't want to store our Facebook API private key on the phone, because then any user who reverse engineers our code could hack our Facebook application!
So, instead, we store the Facebook private key on a (secure) proxy server. When the device needs to interact with Facebook, it contacts the proxy, asks the proxy to log-in, and then the proxy gives a session key to the device to use directly with Facebook.
Certainly, it's still hackable - but you won't lose your private key in the process, and instead, the only thing your user could do is do the same things you do in your proxy server API.
Could you give us a little more information about what you're trying to do?
I would store it encrypted.
If someone would read your password he/she could simply use it. If it is stored encrypted, that person would need to decrypt it before usage.
Stored passwords are not safe at all. Determined user can root it's device and access any database and preferences. If you encypt password, your application can be decompiled to get decode function or step-executed until decrypted password is stored somewhere in process memory.
It doesn't mean you shouldn't encrypt passwords - use any symmetric encryption and initialise key in some non-trivial way (i.e. arythmetic expression). This will prevent script-kiddies and casual programmers from reading passwords. Just remember if some really want them, he will get them anyway.
I am trying to verify the user identity on my application using a certificate / identity that the user has stored by opening a .cer / .p12 attached to an email. The certificate appears on the settings app of the phone under the group "Configuration Profiles".
Is there any way of accessing the certificate using the iphone SDK (I have tried to use the Security Framework, but it seems that it is only possible to access certificates stored in the application keychain or other keychains from its group)?
You talked about the Security framework already, but did you try the following functions in the doc?
I personally never tried/had to do this myself, but anyway it seems that there are some functions like SecCertificateCreateWithData in the framework, so you should be able to build a SecCertificateRef from some NSData/CFDataRef… data which is the content of your mail attachment.
From there you may use it as any other certificate using the other functions (like you would do for a certificate extracted from the Keychain)
Well this is only a guess after simply reading the documentation but let's give it a try as the doc seems to indicate it is the way to go.
Is there any way to bundle a certificate in my application - and then use that to perform HTTP GET/POST using a NSURLRequest?
I.e. the certificate should not be used for other HTTP traffic on the device, only by my application.
Cheers
I don't believe so, but since all applications are sandboxed any special authentication measures you may have within your application cannot be accessed by other applications.
Best (in my opinion) you put the private key and certificate that you want to use on the keychain (or keychains of other 3rd party apps that share the same provisioning certificate).
As for the actual loading of the p12 we do use openssl (we did write a obj-c wrapper around it) to decode the .p12 that we send to the app (you can always use .DER or .PEM to ship the p12 with your app)