IOS signature mechanism

IOS signature mechanism is very complex, a variety of certificates, Provisioning Profile,entitlements,certificatesigningrequest,p12,appid, concept of a heap, is also very error-prone, this article attempts to start from the principle, A step-by-step rollout of why there are so many concepts that hopefully helps to understand the principles and processes of IOS App signing.
Objective
Let's look at what Apple's signature mechanism is for. Before IOS comes out, developing and running software on the main operating system (Mac/windows/linux) is not required to be signed, software can be downloaded from anywhere to run, resulting in the platform for third-party software is difficult to control, piracy popular. Apple wants to solve this problem, in the iOS platform to the third party app has absolute control, make sure that every app installed on iOS is officially allowed by Apple, how to guarantee it? is through the signature mechanism.
Asymmetric encryption
Usually we say the signature is a digital signature, it is based on asymmetric encryption algorithm implementation. Symmetric encryption is the same key to encrypt and decrypt data, and non-symmetric encryption has two keys, respectively, the public key and the private key, the data encrypted with the public key, to use the private key to decrypt, with the private key to encrypt the data, to use the public key to decrypt.
Simply say the common asymmetric encryption algorithm RSA mathematical principles, understand the simple mathematical principle, you can understand how asymmetric encryption is done, why it is safe:
Select two prime numbers p and q to multiply to derive a large integer n, for example p = 61,q = 53,n = PQ = 3233
Choose a random prime number between 1-n E, for example e = 17
After a series of mathematical formulas, a number d is calculated to satisfy: a. After the two data of N and e are mathematically operated, they can be reversed by N and D, and vice versa. B. If you only know N and E, to derive d, you need to know P and Q, that is, you need to decompose the n factor.

The above (n,e) These two data together is the public key, (N,D) These two data is the private key, satisfies with the private key encryption, the public key decryption, or in turn the public key encryption, the private key decryption, also satisfies in the case that only exposes the public key (only knows N and e), to derive the private key (N,d), needs to At present, factor decomposition can only rely on brute force, and the greater the number of N, the more difficult to use the poor to calculate the factor p and Q, the more secure, when n large to binary 1024-bit or 2048-bit, the current technology to crack almost impossible, so very safe.

Digital signatures
Now that there is asymmetric encryption, what is the digital signature?
The role of the digital signature is that I mark a certain piece of data, that I endorse the data (sign a name), and then I send it to someone else who knows that the data has been verified by me and that the data has not been tampered with.

First, an algorithm is used to calculate the abstract of the original data. A. If there is any change in the original data, the calculated digest value will change. B. The summary should be short enough. The most commonly used algorithm here is MD5.
Generate an asymmetric cryptographic public and private key, I hold the private key, the public key is published.
A copy of the data, after the summary, with the private key to encrypt the digest, to obtain a copy of the encrypted data, called the original data signature. Send it to the user along with the original data.
After the user receives the data and the signature, the digest is decrypted with the public key. At the same time the user uses the same algorithm to calculate the abstract of the original data, compared to the summary calculated here and the public key to decrypt the signature obtained by the equality, if equal means that the data midway has not been tampered with, because if tampered with, the digest will change.

The reason for the first step is to calculate the summary, because the principle of asymmetric encryption limit can not be encrypted content is not too large (can not be greater than the number of bits above n, which is generally not greater than 1024 bits/2048 bits), so for any large data signature, you need to change its signature, the effect is the same.
Well, with the foundation of asymmetric encryption, knowing what a digital signature is, how to ensure that a piece of data is certified somewhere, see how the digital signature mechanism ensures that every APP installed on IOS is approved by Apple.
The simplest signature
To achieve this demand is very simple, the most direct way, the official Apple generated a pair of public key, in IOS built a public key, the private key is stored in the background of Apple, we pass the app on the AppStore, Apple backstage with the private key to the app data signature, IOS system download the app, use the public key to verify the signature , if the signature is correct, the app is definitely backed by Apple, and has not been modified to meet Apple's needs: to ensure that every app installed by Apple is officially allowed.

If our IOS device installs the APP only from AppStore download this one way, this thing is over, there is no complicated thing, only a digital signature, very simple to solve the problem.
But in fact, there are three ways to install an APP in addition to downloading from AppStore:
When you develop an app, you can install the app directly into your phone for debugging.
In-house enterprise internal distribution, you can directly install the Enterprise certificate signed APP.
Ad-hoc is equivalent to a limited edition distributed by the Enterprise, limiting the number of installed devices and less use.

Apple has a new need to control apps that are installed in these three ways, not as simple as it is.
The new requirements
Let's start with the first one, install the app at development time, it has two requirements:
The installation package does not need to be uploaded to the Apple server and can be installed directly on the phone. It is obviously unacceptable if you upload an APP to your phone before uploading it to the Apple server signature.
Apple must have control over the installation here, including a. After Apple allows it to be installed. B. Cannot be abused to cause non-developer apps to be installed.

