I was unable to find a way how to install certificates on my iPad to a keychain using iTunes (or other tool that runs on mac os x).
I need to be able to set the group (kSecAttrAccessGroup, eg. "XKFABCDEFGH.com.mycompany.myapp") to store the certificate under. Since there is a chain of certificates, I'll be installing all of them up to the root one. Also, the last (leaf) certificate will have private part (don't know if that makes any difference).
The alternative to this is to write a small app and compile the certificates as its resources. Then I can use SecItemAdd / SecItemUpdate to write those certificates. Downside to this is that I want to install different certificate on every device, so I'll have to compile the app several different times.
Note: The app is to be a B2B, eg. not an application for public iTunes market!
Edit: I want to use the certificates ASIHTTPRequest, I do not require that those certificates are recognized by the iOS itself (unless it will collide with the ASIHTTPRequest library).
Related
I've noticed something somewhat strange when I ran the Xcode build of my app and then launch the app store build. If I run the xcode build (using development certificates), then run my app through the app store (using production certificates) I get prompted with the following dialog box
MyApp want to use your confidential information stored in "com.myApp in the keychain.
I also get this dialog when I run the app store build first, then the Xcode development build. I believe this dialog appears because both builds have different certificates (could be wrong).
My biggest concern is the user updates the app, will the user see this dialog?
Not sure if this is important, but this is how I save data to the keychain.
[[A0SimpleKeychain keychain] setString:string forKey:#"key"];
Apple's code signing guide has the answers.
I believe this dialog appears because both builds have different certificates
Correct. See Understanding the Code Signature:
The most important internal requirement is the designated requirement, or DR. This rule tells an evaluating system how to identify a particular piece of code. Any two pieces of code that have (and successfully verify against) the same DR are considered to be the same code.
...
Some parts of macOS do not care about the identity of the signer. They care only whether the app is validly signed and stable. Stability is determined through the DR, and does not depend on the nature of the certificate authority used. The keychain system and parental controls are examples of such usage.
From Code Signing Tasks:
Shipping and Updating Your Product
The user’s system considers the new version of your product to be the
same program as the previous version. For example, Keychain Services
does not distinguish older and newer versions of your program as long
as both are signed and the unique Identifier remains constant.
Signing your code with a different certificate makes the system consider it a different app. As long as you sign your releases with the same certificate between versions, you will be fine.
I changed the info.plist file in Boot Camp package to make it support making USB installing drives on my Mac, but on Mac OS X Mavericks the app crashed before I signed the new file. I use the following code in terminal to sign it.
sudo codesign -fs - /Applications/Utilities/Boot\ Camp\ Assistant.app
After signing the code, the app ran successfully. The whole tutorial is here: Enable Bootcamp to install from usb for OSX 10.9
BUT I am wondering why I can sign the code so easily, without any formal certificate. I think code signature is a security feature. Only developers with certificates can sign their codes and distribute them, and Apple only allow these signed programs to run: About Code Signing I am a beginner on this topic; can someone explain the process a little bit? Does this means that hackers can sign whatever codes they want (maybe malicious ones) and run them AS LONG AS they get the password for root account?
Then I changed back to the original info.plist and wanted to remove the signature for the file that I created. How do I do this?
Thanks!
The reason is because you are signing the package with a local certificate. When Apple sign the package, it will run on any Mac, as their root certificate is trusted in the base OS.
If you transferred your locally signed package to another mac, you would find that it crashes, because it was signed with a certificate from another machine.
Hope this clears it up.
How can I run my app on physical iOS device without apple developer programm? I read some tutorials but there are only for jailbroken devices.
It's not possible to run apps on an iDevice without an official Apple certificate, because you have to sign the app.
A solution is, to jailbreak your phone and sign it yourself (you already found the tutorials), so you just need AppSync to run them.
Somehow I got the certificate on my phone with my Apple Id, and I haven't actually paid for it yet, and I run it every day on my phone. I'm pretty sure you can get the certificate without having to pay for it, you just have limited options in app capabilities(No access to platforms like GameCenter without paying).
I'm working on an iOS enterprise app that relies on an Configuration Profile being put on the phone. Unfortunately, the user can "cancel" this profile, which really screws with our app.
So I was wondering if a) is it possible to prevent a configuration profile from being deleted OR
b) is there a way to check to see if a configuration profile is installed already (say, at runtime, then we can just install it again if it's not there)?
If you want the configuration profile not to be tampered with / disabled by the user, this is possible! If you're using Apple Configurator to build your .mobileconfig file in the generals tab select security as never. Be aware: once the profile is installed on the device it cannot be reverted unless you restore the device
The long story short is there is no current documented way to even programmatically call / install a configuration profile (.mobileconfig) file onto the device: so if you're thinking about checking whether the profile exists and if not to install it, it's impossible (as for available documentation thus far) - if you do find a way let me know
Note:
.mobileconfig files can only run through Safari / Mail.
This similar SO discussion may help: Installing a configuration profile on iPhone - programmatically
It is possible to check is .mobileconfig is installed.
What you need to do is:
Create CA (certificate authority) and export it as .cer.
Issue certificate using created CA and export is as well as .cer.
Using Apple Configurator app add CA .cer in the certificates area.
Mobile configuration profile will have CA .cer.
Issued certificate (on step two) add to app bundle.
Using Security framework evaluate (SecTrustEvaluate) issued
certificate on step 2.
I am developing a proof-of-concept tool for an internal research project.
We have specific needs which can only be met by running our application as a system app, like the Settings or Phone app.
Am I right in thinking that the only way to run an application under the system user (uid=1000) is by setting the following in the manifest:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.frogdesign.desktop"
android:sharedUserId="android.uid.system" >
and signing my application with the platform certificate?
If so, for a given phone, e.g. Galaxy S, this would require us to sign using Samsung's certificate. Not going to happen, right.
So if we root the phone and stick something like cyanogenmod on it, would the required certificate be cyanogenmod's platform certificate?
Is this generally made available?
I am fairly confident that you would not be using the manufacturer's key. On my Galaxy S, the Gmail app is a system app, and you can update it from the Android Market (i.e. it's signed, if it is at all, by Google and not by Samsung).
If the phone is deodexed, you should be able to just move the app to /system/app/ (or /system/priv-app/ on newer OS versions). This requires a rooted phone, so that you can mount the system partition as writeable. This is in conjunction with your manifest settings, of course. I'm not sure if that's sufficient, since I haven't done this myself, but it's something to try.