Certificates, Provisioning Profiles, public/private keys demystified

Question

This topic continues to confuse me. I thought I'd write out my current understanding and hopefully find out the things I'm right about/things I'm wrong about.

When you create a development certificate, there is a concept of a public and private key. The certificate available thru the provisioning portal holds on to a public key, while your private key is stored within your keychain. In order to code sign your app, you've got to have both.

In order to run an app, the device must have a provisioning profile, which essentially holds on to an app identifier, a set of recognized certificates (the app must've been signed by one of these certificates), and a set of device identifiers (which indicate which devices are allowed to run the app).

The 'recognized certificates' have references to the public key, while the private key is essentially passed on by the app.

Thus, with regards to the App Store, we can think of a normal device as coming with a default prov profile that already has apples 'public key' and apple performs their own code sign operation before distributing whereby they add their private key.

Perfect? Close? Way off? Insane?

Answer 1

Ray Wenderlich has it explained reasonably well here. To improve your description, instead of

The 'recognized certificates' have references to the public key, while the private key is essentially passed on by the app.

I would say:

The app .ipa includes a developer certificate. The developer certificate is signed with your private key - as well as with the official Apple private key.

Thus, by verifying the developer certificate with Apple's and your public keys, the iPhone can verify that:

• you are the developer of this app
• you have been certified by Apple for app development
• this app is allow to be run on the iPhone (as long as there is a provisioning profile on the phone that refers to this developer certificate).

Your private key is not stored in any of the certificates or profiles, it is only used for signing. Not sure whether the public keys are stored. In order to be fully secure, the phone should fetch the public keys from Apple when verifying.

Answer 2

For what it's worth, here is my updated understanding:

A Provisioning profile is a file that tells you which apps (via an AppID), signed by which developer (via the certificate) can run on which devices (the UDIDs).

With certificates, there is a concept of a public and private key. Public and private keys are mathematically linked such that one can encrypt the plain text, and one can decrypt the cipher text. Certificates allow apple to ensure two things: 1, that only registered developers can distribute their code, and 2, that the code that is being distributed isn't altered on its way to your device.

When you build your code in Xcode, you 'code sign' your application with the private key located in your keychain, thereby 'locking' it. In order to unlock/decrypt the code, the destination device must have access to your public key. The device gets the public key from your certificate that is included in the provisioning profile.

In order to verify that the code remains unchanged on its way from the developer to the device, your certificate includes an algorithm that can convert your code/data into what is known as a 'digest.' On the developer side, the data/code is run thru the algorithm, generating into a separate digest, which is then locked with the private key.

When the app package is received by the device, the device can ensure the code hasn't been altered by doing the following: unlocking the digest with the private key, running the unencrypted data thru the algorithm (remember, the device can access the cert thru its prov profile), and making sure the result is a digest identical to the one sent over from the developer.

Beyond that, the prov profile need only check the UDID of the phone, and make sure the AppID from the profile matches the identifier in the app.

The reason we don't need separate prov profiles for apps from the appstore, i assume, is because each iPhone ships with the public key used by apple to code sign distribution apps.