Rambling on about certificates and signatures in iOS applications

Contact iOS development for half a year, has also been confused by the theme pit, but also on Taobao to buy enterprise certificate signature these services, a big god have done a fully automatic release package (but this big god now does not sell enterprise certificate), very envy and worship. Therefore, I spent some time to study the iOS certificate and signature mechanism, and write to share with friends who need it. As a result of my talent and learning, there are many omissions or mistakes, but also ask great god to give advice.

Asymmetric encryption and digests

Asymmetric encryption features and usage

Asymmetric encryption algorithms are probably the most important in the world, and they are the cornerstone of today’s e-commerce and other fields. In short, asymmetric encryption means that the encryption key and the decryption key are different, and the encryption key and the decryption key come in pairs. Asymmetric encryption is also called public key encryption, that is, a pair of keys, one of which is publicly available to everyone, is called a public key, and the corresponding is called a private key, only the producer of this pair of keys can have. The public and private keys have the following important features:

  • For a private key, there is only one corresponding public key. The generator is responsible for generating the private and public keys, saving the private keys, and publicizing the public keys

  • The public key is public, but it is impossible to reverse the private key through the public key, or very difficult to reverse, can only be exhaustive, so as long as the key length is enough, it is almost impossible to get the private key through exhaustive

  • The ciphertext encrypted by the private key can be decrypted only by the public key, and the ciphertext encrypted by the public key can be decrypted only by the private key

Because of the above properties, asymmetric encryption has the following typical uses:

  • Confidentiality of information to prevent manin (middle man) attacks: The plaintext is encrypted by the receiver’s public key and transmitted to the receiver. Only the receiver has the corresponding private key, but others cannot have or calculate the private key through the public key. Therefore, the transmission cannot be intercepted by the middle man. Only the recipient with the private key can read it. This usage is typically used for exchanging symmetric keys.

  • Authentication and tampering prevention: The permission dog encrypts an authorization plaintext with its private key, and sends the authorization plaintext, encrypted ciphertext, and public key together. The receiver can determine whether the plaintext is tampered by decrypting the ciphertext using the public key and comparing it with the authorization plaintext. This method is used for digital signatures.

Asymmetric encryption is known as RSA, which is named after the initials of three inventors.

Asymmetric encryption algorithms are so powerful and reliable, but one drawback is that encryption and decryption are time-consuming. Therefore, in practice, it is often used in combination with symmetric encryption and summarization algorithms. Symmetric encryption is easy to understand, and the 1W word is skipped here. Let’s look at the digest algorithm again.

The algorithm

Another magic algorithm is the digest algorithm. Algorithm refers to that a text of arbitrary length can be obtained by an algorithm with a fixed length. Here the text doesn’t have to be just text, it can be bytes of data. So the abstract algorithm is trying to turn everything into a fixed length thing. Abstract: The algorithm has the following important characteristics:

  • As long as the source text is different, the result of calculation is necessarily different

  • It is impossible to deduce the source from the result (of course, otherwise energy would not be conserved)

Typical digest algorithms, such as the well-known MD5 and SHA. Abstract: The algorithm is mainly used to compare whether the information source is consistent, because as long as the source changes, the summary will be different. And the result is usually much shorter than the source, so it’s called a summary.

A digital signature

Now that you understand asymmetric encryption and digest algorithms, take a look at digital signatures. In fact, digital signatures are a combination of both. Suppose we have an authorization text that needs to be published. To prevent tampering with the text content, ensure the integrity of the text, and ensure that the text is sent by the specified authorization dog. First of all, the text content is extracted through the digest algorithm, and then the private key of the privilege dog is used to encrypt the digest to obtain the ciphertext. The source text, ciphertext, and the corresponding public key of the private key can be published together. So how do you test that?

The verifier first checks whether the public key is of the permission dog, then decrypts the ciphertext with the public key to get a summary, and extracts the text with the same summary algorithm. Then the two summaries are compared. If they are equal, everything is normal. The process is invalid if one step goes wrong.

Digital signature can quickly verify the integrity and validity of text and has been widely used in various fields. Now that we understand digital signatures, let’s take a closer look at what digital certificates are.

The digital certificate

Real life credentials

