Network Security Communication: Principles, Protocols, and Implementation in the ZA App

Preface

When discussing security, data encryption and decryption are unavoidable. Local data storage usually relies on symmetric encryption, but network transmission also often uses symmetric encryption because it is fast. Asymmetric encryption is needed to solve the key‑exchange problem inherent in insecure networks.

However, building a truly secure communication channel requires more than simply combining symmetric and asymmetric encryption. Before diving into network security, we first introduce several basic concepts.

1.1 One‑Way Function

A one‑way function f(X)=Y is easy to compute in the forward direction but extremely difficult to invert. For example, multiplying two integers is trivial forward, but reversing the operation for large numbers (hundreds of digits) is infeasible. Such functions are used for hash algorithms (MD5, SHA‑1) and password protection.

Because a one‑way function cannot be decrypted, it is unsuitable for data encryption; instead, it serves to generate digests or protect passwords by storing only the hash value.

1.2 Trapdoor One‑Way Function

A trapdoor (or backdoor) one‑way function is a special case where, given an additional secret parameter Z, the inverse can be computed. In RSA, the private key acts as the trapdoor that allows decryption of data encrypted with the public key.

1.3 Forward Encryption Security

Forward security means that even if a long‑term session key is compromised, previously exchanged messages remain confidential. Compromising the key at request E does not allow decryption of earlier requests A‑D.

1.4 Asymmetric Encryption

Asymmetric algorithms use a pair of keys: a public key (distributed) and a private key (kept secret). Data encrypted with the public key can only be decrypted with the corresponding private key, and vice‑versa. Common algorithms include RSA, Diffie‑Hellman, and ECC.

Network Security Communication

2.1 First Version of Secure Communication

Using asymmetric encryption, a basic two‑party secure scheme can be designed (see diagram).

The scheme looks secure but suffers from performance issues and is vulnerable to man‑in‑the‑middle attacks.

2.2 Upgraded Secure Communication

To improve performance, symmetric encryption is introduced for data payloads, while digital certificates are used to prevent MITM attacks.

2.2.1 Digest

The digest is the hash of the subject’s information (e.g., domain, company name), the generated public key, and other metadata.

2.2.2 Signature

A Certificate Authority encrypts the digest with its private key, producing a digital signature.

2.2.3 Certificate

The certificate bundles the subject’s information, the digest, and the digital signature.

2.2.4 Classic TLS Handshake

With certificates and symmetric encryption, a secure channel can be established.

Client generates a random number K1 and sends it to the server.

Server generates its own random number K2, sends its certificate and K2 to the client.

Client verifies the certificate; if valid, the handshake continues.

Client generates random K3 and encrypts it with the server’s public key.

Server decrypts K3 with its private key.

Both sides combine K1, K2, and K3 to derive a symmetric key for subsequent data encryption.

Implementation of Network Security in the ZA App

3.1 Challenges Faced

Financial apps require stricter security than ordinary apps. Simple HTTPS without certificate validation is insufficient; replay attacks, request tampering, plaintext exposure, multi‑platform support, and performance must all be addressed.

3.2 ZA App Solution

Inspired by TLS, the ZA protocol adds an extra protection layer on top of HTTPS.

Step 1: Enforce HTTPS with certificate validation and require TLS 1.2+ on the client.

Step 2: Include a random nonce in each request body; the server stores the nonce with an expiration time to prevent replay attacks.

Step 3: Generate an RSA key pair (public key on client, private key on server). Use a randomly generated AES key to encrypt the request body; encrypt the AES key with the RSA public key and place it in the request header.

Step 4: Sign each request using selected header fields and a random timestamp to prevent tampering.

Other App Network Communication Schemes

Two additional password‑based interaction schemes are presented for reference.

4.1 User Login Password Interaction

To protect the plaintext password, the client salts and hashes the password before transmission.

Client hashes the salted password.

Server stores the hash and a UUID for each user.

During login, the server receives the client’s hash (HashPW1) and retrieves the stored hash (HashPW2) and UUID.

Both sides compute a final password by concatenating the hash with the UUID; equality indicates successful authentication.

Pros: The actual plaintext password never appears on the server or in the database.

Cons: If the client‑side hash is intercepted, the attacker can replay it; additional anti‑eavesdropping measures are needed.

4.2 User Transaction Password Interaction

Transaction passwords (typically six digits) often need to be sent in plaintext to third‑party systems, so a hybrid approach is used.

Client requests a token; the server provides an RSA key pair and a random nonce bound to the user.

The client encrypts the concatenation of the nonce and the 6‑digit password with the public key.

The encrypted payload is sent to the server.

The server decrypts with its private key, validates the nonce, and obtains the transaction password.

Pros: Suitable for production environments.

Cons: Backend developers can access the plaintext password, posing a risk if mishandled.

Conclusion

For network‑based apps, especially financial ones, building a secure and stable communication channel is critical. Simple HTTPS is insufficient; a layered approach that adds encryption, replay protection, tamper detection, and forward secrecy is required.

HTTPS is complemented by secondary encryption, ensuring that even if TLS is compromised, data remains encrypted.

Requests achieve both anti‑tampering and anti‑replay, and each uses a dynamically generated key, providing forward security.

The protocol supports iOS, Android, and web platforms.

Security measures are balanced with performance to deliver a fast user experience.

Appendix

D‑H Algorithm

The Diffie‑Hellman (D‑H) algorithm is a key‑exchange method that allows two parties to agree on a shared secret over an insecure channel, though it does not protect against man‑in‑the‑middle attacks.

The simplified exchange process is illustrated below.

A and B publicly agree on numbers P=5 and Q=8. A chooses random Ra=2, B chooses Rb=3.

A computes X = Ra × P = 10; B computes Y = Rb × Q = 24.

They exchange X and Y.

A calculates the shared key as Ra × P × Y = 240; B calculates Rb × Q × X = 240.

The real Diffie‑Hellman algorithm uses modular exponentiation and discrete logarithms, which are far more complex than the simple multiplication shown above.

Author: Xie Pengfei, ZA International, ZA Frontend Team

— END —