Certificate of principle

Asymmetric encryption (public/private key encryption) is at the heart of various certificates in iOS development. The principle of asymmetric encryption is not introduced in this paper.

To get behind the scenes of certificates, we need to understand two key concepts:

  • A digital signature
  • The digital certificate

A digital signature

Digital Signature is the realization of a function equivalent to stamping in the real world in the field of Digital information. Digital signatures can detect tampering and spoofing.

In digital signature technology, there are two kinds of behavior:

  • Signature is generated
  • Signature verification

Signature is generated

Signature generation is carried out by the initiator in the communication, and the process is as follows. The contents of the communication are first hashed, then encrypted using the sender’s private key, and finally signed.

Signature verification

Signature verification is performed by the receiver in the communication, and the process is shown below. Generally, the sender sends the message, the signature, and the hash algorithm together to the receiver. The receiver first decrypts the signature using the sender’s public key to get a digest. The message is then hashed using the same hash algorithm to compute another digest. Finally, the two digests are judged to be equal. If they are equal, the received message has not been tampered with by a third party.

So how does the receiver get the sender’s public key? How does the receiver determine that the public key belongs to the sender? That’s what digital certificates do.

The digital certificate

Digital Certificate is a realization of the functions equivalent to id card in the real world in the field of Digital information. A digital Certificate contains the identity information of an individual or organization and its Public Key, so it is also called a public-key Certificate (PKC).

Similar to the IDENTITY card is issued by the authoritative public security bureau, the public key Certificate is also issued by the authoritative Certificate Authority (CA). The authentication authority provides the recipient with the sender’s certificate, which contains the sender’s identity information and public key. To prevent the certificate from being tampered during certificate issuance, the authentication authority uses the IDENTITY information and public key as the message, uses the CA private key to sign the message, and then adds the identity information, public key, and signature to the certificate, as shown in the following figure.

Root certificate

When receiving the sender’s certificate, the receiver uses the CA public key to authenticate the certificate.

However, it is important to note that in many cases the CA public key is issued by another, more authoritative authority.

Certificates similar to the local public security bureau are issued by the municipal public security Bureau, which in turn are issued by the provincial public security Bureau. A Certificate has a Chain of Trust. Root Certificate is the source of Trust, that is, the origin of the Trust Chain.

The issuer of the Root Certificate is called the Root Certificate Authority (Root CA). The Root Certificate is a self-signed Certificate issued by the Root CA. Installing a Certificate means that you trust the CA authority.

Certificates can be divided into three types based on their position in the trust chain:

  • Root Certificate
  • Intermediate Certificate
  • Leaf Certificate

This raises a fundamental question: How do you ensure that the root certificate is trusted?

In fact, root certificates are installed with software. For example, a list of trusted root certificates is built-in during operating system installation.

Certificate of iOS

First, let’s take a look at an example of a trust chain for iOS development certificates in MacOS (viewed through the keychain) :

  • Apple Root Certificate Authority: indicates the Root Certificate
  • Apple Worldwide Developer Relations Certification Authority
  • IPhone Developer: XXX (XXXXXXX) : Leaf certificate
  • IPhone Distribution: Apple Tech: Leaf Certificate

Root Certificate Apple Root Certificate Authority is built-in during MacOS installation and is issued by the Apple Root CA.

The Apple World Developer Relations Certificate Authority (the actual file is Applewwdrca.cer) is built-in with Xcode installation and is issued by the Apple Root CA. Although applewwdrca. cer is an intermediate certificate, it is the root certificate for the iOS development category;

The certificates we use for development are leaf certificates issued by the Apple Worldwide Developer Relations Certification Authority.

Application for development Certificate

  • The developer locally generates the key pair (public and private keys) and provides the developer’s identity information.
  • Sends the public key and identity information in the key pair to the AppleWWDRCA.
  • AppleWWDRCA Uses the AppleWWDRCA private key to sign the developer’s public key and identity information.
  • AppleWWDRCA assembles the developer’s public key, identity information, and signature into a certificate for download.

Note: Download the certificate from Apple Member Center website to Mac and double click to install.

When manually clicking *. Cer to install the certificate into macOS, Keychain Access traces its issuing CA to Apple Worldwide Developer Relations Certification Authority (Apple Worldwide Developer Relations Certification Authority), The public key of AppleWWDRCA certificate is used to decrypt and verify the digital signature of the development certificate. If the verification succeeds, This certificate is valid.

