preface

The beginning of this article, is the reverse security attack and defense class really began, first to explain the application of signature this knowledge point.

1. Code signature

Code signing is the digital signature of an executable file or script. See 07- Cryptography (3) to ensure that the 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.

1.1 Simple code signing

Before iOS came out, the previous mainstream operating system (Mac/Windows) software can be downloaded from anywhere, there are hidden dangers of system security, pirated software, virus intrusion, silent installation and so on. Apple wants to solve this problem by ensuring that every APP installed on iOS is officially approved by Apple. How do you ensure that? It’s just a code signature.

The easiest way to verify this is through a pair of public and private keys that Apple officially generates for asymmetric encryption. There is a built-in public key in iOS, and the private key is stored in the background by Apple. When we upload the APP to AppStore, Apple background signs the APP data with the private key. After downloading the APP, iOS system verifies the signature with the public key. If the signature is correct, the APP must have been authenticated by Apple and has not been modified, which meets Apple’s requirement that every APP installed is approved by Apple. The whole process is shown below 👇

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, in the development of APP need to be directly real machine debugging, and Apple also opened the enterprise internal distribution channels, enterprise certificate signature APP also need to be installed smoothly. Apple needs to open up these ways to install apps, which can’t be met with a simple code signature.

1.2 Apple demand

  1. The installation package does not need to be uploaded to the App Store and can be installed directly on the phone.
  2. In order to ensure the security of the system, Apple must have absolute control over the installed apps:
    • Install with Apple’s permission
    • Cannot be abused to allow non-development apps to be installed

In order to meet these requirements, the complexity of iOS signature is also increased 👉 Apple’s solution is a two-layer signature.

Two, double signature

A two-layer signature has two roles 👇

  1. iOS
  2. Mac system

Since the iOS APP development environment is on the Mac, this dependency becomes the basis of Apple’s two-tier signature.

2.1 Two-layer Signature Process

  1. inMac systemGenerate a pair of asymmetric encryption algorithmsPublic key private key(Xcode does it for you,Key string). This is calledPublic key M Private key M (M = Mac).
  2. Apple itself has a fixed pair of public and private keys, and beforePrinciple of the App StoreAgain, the private key is in the Apple background and the public key is in every iOS system. This is calledPublic key A, private key A (A=Apple).
  3. thePublic key MAnd some information about the developersApple's backgroundHere it isCSR file),Apple's backgroundIn theThe private key is AGo to the signaturePublic key M. Get a piece of data that contains the public key M and its signature, and call this piece of datacertificate. hereApple serversIs equivalent toAuthentication server.
  4. During development, after compiling an APP, uselocaltheThe private key M(export ofP12) for theAPPforThe signature(The certificate and p12 are bound together), and get the results from step 3Certificate packageInto theAPPInstall it on your phone.
  5. During installation,iOSachievecertificateThrough theBuilt-in public key AGo to thevalidationThe certificate ofA digital signatureIs it correct?
  6. After verifying the certificate, it is ensuredPublic key MIt’s approved by Apple. Use it againPublic key MTo verify theThe signature of the APPP12 signatureThe private key M), here is an indirect verification of this APPInstall the behaviorIs it officially approved by Apple. (This is only validatedInstall the behavior, no validationWhether the APP has been changedBecause APP content is constantly changing during development, Apple doesn’t have to.)

This two-tier signature process is not the final iOS signature principle, but it has to be added to it.

With the two-layer signature process, developer authentication and application security are already guaranteed. 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?

Description file

In order to solve the above problem, the Apple system comes up with another solution 👉 description file.

A Provisioning Profile typically consists of three things: 👉 certificate, App ID, and device. Certificates are used to prove the security and validity of our programs when we run or package a project on a real machine.

In order to solve the problem of app abuse, Apple has added two more restrictions 👇

  1. Limit it to the Apple backgroundRegistered devicesCan be installed.
  2. limitThe signatureonlyTo a particularspecificAPP.

And Apple also wants to control the App inside iCloud/PUSH/ background run/debugging additional these Entitlements, so Apple call these permission switches uniform Entitlements(Entitlements file). And put it in a file 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. � So when we use CSR to apply for a certificate, we also need to apply for one thing — the description file!

In development, you compile an APP, sign the APP with the local private key M, and pack the Provisioning Profile from Apple’s servers into the APP called Embedded. Mobileprovision. Install the APP on your phone. Finally, the system is verified.

With the description file, the double check above becomes 👇

The certificate is bound to the description file.

Viewing the Description file

View the command 👇

security cms -D -i embedded.mobileprovision

The signature file of App is in the -Codesignature folder 👇 in the IPA package

You can also drag the binaries into MachOView and look for Code Signature 👇

conclusion

  • Apple Signature Principles
    • The MacGenerate a pair ofPublic key M and private key M.
      • Create using the local public key MCSR file, request certificate
      • Key string will becertificateandLocal private key M (P12 certificate)Do the associated
    • Apple serversUse of localThe private key is AgenerateCertificate and description file
      • certificate 👉 The Mac's public key MAs well asThe signature
      • Description file 👉 Device list, AppID list, permission
    • iOSIn the systemPublic key A(paired with the Apple server private key) authenticates the App.
      • validationDescription fileWhether or notcertificatematching
      • validationApp installation behavior(Pass verificationcertificate, take out the certificatePublic key MrightSignature of App (P12 private key M)Verify)