IOS signature verification mechanism is the basis of Apple ecological security. In daily work, whether in the development stage or the testing stage, we often encounter many problems that need to be solved by the signature mechanism. Understanding the principle of iOS signature mechanism can help us improve the cost and efficiency of solving related problems. This paper first introduces the principle of digital signature and certificate, and then introduces the process of apple developer certificate generation and installation. Finally, it introduces the process of Apple signature verification and the key information involved in the process, hoping to be helpful to you.

The full text is 9,494 words and the expected reading time is 24 minutes.

background

After the beta version of iOS15 was released, QA students needed to test the functional stability of the new function in iOS15 system, but the enterprise package printed through the company’s assembly line could not be installed on the device of iOS15 system. The details of the error are shown in the following figure:

You can view The error message during The installation on The console and find that The signature information of The IPA package is no longer supported on iOS 15: The code signature version is no longer supported. The detailed console error message is as follows:

In other words, the installation failure is related to the code signature version of IPA. For this reason, the codesign command is used to check the relevant signature information of IPA produced by the pipeline, as shown in the following figure, where the CodeDirectory version is V =20400:

CodeDirectory is the CodeDirectory, which records the hash information of each page after the Mach -o file is paged. In addition, it also contains the summary information of resource files, permission information, etc., which are combined together in a certain format. Different signature versions correspond to different types of information, combination forms, or computing algorithms. Last year, starting with iOS 14 beta2, apple adopted a more secure signature format that will pop up when you run an APP that uses the older signature format. In a future release, the new format will become mandatory, And the system won’t launch apps with the old signature format. Therefore, it is suspected that the signature format is forcibly verified on iOS 15, leading to the installation failure:

If you signed your app on a Mac running macOS 10.14 or later, the app already has the new signature format. In other words, the version of macOS will affect the signature format; “For any value of V less than 20400, you’ll need to re-sign your app.”

When the CodeDirectory version value is less than 20400, you can re-sign to resolve the signature failure problem. CodeDirectory v=20400 can be installed on iOS 14, but not iOS 15. In order to solve this problem, the idea of re-signing is adopted. After re-signing the pipeline IPA package on macOS 11.5.2 and macOS 12.0 Beta, it can be installed on iOS 15 normally.

Above is a reflection of the iOS’s signature check mechanism, development and testing, the daily things associated with the iOS signature verification mechanism and there are many such as make enterprise certificate expires after the modification of the system time leading to start the collapse and so on, here again and share about iOS check some information about the certificate and signature.

Let’s start with a few questions:

• What is the signature verification mechanism?

Digital signature of executable files or scripts to ensure that the software is not damaged or modified after signature;

• Why does Apple use signature verification?

Signing your app allows iOS to identify who signed your app and to verify that your app hasn’t been modified since you signed it.

That is, to determine the source of APP and prevent external attacks, so as to realize Apple’s control over its ecosystem;

• How does Apple implement signature verification?

This is iOS flow diagram of the signature verification mechanism, in the process of learning, personal feel understanding asymmetric encryption, digital signatures, and the principle of a digital certificate to understand the signature mechanism is very important, so in the beginning of the article on the encryption and decryption, digital signature and digital certificate to do some instructions, then combined with the principle of digital signature and certificate, Describes the process of creating developer certificates and the iOS signature verification process, including some key information involved in the process:

1. The roles of encryption and decryption, digital signature, and certificate in communication

2. Analyze the generation and installation process of Apple developer certificate

3. Apple implements signature verification process and key information

I. The respective functions of encryption and decryption, digital signature and certificate in communication process

Whether you download the App from AppStore and install it on the mobile phone or install the App on the test machine for real machine debugging at the Debug stage by Xcode, it is actually a communication process of sending the App package to the sandbox of the mobile phone. How to ensure a safe and effective communication? Or what security problems might be faced during a communication?

The plaintext sent from A to B, which can be viewed directly by an intermediate route, is leak-bugged

The troublemaker C modifies A’s request to B, so that A initiates A wrong request, which is tampered with

The troublemaker C intercepts and simulates A’s request to B, making B think it was INITIATED by A — being deceived

A makes A request to B, but A simply denies making the request – is denied

1.1 Protection against eavesdropping – encryption and decryption

It is difficult to avoid being intercepted by a third party in the process of communication, but it can be done that even if intercepted, the eavesdropper still cannot decipher the valid message, and this process can be achieved through encryption.

At present, there are two main categories of encryption algorithms, symmetric encryption and asymmetric encryption:

