1. A few concepts

Apple ID: Product ID, used to identify one or a group of apps. The Bundle Identifier in Xcode should be Explicit or Wildcard matched. The apple ID string is usually prefixed with the Company Identifier (Company ID) in reverse-domain-name format, and generally contains no more than 255 ASCII characters.

Device: a Device running iOS for developing and debugging apps. Each Apple device is uniquely identified by a UDID.

After the iOS device is connected to the Mac, you can obtain the UDID (Identifier) of the iPhone through iTunes->Summary or Xcode->Window->Devices.

Devices under the personal account of Apple Member Center website include all registered Devices that can be used for development and testing. The average personal development account can only register 100 Devices at most each year.

Digital certificate: A string of numbers used to identify communication parties in Internet communication and provide a means of verifying the identity of communication entities on the Internet. It is a file digitally signed by the CERTIFICATE Authority and contains information about the public key owner and the public key. The simplest certificates contain a public key, a name, and a digital signature from the certificate authority. Another important feature of digital certificates is timeliness: they are only valid for a specific period of time. The root Certificate in an authentication domain is the Certificate issued by the CA Certificate Authority and is the start point of the trust chain. Installing a root certificate means trusting the CA authority.

IOS Certificate: a digital certificate that certifies the validity and integrity of the iOS App content. For an App intended to be installed on a real device or published to the AppStore, only after the Signature is Validated can the source be trusted and the content of the App be complete and untampered.

IOS certificates fall into two categories: Development and Production (Distribution).

Development certificates are used to develop and debug applications: Adevelopment certificateidentifies you, as a team member, in a development provisioning profile that allows apps signed by you tolaunchon devices.

Production is primarily used to distribute applications (depending on the type of certificate) : Adistribution certificateidentifies your team or organization in a distribution provisioning profile and allows you tosubmityour app to the store. Only a team agent or an admin can create a distribution certificate.

2. Analysis of the certificate signature principle

2.1 Why Is the Certificate Signature Adopted?

In order to control that every APP installed on an iPhone is officially certified by Apple, Apple adopted the signature mechanism.

2.2 Installing an App from the App Store

Apple officially generates a pair of public and private keys and builds a public key in the iPhone. The private key is saved by apple background. When we upload the App to AppStore, Apple background uses the private key to sign the MD5 value of the App data value. The App must be approved by Apple and not be modified, which would satisfy Apple’s requirement that every App installed be approved by Apple.

2.3 Installing the APP in other Ways

In practice, there are a few other ways to install apps on your phone:

When developing App, you can directly install the application under development into the mobile phone for debugging;

In-house enterprise internal distribution, you can directly install the enterprise certificate signed App;

Ad-hoc is the equivalent of a limited version of enterprise distribution that limits the number of devices installed and uses them less.

The basic process is as follows:

1) Generate a pair of public and private keys on the Mac, which are called public key M and private key M.

2) Apple itself has A fixed pair of public and private keys. Just like the example of AppStore above, the private key is in the background of Apple, and the public key is built in each iOS device, which is called public key A and private key A.

3) Upload public key M to the Apple background and use the private key A in the Apple background to sign public key M. Get a piece of data that contains the public key M and its signature (that is, the HASH value of the public key), and call that data a certificate.

4) During development, after compiling an App, use the local private key M to sign the App, and package the certificate obtained in the third step into the App and install it on the mobile phone.

5) During installation, the iOS system obtains the certificate and uses the built-in public key A to verify whether the digital signature of the certificate is correct.

Verify the certificate to ensure that the public key M is authenticated by Apple, and then use the public key M to verify the signature of the App, which indirectly verifies whether the installation behavior of the App is officially approved by Apple

The above process only addresses the first requirement, which requires Apple’s permission to install, and does not address the second problem of avoiding abuse. How do you solve it? Apple has added two restrictions. One is that only devices registered in the Apple background can be installed. The second is to limit the signature to a specific App.

So how does it add these two restrictions? In the third step above, when Apple signs our local public key M with the private key A, in fact, in addition to signing the local public key M, it can also add unlimited data, which can be guaranteed to be authenticated by Apple and will not be tampered with.

You can put the list of device ids allowed to install and the corresponding AppID of App and other data in the third step together with the public key M to form A certificate, and then use apple private key A to sign the certificate. In the verification step 5, you can get the device ID list and judge whether the current device meets the requirements. According to the principle of digital signature, as long as the digital signature is verified, the device IDs, AppID, and public key M in step 5 are authenticated by Apple and cannot be modified. Apple can restrict the devices and apps that can be installed to avoid abuse.

Here the certificate has become very complex, there is a lot of additional information, in fact in addition to the device ID/AppID, there are other information also need here with Apple signature, like App iCloud, push, background operation rights Apple want to control, Apple collectively known as Entitlements to these power switches Entitlements, It also needs to be signed to authorize it.

In fact, a certificate has a standard format, and it’s not appropriate for us to stuff all the extra information into the certificate, so Apple created a Provisioning Profile, and a Provisioning Profile contains the certificate and all the extra information mentioned above. And the signature of all the messages.

The final process is as follows:

2.4 The above steps correspond to our ordinary specific operations and concepts as follows:

In step 1 is the corresponding keychain “from the certificate issuing authority request”, here is the local generates a pair of public and private keys, save CertificateSigningRequest is public key and private key is stored in the local computer.

Step 2 Apple takes care of it, we don’t have to.

Step 3 corresponding upload CertificateSigningRequest apple background generated certificate, and downloaded to the local. The keychain will associate the two certificates, because their public and private keys are corresponding. When Xcode selects the downloaded certificate, it will actually find the corresponding private key in the keychain to sign the certificate. If other Macs want to compile and sign this App, export the private key to other Macs and export the private key to the keychain. P12 file. Import the private key to other Macs after opening the App.

Step 4 is all about configuring the AppID, permissions, devices, etc., on the Apple web site, and finally downloading the Provisioning Profile.

Step 5 Xcode will use the certificate downloaded in Step 3 (with the local public key), find the local private key (generated in Step 1), sign the App with the local private key, and package the Provisioning Profile named Embedded. Mobileprovision. Here, the App signature data is stored in two parts. The Mach-O executable will write the signature directly to this file, and other resource files will be stored in the _CodeSignature directory.

The packaging and validation of steps 6 and 7 are done automatically by Xcode and iOS.

2.5 Review some common ios concepts

Entitlements: Contains a list of App permission switches.

CertificateSigningRequest: local public key.

P12: local private key that can be imported to other PCS.

Provisioning Profile: A data packet containing a certificate /Entitlements, and signed by an Apple background private key.

References:

www.jianshu.com/p/bd3bf18b8…

www.jianshu.com/p/fc56a70ee…