A certificate, as its name implies, is a certificate issued by a competent authority. For example, the Cet 6 certificate is a certificate issued by the education department to an individual who has passed cet 6, demonstrating his English ability. Let’s look at the composition of the certificate:

  • Certifiable: Lao Wang

  • Content: Passed Cet-6

  • Seal: the official seal or steel seal of the education department

So Lao Wang can use this certificate to find a job, the employer will check the contents of the certificate (especially the official seal), to verify the validity of the certificate and Lao Wang’s ability.

In real life, there are often fake grade 6 certificates, the most important thing of these fake certificates is that there is a fake official seal. In real life, laws and regulations are used to restrict the behavior of private seal carving, but the employer may not be very accurate judgment of the seal is true or false. These problems can be solved mathematically in front of digital signature.

Digital certificate: certificate implemented with digital signature

In fact, a digital certificate is a digital certificate realized by digital signature. In the general certificate component, other information is added, such as the validity period of the certificate (such as the driving license is valid for 6 years after the initial application), after which it needs to be re-issued (the driving license needs to be re-applied for 6 years after the initial application).

As with the issuing agencies in real life, there are several issuing agencies for digital certificates and they serve different purposes. Apple, for example, can issue certificates related to Apple, while certificates related to Web access are issued by several recognized organizations. These issuing agencies are called Certificate Authority (CA).

For the recipients, it’s usually businesses or developers. For example, if you need to build a website based on SSL, you need to apply for a certificate from several internationally recognized CAS. For example, to develop iOS applications, you need to obtain relevant certificates from Apple. These applications are usually submitted to CA by enterprises or individual developers. Of course, the required materials, qualifications, and fees vary and are set by the CA, such as apple’s $99 or $299 fee.

The reason to apply for a certificate, of course, is to be verified. English level 6 certificate verification party is generally employing units; The verifier of SSL certificates related to Web applications is usually the browser; IOS certificates are authenticated by iOS devices. The reason we have to apply for a certificate from a CA is because the CA has defined the whole validation process. For iOS, the authentication process is already built into the system and cannot be bypassed unless jailbroken.

The authorization chain of the certificate

Digital certificates may also include certificate chain information. For example, if you want to apply for a week-long vacation, you need approval from your boss, your boss needs approval from his boss, and finally, your boss needs approval from his boss. Then these layers of authorization form an authorization chain, and the boss is the root of the authorization chain, and each of these links is authorized by someone closer to the root.

The certificate we get from Apple MC (Member Center) is actually a certificate with a certificate chain, the root of which is Apple’s CA. The certificate we get is essentially telling the iOS device that our certificate is a valid certificate signed by an Apple CA. Before executing app, iOS devices should first verify whether the SIGNATURE of CA is legitimate, and then verify whether the program is really released by us through our public key in the certificate, and not tamper with the program during the process.

Flowchart of iOS Certificate application and signature packaging

Before we go any further, let’s look at a picture.

This diagram illustrates the process of developing aN iOS application, from applying for a certificate to packaging. I’m going to look at each of these steps.

The certificate application

To develop an iOS app, you have to become a developer and apply for the relevant certification, otherwise your app will only run on the emulator, not on the real phone, let alone on the shelf. So before applying for the certificate:

  1. Pay $99 or $299 to become an Apple developer and renew annually. This step is mandatory by Apple, equivalent to overlord terms, no money to play! Everyone knows that $99 is for individuals and small businesses and $299 is for large businesses, and that’s true, but you need to know that the essential difference between the two amounts is the type of certificate you can get, so $99 is certainly less than $299.

  2. Install the Apple Developer root certificate, which is essentially the “root certificate” for all certificates we request from the Apple MC. Installing this certificate means that our developer tools trust this CA so that they can sign and package other certificates issued by this CA. Generally speaking, if Xcode is installed, the certificate is automatically installed in the Key Chain. The certificate is shown below.

Then, we started to apply for certificates and do all kinds of things by following many illustrated tutorials. I’m not going to expand this part because I’m talking about principles. Let’s see what each step means.

What is CertificateSigningRequest certSigningRequest

We need to generate a CertificateSigningRequest certSigningRequest file to submit to the MC, so as to obtain a certificate. So what exactly is this file? As you can see from the flowchart above, this file contains two parts (Certificate Signing Request) :

  1. Applicant information, which is encrypted with the applicant’s private key

  2. Applicant’s public key. This information is the public key corresponding to the private key used by the applicant

  3. Algorithm and public key encryption algorithm