IOS Certificate types:

  • Development: Development certificate, used to develop and debug App. The general certificate name is iPhone Developer: XXX. If it is a multi-team developer account, any member can apply for their own Development certificate.

  • Distribution: distributes a certificate for distributing apps. The common certificate name is iPhone Distribution: XXX. Only the developer account with administrator status can apply, so you can control the scope of submission permission.

  • Ad-house, Ad-Hoc and App Store all use distribution certificates. After ad-House is distributed with enterprise certificates, there is no limit on the number of installs, while Ad-Hoc has a limit on the number of installs

The following describes the development certificate during iOS App development and debugging.

App ID

App ID is the Product ID, which identifies one or a group of apps.

The App ID string is usually prefixed with the Company Identifier (Company ID) in reverse-domain-name format and contains no more than 255 ASCII characters.

The full name of the App ID is appended with an Application Identifier Prefix (typically TeamID). App ids can be divided into two types:

  • Explicit App ID: The unique App ID used to identify an application. For example, com.apple. garageBand is an App that identifies the Bundle Identifier as com.apple. garageBand.
  • Wildcard App ID: App ID with a Wildcard, used to identify a group of applications. * used to identify Bundle identifiers with com.apple. All apps at the beginning (Apple).

Developers can Register or Delete registered App IDs on the Developer Member Center website.

In Xcode, the configuration item Xcode Target -> Info -> Bunlde Identifier must be consistent with the App ID (Explicit) or matched (Wildcard).

Note: Registering an App ID allows the developer to tick the required Capabilities TAB. This matches Entitlements as described above.

Device id

A Device is an iOS Device used for development and debugging. Each Apple Device is uniquely identified by a Unique Device Identifier (UUID).

The Device under the personal account of Apple Member Center website contains all registered devices that can be used for development and testing. The average personal development account can register 100 devices at most every year.

Developers can register or Enable/Disable registered devices on the site.

Authorization Document (Entitlements)

Sandbox technology is a very important technology in iOS security system. Its purpose is to restrict the behavior of App, such as: the path that can be read and written, the hardware that can be accessed, the service that can be used, and so on. Therefore, if a bug occurs in the code, it will not affect the system outside the sandbox.

Sandbox uses Entitlements files/to declare permissions for App. If a sandbox restriction function is used in the App, but the corresponding permission is not declared, the relevant code will Crash directly.

New project is no Entitlements file, if in [Capabilities] open the required Entitlements, Xcode will automatically generate Entitlements file, and add the corresponding Entitlements statement to the file.

Entitlements file is a PLIST file in XML format, Entitlements in projects generally with the suffix.Entitlements, its content is as follows:

In fact, Entitlements are not all statements of entitlement within the document. By default, App contains permissions related to TeamID and App ID, as follows:

Get-task-allow indicates whether debugging is allowed. It is a required permission during the development phase and removed when Archive is packaged for shelving.

Note: code signature, will merge Entitlements file (if any) with the default content of the above, get the final authorization file, and embedded in binary code, as part of the content to be signed, by the code signature to ensure its tamper-proof.

Provisioning Profile

A Provisioning Profile (PP) contains all of the above:

  • App ID (App ID can declare required sandbox permissions at registration, therefore includes Entitlements)
  • certificate
  • Device ID

A Provisioning Profile corresponds to a Explicit ID or Wildcard ID. When manually creating a Provisioning Profile on a Web site, you specify the following three items in sequence:

  • App ID: single option (Sandbox permission, multiple options available)
  • Certificates: Certificates, optional, for multiple developers
  • Devices: multiple options, corresponding to more development Devices

Developers can download the Provisioning Profile, which is a.mobileprovision file. Developers can also Delete a registered Provisioning Profile. Constitute a

. Mobileprovision contains the following fields and contents:

  • Name: indicates the Mobileprovision file.
  • UUID: the real file name of the Mobileprivision file, which is a unique identifier.
  • TeamName: Apple ID account name.
  • TeamIdentifier: Team Identity.
  • AppIDName: explicit/wildcard Apple ID name (ApplicationIdentifierPrefix).
  • The prefix ApplicationIdentifierPrefix: complete the App ID.
  • ProvisionedDevices: UUID of all development devices authorized by the.mobileprovision provision.
  • DeveloperCertificates: This.mobileprovision allows you to use certificates to sign your application, depending on the developer. If you use a certificate that is not in this list, the code signing failed will appear.
  • Entitlements: contains a set of key-value pairs. ,.
    • Keychain access – groups: $(AppIdentifierPrefix)
    • Application-identifier: The full name with a prefix. Such as: $(AppIdentifierPrefix) com. Apple. Garageband
    • Com. Apple. Security. Application – groups: App Group ID.
    • Com.apple.developer. Team-identifier: the same team identifier

Sign & Pack

1. First, Xcode checks that the Signing (certificate) configuration matches the Provisioning Profile. Otherwise, an error will be reported.