In order to achieve these requirements, the complexity of iOS signatures began to increase.
Apple's solution here is to use a double-layer signature, which would be a bit more around, and the process might be:

In your MAC development machine generate a pair of public private keys, here called the public key L, the private key L. L:local
Apple has its own fixed pair of private keys, like the AppStore example above, with the private key in Apple backstage and the public key on each IOS device. This is known as public key A, private key A. A:apple
The public key l to the Apple backstage, with the Apple backstage private key A to sign the public key L. Get a copy of the data that contains the public key L and its signature, which is called the certificate.
At the time of development, after compiling an app, sign the app with the local private key L, and package the certificate from the third step into the app and install it on the phone.
At the time of installation, the IOS system obtains a certificate and verifies that the digital signature of the certificate is correct through the system's built-in public key A.
Verifying the certificate ensures that the public key L is Apple-certified, and then uses the public key L to verify the app's signature, which indirectly verifies that the app installation behavior has been officially permitted by Apple. (This only verifies the installation behavior and does not verify that the app has been altered because the app content is always changing in the development phase and Apple doesn't need a tube.) ）

Add something.
The above-mentioned process only solves the first requirement above, which requires Apple's permission to install, and does not solve the second problem of avoiding misuse. How to solve it? Apple added two more restrictions, one is to limit the apple registered in the background of the device can be installed, the second is to limit the signature only for a specific APP.
How do you add that? In the third step above, Apple signed our local public key L with private key A, in fact, in addition to signing the public key L, but also can add an unlimited number of data, which can be guaranteed by the official Apple authentication, there is no possibility of tampering.

You can think of the list of installed device IDs and apps corresponding to the AppID data, all in the third step together with the public key L to form a certificate, and then use the Apple private key A to sign the certificate. At the end of the 5th step verification, you can get a list of device IDs to determine whether the current device meets the requirements. According to the principle of digital signature, as long as the digital signature through verification, the 5th step here the device ids/appid/public key L are all Apple-certified, cannot be modified, Apple can limit the installation of devices and apps, to avoid misuse.
Final process
Here the certificate has become very complex, there is a lot of extra information, in fact, in addition to the device id/appid, there are other information also need to be here with Apple signature, such as the APP Icloud/push/background running and other rights Apple want to control, Apple put these permissions switch unified called Entit Lements, it also needs to be authorized by signature.
In fact, a "certificate" would have a specified format specification, above we put a variety of additional information into the certificate is not appropriate, so Apple has another thing, called Provisioning profile, a Provisioning profile Contains the certificate and all the additional information mentioned above, as well as the signature of all information.

Because the steps have small changes, here we do not hesitate to re-list the entire process:
In your MAC development machine generate a pair of public private keys, here called the public key L, the private key L. L:local
Apple has its own fixed pair of private keys, like the AppStore example above, with the private key in Apple backstage and the public key on each IOS device. This is known as public key A, private key A. A:apple
The public key l to the Apple backstage, with the Apple backstage private key A to sign the public key L. Get a copy of the data that contains the public key L and its signature, which is called the certificate.
In the background of Apple application AppID, configure the device ID list and the APP can use the permissions, coupled with the ③ step of the certificate, composed of data with private key a signature, the data and signatures together to form a Provisioning profile, download to the local MAC development machine.
At the time of development, after compiling an app, use the local private key L to sign the app, and package the Provisioning profile file from step ④ into the app with the file name embedded.mobileprovision and install the app On the aircraft.
At the time of installation, the IOS system obtains the certificate, through the system built-in public key A, to verify the Embedded.mobileprovision digital signature is correct, inside the certificate signature also will examine again.
Ensure that the data in the embedded.mobileprovision is the Apple authorization, you can take out the data inside, do a variety of verification, including using the public key to verify the APP signature, verify that the device ID is on the ID list, whether the AppID corresponds, whether the permission switch with the APP Entitlements correspondence and so on.

Developer certificate from signature to certification eventually Apple takes the process roughly the same, and there are some details like the certificate validity period/certificate type and so on.
Concepts and actions
The steps above correspond to our usual specific operations and concepts such as:
The 1th step corresponds to the "Request certificate from a Certificate authority" in keychain, where a bunch of public private keys are generated locally, the saved Certificatesigningrequest is the public key and the private key is stored on the local computer.
2nd Step apple Processing, no tube.
The 3rd step is to upload the certificatesigningrequest to the Apple background to generate the certificate and download it locally. At this time there are two local certificates, one is the 1th step generated, one is downloaded here, Keychain will associate the two certificates, because their public private key is corresponding, in Xcode choose to download the certificate, will actually find the corresponding private key in keychain to sign. Here the private key only generates it for this Mac has, if other Mac also want to compile signature this App what to do? The answer is to export the private key to other Macs, export the private key in the keychain, it will be saved as a. p12 file, the other Mac opens and imports the private key.
The 4th step is to operate on the Apple website, configure AppID/permissions/devices, and finally download the Provisioning profile.
5th step XCode will download the certificate from the 3rd step (with the public key), locate the corresponding private key locally (generated in the first step), sign the APP with the local private key, and name the Provisioning profile Embedded.mobileprovis Ion pack it in together. Here the signature data of the APP is saved in two parts, the Mach-o executable will write the signature directly to the file, and the other resource files will be saved in the _codesignature directory.