We can use OpenSSL to parse the contents of the file to find out:

openssl asn1parse -i -in CertificateSigningRequest.certSigningRequest

    0:d=0  hl=4 l= 649 cons: SEQUENCE          
    4:d=1  hl=4 l= 369 cons:  SEQUENCE          
    8:d=2  hl=2 l=   1 prim:   INTEGER           :00
   11:d=2  hl=2 l=  68 cons:   SEQUENCE          
   13:d=3  hl=2 l=  36 cons:    SET               
   15:d=4  hl=2 l=  34 cons:     SEQUENCE          
   17:d=5  hl=2 l=   9 prim:      OBJECT            :emailAddress
   28:d=5  hl=2 l=  21 prim:      IA5STRING         :[email protected]
   51:d=3  hl=2 l=  15 cons:    SET               
   53:d=4  hl=2 l=  13 cons:     SEQUENCE          
   55:d=5  hl=2 l=   3 prim:      OBJECT            :commonName
   60:d=5  hl=2 l=   6 prim:      UTF8STRING        :Parker
   68:d=3  hl=2 l=  11 cons:    SET               
   70:d=4  hl=2 l=   9 cons:     SEQUENCE          
   72:d=5  hl=2 l=   3 prim:      OBJECT            :countryName
   77:d=5  hl=2 l=   2 prim:      PRINTABLESTRING   :CN
   81:d=2  hl=4 l= 290 cons:   SEQUENCE          
   85:d=3  hl=2 l=  13 cons:    SEQUENCE          
   87:d=4  hl=2 l=   9 prim:     OBJECT            :rsaEncryption
   98:d=4  hl=2 l=   0 prim:     NULL              
  100:d=3  hl=4 l= 271 prim:    BIT STRING        
  375:d=2  hl=2 l=   0 cons:   cont [ 0 ]        
  377:d=1  hl=2 l=  13 cons:  SEQUENCE          
  379:d=2  hl=2 l=   9 prim:   OBJECT            :sha1WithRSAEncryption
  390:d=2  hl=2 l=   0 prim:   NULL              
  392:d=1  hl=4 l= 257 prim:  BIT STRING        
Copy the code

You can see that the file contains my information and indicates that SHA1 digest algorithm and RSA public key encryption algorithm are used. When apple’s MC gets this information, it records it and issues a certificate. In this case, Apple doesn’t actually have to verify my information, because if I don’t pay, I can’t upload this file and I can’t get a certificate.

What exactly is the certificate applied from MC

Apple. Remove CertificateSigningRequest certSigningRequest the public key, regardless of my other information, and then to my MC account information and I submit the public key encapsulation in the certificate, and digitally signed. For example, let’s use OpenSSL to look at the contents of the certificate:

