Welcome to my blog post

Many Apple fans love Apple because of its purity and security. We found that downloading apps on Apple devices does not trigger the downloading of a series of junk software. Users can also identify the source of the App — whether it is purchased through the official AppStore, installed with a corporate certificate, or downloaded from TestFlight. To prevent piracy, virus attacks, silent installs, and other factors beyond your control, and to ensure that every app installed on an iOS device is officially approved, Apple has set up an app signature mechanism.

A digital signature

A digital signature, also known as a public key digital signature, is a string of digits that can only be generated by the sender and cannot be forged by others. The sender marks the signature mark on the data to be sent to indicate that the data has been authenticated and not been tampered with.

The data transfer

Here is a simulation of the data transfer process:

  1. If the sender directly transmits the original data in plaintext to the receiver, the data is very insecure and easily tampered with.

  2. To improve security and simplify plaintext, the data can be hashed to obtain a summary of the original data, which can then be sent to the recipient. However, if the hash algorithm is leaked, there is still a risk of data tampering;

  3. The asymmetric encryption algorithm is introduced. After calculating the abstract with hash algorithm, the RSA private key is used to encrypt the abstract, and the digital signature of the original data is obtained. The sender sends the digital signature together with the original data to the receiver.

We call the original data hashed and asymmetric encrypted data digital signature.

After receiving the data, the receiver needs to perform signature verification to ensure that the data has not been tampered with during transmission.

Digital signature verification

The steps for signature verification are as follows:

  1. After receiving the data, the recipient uses the same hash encryption to process the original data and get the hash value (digest).

  2. Then the checksum hashes (abstracts) in digital signature are decrypted by asymmetry.

  3. Finally, the two hashes are compared to determine whether the data is tampered with.

The complete process of restoring a digital signature with a single image:

Let’s take a look at how to use digital signatures to ensure that every App installed on iOS is approved by Apple.

Code signing

Code signature is the digital signature of executable files or scripts to ensure that the software has not been modified or damaged after signing. It works in a similar way to digital signatures, except that instead of signing data, you sign code.

Simple code signing

If the App is only available for download from the App Store, it’s easier to verify.

A pair of public and private keys is generated by Apple. A public key is built-in in the iOS system, and the private key is stored in the Apple background.

When we upload the App to the App Store, the Apple background signs the App data with the private key. After downloading the App, the iOS system verifies the signature with the public key. If the signature is correct, the App must be authenticated by the Apple background and has not been modified or damaged.

However, the App Store is not the only channel for iOS devices to install apps, such as developers’ real machine debugging, TestFlight internal testing, in-house enterprise certificate distribution, etc. In this case, simple code signature is not enough to fully verify the App.

The complexity of iOS code signature needs to increase accordingly, hence the emergence of two-tier code signature (double signature).

Double-layer code signature

The idea is to use two pairs of public and private keys, one native to the Mac and one provided by Apple services, for encrypted authentication.

Two-layer code signatures exist to satisfy:

  • Apps need Apple’s permission to install;
  • Only devices that have been registered with Apple in the background can be installed, such as in TestFlight test or real machine debug mode.
  • Restricted signatures can only correspond to unique apps.

To guess the full signature flow, we can extract an IPA file, and in the Payload directory there’s an embedded. Mobileprovision, which we call the description file, It corresponds to the Apple back-end generated Provisioning Profile (PP) file. The documents include:

  • Certificate (public key, signature)
  • App ID
  • Entitlements
  • Registered Device List
  • All other information about whether or not the App can start properly

So we guess the general process of signature is like this:

  1. Generate a pair of public and private keys locally on the development device Mac.

  2. Apple has a pair of public and private keys, Apple’s private key in the Apple background and Apple’s public key on every iOS device.

  3. Upload Mac public key to Apple background, sign Mac public key with Apple private key, you can get a Mac public key and signature combined data, we call this data certificate.

  4. Application App ID in Apple background, configured UDID (registered device) list and Entitlements for App (Entitlements), plus the certificate in Step 3, combined data signature with Apple private key, the data and signature together constitute PP file, Download it to your local development device, Mac.

  5. When we compile the project, the Mac private key signs the App and packages the PP file obtained in Step 4, called Embedded. Mobileprovision, ready to install the App on the phone.

  6. During installation, the iOS system obtains a certificate and uses the built-in Apple public key to verify whether the signature in the certificate is correct.

  7. Continue to verify that the description file is correct with the Apple public key.

  8. Verify that the App signature is tampered with the Mac public key.

The steps above correspond to the actual operation and concept like this:

Step 1: Open “Keychain Access → Certificate Assistant → Request a certificate from a Certificate Authority…” on the Mac. , do this step, will be locally generated a pair of public and private key, CSR export file (CertificateSigningRequest. CertSigningRequest) is Mac public key, Mac private key is stored locally, what is the specific file in step 3.

Step 2: Every iOS device already has an Apple public key. See Step 3 for the Apple private key.

Step 3: In the Apple background iOS Certificates module, upload the locally exported CSR file to generate the. Cer certificate file, which is also the Apple private key. You can export the Mac private key, which is a.p12 file, by downloading the.cer certificate locally, installing the certificate, and finding the certificate in the keystring. This corresponds to the Mac public key exported in Step 1, and the key string associates the two certificates. Use the. Cer certificate to sign the CSR file and get the signed certificate.

Step 4: Configure App ID, Entitlements, Devices, etc., in Apple background, and then download PP file.

Step 5: When compiling the App, Xcode will use the certificate downloaded in Step 3 (with the Mac public key), find the corresponding Mac private key locally, and then use the Mac private key to sign the App. At the same time, the installation package contains PP files. The file name in the IPA is embedded. Mobileprovision. The signature data of the App is divided into two parts. The Mach-O executable will write the signature directly to the description file, and the resource file will be stored in the _CodeSignature directory. Then the App will be installed.

Step 6: Verify the description file signature with the Apple public key. Corresponding to Step 4, if the signature passes, the certificate is available. Go to the next step.

Step 7: Use the Apple public key to verify the certificate signature. If the signature passes in step 3, the Mac public key is valid. Go to the next step.

Step 8: Using Mac public key to verify App signature corresponds to step 4. After all the above verification is passed, the content in the description file needs to be verified and compared with the information of App itself, such as whether the device ID is in the UDID list and whether the App ID is the same. Permission switch is consistent with Entitlements, are verified through, can begin to install App.

As mentioned above, two-layer code signature is a process of signing and verification for developing test packages, in-house enterprise signature and ad-Hoc package. However, enterprise signature does not limit the number of devices installed, so there is no device list In the description file. Instead, it is a

ProvisionsAllDevices

record.

However, there is no description file in the installation package downloaded from the App Store, but you still need to configure the certificate and PP file before launching the App, because the App ID and permission check still need to be done. However, after the App is uploaded to AppStore, it has nothing to do with PP files. Therefore, we can understand that the signature verification of the package on AppStore adopts the simplest signature method mentioned above. Apple background can directly sign the App with the private key.