This is the first day of my participation in the August More text Challenge. For details, see: August More Text Challenge

IOS underlying principles + reverse article summary

What is code signing and what is app signing in iOS

Code signing

Code signing is the digital signing of an executable file or script. A measure to confirm that the software has not been modified or damaged after the signature. It works the same way as a digital signature, except that the signed data is code.

Purpose: To prevent executable files or scripts from being tampered with

Simple code signing

  • Before iOS came out, the previous mainstream operating system (Mac/Windows) software can be downloaded from anywhere to run, system security risks, pirated software, virus invasion, silent installation and so on. So Apple wants to solve such a problem, to ensure that every APP installed on iOS is officially approved by Apple, how to guarantee? That’s code signing.

  • If you want to implement validation. In fact, the easiest way to do this is to generate a pair of public and private keys with asymmetric encryption through The Apple official. A public key is built into the iOS system, and the private key is saved by the Apple background. When we upload the APP to the AppStore, the Apple background signs the APP data with the private key. After the iOS system downloads the APP, the public key is used to verify the signature Apple requirements: ensure that every APP installed is officially approved by Apple.

  • If we install apps on iOS devices from the APP Store, this is a simple matter, no complicated things, a digital signature.

  • But there are other ways to install apps on iOS. For example, for us developers in iOSer, we need to debug directly on the real machine when developing the APP. In addition, Apple has opened up the distribution channels within enterprises, and the enterprise certificate signing APP also needs to be installed smoothly.

  • Apple needs to open up these ways of installing apps, which can’t be done with simple code signatures.

Apple’s demand

  • The installation package does not need to be uploaded to the AppStore, and can be installed directly to the phone

  • In order to keep the system secure, Apple must have absolute control over which apps are installed

    • You need apple’s permission to install it
    • It should not be abused so that non-developed apps can be installed

In order to achieve these requirements, the complexity of iOS signature has also started to increase, and Apple’s solution here is a double-layer signature

Two-layer code signature

In order to meet some of Apple’s requirements for verifying applications, the complexity of iOS signature has increased, and Apple’s solution is a two-layer signature.

  • Here’s a quick rundown of the two-tier code signing process for iOS. This is not the final iOS signature principle.

  • First of all, there are two characters. One is iOS and the other is our Mac. Because the iOS APP development environment is on the Mac. So this dependency becomes the basis of Apple’s two-layer signature.

  • 1. Generate a pair of public/private keys for asymmetric encryption in the Mac system (your Xcode does it for you). This is called public key M Private key M

  • 2. Apple has a fixed pair of public and private keys, just like in the App Store. The private key is in apple’s background, and the public key is in each iOS system. This is called public key A, private key a. A=Apple

  • 3. Upload public key M and some of your developer’s information to the Apple backend (this is the CSR file). Use private key A in the Apple backend to sign public key M. Get a piece of data containing the public key M and its signature, and call this piece of data a certificate.

Apple two-way signature verification steps

The steps for apple’s two-way signature are described below

  • 1. Premise:

    • Xcode generates a pair in the keychainPublic key M, private key M, and save it on the MAC
    • There are a pair ofPublic key A (iPhone), Private key A (Apple server)

  • 2. Generate a CSR file by using public key M (core) + ca information in the MAC and send it to the Apple server

  • 3. The Apple server passesPrivate key A Encryption public key MTo generate a certificate containingPublic key M + Hash value, and theThe Hash value of public key M is used as the digital signature

– The private key is AencryptionPublic key M

- Apple servers are equivalent to CA agencies - 'certificates' are' CRT files'Copy the code

Question: Compiling the App needs to be installed on the phone, how to verify the iPhone?

  • 4. Through the MACThe private key M, for the AppMach-o does the signing, generate an App signature, and package the certificate to form an IPA package
    • 1) Through the MACPrivate key M to sign Mach-O in App

– 2) Generate an App signature– 3) Package mach-o file, App signature, certificate and other information together to form an IPA package – certificateIt’s available from the iPhonePublic key A decryption– Private key M is the P12 certificate. After the certificate is returned, it is bound to private key M