openssl x509 -inform der -in ios_development.cer -noout -text Certificate: Data: Version: 3 (0x2) Serial Number: 65:97:cd:73:6f:19:37:c2 Signature Algorithm: sha256WithRSAEncryption Issuer: C=US, O=Apple Inc., OU=Apple Worldwide Developer Relations, CN=Apple Worldwide Developer Relations Certification Authority Validity Not Before: Jul 29 07:36:28 2015 GMT Not After : Jul 28 07:36:28 2016 GMT Subject: UID=8VPWB57FDW, CN=iPhone Developer: Liang Ding (2U967A2YJ6), OU=7XPNRZE9TC, O=Liang Ding, C=US Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (2048 bit) Modulus (2048 bit): 00:ab:43:a4:57:32:57:30:81:89:eb:b4:5c:b6:88: 7f:4f:59:3a:9e:f6:14:50:2c:5c:14:6d:01:58:bd: d7:2b:a6:66:71:f7:d9:da:58:a2:e8:4c:d5:a9:87: 20:5b:b7:4c:58:29:3c:b3:48:de:7f:ad:3f:98:cc: 9d:b3:07:2f:93:4a:3a:e5:32:e2:fc:59:30:1e:ee: 65:11:c3:88:ea:7a:54:d8:60:56:d1:fa:69:06:40: dd:72:1d:7f:d9:14:85:bf:7a:b0:a3:34:a0:ac:c1: dc:a9:48:3c:9c:43:c8:e4:fd:02:eb:fe:d2:a7:ce: 2e:e4:9a:51:20:0b:5b:e5:5a:d4:04:9e:a4:52:8d: c2:1e:1f:50:80:fb:ea:c1:e4:bb:b4:ec:35:fd:96: 6a:86:0a:62:fa:d2:5a:8b:34:1b:f2:c5:c8:c9:2c: 85:d1:4d:8c:cb:91:be:db:92:f0:88:37:7a:6d:8d: ef:c6:e1:47:5c:e5:ca:e2:5a:47:14:5d:2f:5b:2e: d4:df:61:d9:99:e2:3e:6b:24:b2:aa:36:b3:af:e6: a8:a8:28:a7:8a:73:aa:68:a9:71:ac:81:a8:20:98: bb:3e:76:e2:09:19:41:45:d7:9a:68:1b:7c:1d:f5: b2:0b:36:ac:f0:4b:fc:0a:f1:3c:de:96:a0:10:14: aa:79 Exponent: 65537 (0x10001) X509v3 extensions: Authority Information Access: OCSP - URI:http://ocsp.apple.com/ocsp03-wwdr01 X509v3 Subject Key Identifier: C7:AB:35:54:A3:7B:96:2A:67:55:B8:2F:B6:82:4B:B8:F0:49:0F:EB X509v3 Basic Constraints: critical CA:FALSE X509v3 Authority Key Identifier: keyid:88:27:17:09:A9:B6:18:60:8B:EC:EB:BA:F6:47:59:C5:52:54:A3:B7 X509v3 Certificate Policies: Policy: User Notice: Explicit Text: Explicit Text: Reliance on this certificate by any party assumes acceptance of the then applicable standard terms and conditions of use, certificate policy and certification practice statements. CPS: http://www.apple.com/certificateauthority/ X509v3 Key Usage: critical Digital Signature X509v3 Extended Key Usage: Critical Code Signing 1.2.840.113635.100.6.1.2: critical.. Signature Algorithm: sha256WithRSAEncryption 80:99:47:27:ae:e5:1e:89:1e:c2:ec:52:d7:c8:8b:df:86:25: a9:cb:b2:f2:01:6c:5e:a0:55:6c:ad:1d:bd:3b:1c:ce:b4:53: 4d:03:d0:98:f6:f7:0e:24:2b:c5:cb:5e:71:88:bd:53:46:a8: c7:e0:d9:f4:81:47:98:a5:91:5c:04:f6:df:b9:c2:06:64:a4: 73:3d:0b:78:0d:8b:11:29:d3:3a:ea:88:b7:97:a9:2a:e0:74: a9:0b:1f:91:0f:47:78:be:90:46:21:10:16:a5:4b:0d:a6:33: 7e:0c:18:95:ba:7c:8e:b5:ed:86:5f:73:1b:cb:9e:ae:c8:96: 9d:4f:12:0a:9b:43:cc:58:ca:f3:d5:f0:6e:19:a6:e9:bf:9d: 95:34:39:4d:86:34:46:7e:11:e7:7c:9f:7b:1d:b1:9c:7d:1b: 39:85:5f:77:b0:89:d4:bb:55:c3:a9:24:af:54:a6:42:47:bf: 7c:d3:b0:6f:af:6a:2e:c6:00:07:1c:de:6b:aa:5b:a6:23:2b: fb:cd:2b:eb:04:fb:19:3e:1d:9d:ca:ae:d4:20:f1:4d:63:10: 44:80:d1:cf:fd:82:51:d2:cd:77:cb:46:1e:bd:63:df:4f:82: c7:5d:b3:61:45:03:6b:84:35:17:4b:c6:16:f0:47:1f:7b:26: 62:e3:d1:1bCopy the code

The Data field is the actual content of the certificate, and the Signature Algorithm equal to the Data field is actually the public key of apple’s CA, while the Signature of the summary should not be displayed. The next level of the Data field is my Apple account information, among which the most important is my public key, which corresponds to my local private key. After the certificate is installed, the KeyChain automatically associates the pair of keys, so you can see similar effects in the KeyChain:

Review images

The private key is then used to sign the code when the program is authenticated, and the public key is packaged into the app in the Mobileprovision file.

