Ios Code Signing

iOS Code Signing

Developing iOS apps can be fun. You can play with animations, experimenting with code architecures, trying out different components from UIKit or 3rd party. But if you’re serious about it you will want to test it on a physical device, send it for beta testing or upload to the App Store. This requires your app to be code signed - by you and by Apple. iOS devices simply don’t run unsigned code (unless they are jailbroken). This is when developers encounter problems.

The whole process of signing an app is a bit fuzzy and if you’re dealing with that for the first time the frustration is almost certain. But if you understand how it works and you’re in control of the process, then this can become even fun (or maybe not).

In this article, I’ll try to explain a bit of the inner workings so that the next time you deal with code signing you have a better picture of what’s going on.

Certificate

Why do you think we need a certificate? Do we even need it? Let me ask you another question: would you buy a hamburger not knowing with what meat it was made? I assume that your answer is “I wouldn’t buy it” and that you prefer to know at least the basic information like whether it is pork or beef and maybe even know in which country the animals lived.

Something similar happens when users enter the App Store and search for an app. They need to know that they are not downloading a virus and who is the developer. This is why you need the certificate. You request it from Apple and once you have it you can sign your apps. Now people looking at your app know that you’re the author (technically you can still upload a virus but you will be legally responsible for it).

What is a certificate? A certificate is a public key combined with additional information that was itself signed by Apple. Okay, but what is a public key? I’m glad you asked.

Public and private keys

There are two different types of cryptography: symmetric cryptography and asymmetric cryptography.

With symmetric cryptography, there’s only one key. You use that key to encrypt and decrypt a message. In order another person to read your messages, you need to share your secret key.

With asymmetric cryptography there are two keys - a public key and a private key. The public key can encrypt a message. The private key is used for decrypting a message. Security then depends only on keeping the private key private, and the public key may be published without compromising security.

Code signing relies on public-key cryptography based on the X.509 standard. On Mac OS X, the main utility to manage certificates is the Keychain Access app. To issue a certificate from Apple Developer Certificate Authority you need to generate a request (a .certSigningRequest file) and upload it to your developer account’s certificates. Apple will generate a certificate for you and you can download and save it in your Keychain Access app. See the instructions on how to create a certificate signing request for more details.

To generate the certificate signing request (CSR), Keychain Access app first generates public and private keys that are saved to your keychain. The private key is used to sign the request file to prevent 3rd parties to obtain a certificate on your behalf. Once the CSR file is generated and uploaded, you can download your certificate. When downloaded, double-click it to add it to your keychain.

It is important to mention here that you need to keep safe your private key. The private key is in the core of everything and without it you cannot use your certificate neither your provisioning profiles. You can export it and save it to a flash drive dedicated for keeping your key. To export your key from your keychain, right-click the private key and choose “Export “ and choose Personal Information Exchange format (.p12). You will be asked to enter a password to protect this file. Once you are done, anyone who has the p12 file and the password will be able to install the private key into their own keychain.

So far so good. You’ve generated the public and private key, the certificate signing request, uploaded the request and downloaded the certificate issued by Apple. Let’s take a look at App IDs.

App IDs

When you create a project in Xcode, you are asked for a Product Name and Company Identifier. For the product name, you usually give a shortened version of your app (such as myapp), and for the company identifier you usually give a unique string for your company (reverse DNS notation works well, such as com.mycompanyname). These combine to form the Bundle Identifier, found in the “-Info.plist” file in your project.

An App ID is simply this same Bundle identifier here, along with a prefix of random characters. It looks something like “EHGK3498DL.com.mycompanyname.myapp” forming a unique identifier for your application. For every app you release, you need to register your App ID in the iTunes Developer Center and it needs to match what you have set in your Info.plist. Another type of ID that you will need to sign your app is a device ID or UDID.

UDID (Device ID)

A UDID is a unique identifier for each physical device. Your iPhone is guaranteed to have a different UDID than your iPad, for example. It is usually displayed as a 40-character hexadecimal string. When you want to get code on a device through means other that the app store or enterprise distribution this is the way you identify each device that your code is signed to run on. If you want to install an app you make on a device, you need to know that device’s UDID! But how can you find a device’s UDID? There are several ways.

Provisioning profile

When you combine the certificate, the App ID and the Device IDs you get the provisioning profile. A provisioning profile is a container for the information needed by the operating system to decide if it can let your app run. The provisioning profile accompanies the device either by being copied into Xcode or iTunes and from there onto the device, or by being part of a “.ipa” archive containing both app and profile.