Digitally signed. For example: Digitally signed, foreigners like to use a check. The check has a signature that says it’s yours. So digital signature, as the name implies, is a method used to identify digital information. This is a very graphic statement. Digital signature in IOS app: The original data is obtained using the Hash algorithm to obtain the original Hash value, and then the asymmetric encryption algorithm RSA is used to encrypt the Hash value to obtain the final encrypted data. This process is called digital signature.
Digital signature (also known as public key digital signature, electronic signature, etc.) is a common physical signature similar to that written on paper, but it uses the technology in the field of public key encryption to identify digital information. A set of digital signatures typically defines two complementary operations, one for signing and one for verification.
A digital signature is a string of numbers that can only be generated by the sender of a message and cannot be forged by others. This string is also an effective proof of the authenticity of the message sent by the sender.
What is the best way to prove the validity of digital information (that is, binary data, any data in a computer)?
In my last blog post, “IOS Reverse HASH (2) Cryptography Hashes,” I talked about HASH algorithms that are specifically used to identify file data. So in the process of network data transmission, we can pass the plaintext data and the HASH value of the data to each other. The other party can use the HASH value for verification.
But in this process, how to achieve data protection? Plaintext data and HASH values run the risk of being tampered with if passed directly. So here we’re going to encrypt the data. Plaintext data is sometimes too large to use the RSA asymmetric encryption algorithm, so the HASH value of the data is relatively small. This data is for verification and can be encrypted using RSA.
Therefore, the plaintext data and the RSA encrypted parity data are transmitted to each other during data transmission. So this validation data, encrypted by RSA, we call it a signature.
What is the process of digital signature?
1.1 Digital Signature Process:
The original data is sent along with the digital signature when the data is first transmitted
After the other party gets the data, they verify it first. Take the raw data and use the same HASH algorithm to get the HASH value of the data.
Then use asymmetric encryption to decrypt the checksum HASH value in the digital signature.
Finally, check whether the two HASH values are consistent. This is a good way to determine whether the data has been tampered with!
Digital signature verification process
Digital signature technology is to encrypt the abstract information with the sender’s private key and send it to the receiver together with the original text. The receiver can decrypt the encrypted digest only with the sender’s public key, and then use the Hash function to generate a digest of the received text and compare it with the decrypted digest. If they are the same, the received information is complete and has not been modified during transmission. Otherwise, the received information has been modified. Therefore, the digital signature can verify the integrity of the information.
1.2 Client and server signature verification process:
If the client does nothing when sending data to the server, it may be attacked by a man-in-the-middle, regardless of the consequences. So how do we prevent middlemen from intercepting, or checking to see if data has been tampered with?
Direct encryption using RSA does not meet our requirements. RSA is only suitable for encrypting small data. We know that the integrity of data can be verified by using Hash (Hash overview). The server hashes the original data and compares the Hash value with that sent by the client. If the Hash value is the same, the data validity is guaranteed. If the middleman tampered with the data sent by the client, of course, he could also modify the Hash value sent by the client, so this operation is not feasible.
In this case, RSA can be used to protect the hash value. In this case, the client sends the original data and the hash value of the data encrypted by RSA.
The server decrypts RSA encrypted data to obtain the hash value of the original data. Then the server uses the same hash algorithm on the original data to compare the hash value obtained with the decrypted hash value. If the hash value obtained is consistent with the decrypted hash value, the data validity is guaranteed. Or if RSA data cannot be decrypted, the data is tampered with.
The procedure for verifying whether data has been tampered is as follows:
2. Code signature
What is code signing?
Code signing: Digitally signing executable files or scripts. A measure used to verify that software has not been modified or corrupted after being signed. The principle is the same as digital signature, but the data of signature is code. The code signature is used to validate our executable
As an IOS developer, why do you need to understand how code signing works?
Gone are the days when iOS engineers deployed iOS applications with Xcode installed from their local computer. Companies are building software using DevOps and CI/CD, so all builds need to be automated without any human or GUI interaction.
Because Xcode’s code signing failed, developers wasted thousands of developer time trying to fix the code signing problem by regenerating and repairing certificates and configuration files.
Third-party tools like Fastlane make it easier for iOS developers to build scripts. However, After Apple made changes to the underlying technology, Fastlane kept breaking, and developers spent hours, days and weeks fixing broken deployment scripts. In some cases, engineers must wait until Fastlane implements new changes.
If you are an iOS developer/engineer and want to be an iOS engineer for life, you don’t need to know this. However, if you want to grow in your career, you must have a detailed understanding of the underlying tools, technologies, and the entire iOS ecosystem. If you don’t understand these underlying technologies, no matter how good your iOS development skills are, you won’t get an iOS technical lead, iOS technical architect, or similar role. As a technical architect, you should be able to quickly fix code signing or similar infrastructure-related issues without relying on Xcode or other third-party tools.
2.1 Simple code signing
Background to the generation of code signatures
Before iOS came out, the previous mainstream operating system (Mac/Windows) software can be downloaded from anywhere, system security risks, pirated software, virus intrusion, silent installation and so on.
So Apple wants to solve this problem by making sure that every APP installed on iOS is officially approved by Apple.
To do this, you need code signatures.
How do you ensure that every APP you install is approved by Apple?
If you want to implement validation. The easiest way to do this is to create a pair of asymmetrically encrypted public and private keys via Apple.
There is a built-in public key in the iOS system, and the private key is saved by the Apple background. When we send the APP to AppStore, the Apple background signs the APP data with the private key.
After downloading the APP, the iOS system uses the public key to verify the signature. If the signature is correct, the APP must be authenticated by the Apple background and has not been modified, which meets Apple’s requirement: ensure that every APP installed is officially approved by Apple.
The process is simple, ensuring that every APP installed by Apple is officially approved. For most ordinary users, such a digital signature solves the security risks, but in fact, iOS devices install APP is not only the APP Store this channel, for example, for our iOSer, we are still in the real machine debugging APP development, of course, Apple also opened the enterprise internal distribution channels, These requirements can no longer be met by simple code signing.
To implement these requirements, you need a better mechanism, which is bidirectional code signing
2.2 iOS two-layer code signing
Background to the generation of two-layer code signatures
If we install the APP from the APP Store on our iOS device, it’s easy to do, nothing complicated, just a digital signature.
But there are actually other ways to install apps on iOS. For example, for our developer iOSER, we need to develop the APP directly real machine debugging. Moreover, Apple has also opened up the distribution channels within the enterprise, and the enterprise certificate signing APP also needs to be installed smoothly.
Apple needs to open up these ways to install apps, which can’t be met with a simple code signature.
Apple Dad uses two-layer signature technology to fulfill the following requirements: (1) The installation package does not need to be uploaded to the App Store, but can be installed directly on the mobile phone. (2) In order to ensure the security of the system, the installed App must have absolute control over the installed App. (3) The installed App can only be approved by Apple. (4) The installation of non-developed apps cannot be abused
2.2.1 Principles of two-layer code signature
First there are two roles. One is iOS and one is our Mac. Because iOS APP development environment in the Mac system. So this dependency became the basis of Apple’s two-tier signature.
The Xcode we used just needed a certificate to install the IPA on the phone.
When applying for a certificate, Xcode generates a pair of public/private keys for an asymmetric encryption algorithm in the Mac system (your Xcode does it for you). Public key M private key M. M = Mac
Apple has its own set of public and private keys. Just like the App Store, the private key is in apple’s background and the public key is in each iOS system. Public key A, private key A. A=Apple,
Send the public key M, along with some of your developer’s information, to the Apple background (this is the CSR file) and sign the public key M with the private key A in the Apple background. Get a piece of data that contains the public key M and its signature, and call this data a certificate.
As shown in the figure above, the certificate bidirectional signature verification process:
We Xcode went to the Apple server to ask for the certificate. This process used a CSR file, which has a core thing called the public key M. Xcode sends the MAC’s public key M to Apple’s servers via a CSR file.
After receiving the CSR file, the Apple server signs the public key M, that is, uses the apple server’s private key A to perform asymmetric RSA encryption. The public key M itself is not large, so it is not time-consuming. Encrypt it and you get a certificate. The certificate is A file encrypted by private key A, which contains the public key M. This certificate is our developer certificate.
Xcode signs our app using the private key M on the Mac. As long as we’re using Xcode to command + B to bulid we’re going to do this. The local private key M is our P12 file.
When Xcode packages the signature for us, it also packages the certificate.
When we install the IPA package, Apple checks the certificate to see if it is issued by Apple. If you do not have a certificate issued by Apple, you cannot install.
The iPhone decrypts the certificate in the IPA package using the public key A given by the Apple server carried in the certificate. If the certificate can be successfully decrypted, it is issued by Apple. If the certificate is not issued by Apple, the certificate cannot be decrypted.
The next step is to verify app and decrypt the certificate with public key A to get public key M. In this way, the app can be verified with the public key M.
During development, after compiling an APP, sign the APP with the local private key M(P12 you will export in the future), and package the certificate obtained in the third step together into the APP and install it on the mobile phone.
During the installation, the iOS system obtains the certificate and uses the built-in public key A to verify the digital signature of the certificate.
After verifying the certificate, 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 APP installation behavior is officially approved by Apple. (This only verifies installation behavior, not whether the APP has been changed, since APP content is constantly changing during development and Apple doesn’t need to deal with it.)
General flowchart of two-layer code signature
The above bidirectional code signing process can already ensure the developer’s authentication, and the security of the program. However, you should know that iOS programs can only be distributed to user devices through the APP Store. If there is only the above process, isn’t it possible to install them on all iOS devices as long as you apply for a certificate?
The above process verifies that the installed IPA is apple-approved, but not the installed IPA behavior.
To prevent abuse, Apple has added a few more restrictions, mainly limiting the number of devices installed through description files.
Next we need to know what the description file is.
3. Describe the file
3.1 Provisioning Profile
What is a description file?
The Interpretation of apple’s Xcode on Provisioning Profile is: A provisioning profile is a collection of digital entities that uniquely ties developers and devices to an authorized iPhone Development Team and enables a device to be used for testing.
A Provisioning Profile typically consists of three things: a certificate, an App ID, and a device. When we run or package a project in a real machine, certificates used to prove the security and legitimacy of our program Provisioning Profile here plays a role in the authorization of equipment and developers, he will developer accounts, certificates, Entitlements file and equipment bound.
During development, Xcode 8 and later automatically manage the Provisioining Profile for us by default, and automatically downloaded Provisioning profiles are stored~/Library/MobileDevice/Provisioning\ Profiles/In the directory, it is named in UUID format. It can also be copied by directly dragging the gear icon in the image below into Finder.
As we mentioned earlier, Apple’s security needs cannot be solved by simply signing code, so how does Apple prevent a single certificate from being installed on all devices?
Apple has added two restrictions: (1) only devices registered in the Apple background can be installed, and (2) the signature can only be for a specific APP.
Apple also wants to control iCloud/PUSH/ background/debugging within the App attach these Entitlements, so Apple refer to these permission switches as Entitlements(authorization files).
Moreover Apple has this Entitlements file in a document called *Provisioning Profile **. The description file is created on the AppleDevelop website (fill in the AppleID in Xcode and it will create it for you), and Xcode is packaged into the APP when it runs.
As IOS developers, we all know the rule: when applying for a certificate using a CSR, we also need to apply for one thing: a description file
In the Xcode project, we must download the description file from apple server through Xcode to debug the real machine, as shown below:
In addition to the information such as appID, the description file also contains the certificate encrypted with the private key A of the Apple server, which contains the public key M from the MAC to the server.
The process of generating a description file
The generated description file is what devices can be installed.. What is the ID of APP.. What are the permissions!
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.
We can use$security cms -D -i embedded.mobileprovisionCommand to seeProvisioning profileContent, theseXcodeTo create theProfileFiles are stored~/Library/MobileDevice/Provisioning Profiles/directory
We can view our Mach-O executable through MachOView
We can use it at the terminalSecurity CMS -d -i + [name]Command to view the information in the description file, we will find that the description file is a plist file
The ones in the red box above are the executables
As you can see from the above analysis, the description file is a PLIST file in XML format. Let’s explain some key attributes below.
DeveloperCertificates: Allowed developer certificates. This is a list that generally contains all valid Development certificates under the current developer account when the Provisioning Profile is generated. The certificates are stored in Base64 and decoded in Base64 to get developer certificates in DER. By calculating the SHA1 value of each certificate, you can see that the newly applied certificate is in this list
Entitlements: list of allowable permissions, Entitlements actually used in the App must be a subset of this list, otherwise the installation will fail to pass the verification and fail. If a feature has been enabled and Xcode automatically updates the Provisioning Profile and then turns it off, Xcode does not remove it from the Provisioning Profile, See com.apple.developer.team-identifier above.
ProvisionedDevices: list of devices that can be installed. If the UUID of the target device is not in this list, the installation will fail. For this, the general developer certificate and the enterprise developer certificate are treated differently. The normal developer certificate uses a Provisioning Profile to install apps on devices for testing and debugging purposes only, so Apple only allows a maximum of 100 devices to be registered for testing, otherwise developers can distribute their apps as they please under the name of testing. For enterprise developers, there is inherently an arbitrary install requirement, so at distribution, this is replaced by ProvisionsAllDevices, which represents licensing any device.
Xcode automatically reprovisioning a Provisioning Profile when any of this information changes, such as a developer certificate being added or expired, enabling a new feature in Capabilities that is not currently available in the App, or connecting a new iPhone to Xcode for testing.
Every time we create a new project, we actually generate a description file, and we choose to run it on the phone, and we just compile it and we can see it in the APP package.
A Provisioning Profile will be built into the App, embedded. Mobileprovision, in the App root. When installing the App if signature verification through, the files are automatically copied to the iOS devices/Library/MobileDevice/Provisioning \ Profiles/directory. Since this file has been officially signed by Apple, the system can trust it unconditionally and use it to verify whether the App signature, permissions, and UUID of the machine meet the authorization from the official. In this way, you indirectly trust apps signed with a developer certificate, allowing iOS devices to run apps that are not officially signed by Apple.
If you have a jailbroken device, any App you download from the AppStore won’t have the embedded. Mobileprovision file in it, because Apple will no longer need it after it’s re-signed.
In fact, we often come into contact with code signing in the development process, but we are automatically done by Xcode for us, so we are not familiar with the principle of code signing.
Recall that when we finished developing, we used Xcode’s Archive feature for packaging, and when we clicked Archive, Xcode compiled and linked our code, resulting in an.app file (technically a folder, Is the package file on the Mac, which is treated as a folder in the terminal. Xcode then copies the corresponding MobileProvision file to the APP file (which is the file we downloaded after configuring the provision profile). Details of this step can be seen in the Archive log under the “Process Product Packaging” step. After that, Xcode signs the APP file using the codesign command.
If we have multiple Signing identities, we can also configure them in the project “Build Settings” option
An unsigned APP file has a structure similar to this:
When signing APP files, CoDesign will directly add the corresponding signatures to the internal binary files, while for resource files, it uses a plist file named “CodeResources” to record the corresponding resource files and digital signatures. The content of the APP file after signing is as follows:
After completing the signature, we can use Xcode package to generate the corresponding IPA, which is convenient to install on the device later.
In addition, we can view the content via Xcode:
The Provisioning Profile itself is also signed, so don’t think you can change things in it to expand permissions/devices. Just go to the site and ask Apple for a profile with more permissions and more devices.
3.2 Authorization Document (Entitlements)
Entitlements Sandbox technology is a very important technology in iOS security system, his purpose is to restrict the behavior of App through various technical means, such as read-write path, allow access to hardware, allow the use of services and so on, even if the application of arbitrary code execution vulnerabilities, Nor can it affect systems outside the sandbox.
Commonly referred toEntitlements(Authorization document), is the configuration file of iOS sandbox, which declares the permissions required by the app. If a sandbox restricted function is used in the app, but the corresponding permissions are not declared, it may Crash directly when the relevant code is run. New iOS project is not this file, if in Capabilities open some functions that require permissions, Xcode will automatically (Xcode 8 and later version) generate Entilements file, and add Entitlements to Entitlements file.
This file is actually a PList file in XML format, with the following contents
In fact, the contents of this file are not all permissions, because by default the App contains the following permissions declarations related to the Team ID and App ID:
<dict><key>keychain-access-groups</key><array><string>xxxxxxxxxx.*</string></array><key>get-task-allow</key><true/><key>application-identifier</key><string>xxxxxxxxxx.test.CodeSign</string><key>com.apple.developer.team-identifier</key><string>xxxxxxxxxx</string></dict>Copy the code
Get-task-allow indicates whether debugging is allowed. It is a required permission during the development phase and removed when Archive packaging is used for shelving.
Code signature, will merge this Entitlements file (if any) with the default content of the above, obtain the final authorization file, and embedded in binary code, as part of the content to be signed, by the code signature to ensure its tamperability.
4. Store signature data
App’s signature data is saved in two parts:
The Mach-O executable writes the signature directly to the file
Other resource files will be stored in the _CodeSignature directory in the APP package.
The Mach-O executable writes the signature directly to the file
Other resource files will be stored in the _CodeSignature directory in the APP package.
5. IOS certificate file
5.1 Concepts related to Certificate Files
Certificate: the content is a public or private key, signed by the authentication authority to its packet! We developed the ability to use keystring access to see.
There are two types of certificates: developer certificate and publisher certificate. The former is used for development and the latter for release.
Emulator debugging without code signing; Real machine debugging requires developer certificate code signature; The certificate signature must be published
The code signature requires: certificate + private key
A provision profile must be installed on the device during commissioning. The provision profile contains the debugger certificate, list of authorized devices, and application ID. Each application corresponds to a description file.
Developer certificates can be divided into Development certificates and Distribution certificates by use: (1) Development certificate is used for the Development and test phase of the certificate, it is used to verify the integrity of the App after the Development phase of the App is installed on the device, the general name of the certificate is iPhone Developer: XXXXXXX. If it is a multi-team developer account, any member can apply for their own Development certificate. (2) Distribution certificate is the certificate used to submit AppStore, generally named iPhone Distribution: XXXXXXXXX, used for App store to verify the integrity of submitted App, only the administrator above the developer account can apply, so you can control the scope of submission permission. Also, the Distribution certificate cannot be used for issuing and debugging.
Enterprise developer Certificate: In addition to the normal developer certificate (used by individual developer accounts and corporate developer accounts), there is a special enterprise developer certificate that can be installed directly on any iOS device, as long as the user actively trusts the certificate. Its function is to facilitate enterprises to distribute productivity tools to internal employees. For example, there are often situations where enterprises do not have access to the Internet, so they cannot install applications through AppStore or use private apis to complete some functions not allowed by AppStore. The mechanism described above for installing and running without an Apple signature also applies to, and is the basis for, enterprise developer certificates.
P12: the local private key can be imported to other computers
Entitlements: Entitlements file, a plist file containing some Entitlements of APP
CertificateSigningRequest: CSR file contains the data files of local public key
Provisioning Profile: Description file, contains certificate/data, Entitlements, and data packets signed by apple background private keys.
How to share certificates in team development?
In team development, you need to share certificate files and private keys. Unable to code design using identities in this team: Unable to code design using identities in this team No private keys available (unable to sign code in team: no valid private key found). Solution: (1) open the key chain program, select the ‘secret key’ type. (2) Right click (or hold control click) the private key (private key) matching the development certificate, and click “Export”, save it as a Personal Information Exchange (.p12) file format, you will be prompted to create a password, and need the administrator password to export. (3) Copy the P12 file to another computer, you will be prompted to enter the password entered in the previous step.
5.1.1 Certificate-related Resources
Keystring program (common tools -> keystring), used to create a certificate request, install a certificate, export a private key, etc
IOS development center: developer.apple.com/devcenter/i…
IOS Provisioning Portal, where certificates, description files, push services, and more can be configured:
Developer.apple.com/ios/manage/…
IOS app release: itunesConnect.apple.com/
5.2 Developing the certificate Generation process
5.2.1 Generating a Certificate
Step 1: the corresponding is the keychain “from the certificate issuing authority request”, here is the local generates a pair of public and private key, save CertificateSigningRequest inside contains the public key, private key is stored in the local computer.
This operation will produce a called CertificateSigningRequest. CertSigningRequest signature request file, generate the file before actually Keychain has automatically generated a probability, the private key
You can right-click this entry in the Keychain and choose Export from the shortcut menu to export the key file as a P12 file and use OpenSSL to view its contents
$ openssl pkcs12 -in JustForTesting.p12 -out private_key.pem Export the key in the P12 fileEnter Import Password: # Enter the Password of the P12 file. MAC verified OK Enter PEM pass phrase: Verifying - Enter PEM pass phrase: # Confirm the password$ openssl rsa -in private_key.pem -noout -text View the contents of the key fileEnter pass phrase for private_key.pem: # Enter the Key file password private-key: (2048 bit) Modulus: 00:c2:98:f5:02:eb:dc:a6:fd:4b:12:4c:70:17:a6: xx:xx:xx:xx:xx:xx:xx:... publicExponent: 65537 (0x10001) privateExponent: 00:a1:67:68:e1:51:6c:a4:fd:36:45:29:2d:58:10: xx:xx:xx:xx:xx:xx:xx:... prime1: 00:f3:91:5d:5b:dc:c1:de:d2:ab:7a:5f:b2:27:41: xx:xx:xx:xx:xx:xx:xx:... prime2: 00:cc:87:b5:c9:7e:81:39:94:13:c1:ff:3f:d7:7b: xx:xx:xx:xx:xx:xx:xx:... exponent1: 00:a5:a0:22:c0:f5:d3:eb:86:8c:4e:b1:c6:3e:85: xx:xx:xx:xx:xx:xx:xx:... exponent2: 00:8b:e1:00:85:a6:7c:10:79:e2:2d:5a:39:3a:51: xx:xx:xx:xx:xx:xx:xx:... coefficient: 7e:30:60:84:fc:47:6b:90:fe:e7:32:1a:2f:b0:c4: xx:xx:xx:xx:xx:xx:xx:...Copy the code
Modulus n = P * q publicExponent = public key factor The value is e (0x10001 (65535)). The privateExponent is the private key factor (d)
Modulus + PublicExponent, self-signature (signed with your own private key). You can view the contents of the CSR file with openssl command:
Step 2: Apply to Apple to generate a certificate corresponding to transferring the CSR to apple background.
On the Apple Developer website, submit a CSR to Apple for signature, and Apple will return a signed certificate file with the suffix CER.
First check his SHA1 value
$ shasum ios_development.cer
11447116f2c5521b057b9b67290f0fdadeadfa0a ios_development.cer
Copy the code
Double-click to import the CSR to the Keychain. The Keychain will automatically group the keys automatically generated when the CSR is created. Whether you look in the certificate list or the key list, you will see the other half that matches it.
You can get a few key things from the certificate:
The owner of the certificate, which is not designated by us, is automatically generated by the issuer Apple according to our account information
The issuer of the certificate is the CA mentioned above
The public key information of the certificate is the same as the previously generated key file and CSR
Now you can understand the relationship between a certificate and a key. The key contains the private key and the public key, the private key is used for signing, and the certificate contains only the public key, which is authenticated by a third-party CA for decryption and verification.
Such a certificate chain mechanism simplifies the work of the root certificate Authority and improves the security of certificate management. The root certification Authority only needs to manage and issue the certificates of the lower-level authorities. This reduces the frequency of using the root certification Authority’s private key and reduces the risk of private key disclosure. Intermediate certificate authorities have their own responsibilities, and even if there is a major security incident such as a private key leak, the entire certificate network will not be affected.
Step 3: Download the certificate locally. There are two local certificates. One is the private key generated in step 1, and the other is the certificate downloaded from here. Keychain will associate these 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 private key is only available on the Mac that generated it. What if other Macs want to compile and sign this App? The answer is to export the private key to another Mac. If you export the private key to a keychain, it will be saved as a.p12 file. Other Macs will import the private key when they open it.
Step 4: Do it all on the Apple web site, configure AppID/permissions/devices, etc., and download the Provisioning Profile.
Step 5: XCode will use the certificate downloaded in step 3 (with the public key), find the corresponding private key locally (generated in step 1), and use the local private key to sign the App. And package the Provisioning Profile named Embedded. Mobileprovision. So any locally debugged APP will have an Embedded. Mobileprovision (description file) downloaded from the APP Store without one.