Symmetric encryption is characterized by using the same secret key for encryption and decryption. It is characterized by high speed. Common algorithms include DES, 3DES and AES.

Asymmetric encryption consists of public key and private key. The most important feature of asymmetric encryption is that information encrypted with public key can only be decrypted using private key, while information encrypted with private key can only be decrypted using public key. RSA is the most commonly used algorithm.

However, the key management of symmetric encryption is tedious and the key transmission has some security risks, while the speed of asymmetric encryption algorithm is slow, especially for the information with large data, the time is more obvious. Therefore, in the actual use process, the most commonly used is mixed encryption:

Sender: 1. Encrypt messages (plaintext) with the DES key. 2. Use RSA to encrypt the DES key. The information generated in steps 1 and 2 is then combined and delivered.

Recipient: After receiving the message: 1. Decrypt the DES key using RSA. 2. Use the RSA key to decrypt the ciphertext. Finally, we can get the information we want (plaintext).

1.2 Denial Prevention – Digital signature

Because the public key is public, A can use the public key to encrypt the information and calculate the abstract, and B can also use the public key to encrypt the information and calculate the abstract, that is, all the people who have the public key can become the information sender, which leads to A can deny the message after sending it. We mentioned asymmetric encryption: Information encrypted with a public key can only be decrypted using the private key, while information encrypted with a private key can only be decrypted using the public key. Public key is made public, but the private key is confined to the key to produce his own hands, so when in sending messages using the sender’s private key to encrypt the information, at the receiving end use the sender’s public key to decrypt the information, then the receiver can accurately confirm the message sender, also solved the problem of the message sender denied to send. Encrypting the digest with the sender’s private key creates a signature, a digital signature.

Let’s look at how digital signatures work:

To sum up the functions of digital signature, there are three main points: 1. 2. Can identify whether the message is tampered with; 3. It prevents the sender from denying the message.

But we can’t ignore a point: the premise of effective digital signature: the public key used for encryption must belong to the real receiver, the public key used for decryption must belong to the real sender. If the public key is forged or the perpetrator impersonates the sender to send the message, the digital signature alone cannot solve the problem; Let’s take a look at what happens when a public key is forged:

As can be seen from the figure above, if the public key is forged during transmission, a forged key pair is established for subsequent communication, resulting in insecure communication. Therefore, the validity of the public key must be verified before the signature can be verified.

But how do you ensure that the public key is legitimate?

According to the above introduction, in order to ensure that the public key information is not tampered with and spoofing, then the best way is to digitally sign the public key, but the problem arises again, how to ensure the validity of the public key in the digital signature verification process? Digital signature again? This is a chicken-and-egg process. In order to break the cycle, people create certificate centers and digital certificates.

1.3 Verifying the Validity of public Keys – Digital Certificates

The reason for cyclic digital signature is that public keys may be forged. Therefore, some organizations or government departments with public trust are used as certificate centers, which use their private keys to digitally sign public keys. A certificate center (CA) is an authoritative individual or organization that can determine that a public key really belongs to that person and generate a digital signature. The CA creates a certificate by digitally signing the public key and other information.

Let’s look at how digital certificates work:

The receiver first generates a key pair and registers public key _B and email with the CA. The CA uses its private key _CA to digitally sign public key _B and generates a certificate. Sender A requests A certificate from CA and authenticates the digital signature through public key _CA of CA to verify the validity of public key _B.

In this paper, we have a general review of the concepts and functions of public key, private key, digital signature and digital certificate. The following describes the generation and installation of iOS developer certificates from the perspective of digital signatures and certificates.

Ii. Generation and installation of Apple Developer certificate

-1. Generate a certificate request: Key string access -> Certificate Assistant -> Request certificate from certificate authority (it can be understood as the process of creating asymmetric encryption key pair M and M on the Mac side, using the private key M to sign and generate a CSR file, which contains the developer’s information and the public key M, and the private key M is stored locally on the Mac side)

– 2. Login Developer platform, the first step will be generated CertificateSigningRequest. CertSigningRequest uploaded to the Developer to generate the certificate. (CertificateSigningRequest certSigningRequest Mac generated can be understood as public key, can be uploaded to the developer platform for the public key M in CA CA to register, and USES the public key of the apple developer center A public key to sign the Mac equipment, Generate developer certificate)

– 3.Mac Download the certificate to the local PC and double-click to install it. During the installation, keychain will associate the private key M generated in step 1 with the Cer certificate generated in Step 2.