Note that the public key comes with Mobileprovision, not packaged directly with the code, so I don’t think it’s practical to install the certificate on the computer, essentially, because mobileprovision is generated for us by the MC. The reason we need to install a certificate is because the signing programs coDesign or Xcode only allow us to choose “which certificate to sign with”, because the certificate we choose will still correspond to the private key, which is really used for signing. Mobileprovision and code signatures are detailed below.

So, even if you have a certificate, it’s useless if you don’t have the corresponding private key. So someone has to ask, since the private key is only a computer generated, so how does the team development unfold?

Team development

So people search for something like “iOS certificate sharing” and the solution is “private key export.” Yes, since the key issue is the private key, why don’t we share the private key, export the private key of the machine that originally applied for the certificate as a.p12 file, and let other machines import it, and other machines should install the downloaded certificate as well.

Another option is for each machine to apply for its own certificate. However, this can be messy later on.

Since there are many types of iOS certificates for different purposes, we may apply for other certificates on MC later. . So it is strongly recommended that CertificateSigningRequest certSigningRequest needs to retain, because if again to generate CertificateSigningRequest certSigningRequest file, Maybe it’s another private key! Also need to share the private key once, will be more troublesome.

IOS Certificate Type

When we click “New Certificate” on the CERTIFICATE Application interface of MC, we need to select a certificate. Each certificate has different uses, like if you want to give birth to a child, you have to have a birth permit; You need a driving license to drive a motor vehicle; You need a passport to go abroad… So what is the difference between certificates involved in iOS development? In essence the difference between them is only USES, tell from the certificate structure are all the same, as long as you don’t change application with CertificateSigningRequest. CertSigningRequest file, the certificate contains a public key and the corresponding private keys are the same. Here are some common certificate types:

  1. The iOS App Development. Development, real machine debugging

  2. Apple Push Notification Service SSL (Sandbox). Apple’s push service was used in the development phase

  3. App Store and Ad Hoc. For shelves and AdHoc distribution

  4. Apple Push Notification Service SSL (Production). Use Apple Push when it hits the shelves

  5. The In – House. Enterprise edition, $299 to own, and deng code

I will not list the others that are not commonly used. Talk about ad-hoc methods later in MobileProvision.

IOS licensing and description files

However, certificates alone are not enough to solve Apple’s “worries”. Certificates can prove the ownership and integrity of the app and ensure that the app itself is secure. However, it cannot be specified that some services used by app are approved by Apple, such as APN push service. And the certificate does not limit the installed scale of the debug version of the APP. So Apple came up with mobileprovision. You can view a Mobileprovision using the following command:

security cms -D -i embedded.mobileprovision
Copy the code

The Mobileprovision file contains:

  1. AppId. Each app must create a corresponding AppId in the MC. The rules are long.

  2. Which certificates to use. As mentioned above, different types of certificates represent different distribution methods, including the availability of some functions (such as APN).

  3. Function Authorization List

  4. List of devices that can be installed. For app released in AdHoc mode or real machine debugging, there will be a list, which contains the UDID of iOS devices. The factory UDID of each iOS device is different, so it can be used to identify the device. It is available via iTunes connection to the device, or fir. Im/uDID here

  5. Apple’s signature!

Note 5 that the signature here is signed by apple and has nothing to do with our private key. In other words, the Mobileprovision file is signed by Apple and we have no other choice but to obtain it from the MC. Nor can it be taken and tampered with (such as adding other devices). Therefore, the above ones 1-4 are firmly controlled by Apple, and all rules must be formulated and constrained by Apple.

AdHoc publishing and real machine debugging

AdHoc allows beta appsto be released to a limited number of devices without approval from the appstore. The key here is how to control which devices can be installed. The answer is the Mobileprovision file. Remember that you need to select the UDID of the Devices when you generate the Mobileprovision file, so these Devices need to be added to the Devices of the MC in advance. For real machine debugging at development time, the principle is similar. This is done through item 4 of Mobileprovision. Apple limits the number of debug and test machines to 100!

IOS code signing

Many people study up to the above also stop, but life, death. Code signing has been mentioned many times above, so how exactly code is signed. This is important to understand for organizations or teams that may need to do auto-signed publishing. Also, you might want to read the source code for iReSign.

The composition of ipa

IOS applications will eventually be exported as an. Ipa file. Let’s first understand the structure of ipA files:

