Code signing is the digital signing of 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.

Simple code signing

  • 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, to ensure that every APP installed on iOS is approved by Apple official, how to ensure? It’s just a code signature.
  • 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 upload the APP to AppStore, the Apple background signs the APP data with the private key. After downloading the APP, the iOS system verifies the signature with the public key Apple’s requirement: Make sure every APP you install is approved by Apple.
  • 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.

I understand it

  • The ios system in our phones has a built-in public key, and the private key is in the background of Apple.
  • When the APP is launched, AppStore signs the APP data, which is RSA encryption of the HASH value of the APP code
  • When other users download the APP, the public key decrypts the HASH value and computes the HASH of the APP using the same algorithm locally. If the signature is correct, the APP must be authenticated by the APP background

Other problems

  • Real machine commissioning
  • Distribute apps within the enterprise

Apple’s needs

So let’s analyze what its requirements are:

  • The installation package does not need to be uploaded to the App Store and can be installed directly on the phone.
  • In order to ensure the security of the system, Apple must also 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 signatures has also begun to increase, and apple’s solution here is a two-layer signature.

Double-layer code signature

  • In order to meet some of Apple’s requirements for authentication applications, the complexity of iOS signatures has increased, and Apple has proposed a two-layer signature scheme.

  • This is not how the final iOS signature works. The final iOS signature has to be a little bit more based on this.

  • 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.

Namely: a phone, a computer, an Apple server, the appStore. Four, the direct relationship

  • 1. Generate a pair of public/private keys for an asymmetric encryption algorithm on the Mac (your Xcode does it for you). Public key M private key M. M = Mac

  • 2. Apple has a fixed pair of public and private keys. Just like the principle of the App Store before, the private key is in the Background of Apple and the public key is in each iOS system. This is called public key A and private key A. A=Apple

  • 3. Send the public key M and some of your developer’s information to the Apple background (this is the CSR file), and use the private key A in the Apple background to sign the public key M. Get a piece of data that contains the public key M and its signature, and call this data a certificate.

  • 1. The Mac generates a CSR file, which contains the developer’s information and its public key M (the main information) and sends it to the Apple server.
  • 2. The Apple server encrypts the public key M and the HASH value of the generated public key M with RSA. The data signature generates a certificate file and returns it. Apple servers act as a certification authority, issuing certificates.
  • 3. Private key M is a.P12 file
  • 4. I developed an APP on the computer. I used the private key M to sign the APP and calculate HASH value on MachO, the execution file of the APP, and binary data file, while using the private key M to encrypt HASH value. Together with the certificate we got from Apple, we packaged it and uploaded it to APPStore. After the review of the APP, the APP can be used by users.
  • 5. The user downloads the IPA package and loads it into the mobile phone. Public key A in the mobile ios system authenticates and decrypts the certificate to obtain the public key M and the HASH value. Public key M calculates A HASH value using the same algorithm to compare the obtained HASH value and verify whether the data is tampered with. After passing, I use the public key M to decrypt the signature data of this APP. Public key A decrypts the certificate to obtain public key M.
  • 6. Public key M decrypts the signature of APP and verifies and decrypts the MachO execution file. Passing indicates that you have been authenticated by Apple’s servers.

Description file

  • To address the problem of app abuse, Apple has added two more restrictions.
    • First, only devices registered in the Apple background can be installed.
    • The second restriction signature can only be applied to a specific APP.
    • 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 apply for a certificate using CSR, we also apply for one more thing!! That’s the description file!
    • 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. Finally, the system is verified.

conclusion

  • 1. The Mac generates a pair of public and private keys
    • Create a CSR file using the local public key, request a certificate, open the keychain -> Certificate Assistant -> Request a certificate from a certificate Authority -> fill in the information and download it locally. Request certificate login AppleDeveloper, to open just after the SCR file download, there are development certificates and issued certificates, detailed steps please Baidu, a lot of people have written.
    • Keystring associates the certificate with the local private key (P12 certificate)
  • 2. Apple servers use local private keys (the server’s own private key is not our computer’s private key) to generate certificates and descriptions
    • The certificate contains the MAC’s public key and the signature (the HASH value of the encrypted public key M)
    • Description file: Device list, AppID list, permissions (push permissions and others)
  • 3. The ios system (mobile phone) uses the public key in the system (which is a pair with the private key of the Apple server) to verify the APP
    • Verify that the description file matches the certificate
    • Verify the installation behavior of APP (by verifying the certificate, taking out the public key in the certificate and the signature of APP for verification)