Iii. Apple’s signature verification process and key information

The purpose of Apple signature verification is to ensure that every App installed on an iOS device is officially authorized by Apple. To achieve the above effect, Apple adopts the scheme of double signature, the process can be seen below:

> 1. A key pair (public key M and private key M) is generated on the Mac terminal, and A private key pair (public key A and private key A) is generated on the Mac terminal. Public key A is preset on the iOS device, and private key A is stored on the Apple server.

> 2. The developer uploads public key M to the Apple server through the developer background. The Apple server uses private key A to sign public key M to generate A certificate, and the developer downloads the certificate and installs it in the Mac. During the installation, the certificate is associated with the private key M.

> 3. During the development process, the private key M will be used to sign the APP, and the certificate will also be packaged into the APP.

> 4. During the installation process, the iOS system will first use preset the public key of A certificate for verification, get the public key M (verification is successful, the certificate is through the apple the private key signature, according to we know that you know the interpretation of the front is A apple certification), and then use the public key for signature verification, m. The APP can only be installed on the device after the verification is successful.

Is it possible to install any App on any test machine as long as you have an Apple certified developer certificate? Clearly this is not allowed by apple’s ecology. So how does Apple achieve device limitations? Also, in team development, not everyone generates developer certificates, so how does team authorization work? And what role does BundleID, Capabilities, and Devices play in apple’s Developer Center?

3.1 About Teamwork development for P12

In the signing process above, we see that the developer mainly uses two pieces of information when signing the App: the private key M and the certificate, so only these two pieces of information need to be provided to the rest of the team. In the process of certificate installation, we know that the key string will associate the certificate with the private key M generated by Mac and store it as one item in the key string. The key string can be exported as a P12 file, and then we can provide the P12 file to team members for installation.

3.2 About Entitlements control

Xcode will automatically execute the /usr/bin/codesign command when compiling the package to sign the code. Here are the signature details:

Certificate information is specified through –sign at signature time, then — Entitlements configure what information?

Entitlements links:

(developer.apple.com/library/arc…).

An Entitlement can be thought of as the string written into an app’s signature that allows a specific capability or opts the app into a specific service. The operating system (OS) checks these strings before allowing an app access to certain features. For example, an app must have the iCloud entitlement before it is allowed to access iCloud APIs at runtime.

In simple terms entitlements is actually an iOS sandbox environment configuration file, Apple entitlements file to control an App can use services and entitlements. Sandbox is an important part of iOS security system. Sandbox not only makes apps independent of each other, but also controls the behaviors that each App can operate, such as which sensitive system capabilities can be used (Push, Sign in with Apple, etc.). Xcode will default to generate a permissions statement containing Team ID information and App ID information, entitlements if Xcode Signing&Capabilities is enabled related permissions, then explicitly generate a.entitlements configuration file, entitlements, It contains a description of the relevant permission information. The file after the — Entitlements option is entitlements based on the.Entitlements configuration file with added information after the default configuration. When Xcode is signed, the permission information file is embedded in the binary code as part of the signed content, and the code signature guarantees that it will not be tampered with.

Through security CMS – D – I/path/to/iOSTest mobileprovision to check local Provisioning Profile contains the required permissions.

3.3 About Provisioning Profile

Provisioning profile act as a link between the device and the developer account. During development, you choose which devices can run your app and which app services your app can access. A provisioning profile is downloaded from your developer account and embedded in the app bundle, and the entire bundle is code-signed.

A Provisioning Profile is a plIST file encrypted and signed by The Apple Certificate Center. It contains the App ID bound to it, the UUID list of the device, expiration time, TeamID, Entilements, and the certificate used to sign the application. It is apple’s solution for device authorization and APP sensitive permissions control. Its configuration page in the certificate center is as follows:

After the certificate center configures App ids, Unique Device Identifiers, and capabilities, The Certificate Center signs the certificate with apple’s private key. Finally, the signature information is combined with configuration information, certificates, and signature information to form a Provisioning Profile. The developer downloads it and installs it, and by default Xcode automatically helps the developer manage it. Here is the Provisioning Profile information installed in Xcode:

After the Mac compiles an App, the Provisioning Profile is bundled into the App and named Embedded. Mobileprovision. When the App is installed on an iOS device, the iOS device uses the preset public key information to verify the signature of embedded. Mobileprovision and verify the signature in the certificate.

