Knowledge points of iOS Certificate Signature and knowledge points of ios Certificate Signature
I interviewed a lot of iOS development engineers before, but the project is still good, but when talking about certificates and signatures, few of them can be said first. As an iOS development engineer, whenever you are busy configuring various certificates, have you ever wondered what the TM is? This article tells you what this TM is!
Why?
Apple users all know that our favorite apps are downloaded from the AppStore. However, if Apple wants to have absolute control over third-party apps on the iOS platform, it must ensure that every APP installed on iOS is officially approved by Apple. How can this be ensured? It is through the signature mechanism.
Asymmetric encryption
Generally, the signature is a digital signature, which is based onAsymmetric encryption algorithm. Symmetric encryption encrypts and decrypts data through the same key, While asymmetric encryption has two keys: the public key and the private key. Data Encrypted with the public key can be decrypted only with the private key, data Encrypted with the private key can be decrypted only with the public key.
Let's briefly describe the mathematical principles of the common asymmetric encryption algorithm RSA. By understanding the simple mathematical principles, we can understand how asymmetric encryption is implemented and why it is secure:
Select two prime numbers p and q and multiply them to produce a large integer n, for example, p = 61, q = 53, n = pq = 3233.
Select a random prime number e between 1 and N, for example, e = 17.
After a series of mathematical formulas, a number d is calculated to meet the following requirements:
A. After a mathematical operation is performed on a group of data through n and e, the inverse operation can be performed through n and d, and the inverse operation can also be performed.
B. If you only know n and e, to export d, You Need To Know p and q, that is, you need to break down the n factor.
The preceding data (n, e) is the Public Key together, and the data (n, d) is the private key, which can be encrypted with the private key and decrypted with the public key, or, in turn, public key encryption and Private Key decryption can also enable the export of the private key (n, d) when only the Public Key (n, d) is exposed ), the big integer n factor must be decomposed. At present, factorization can only rely on brute force, while the larger the n number, the more difficult it is to calculate the p and q factors with the exhaustion. The safer it is. When n is as large as 1024 bits or 2048 bits in binary, it is almost impossible to crack the current technology, so it is very safe.
Digital Signature
Many articles are similar to the document stamp in real life. I think it is inappropriate and easy to mislead beginners. In the world of data, it is impossible to be as simple as in real life. Now let's analyze what a digital signature is.
Time: A month or a day
Location: Any computer on the earth
People: Old Wang next door and old tie Northeast China
Event: The Old Wang next door will send a file (O) to the old man in northeast China ).
After: Old Wang has a computer next door, which can generate a pair of public keys and private keys. Old Wang next door first abstracts the file (O) with the Digest algorithm to generate the file Digest (M ). Then, encrypt the file Digest (M) with the private key, that is, digital signature (hereinafter referred to as "signature"), and generate a signature file (S ). Then Old Wang next door sent the file (O), the signature file (S), and the Public Key together to the northeast iron.
After getting these three things, the Northeast Iron first decrypts the signature file (S) with the public key, generates the file Digest (m), and then uses the same digest algorithm) abstract to generate a file Summary (M ). The old iron in Northeast China only needs to compare m and M to see if this file has been changed by others. This is the purpose of digital encryption.
Understanding:
1. First, use an algorithm to calculate the summary of the original data. A. If the original data changes, the calculated summary value will change. B. The summary should be short enough. The most common algorithm here is MD5.
2. generate an asymmetric encryption public key and private key. I hold the private key myself and publish the public key.
3. After calculating the summary for a piece of data, use the private key to encrypt the summary and obtain the encrypted data, which is called the signature of the original data. Send it with the raw data to the user.
4. After receiving the data and signature, the user uses the public key to decrypt and obtain the abstract. At the same time, the user uses the same algorithm to calculate the digest of the original data. Compare the digest calculated here with whether the digest obtained by Decryption signature with the public key is equal, if they are equal, the data has not been tampered with in the middle, because if the data has been tampered with, the summary will change.
Download APP from AppStore
Apple generates a pair of public and private keys, which are built into iOS. The private keys are saved in the Apple background, the Apple background uses the private key to sign the APP data. After the iOS system downloads the APP, it uses the public key to verify the signature. If the signature is correct, the APP must be authenticated by the Apple background, without modification, it meets Apple's needs: ensure that every installed APP is officially approved by Apple.
Install the app in other ways
The process is not that simple. In fact, apart from downloading from the AppStore, we can install an App in three ways:
1. During App development, you can directly install the developed application on your mobile phone for debugging.
2. In-House enterprise distribution, you can directly install the APP after the enterprise certificate is signed.
3. AD-Hoc is equivalent to a restricted edition distributed by enterprises, which limits the number of installed devices and is rarely used.
Apple needs to control apps installed using these three methods, so it has new requirements and cannot be as simple as above.
Apple's solution is a two-layer signature, as shown below:
1. Generate a pair of public and private keys on your Mac development machine, which is called public key L and private key L. L: Local
2. Apple has a fixed pair of public and private keys. Like in the AppStore example above, the private key is on the Apple background and the Public Key is on every iOS device. This is called Public Key A and Private Key. A: Apple
3. Upload the Public Key L to the Apple background, and use the private key A in the Apple background to sign the Public Key L. The obtained data contains the Public Key L and its signature. This data is called a certificate.
4. after compiling an APP during development, use the local private key L to sign the APP and package the certificate obtained in step 3 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.
6. Verify the certificate and ensure that the public key L is apple-certified. Then, use the public key L to verify the APP signature. Here, it indirectly verifies whether the APP installation behavior has been officially permitted by Apple. (Here, we only verify the Installation Behavior and do not verify whether the APP is changed. Because the APP content is constantly changing in the development stage, Apple does not need to worry about it .)
Restrict installation devices and apps
The above process only solves the first requirement above, that is, installation can only be performed with Apple's permission. The second problem to avoid abuse has not yet been solved. How can this problem be solved? Apple adds two restrictions: one is to restrict the installation of devices registered in the Apple background, and the other is to restrict the signature to a specific APP.
You can think of the List of device IDs that can be installed and the AppID data corresponding to the App, all constitute A certificate together with the public key L in step 3, and then use Apple Private Key A to sign the certificate. You can obtain the device ID list during the last step of verification to determine whether the current device meets the requirements. According to the principle of digital signature, as long as the digital signature passes verification, the device IDs, AppID, and public key L in step 1 are all authenticated by Apple and cannot be modified, apple can restrict installable devices and apps to avoid abuse.
This certificate has become very complicated, and there are a lot of additional information. In fact, in addition to the device ID/AppID, there are other information that needs to be signed by Apple here, for example, Apple wants to control the permissions such as iCloud, push, and backend operations in this APP. Apple calls the permissions switch "Enments" in a unified manner and requires authorization through signatures.
Restrictions, such as pushing
Because the steps are slightly changed, we will repeat the entire process here:
1. Generate a pair of public and private keys on your Mac development machine, which is called public key L and private key L. L: Local
2. Apple has a fixed pair of public and private keys. Like in the AppStore example above, the private key is on the Apple background and the Public Key is on every iOS device. This is called Public Key A and Private Key. A: Apple
3. Upload the Public Key L to the Apple background, and use the private key A in the Apple background to sign the Public Key L. The obtained data contains the Public Key L and its signature. This data is called a certificate.
4. apply for AppID in the Apple background, configure the device ID list and permissions available for the APP, and add the Certificate in step 3 to sign the data with the private key, combine the data and signature to form a Provisioning Profile file and download it to the local Mac development machine.
5. after compiling an APP during development, use the local private key L to sign the APP and package the Provisioning Profile file obtained in Step 4 into the APP, the file name is embedded. mobileprovision: Install the APP on your mobile phone.
6. During installation, the iOS system obtains the certificate and verifies whether the digital signature of embedded. mobileprovision is correct through the built-in Public Key A. The certificate signature will be verified again.
7. embedded. after the data in mobileprovision is authorized by Apple, you can retrieve the data and perform various verifications, including verifying the APP signature with the public key L to verify whether the device ID is on the ID list, whether the AppID corresponds to each other, and whether the permission switch corresponds to the Enments in the APP.
Request a certificate from a Certificate Authority
In the key string program, the process of requesting a certificate from the Certificate Authority is to generate a pair of public and private keys on the computer. The file CertificateSigningRequest stores the public key.
Certificate
Download the local certificate from the apple developer platform. The content is the public key or private key, which is a data packet signed by other organizations.
Description file
Provisioning Profile, which contains data packets signed by the private key of the Apple background, such as certificates and Enments.