Menu
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?
413
A provisioning profile specifies a Bundle Identifier, so the system knows which app the permission is for, a certificate, with the information who created the app, and it's defined in which ways the app can be distributed.
A provisioning profile is a collection of information that links an App ID with signing certificates and authorized devices. It is used to control and authorize the devices on which the app can run and the Apple services it can access (such as iCloud or In-App Payment).
Your Apple ID identifies your team and/or you as a developer. The App ID identifies a specific application or extension and the reference to the signing certificate identifies it as yours. The Provisioning Profile brings all the above together and identifies where and how this app can be distributed.
Using certificates with Apple devicesThese digital certificates can be used to securely identify a client or server, and to encrypt the communication between them using the public and private key pair. A certificate contains a public key, information about the client (or server), and is signed (verified) by a CA.
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.
80
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:
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.
45
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