Dual authentication

  • 5. IPhonePublic key A decrypts the certificateIs obtained after the certificate is decryptedPublic key M.Public key M can verify the signature of the AppIf the verification is passed, the installation behavior is allowed and legal

The following is the signature information for Mach-O

Note: This process is problematic because any device can be installed as long as you apply for a certificate

Description file

So in order to solve the problem of app abuse, Apple added two more restrictions.

  • The first is to limit the installation to devices registered with Apple in the background.

  • The second restriction is that the signature can only be specific to a specific APP.

And Apple also want to control the App inside iCloud/PUSH/ background run/debugger additional these rights, so Apple put these rights switch unified called Entitlements(Entitlements file). This file is placed in a file called Provisioning Profile.

  • The description file is created on the AppleDevelop website (you fill in the AppleID in Xcode and it will create it), and Xcode will run and package it into the APP. So when we use CSR to apply for a certificate, we also need to apply for one more thing!! The description file!

  • In development, after compiling a APP, with local private key M to signature of the APP, at the same time got from apple server Provisioning Profile file is packaged into the APP, file called embedded. Mobileprovision, the APP Install it on your phone. Finally, the system is verified.

  • 6. To limit this, Apple provides a permission file called a profile-description file, so the certificate in 3 is included in the description file. In addition, the device ID, AppID, and permission file are included. The purpose is as follows: 1) To restrict the installation of devices with free certificates; 2) Limit the installation period of the free certificate. The following is the double verification process with the description file

– 1) The Apple server provides a description file, which containsThe CRT certificate.

- 2) Then 'mach-o file' is signed by 'private key M' of the MAC, and 'App signature' is generated. - 3) Package 'ipA' with 'mach-o' file, 'App signature' and 'description'. - 4) Install App on iOS device. - 5) Decrypt 'CRT certificate' in description file with 'private key A' of iPhone. Decrypt to get 'public key M' -6) and then through 'public key M to verify App signature'. Because 'App signature' is signed by 'private key M', if the verification is successful, the installation is validCopy the code

Looking at the description file, here is the term of the description fileIn the compiled App package, you can also see the description fileTerminal Command Viewing: Run commands to view the description file (in the.app package directory) :security cms -D -i embedded.mobileprovision

Double validation summary

Therefore, to sum up, Apple’s dual verification mainly refers to the following two signature verification:

  • 1. In iOS, the built-in public key A is used to verify the CRT certificate

  • 2. Verify the App signature through the public key M extracted from the certificate in 1

conclusion

  • Certificate: a data packet composed of public key M and private key M sent and signed by an official organization

  • P12 is the local private key M

  • Description file: Contains information such as a certificate, Entitlements file (/ – permission switch), AND Entitlements. Do not modify

  • Certificate generation process:

    • 1. Use the local public key M/ private key M to apply for a CSR file

    • 2. The server performs RSA encryption on the public key M to get the CRT certificate.

    • 3. Download the CRT certificate to the local PC and bind it to private key M (P12)

  • The following figure shows apple’s two-way signature verification process

– 1. Pass the file in the Mac addressPublic key M+ Information about the certificate authoritygenerateCSR file

Pass the CSR file to the Apple server and apply for A CRT certificate. - 3. The Apple server encrypts public key M using private key A, generates A CRT certificate, and digitally signs the hash value of public key M using RSA encryption. At the same time, Apple also provides' description file '-4, through' private key M 'to' Mach-o 'signature, generate an' App signature ', at the same time, the description file, CRT certificate package, etc., form an 'IPA' package -5, App installed on the iOS device - 6, get 'public key A' from the iPhone, Through public key A 'decrypt CRT certificate', get 'public key M' -7, through 6 get 'public key M verify App signature'Copy the code
  • Apple’s dual verification mainly refers to the following two signature verification:

    • 1. In iOS, the built-in public key A is used to verify the CRT certificate

    • 2. Verify the App signature through the public key M extracted from the certificate in 1

Refer to the link

  • Bidirectional signature Signature principle & Re-signature correlation
  • IOS digital signature, code signature, and double signature details