In fact, the IPA file is just a ZIP package that can be decompressed using the following command:

/usr/bin/unzip -q xxx.ipa -d 
Copy the code

Payload Payload Payload Payload Payload Payload Payload Payload Payload

  1. Resource files, such as images, HTML, and so on.

  2. _CodeSignature/CodeResources. This is a plist file that can be viewed as text, and the content is the signature of all the files in the package (excluding Frameworks). Notice all the files here. This means that once your program is signed, nothing in it can be changed, including the resource file and the executable itself. IOS checks these signatures.

  3. Executable file. This file needs to be signed just like a resource file.

  4. A Mobileprovision file. Used for packaging, generated from the MC.

  5. Frameworks. Frameworks are Frameworks that are not native to the system. Each Frameworks is an app, which should have the same structure as the app, and also contain the CodeResources signature message file

Related procedures and commands

Generally, we use Xcode’s archive function to package IPA and signature. In fact, Xcode just calls some external programs to do the work. If we need to implement the automatic signature process ourselves, we need to know what the related programs and commands are.

Use the following command to list the valid certificates in the system that can be used for signing:

/usr/bin/security find-identity -v -p codesigning

1) E056929276F94152F3FDF0EA84BD2B06396F2DDD "iPhone Developer: Liang Ding (2U967A2YJ6)"
2) 7C608F653A989E95E1A4D303EC4E6625D95EEB42 "iPhone Distribution: Liang Ding (7XPNRZE9TC)"
  2 valid identities found
  Copy the code

You can see that this command lists the certificate name as a string, for example: iPhone Developer: Liang Ding (2U967A2YJ6). This name will come later.

Use the following command to sign the xxx.app directory, and coDesign will automatically sign all the files in it (Frameworks does not automatically sign) :

/user/bin/codesign -fs "iPhone Developer: Liang Ding (2U967A2YJ6)" --no-strict Payload/xxx.app
Copy the code

For each Framework, you also need to use this command to sign. The Framework structure is similar to the app structure, so the signature command is similar. This command automatically finds the private key associated with the certificate. -f Indicates that the signed APP is forcibly re-signed.

Finally, run the following command to check whether the signature is valid:

/usr/bin/codesign -v xxx.app
Copy the code

If there is no output, there is no problem.

Use the zip command to repackage the ipA package

/usr/bin/zip -qry destination source
Copy the code

The process of re-signing the app

If you want to design an automated rescheduling program, there is a general process:

  1. First, unpack the IPA

  2. If Mobileprovision needs to be replaced, replace it

  3. If there is a Frameworks subdirectory, sign all Frameworks in the.app folder, in the.dylib or.framework folder

  4. Signature of XXX. App

  5. repack

How do iOS devices verify that an APP is valid

Key points:

  1. Unpack the ipa

  2. Take out embedded. Mobileprovision and check whether it has been tampered with the signature

    1. There are several public keys for certificates, which develop and publish certificates for verifying signatures

    2. BundleId

    3. Authorization list

  3. Verify the signatures of all files, including Frameworks

  4. Check whether the BundleId in info. plist complies with embedded. Mobileprovision files

conclusion

Asymmetric key algorithm is the cornerstone. This paper introduces asymmetric encryption algorithm and summary algorithm in detail, and introduces digital signature and digital certificate gradually. Understanding asymmetric key algorithms is key.

Apple authorizes developers to develop iOS applications through certificates. Different certificates have different functions. You are advised to use the same request file (that is, ensure that the private key is unified) when applying for iOS applications. The team can use the same private key and certificate by sharing the private key, which facilitates development. To keep the app secure, all files in the app are signed, so that the signed app can’t change anything in it unless it re-signs.

Mobileprovision is a configuration file signed by Apple and distributed to developers. A configuration file is a collection of information that determines whether an application can run on a particular device. Profiles can be used to run and debug applications on your development device, for internal testing (ad-hoc), or for enterprise application distribution. With profiles, Apple’s grip on developers is very strong.

Therefore, the certificate (and its corresponding private key) and the configuration file are the two necessary files for signing and packaging. It takes deep understanding to find solutions in everyday mistakes.

For more information, please refer to these:

Inside Code Signing

Analysis of code signature

Learning notes on iOS Code Signing