Apple’s needs

  1. To ensure security, all apps installed on the iPhone must be authorized by Apple
  2. Installation packages can be installed without uploading them to the App Store.
  3. Prevent abuse of certificate permissions: additional permission controls such as device restrictions, designated APP, iCloud/PUSH/ background running

Apple’s solution: double layer code signature + description file:

Draw a picture here and attach:

Code signing

To achieve verification, the simplest way is that Apple officially generates a pair of RSA public and private keys. A public key is built into iOS system, and the private key is saved by Apple background. When we upload APP to APP Store, Apple background encrypts APP data with the private key. The iPhone downloads the APP and verifies the signature with the public key to determine whether the APP has been approved or tampered with by three parties. However, the APP Store is not the only way to install apps, such as real phone debugging, enterprise packages, etc., so it is not enough to rely on this simple digital signature method.

We all know that iOS apps must be developed on the Mac, and it’s this dependency that gives rise to the two-layer signature:

  1. Generate a pair of public and private keys for an asymmetric encryption algorithm on the Mac (Xcode will do it for you)
  2. Apple itself has A fixed pair of public and private keys, as mentioned in the simplest code signature above: private key A is in the Apple background, and public key A is in every iOS phone
  3. Send the public key M and some developer information (CSR file) to apple background, use the private key A of Apple background to sign the public key M, and get A data containing the public key M and its signature result is the certificate (.p12).
  4. During development, we will use the local private key M (that is, developer certificate that can be exported to partners) to sign the APP when packaging. Meanwhile, we will package the certificate obtained in the third step into the APP, and then install it on the mobile phone (real phone interplay) or submit it to the APP Store for review
  5. During installation, the iOS system obtains the built-in public key A to verify the digital signature certificate of public key M
  6. After verifying that the public key M is authenticated by Apple, the public key M is used to verify the signature of the APP, which indirectly verifies that the installation of the APP is approved by Apple (note that only the installation behavior is verified here, not whether the APP has been modified, because the content of the APP is always changing during the development stage).

The above process can already ensure the developer’s authentication and program security, but if there is only the above process, then just apply for a certificate can be installed on all iOS devices? So Apple adds the Provisioning profile validation. A Provisioning Profile typically consists of three things: a certificate, an APP ID, and a device.

The description file is created on the AppleDevelop website (fill in the AppleID in Xcode and it will create it for you), and Xcode is packaged into the APP when it runs. In development, you compile an APP, sign the APP with the local private key M, and pack the Provisioning Profile from Apple’s servers into the APP called Embedded. Mobileprovision. When the APP is installed on the phone, iOS verifies it.

The above is the principle of iOS application signature, the next article WILL be based on this principle to hand you a script for automatic re-signing.