The package and verification of step 6–7 is something that Xcode and IOS systems do automatically.
Here we summarize these concepts:
Certificate: A packet of content that is a public or private key that is composed of signatures by other agencies.
Entitlements: Contains the APP permissions switch list.
Certificatesigningrequest: Local public key.
P12: Local private key, which can be imported to another computer.
Provisioning Profile: A packet that contains data such as certificates/entitlements and is signed by the Apple backend private key.

Other ways to publish
Before the development package as an example of the signing and verification process, the other two ways in-house enterprise signature and Ad-hoc process is similar, but the enterprise signature does not limit the number of devices installed, in addition to users in the IOS system settings manually Click Trust This enterprise can be verified.
and AppStore signature verification method somewhat different, before we talk about the simplest signature, Apple in the background directly signed with the private key App can be, in fact, Apple is actually doing this, if you go to download a AppStore installation package, you will find that it is not The embedded.mobileprovision file, that is, its installation and startup process is not dependent on this file, the verification process is different from the above several types.
It is speculated that because the package uploaded to AppStore Apple will re-encrypt the content, the original local private key signature is no use, need to re-sign, the package downloaded from AppStore Apple does not intend to control its validity period, do not need to build a Embedded.mobileprovision to do the verification, directly in the apple with the background of the private key re-signed, IOS installation with the local public key to verify the APP signature.
So why publish AppStore's package or do the same with the development version of the certificate and Provisioning profile? Guess because Apple wants to do unified management, Provisioning profile contains some rights control, AppID test, etc., Apple does not want to upload the AppStore package to re-use another protocol to do the verification, it is better to unify this part in the Provisioning Profile, upload AppStore as long as the same process to verify that the Provisioning profile is legitimate.
So when the App is uploaded to AppStore, it has nothing to do with your certificate/Provisioning profile, regardless of whether they expire or are revoked, and will not affect the installation package on AppStore.
The principle and the mainstream of the IOS signature mechanism are roughly finished, hoping to help understand Apple's signature and troubleshoot everyday signature problems.
P.s. Some questions
Finally, let me mention some of my questions about the signature process.
Enterprise Certificate
Enterprise Certificate signing because of limited, in the domestic is widely used for testing and piracy, fir.im/dandelion and other test platforms are distributed through enterprise certificates, some domestic markets like PP Helper, Extron Assistant, part of the installation means is also through the Enterprise certificate re-signed. Apps that are installed through the Enterprise Certificate signature Verify the validity of the certificate at startup, and do not periodically request the Apple server to see if the certificate has been revoked, and if it has expired or been revoked, it will not be able to launch the app. For this kind of assistant's pirate installation means, Apple want to hit only a revocation of enterprise certificate, and there is no good way.
My question here is that Apple has done so many signing and verification mechanisms to limit the App in IOS, why is there such a limited way to make piracy go away? If the enterprise is not suitable for the use of AppStore, but also can be opened in AppStore a small private section, or through the AppStore to install, there will be no problem.
AppStore encryption
Another problem is that after we put the app on the AppStore, Apple will encrypt the app, resulting in a lot of app volume, this encryption is actually no eggs, just let the cracked person to do a step more, run the app to the memory dump executable file, no matter how to encrypt, can use this method to take out the executable file before encryption. So why do you do this encryption? I don't think there's any good.
Local private key
We see that the signature process is very complex, often appear a variety of problems, such as the Provisioning profile file but the certificate is not correct, the local public key certificate does not correspond to the private key, etc., do not understand the principle of the case will be around Halo, my question is, why not simplify it here? Or take the development certificate as an example, why must the private key generated by the local MAC be signed? Apple wants only local signature, the private key is not necessarily to be generated locally, apple can also generate a pair of public private key to us, put in Provisioning profile, we use the inside of the private key to encrypt it, so there will not be Certificatesigningrequest and P12 concept, with the local keychain no relationship, do not need to care about the certificate, as long as the Provisioning profile can be signed, the process will be reduced, ease of use will improve a lot, At the same time, Apple wants to control a little, and there is no security problem, why not design it?
One reason to think of this is that Provisioning profile will be packaged into the installation package during non-AppStore installation, and a third party can get the Provisioning profiles directly to sign his own App. But this kind of problem is also very good to solve, only need to remove the file's private key when packaging, so still do not understand why this design.

IOS signature mechanism