After ensuring that the embedded. Mobileprovision data is authorized by Apple, you can use that information to verify the installation. Use the public key A to verify the Mach-O signature information, the signature and validity of the certificate, whether the device ID is in the device list, whether the App ID in the Provisioning Profile matches the BundleID, and so on;

Note that the device list only works with the Development certificate. Enterprise and Distribution certificates are inherently installable, so they are not restricted by the device list. The expiration time is valid only for Development and Enterprise certificates, but not for Distribution certificates. If the Development and Enterprise certificates expire, applications cannot be installed or started. There is no time limit for downloading apps from the App Store.

Of course, changes can be made to a Provisioning Profile at any time in the Developer Center. Updates will not affect existing Provisioning profiles.

3.4 Signing executable files and resources

During the compilation of the App, Xcode signs the binaries by finding the private key M paired with the configuration certificate through the keystring, and emashes the signature information into the executable binaries to verify whether the Mach-O file has been modified at installation time. This can be verified by MackOView:

However, App contains not only binary files, but also a series of preset resources such as pictures, audio and video files. Therefore, signing a single binary file is not enough to ensure the integrity and validity of the entire App file. In iOS, applications use directories that follow the shallow Application Bundles structure to store the necessary resources and data information, roughly as follows:

TestProject. App | users can be found in the application

Info. Plist | file that contains information about the package

TestProject | executable binary

Assets. Car | icon showing visible for the user application

Framework | any executable file using the Framework, or dynamic libraries

AFNetworking. Framework | common framework example in the iOS software

Here is a very simple IPA package structure:

It can be seen that in order to ensure that the executable file and the data and resources it depends on during running are not tampered, a new _CodeSignature directory will be generated in the actual generated APP package, which contains a plist file named CodeResources. It contains information about other files under App except executable files. Key is usually the file name and value is usually the summary information. Files stores the sha1 value of each file. Files2 stores both SHA1 and SHA256, mainly because SHA1 is insecure. Is the main purpose of _CodeSignature/CodeResources file record after signature of each file hash value, in the installation to ensure that the corresponding file has not been tampered with.

3.5 Signature and Verification Process

> 1. A key pair (public key M and private key M) is generated on the Mac terminal, and A key pair (public key A and private key A) is generated on the Mac terminal. Public key A is preset on the iOS device, and private key A is stored on the Apple server.

> 2. The developer integrates the public key M into the CSR file and upload it to the Apple server through the developer background. The Apple server uses the private key A to digitally sign the public key M to generate A certificate. At the same time, private key A is used to encrypt the certificate, AppID, Entilements, device UDIDs and other information to generate A Provisioning Profile. The corresponding developer downloads the certificate and Provisioning Profile and installs it on the Mac. The certificate is associated with the private key M during installation, and Xcode manages the Provisioning Profile by default.

> 3. During the development process, the private key M is used to sign the App and the Provisioning Profile is also packaged into the App, namely embedded. Mobileprovision file.

> 4. When the iOS device is connected to Xcode and authenticated, Xcode will transfer the App data to the iOS device. The iOS device will not create a real sandbox environment to run the App, but will store the continuously received data in a temporary sandbox environment. The iOS system uses the preset public key A to verify the signature of the Embedded. Mobileprovision file to check whether the App source is valid. After the source validity verification succeeds, you can use the public key M to verify the signature information of the certificate, whether the device ID is in the corresponding UUID list, and whether the permission switch configuration in the APP matches the Entilements information configured in the Embedded. Mobileprovision file. At the same time will read the information in the _CodeSignature/CodeResources check for resource files. Only after everything is verified will a real sandbox environment be created for the App to install. When the APP is started, the system will also perform the corresponding startup verification to prevent changes made after installation.

References:

1. developer.apple.com/documentati…

2. developer.apple.com/library/arc…

3. pewpewthespells.com/blog/migrat…

4.blog.cnbang.net/tech/3386/

5. developer.apple.com/library/arc…

6. developer.apple.com/library/arc…

7. developer.apple.com/library/arc…

8. getupdraft.com/blog/ios-co…

9. abhimuralidharan.medium.com/what-is-a-p…

Recommended reading:

Information flow recommendation system intelligent delivery solution exploration

Application and exploration of atlas correlation technology in risk control and anti-cheating

Android Refactoring — Refactoring practices around players

———- END ———-

Baidu said Geek

Baidu official technology public number online!

Technical dry goods, industry information, online salon, industry conference

Recruitment information · Internal push information · technical books · Baidu surrounding

Welcome to your attention