Recently saw Objc.io on the 17th issue of the article "Inside code Signing" corresponding to the Chinese translation version of "Code signature Analysis", the benefit is quite deep, the iOS code signing mechanism has a further understanding. For more details, we'd better go and see the original article.
The following is an understanding of this article and then combined with their previous knowledge of this part of the study notes written. The premise of this paper is that we have a certain understanding of asymmetric encryption.
First, digital signature (digitally signature)
Uses a hashing algorithm for the specified information, obtains a fixed-length information digest, and then uses the private key (note must be the private key) to encrypt the digest, the digital signature is obtained. The so-called code signature is what this means.
Second, digital certificate (certificate)
Certificate generation
When applying for an iOS development certificate, developers need to generate a CSR file via keychain (Certificate Signing request), which is submitted to Apple worldwide Developer relations Certification authority (WWDR) certification Center for signature, and finally downloaded from the Apple official website and installed use. This process also generates a private key, where the certificate and private key are located in the keychain.
Certificate composition
The digital certificate after WWDR digital signature looks like this:
It consists of two parts:
· The certificate itself
Contains information about the user's public key, user's personal information, certification Authority information, certificate validity period, and so on.
· Certificate signing
WWDR uses the hash algorithm of the certificate itself to obtain a fixed-length information digest, and then uses its own private key to encrypt the information digest to generate a digital signature, the entire process:
Certificate usage
The iOS system originally holds the public key of the WWDR, the system first calculates the content of the certificate through the specified hash algorithm to obtain a message digest, and then uses the public key of WWDR to decrypt the digital signature contained in the certificate, thus obtains the information digest which the WWDR private key encrypts, and finally compares two summary of information, If the content is the same, it means that the certificate is trustworthy. The whole process:
After verifying that the certificate is trustworthy, the iOS system can obtain the public key of the developer included in the certificate and use that public key to determine the availability of the code signature.
The meaning of certificate existence
Through the certificate use process can be seen, the certificate itself is only an intermediary, the iOS system does not care about the certificate, it actually only want the certificate contains the developer's public key!!
But how can developers prove that the public key is their own? How can the iOS Security system Trust this public key as the developer?
No matter which developer is on the iOS security system, this public key is mine, the system is not believed, that is, the system of developers have a sense of distrust. But the iOS security system is trustworthy for its wwdr, and Apple has built the WWDR public key into the iOS system. With the certificate, the iOS security system only needs to pass the WWDR public key to obtain to any developer's trusted public key, this is the certificate existence significance!!
Third, public key
The public key is included in the digital certificate, and the digital certificate is included in the description file (Provisioning file), which is copied to the iOS device when the app is installed.
The iOS security system can determine the developer identity through the certificate, it can be obtained from the certificate by the public key to verify that the developer with the public key corresponding to the private key signed code, resource files, etc. have been changed to destroy, and finally determine whether the application is legitimate on the iOS device legitimate operation.
Iv. private Key
Each certificate (in fact, the public key) should have a private key,
The private key is used to sign code, resource files, and so on. Only development certificates and profiles are not properly debugged because no private key can be signed at all.
Thereafter the content is basically from the "Code signature analysis" Excerpt from the notes, suggest you look at the original.
V. Signature-related commands
A certificate that can be used to sign code in a Quick View system
You can use the following command:
| 123 | $security find-identity -v -p codesigning 1) F10B42FFDE18DF28BA21190121439F2E04BEE4B8 "iPhone Developer: weizheng li (P7QJ74LFSA)" 1 valid identities found |
This means that there is currently a certificate available that has both a public and private key.
Sign the unsigned app manually
Use the following command:
| 1 | $ codesign -s ‘iPhone Developer: Thomas Kollbach (7TPNXN7G6K)‘Example.app |
Re-signing the signed app
In order to reset the signature, you must take the-f parameter, and with this parameter, Codesign will replace the one that already exists with the signature of your choice:
| 1 | $ codesign -f -s ‘iPhone Developer: Thomas Kollbach (7TPNXN7G6K)‘Example.app |
View signature information for a specified app
Codesign can also provide you with information about the status of an executable file's signature, which can provide great help when an unknown error occurs:
| 1 | $ codesign -vv -d Example.app |
The following signature information about Example.app is listed:
| 12345678910111213 | |
Verifying the integrity of the signature file
To check if the signed file is complete, you can use the following command:
| 1 | $ codesign --verify Example.app |
Just like most UNIX tools, there is no output to represent that the signature is intact. If you modify this binary file:
| 123 | $ echo ‘lol‘>> Example.app/Example$ codesign --verify Example.appExample.app: main executable failed strict validation |
As expected, modifying an application that has already been signed will cause digital signature validation to pass.
Vi. Resource File Signature
The apps and frameworks for IOS and OS X include the resources they need. These resources include images and different language files, and resources include important application components such as xib/nib files, archive files (archives), and even certificate files. So when you set a signature for a package, all the resource files in the package are also set to be signed.
To achieve the purpose of signing for all files, the signature process creates a new file called _codesignatue/coderesources in the package (that is, Example.app), which stores the signatures of all the files in the signed package. You can view the signature list file yourself, which is just a plist format file.
This list file contains not only a list of files and their signatures, but also a set of rules that determine which resource files should be signed. With the release of OS X 10.10 DP 5 and 10.9.5, Apple changed the format of the code signature and changed the rules about the resources. If you use 10.9.5 or a later version of the Codesign tool, there will be 4 different areas in the Coderesources file, where rules and files are prepared for the old version, and Files2 and Rules2 are prepared for the new second version of the code signature. The main difference is that in the new version you will no longer be able to exclude certain resource files from the code signature, in the past you can, just add a file named Resourcerules.plist in the package that is signed. This file specifies which resource files should be ignored when checking that the code signature is intact. However, in the new version of code signing, this practice is no longer valid. All code files and resource files must be signed and no longer have exceptions. In the new version of code signing, an executable package in a package, such as an extension (extension), is a standalone individual that needs to set a signature and should be treated separately when checking whether the signature is complete.
Vii. Authorization Document (entitlements)
What your app can do on IOS is still a sandbox limitation, and most of these restrictions are determined by the authorization file (entitlements). The authorization mechanism determines which system resources are allowed to be used by an application, which is simply a sandbox configuration list.
Run the following command:
| 1 | $ codesign -d --entitlements - Example.app |
Will get a similar result:
| 123456789101112131415161718192021222324 | |
After you select some options under the Capabilities tab of Xcode, Xcode generates such an XML. Xcode automatically generates a. entitlements file and adds entries to it when needed. When the entire application is built, this file is also presented to codesign as a reference to what authorization is required for the application. These authorization information must be enabled in the developer Center App ID and included in the profile described later in this article. The authorization file that you need to use to build your app can be set in the code signing entitlements in Xcode build setting.
After the new version of Xcode 6, the list of authorized information is included in the app package as a file of the name Example.app.xcent. This may be done to provide more useful error information when a configuration error occurs.
Viii. Description Document (provisioning file)
There is one component in the entire code signing and sandbox mechanism that links the signature, authorization, and sandbox, which is the description file (provisioning profiles).
Save directory in OS X
Xcode will have all the profiles downloaded from the Developer Center here:
| 1 | ~/Library/MobileDevice/Provisioning Profiles |
File format
The description file is not an ordinary plist file, it is a file that is encrypted according to the password message syntax (Cryptographic message Syntax).
The command to view the file in XML format:
| 1 | $ security cms -D -i example.mobileprovision |
File contents
The description file mainly contains the following content:
· Uuid
Each configuration file has its own UUID. Xcode uses this UUID as an identifier to record which profile you chose in build settings.
· Provisioneddevices
Records all device IDs that are available for debugging.
· Developercertificates
Contains all certificates that can be signed for an app that uses this profile. All certificates are based on BASE64 encoded in PEM (Privacy enhanced Mail, RFC 1848) format.
· Entitlements
Everything about the previously mentioned configuration file will be saved here.
IOS Code Signing Learning notes < transliteration >
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
1 on 1 presale consultation
24/7 Technical Support 6 Free Tickets per Quarter Faster Response
Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.
A comprehensive suite of global cloud computing services to power your business
Payment Methods We Support
