Demystifying iOS App Signing: From RSA Basics to Provisioning Profiles

Introduction

iOS signing involves many concepts—certificates, provisioning profiles, entitlements, CSR, p12, AppID—and is prone to errors. This article builds the theory step by step to help understand the signing principles and workflow.

Purpose

Before iOS, most operating systems allowed software to run without signatures, leading to piracy and lack of control. Apple introduced signing to guarantee that every app installed on iOS is explicitly authorized by Apple.

Asymmetric Encryption

Digital signatures rely on asymmetric encryption. Symmetric encryption uses the same key for encryption and decryption, while asymmetric encryption uses a public key and a private key. Data encrypted with the public key can only be decrypted with the private key, and vice‑versa.

RSA, a common asymmetric algorithm, works as follows:

Choose two prime numbers p and q and compute n = p·q (e.g., p=61, q=53, n=3233).

Select a random prime e between 1 and n (e.g., e=17).

Through a series of calculations derive d such that the pair ( n, e) forms the public key and ( n, d) forms the private key. Deriving d from n and e requires factoring n into p and q, which is computationally infeasible for large keys (1024‑ or 2048‑bit).

The public key is ( n, e) and the private key is ( n, d). Knowing only the public key makes it practically impossible to recover the private key.

Digital Signature

Using asymmetric encryption, a digital signature is created by:

Computing a short hash (e.g., MD5) of the original data.

Generating a public‑private key pair; the private key is kept secret.

Encrypting the hash with the private key to produce the signature.

Sending the data together with the signature.

The receiver decrypts the signature with the public key to obtain the hash and compares it with a freshly computed hash of the received data; a match confirms integrity and authenticity.

Because asymmetric encryption can only encrypt data up to the size of the key, the hash is used instead of the whole file.

Simple Signing Model

Apple can generate a key pair, embed the public key in iOS, and keep the private key on its servers. When an app is uploaded to the App Store, Apple signs the app with its private key; iOS verifies the signature with the embedded public key, ensuring the app is Apple‑approved and untampered.

However, iOS supports three additional installation methods that require more complex signing:

Direct installation of a development build for debugging.

In‑House enterprise distribution.

Ad‑Hoc distribution with a limited device list.

New Requirements

These methods need two guarantees: the installation must be Apple‑approved, and it must not be abused. Apple therefore adds two constraints: only devices registered in the Apple portal may install the app, and the signature must be tied to a specific App ID.

Final Workflow

The complete process involves:

Generating a local key pair (L) on the developer’s Mac.

Apple’s own key pair (A) with the private key on Apple’s servers and the public key on every iOS device.

Sending the local public key L to Apple; Apple signs it with its private key A, producing a certificate.

Creating an App ID on Apple’s portal, configuring device IDs and entitlements, then bundling the certificate into a Provisioning Profile signed by Apple’s private key A.

After building the app, signing it locally with the private key L and embedding the Provisioning Profile (named embedded.mobileprovision) into the app bundle.

During installation, iOS verifies the Provisioning Profile’s signature using the built‑in public key A.

After verification, iOS uses the embedded public key L to verify the app’s signature and checks that the device ID, App ID, and entitlements match the data in the Provisioning Profile.

Key Concepts

Certificate : Contains a public or private key signed by a certificate authority.

Entitlements : List of app permission switches.

CertificateSigningRequest (CSR) : The local public key submitted to Apple.

p12 : Exported private key that can be imported on other machines.

Provisioning Profile : Bundles certificate, entitlements, device list, and is signed by Apple’s private key.

Other Distribution Methods

Enterprise (In‑House) and Ad‑Hoc distributions follow similar steps; the main difference is that enterprise builds do not limit device count but require the user to manually trust the enterprise certificate.

App Store builds differ because the final binary does not contain an embedded.mobileprovision file; Apple re‑signs the uploaded binary with its own private key, and iOS validates it with the built‑in public key. Nevertheless, developers still create certificates and provisioning profiles for App Store submission to embed entitlement and App ID information.

After an app is on the App Store, the original certificates and provisioning profiles no longer affect the installed binary, even if they expire or are revoked.

Open Questions

The article ends with several discussion points about enterprise certificates, App Store encryption, and why Apple requires local private keys instead of providing them directly in the provisioning profile.