Second, Xcode checks to see if the Signing & Capabilities certificate has the corresponding Public/Private Key Pair in the native Keychain Access. Otherwise, the compiler will report an error.

3, the Xcode certificate then executes the private Key Pair application content (Executable Code, Resources such as images and NIb files are not signed) for signing (CodeSign). Note: Entitlements files can also be embedded within the content to be signed.

Eventually, signatures, Provisioning profiles, and applications are packaged into.ipA

The app file

In the case of solar.app, the.app directory contains the following types of files:

  • Executable file: The executable file named after the project name. Such as: Solar.
  • Xxx. bundle: resource files corresponding to different SDKS and pods.
  • Xxx. lproj: multilingual localization resource file. Each language defines its resources separately, including images, text, Storyboard, Xib, and so on.
  • Frameworks: contains third-party static libraries and Swift dynamic libraries used by apps.
  • Info.plist: app configuration, including: Bundle Identifier, executable file name, etc.
  • Embedded. Mobileprovision: Provisioning Profile.
  • _CodeSignature/CodeResources: a file, save the signature of each file hash value (abstract), to encrypt the hash value does not need to have, because of the asymmetric encryption is relatively poor, the performance of all encryption will only slow down the speed of the signature and verification.

When running test packages and formal packages on a real machine, the system validates them differently. In short, the test pack performs complete signature verification on the device; The verification process of the official package is handed over to the App Store, and the App Store will re-sign after the verification. The verification process is much simpler after the device downloads the official package.

The validation process of the test package.

The App is verified when it is installed and running on the device.

1, first of all, the equipment system will be on the App bundle ID, Entitlements, certificate and Provisioning Profile App ID, Entitlements, certificates matching verification, Otherwise, the App cannot be launched.

2. Secondly, the device uses the built-in CA public key to sign the matched certificate in the Provisioning Profile to verify the validity of the matched certificate.

3. The device system then takes the public key out of the Provisioning Profile’s matching CA-validated certificate (that is, the packaged application developer’s certificate) and signs the App. Otherwise, the App cannot start.

4. Finally, the Device system matches the Device ID of the Device with the Device ID in the Provisioning Profile. Otherwise, the App cannot be started.

Formal package

If you have a jailbroken device and look at any of the apps you download from the App Store, you will find no embedded. Mobileprovision file because the App Store has already validated the App (similar to the validation process for the test pack above). When the App passes the verification, Apple Store will re-sign the App, as shown in the picture below. The re-signed content will no longer contain the Provisioning Profile, nor will it be included in the final IPA file.

When the device downloads an App from the App Store, it directly uses the CA public key on the device to verify the IPA signature. Compared with the signature verification of the test package, the signature verification of the formal package is much simpler, because part of the verification work has been completed by the App Store.

Certificate invalid solution

This is a common problem. This error indicates that the Apple Worldwide Developer Relationship certificate AppleWWDRCA is not installed on the development device, or the installed WWDRCA is invalid. Solutions:

The current Apple Worldwide Developer Relationship Certification intermediate certificate, WWDRCA (the one we downloaded above), expires on February 7, 2023. Apple has released a new WWDRCA with an updated certificate expiration date of February 20, 2030. The new certificate will be used to sign new software signing certificates issued for Apple developer programs after January 28, 2021.

Therefore, we need to download and install the new WWDRCA: www.apple.com/certificate…

Apple Certificate List:www.apple.com/certificate…

Push the certificate to the pem command

Step 1 Convert aps_development.cer into a PEM file. Cer -inform der -out aps_development.pem 2. Convert the p12 private key file to a PEM file. $openssl pkcs12 -nocerts -out key.pem -in key.p12 3. $ cat aps_development.pem key.pem > ck.pemCopy the code

The development and production environments are transformed in the same way

Sharing development accounts and certificates across multiple machines

After the CER is installed locally and matches the local private key. We usually make a backup of the certificate, which is a P12 file. P12 backup file = CER file + private key; So with this P12 there is no need to worry about certificate loss. Operation diagram: After the CER is installed locally and matches the local private key. We usually make a backup of the certificate, which is a P12 file. P12 backup file = CER file + private key; So with this P12 there is no need to worry about certificate loss. Operation diagram:

Note: Two files are required for a successful installation on someone else’s computer:

1. The. P12 file is exported.

2. The p12 file corresponding to “certificate” in apple developer is an encrypted certificate, so you can use these two files for other MAC devices. After getting these two files, double-click development Description file and P12 file one by one. The function of “description file” is to be placed in Xcode to let Xcode know the legitimacy of our development. After adding, it can be used.

Testlight release

Package it with a production certificate and submit it to APP Connect for self-distribution