iOS APP signature

Objective

Believe that many students for iOS real-computer debugging, app packaging and publishing process of various certificates,, Provisioning Profile CertificateSigningRequest , p12 The concept is vague, resulting in the actual operation of the process is also prone to error. Fortunately Xcode8.0 appeared Automatically manage signing , let us in this step operation to reduce the difficulty. Although we can choose to have Xcode automatically managed after Xcode8.0, we should still know how the app is signed. This article attempts to start with a rationale for why there are so many concepts and hopefully help to understand the principles and processes of iOS app signing.

Signature Purpose

Let's take a look at the purpose of Apple's signature mechanism. 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 have absolute control over the third-party app on the iOS platform, and make sure that every app installed on iOS must be officially certified by Apple. So the question comes, how can I guarantee it? Is by signing this mechanism.

Asymmetric encryption

Usually we call the signature is the 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 copies of the key, respectively, the public key and the private key, the data encrypted with the public key, to be decrypted with the private key, the data encrypted with the private key to be decrypted with the public key.

Simply say the common Asymmetric encryption algorithm RSA mathematical principles, understand the simple mathematical principle, you can understand how asymmetric encryption is done, why is safe:

1. Select two prime numbers ' Q ', multiplying a large integer 61,q=53,n=p*q=3233 2. Select 1- ' n ' a random prime number  ' E ', for example: E=173. After a series of mathematical formulas, figure out a number  ' E ', It can be reversed by  ' n ' and  ' E ', to derive  ' d ', you need to know  ' Q ', which requires the decomposition of  

The above (n,e) two data together is the public key, (n,d) these two data is the private key, satisfies with the public key encryption, the private key decryption, or in turn the private key encryption, the public key decryption, also satisfies in the case only exposes the public key (only knows n and e ), to deduce the private key (n,d) Need to be large integer n factor decomposition, the current factor decomposition can only rely on brute force, and the larger n the number, the more difficult to use the poor to calculate the factor p and q , the more secure, when n large to binary 1024 bits or 2048 bits, With the current technology to crack almost impossible, so very safe.

If d you are interested in how the numbers are calculated, you can read these two articles: the Principle of RSA algorithm (i) (ii)

Digital signatures

Now that there is an asymmetric cryptographic algorithm for this thing, then 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.
With the asymmetric encryption described above, this requirement can be achieved:

1. First, an algorithm is used to calculate the abstract of the original data, which needs to be satisfied:

   A. If there is any change in the original data, the computed digest value will also change.

   B. Short enough to digest, the algorithm used here is MD5 .

2. Generates an asymmetric cryptographic public and private key, the private key is held by itself, and the public key is released.
3. After a copy of the data is calculated, the digest is encrypted with the private key, and a copy of the encrypted data is obtained, which is called the signature of the original data. Send it to the user along with the original data.

4. After the user receives the data and the signature, decrypts the digest with the public key, simultaneously the user calculates the raw data summary with the same algorithm, compared to the summary which calculates here and the public key decryption signature to obtain the summary is equal, if equal then indicates that this data midway has not been tampered with, because if has 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 (not larger than n the above number of bits, which is generally not greater than 1024 bits/2048 bits), so to the arbitrary large data signature, you need to change its signature, the effect is the same.

Well, with the foundation of asymmetric encryption and digital signatures, how can you ensure that a piece of data is certified somewhere, to see how the digital signature mechanism ensures that every app installed to 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 is approved by Apple.

If our iOS app only downloads one way from AppStore, it's done, there's nothing complicated, just a digital signature, very simple problem solving.
But in fact, there are three ways to install an app, in addition to downloading it from AppStore:

1. Development of the app can be directly installed in the application of the mobile phone debugging;
2. In-house enterprise internal distribution, you can directly install the Enterprise certificate signed app;
3. 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 the one above.

The new requirements

Let's start with the first one, install the app at development time, it has two requirements:

1. 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.

2. Apple must have control over the installation here, including:

   A. The installation can be done with Apple's permission;

   B. Can not be abused to cause non-development apps to install the same way;

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:

