Details of iOS APP signature mechanism
Demand for Apple：
To ensure system security, all apps installed on the iPhone must be authorized by AppleInstallation packages can be installed without uploading to the App Store (developer debug enterprise gray scale)Prevent certificate permission abuse: Additional permission control, such as device restriction, specified APP, iCloud/PUSH, and background running
Apple's solution: Double layer code signature + description file:
Before iOS came out, the mainstream operating system (MacOS/Windows) software could run from wherever it was downloaded. There were hidden dangers in system security, such as pirated software, virus invasion, silent installation, etc. Apple hoped to solve similar problems. It ensured that all apps on iPhone iOS were officially approved by Apple. It's just code signature.To realize verification, the simplest way is that Apple official generates a pair of RSA public and private keys, and a public key is built into the iOS system. The private key is saved by Apple background. When we upload the APP to the App Store, Apple background uses the private key to encrypt the APP data. The iPhone downloads the APP and uses the public key to verify the signature to see if the APP has been approved or tampered with by three parties. However, App Store is not the only way to install apps, such as real machine debugging, enterprise packages, etc., so only relying on this simple digital signature is not enough.So Apple designed a two-layer signature mechanism. As we all know, iOS application development must be carried out on the Mac system. It is because of this dependency that the two-layer signature is based on:
Generate a pair of public and private keys for an asymmetric encryption algorithm in Mac (Xcode will do it for you)
Apple has its own 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
Send the public key M and some developer information (that is, the CSR file) to the Apple background, use the private key A of the Apple background to sign the public key M, and get a copy of the data containing the public key M and its signature result is the certificate (.p12).
During development, when we package, we will sign the APP with the local private key M (that is, the developer certificate that can be exported to friends), and package the certificate obtained in step 3 into the APP, and then install it on the mobile phone (real phone joint inspection) or submit it to the App Store for approvalDuring installation, the iOS system obtains the internal public key A to verify the digital signature certificate of public key M
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 allowed by Apple (note that only the installation behavior is verified here, not whether the APP is changed, because the APP content is always changing in the development stage).
The above process can already ensure the developer's certification and the security of the program, but if only the above process, wouldn't it only need to apply for a certificate to install on all iOS devices? So Apple added validation for a license profile, which typically includes three things: a certificate, an APP ID, and a device.The description file is created in the AppleDevelop website (put an AppleID in Xcode and it will create it for you), and the Xcode runtime will package it into the APP. During development, after compiling an APP, the local private key M is used to sign the APP, and the Provisioning Profile obtained from the Apple server is packaged into the APP with the file named embedded.mobileprovision. When the APP is installed on the phone, the iOS system verifies it.