It was a pleasure to use RSA, AES128, and MD5 in the project to secure communication between the Client and the Server. Next, I will try to describe the process of this use clearly. For more details on the algorithm, please visit the Wiki.

Originally just a very simple understanding of encryption, such as only know some symmetric encryption, asymmetric encryption, MD5 one-way encryption and so on. Through this study, it is amazing to be able to combine a variety of encryption methods so perfectly together. Makes the whole communication process so wonderful. Although it increases the workload of the server and the client, it only needs to add logic in the exit and entry to ensure the consistent export and entry of data, so as to avoid the trouble of disturbing the original logic.

Simple concepts that the article may cover

  1. RSA — Asymmetric encryption, which generates public and private keys, the public key on the client and the private key on the server. The public key is used for encryption and the private key for decryption.
  2. AES — Symmetric encryption, encryption directly with the given secret key, decryption with the given secret key. (Use the same secret key for encryption and decryption)
  3. MD5 — a widely used password hash function that produces a 128-bit hash value.
  4. Base64 encoding – an encoding of byte arrays into strings

Communication logic between client and server

Before: Plaintext transmission communication

  1. The data to be uploaded by the client is packaged as a dictionary (Map) and posted to the server.
  2. The server receives the data packet submitted by the client, obtains the Value in key-value format, and processes the data packet.
  3. After processing, the data is packaged as a dictionary (Map) and returned to the client for processing.

Encrypted transmission communication

The whole process is:

The client uploads data for encryption ==> The server obtains data for decryption ==> The server returns data for encryption ==> The client obtains data for decryption

  • Encrypting data uploaded by the client A

    1. The client randomly generates a 16-bit string to be used as an AESKey for subsequent ENCRYPTION.
    2. RSA is used to encrypt the AESKey, RSAKey
    3. (Some important interfaces need to be signed, which will be explained later. Do not omit this step for signing.)
    4. JsonAESEncryptedData is obtained by converting plaintext data packets (dictionary /Map) into Json strings and encrypting them with AESKey.
    5. {key: RSAKey, value: JsonAESEncryptedData} dictionary upload server, the server only need to pass the key and value, then parse, obtain the data.

  • Server gets data to decrypt B

    1. After obtaining the RSAKey, decrypt it using the server private key to obtain the AESKey
    2. JsonAESEncriptedData is obtained and decrypted using the AESKey to obtain the data uploaded by the plaintext client.
    3. (If the client is signed, check the signature to ensure whether the data is tampered during network transmission.)

  • The server returns data encryption C

    1. The data to be returned to the client (dictionary /Map) is converted to a Json string, encrypted with an AESKey
    2. (This can also be signed)
    3. The encapsulated data {data: value} is returned to the client

  • The client obtains data to decrypt D

    1. After retrieving the data, the client uses the key to retrieve the AESEncryptedResponseData returned by the server
    2. The AESEncryptedResponseData is decrypted using the AESKey to get the data returned by the plaintext server.

Add and check

Section 2 – **” Client, server communication logic “has basically covered the client – server communication encryption logic. As for “add and check”, ** is mainly aimed at preventing data from being tampered with in the process of data transmission.

Data tampered with, chestnut:

For a sports APP, uploading the number of moves is a common interface operation. For example, the interface will have several fields: step(number of steps), time(time when the number of steps is generated), memberId(user ID).

Let’s say someone grabs your uploaded data and succeeds in breaking your encryption. Get the plaintext, then the user can modify your data, such as step, encrypt it in the same way, and post it to your server, which will consider it a normal request and accept the modified number of steps. In fact, the data is wrong. So undetected…

In order to prevent this practice, we can be signed processing mode

  • Sign processing (Data initiators can sign data, in this case, the client)

    1. We generally select key fields (fields that may be modified by others), such as step, time and memberId, which are sensitive.
    2. After the second step in A above, get step, time, memberId, concatenate it into A string (order and server agreement), then use MD5, base64 encoding (encoding format and service agreement). Get signData
    3. Then, the obtained signData is saved in the form of key-value into the original plaintext data packet, and then the third step of A is performed

  • Verification processing (data receiving party can verify the verification, here on the server)

    1. As shown in step 3 to B, we now have the plaintext data uploaded by the client
    2. According to the field concatenation agreed by the client, the step, time and memberId obtained are concatenated, and the same MD5_base64 is used for processing. Then, the signature sign in the packet is compared with the signature of the client at that time.
    3. If yes, accept the data. If no, discard the data and terminate the operation

Assume that the packet after signing is intercepted and decrypted successfully, and the plaintext packet is obtained. But signed MD5 encryption cannot be decrypted (one-way encryption). At this time, step is immediately modified and then posted to the server. The string obtained by the server through the modified step, time and memberId will be inconsistent with the signature of the client after MD5 encryption. The data is discarded.

Flow chart description above

The sample code

AES and RSA encryption and decryption, only iOS code. How to generate RSA public key and private key certificate in Linux, refer to RSA public key and private key generation, detailed explanation, many online

Github demo address –CAAdvancedTech

Run, as shown below

RSA public key – Generates a self-signed certificate

Pem 1024 // Generate a CSR file based on the private key. Openssl req -new -key private_key.pem -out CSR // Generate a CRT file based on the private key and CSR file openssl x509 -req -days 3650 -in rsaCertReq. CSR -signkey private_key.pem -out CRT // Generate the public key der file openssl x509 -outform der -in rsacert. CRT -out public_key.der // Export the private key as the p12 file openssl pkcs12 -export -out private_key.p12 -inkey private_key.pem -in rsaCert.crtCopy the code

See chatter on RSA asymmetric encryption and decryption

Recommended tools

  1. On drawing flow charts

    Before, I was struggling with whether there was a good tool on Mac that could draw flow charts, UML, and even Keynote. Finally, I found this online tool is very good. The picture above was drawn for the first time using this tool. It worked well. Is exporting PNG image resolution is not very good

    Tool processOn

    What is the best flowchart software to use on the Mac?

  2. Online tool about AES encryption and decryption

    Online AES encryption and decryption