Apk packet is digitally signed to improve transmission security

preface

At this time, there is a requirement for web App signature verification. In order to ensure that the DOWNLOADED APK package comes from the trusted server and prevent the request from being hijacked or replaced, we still use HTTP for the time being and there is a transition period before HTTPS, so we have to consider transmission security. HTTP, after all, is running naked across the web.

A digital signature

Before doing this, we should first understand what digital signature is on earth. Before doing this verification, I have always been in the state of hearing about it, so I spent some time to understand it before doing this task. To put it simply, digital signatures only do one thing, that is, prove that the content must come from someone. Why? Because he signs with a private key, only he can generate his own signature (private key theft does not count).

Before saying this digital signature, we first briefly mention the knowledge of cryptography. Encryption methods can be roughly divided into two categories: symmetric encryption (encryption and decryption use a set of key), asymmetric encryption (there are two sets of key, a set of private key, a set of public key, private key only know, public key can be given to others; Generally, the sender encrypts the message with the public key, and only the sender can decrypt the message with the private key, so as to achieve the purpose of secure message transmission. The private key is generally used for signature, and the public key is used to verify the signature. However, I found a problem in the process of my implementation. Most of the articles on digital signature on the Internet seem to be different from the real signature algorithm. Finally, THE chapter on digital signature made me a little clear in the former group leader and the review of cryptography and Network Security.

Online information about the process of digital signature is mainly as follows: Hash to get the content of the server will content, then use the private key with the complete signature, and then will issue together content and signature receiver, the receiver received after using the server’s public key to decrypt got the one, and then USES the same hash algorithm to the content and the server to get the two hash, Then compare the two abstracts to see if they are equal. If they are equal, the signature is approved. If they are not equal, the signature fails.

The practical application did not go well

With my understanding, I started to do the signature task, and found that there was a little difference when docking with the background. I understood that to decrypt the comparative abstract, there was a little difference in the verification of the background (hash+ public key + signature substituted into the signature verification algorithm). Finally, I checked the data and found that the general model of digital signature is:

According to this model, there is no problem in the first part of understanding, but the problem is in the process of checking signatures. In the figure, the result is obtained by using content hash+ signature to substitute into the signature verification algorithm, which perfectly fits the background understanding. See here I am more confused, is there a problem with the information on the Internet? And the principle of digital signature given by Wikipedia is the same as what I understood before, as shown below:

The first part is exactly the same as the process above, except for the verification process. For the purpose of finding the reason, I continued to look for the reason in the book cryptography and Network Security, and finally found the shadow:

RSA method: The input of the hash function is the message to be signed, and the output is a fixed-length hash code (before H). The hash code is encrypted to form a signature using the sent private key (PRa), and then the message and its signature are sent. After receiving the message, the recipient computes the Hash code (after H) and decrypts the signature using the public key of the sender. If the hash code calculated is the same as the decrypted result, the signature is considered valid. Because only the sender has the private key, only the sender can generate a valid private key. DSA method: DSA uses the hash function to obtain the hash code, which takes the hash code and the random number (k) generated for the signature as the input of the signature function. The signature function depends on the sent and sent private key (PRa) and a set of parameters shared by the communication partners. These parameters constitute the global public key (PUG). The receiver generates a hash on the received message. This hash code, along with the signature, is used as input to the authentication function, which relies on the global public key and the sender public key (PUa). The signature is valid if the output of the validation function is equal to the r component.

Finally, my understanding is that the model of digital signature is as shown in 13.1 above, but the implementation mode can be adjusted. Therefore, most of the information on the Internet should be relative to a certain signature mode, rather than analyzing the signature process.

Apk signature practices

Here I only say the front-end direction, in this task I use is the basic process of the general model, Sir Into a set of RSA public and private keys, the front-end directly hard code the public key. The back-end reads apK (read by buffer) and hashes the content (sha256 is used for front-end and back-end negotiation). The hash code is substituted into the signature function based on the private key of the sender to obtain the signature. Apk and signature are sent to the front end, the front end downloads APK first, and then reads APK files (front end reading can be in the form of text, dataURL, and ArrayBuffer), and the check will fail if the front end reads in different forms, because the background uses buffer reading. Therefore, the front-end can only use buffer to read. ⚠️ (sha256 in crypto-js does not support native ArrayBuffer, so jS-SHA256 is the last choice. Jsencrypt is the signature verification library, except that the document is not very friendly, but it is quite good, and comes with a test demo). The file reading method is not unified, which determines whether the signature can be successful.

The above are personal understanding, if there is a mistake, but also trouble to point out the big guy.