1. Generate a pair of public private keys on your Mac development machine, which is called the public key L, the private key L. (l:local)
2. Apple itself has a fixed pair of public private keys, like the above AppStore example, the private key in Apple backstage, the public key is built into each iOS device, here is called public key A, private key A. (a:apple)
3. Upload the public key L to Apple backstage and use the private key A in the background of Apple 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.
4. At development time, after compiling an app, use the local private key L to sign the app, and then package the certificate from the third step into the app and install it on the phone.
5. 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.
6. Verifying the certificate ensures that the public key L is Apple-certified, and then uses the public key to verify the app's signature, which indirectly verifies that the app's installation behavior is 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 restrictions, one is limited to the Apple background registered devices can be installed, the second is to limit the signature only for a specific app.
So how does it add these two restrictions? In the third step above, when Apple signed our local public key L with private key A, in fact, in addition to signing the local public key L, but also can add unlimited data, the data can be guaranteed by the official Apple certification, there will be no tampering with the possibility.

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 is 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 app iCloud , push background running and other rights Apple want to control, Apple put these permissions switch collectively Entitlements , It also needs to be authorized by signature.
In fact, a certificate has a specified format specification, it is inappropriate for us to cram all kinds of additional information into the certificate, so Apple has another thing, called Provisioning Profile , one contains the Provisioning Profile certificate and all of the above mentioned additional information, as well as all the information of the signature.
So, the whole process changes a little bit, that's it:

Because the steps have small changes, here we do not hesitate to re-list the entire process:

1. In your MAC development machine generate a pair of public private keys, here called the public key L, the private key L. L:local
2. 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
3. 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.
4. 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 file, download to the local Mac development machine.
5. At the time of development, after compiling an app, use the local private key L to sign the app, and pack the files from step ④ into the app with the Provisioning Profile file name embedded.mobileprovision and install the app on the phone.
6. At the time of installation, the iOS system obtains the certificate, through the system built-in public key A, to verify embedded.mobileprovision the digital signature is correct, the certificate signature inside will also check again.
7. Ensure that the embedded.mobileprovision data in 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 and the Entitlements corresponding app.

Developer certificate from signature to certification the final process of Apple adoption is generally the case, with some details such as the certificate validity period/certificate type and so on.

Concept and practical operation

The above steps correspond to our usual specific operations and concepts such as:

1. The 1th step corresponds to "request a certificate from a certificate authority" in Keychain , where a pair of public private keys are generated locally, and the saved certificatesigningrequest is the public key and the private key is stored on the local computer.
2. Step 2nd Apple handle it by itself, we don't have to.
3. 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 generated in the 1th step, one is downloaded here, Keychain will associate the two certificates, because their public key is the corresponding, when Xcode chose to download the certificate back, will actually find the Keychain the corresponding private key inside the to sign. Here the private key only the Mac that generated it, if the other Mac also to compile signed this app, what to do? The answer is to export the private key to another Mac, export the private key in keychain , and save it as a . P12 file, and then import the private key when the other Mac is open.
4. The 4th step is to operate on the Apple website, configure AppID , permissions , device , and so on, and finally download   Provisioning Profile file.
5. The 5th step xcode will download the certificate from the 3rd step (with the local public key), locate the corresponding private key locally (generated in step 1th), sign the app with the local private key, and name the Provisioning profile file embedded.mobileprovision in the package. The signature data for the app is saved in two parts, and the mach-o executable writes the signature directly to the file, and the other resource files are stored in the _codesignature directory. The 6th, 7-Step package and verification of
6. is done automatically by Xcode and the IOS system.

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 certificate/entitlements and is signed by the Apple background private key.

Other ways to publish

In front of the development package as an example of the signing and verification process, the other two ways In-House the 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 to pass the verification.
and AppStore the signature verification method some 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 an AppStore installation package, you will find that it is not a embedded.mobileprovision file, That is, it installs and starts the process is not dependent on this file, the verification process is not the same as the above several types.

According to speculation, because the upload to AppStore the package Apple will re-encrypt the content, the original local private key signature is no use, need to re-sign, from AppStore the download package Apple also does not intend to control its validity period, do not need a built-in embedded.mobileprovision to do the verification, directly in the apple with the background of the private key re-signed, Use the local public key to verify the app signature on iOS installation.

Then why does AppStore the release of the package or the development version of the same as the various certificates and Provisioning Profile ? Guess because Apple wants to do unified management, Provisioning Profile contains some permissions 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 Provisioning Profile , upload AppStore as long as the same process to verify the Provisioning Profilewhether it is legal or not.

So when the App is uploaded AppStore , it has nothing to do with you 证书 / Provisioning Profile , no matter if they expire or are revoked, it will not affect AppStore the installation package.

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.

Thanks

Thank you for your patience to read, but also hope to bring help to everyone. Also thanks to the original author's article. This article is mainly for taking notes.

Finally, play a wave of ads, need to sign a friend can add qq:2302398895 a friend specializing in iOS app signing.

iOS APP signature