Common encryption algorithms

Symmetric encryption algorithms: AES and DES

Encryption and decryption use the same key.

  • Fast encryption speed
  • Key management difficulty, arbitrary leak

Asymmetric encryption algorithms: RSA, DSA, and ECC

Encryption and decryption use different keys, including private key and public key. Data encrypted by the private key can be decrypted only by the public key, and vice versa. The private key is stored locally, and the public key is shared.

  • After all, the encryption speed is slow, which is suitable for data encryption with small amount of data and high security requirements
  • Not easy to leak

Hash algorithms: MD5 and SHA1

Also known as hash algorithm, summary algorithm, is to map arbitrary length of data to a finite fixed length field, is a one-way irreversible algorithm.

  • The signature certification
  • Data integrity verification
  • Non-recoverable data stores, such as passwords

The information in this paper,

The data of arbitrary length is obtained by hashing algorithm to obtain the data of fixed length, and the obtained data is called the summary of the original data. The main function is to ensure the integrity of information.

  • No matter how long the data is, the calculated summary length is fixed
  • The summary looks “random” and is guaranteed to be impossible to reverse and find any relationship to the original content in the summary
  • Abstracts with the same content are the same, while those with different contents are different. In extreme cases, the abstracts with different contents may be the same, which requires collision processing. The better the algorithm, the lower the probability of collision

A digital signature

In the past, people usually used signatures, seals and so on to prove the reliability of information. With the popularization of the Internet, more and more information is digitized, so how to confirm the reliability of an information on the network?

Encryption is a good option, with the sender encrypting the message and the receiver decrypting it. If symmetric encryption is used, it will face the risk of key management difficulties, so asymmetric encryption is a good choice.

The sender generates a pair of keys, the private key is kept and the public key is disclosed. Each time a message is sent, it is encrypted with the private key and decrypted with the corresponding public key, which seems to ensure that the message is received reliably. But asymmetric encryption is slow when there is a lot of information, and we just want to prove that the source of the information is reliable, not necessarily encrypt the entire content.

Summary information is especially useful at this time, we only need to calculate the summary of the original information, with the private key is encrypted, this time is a digital signature, then we put the original information send out package with a digital signature, the receiver receive information before, with public key to decrypt the digital signature, first get in, Finally, the same hash algorithm is used to calculate the summary of the information, compared with the summary decrypted before, we can get whether the received information is reliable and complete.

App signature

Why do I need an App signature

Before iOS came out, the installation software of various operating systems did not need to pass any certification, so the software could be installed and run wherever it was downloaded. As a result, the platform was difficult to control third-party software, piracy was rampant, and there would be security problems. In order to eliminate this phenomenon, Apple adopts the method of App signature verification to ensure that every App is approved to be installed on iOS.

Principle of App Signature

To put it simply, add the signature when the App is packaged, and then check the signature when the user downloads and starts the App. If successful, it will run normally, and if failed, it will blink back.

Generally, asymmetric encryption algorithms are used for authentication, and Apple is no exception. Apple generates a pair of keys: the private key is stored in the server, and the public key is delivered to iOS devices. In this way, when developers upload the developed App to the Apple server, the Apple server will encrypt the abstract of the App with the private key to generate a digital signature. When users download the App from the App Store, they will use the local public key to verify it.

The simple process is as follows:

This may seem simple, but it’s not enough for every scenario. In which scenario do we need to install an App?

  • When you develop your App, install it on your iPhone with Xcode
  • When releasing an App, users can download and install it by uploading it to the App Store
  • The App is distributed in ad-hoc form, with a limited number, and is generally used for normal testing
  • The App is distributed in the form of in-house, with unlimited quantity, and is generally used for large-scale internal testing of enterprises

In addition to the Apple Store, for other kinds of App, the release and installation may not go through Apple server, can not go to Apple certification first. Since we know that verification is usually done with a pair of keys, can we generate a pair of keys locally and repeat the above steps? This eliminates the need to upload apps to Apple servers, but there are two problems:

  • How do users get our locally generated public keys?
  • Did Apple lose the right to install approval?

To avoid the above two problems, Apple adopts the mechanism of double signature.

To put it simply: a pair of keys generated by Apple is used to verify App, which is converted into a pair of keys generated by Apple to verify a pair of keys generated locally by us, and then the pair of keys generated by us is used to verify App.

In terms of the process, we will first upload the locally generated public key L to the Apple server. The Apple server will use its own private key A to encrypt and sign the public key L and generate A certificate for us to download. Then we use the local private key L to sign the App and package it together with the downloaded certificate into ipA file for users to download. When downloading, the user will first use the built-in Apple public key A to verify the certificate in the IPA file. After the verification is successful, the user will take out the public key L in the certificate and then use the public key L to verify the signature of the APP. After passing the verification, the app can be installed and run.

We can clearly see that the private key is kept locally for signing and the public key is distributed for verification.

We have briefly described the mechanism of double signature above, although it is a bit complicated, but Apple’s permission control for App is not limited to this, Apple also wants to control:

  • Device List (Devices allowed to be installed)

  • App ID (Unique IDENTIFIER of App)

  • Various permissions of App (push, iCloud, background running, etc.)

This information will be packaged as a Provisioning Profile along with the certificates we downloaded above, so the process becomes more complicated as follows:

Https

Https is an SSL/TLS protocol added to HTTP to ensure data transmission security. The security of transmission is reflected in the following aspects:

  • The identity authentication
  • Content encryption
  • Data integrity

These security guarantees are also achieved by encryption algorithms in essence, in terms of core:

Asymmetric encryption is used to share symmetric encryption keys, and then symmetric encryption is used to communicate.

Overall process:

For the certificate & Key process:

reference

  • Principles of iOS App signature