How to Secure API Calls with Hybrid Symmetric‑Asymmetric Encryption and Signing

Background and goal: With rapid network development, data security issues become prominent. To prevent crawlers, request tampering, replay attacks, and verify data integrity, the solution combines HTTPS principles and WeChat Pay encryption design, using symmetric encryption, asymmetric encryption, signatures, and other techniques to provide API encryption design.

Design Overview

Symmetric, Asymmetric, Hash, Signature Algorithms

Symmetric encryption: Uses the same key for encryption and decryption; fast but key distribution is a challenge. Used for actual data transmission.

Asymmetric encryption: Uses a public/private key pair; public key encrypts, private key decrypts. Secures key exchange; slower, not suitable for large data. Used to encrypt the symmetric key.

Hash algorithms: Produce fixed‑length digests; any change in input yields a different output.

Signature algorithm: Data is signed with a private key and verified with the corresponding public key.

HTTPS Principle Overview

HTTPS (Hypertext Transfer Protocol Secure) secures communication by using SSL/TLS to encrypt HTTP traffic and certificates for identity verification, ensuring confidentiality and integrity.

WeChat Pay Encryption Principles

Request signature: Each request is signed with RSA‑SHA256 using the merchant API certificate private key; WeChat Pay verifies the signature.

Callback verification: WeChat Pay signs callbacks with its platform certificate private key; the merchant verifies using the platform public key.

Callback decryption: Merchant decrypts encrypted callback data with the configured apiV3 key using AES‑256‑GCM.

API Encryption Design Ideas

Key exchange: Client encrypts the symmetric key with the server’s public key and sends it; server decrypts with its private key.

Data encryption: Client encrypts request data with the symmetric key; server decrypts with the same key.

Data hash (signature): Client computes a hash of the data and sends it; server recomputes and compares to verify integrity.

Data validity check: Client includes a timestamp; server validates the timestamp to prevent replay attacks.

Technical Implementation

Key Generation and Management

Generate an asymmetric key pair; the server stores the private key. Clients may periodically fetch the public key and store it locally.

Encryption Algorithm Choices

Symmetric: AES; Asymmetric: RSA; Hash: SHA‑256 (or MD5); Signature: RSA‑SHA256. Example using Hutool library:

// Symmetric key
String key = "key";
AES aes = SecureUtil.aes(key.getBytes());
// Encryption
String ciphertext = aes.encryptBase64(content);
// Decryption
String result = aes.decryptStr(ciphertext);
// Asymmetric public key
String publicKey = "xxxxxxx";
RSA rsa = new RSA(null, publicKey);
// Encrypt symmetric key
String ciphertextKey = rsa.encryptBase64(key, KeyType.PublicKey);
// Asymmetric private key
String privateKey = "xxxxxxx";
RSA rsa2 = new RSA(privateKey, null);
// Decrypt symmetric key
String key = rsa2.encryptBase64(ciphertextKey, KeyType.PrivateKey);
// Hash example
Digester sha256 = new Digester(DigestAlgorithm.SHA256);
System.out.println(sha256.digestHex(data));
// Signature example
Sign privateSign = SecureUtil.sign(SignAlgorithm.SHA256withRSA, privateKey, null);
String sign = new String(Base64.getEncoder().encode(privateSign.sign(data)));
System.out.println("Signature: " + sign);
Sign publicSign = SecureUtil.sign(SignAlgorithm.SHA256withRSA, null, publicKey);
System.out.println(publicSign.verify(data.getBytes(), Base64.getDecoder().decode(sign.getBytes())));

Signature Rules

After encrypting queryString and body, concatenate queryString, timestamp, plaintext symmetric key, and body, then hash with SHA‑256 to produce the signature placed in the request header.

Parameter Transmission

ek (encrypt‑key): asymmetric‑encrypted symmetric key.

ts: timestamp.

sign: signature.

Construct queryString as param1=value1&param2=value2, encrypt it with the symmetric key to obtain ciphertext=xxxxx, and append to the URL. Body parameters are encrypted with the symmetric key and sent as Base64.

url?ciphertext=xxxxx
body：xxxxxxxx

Backend Processing Steps

Validate request freshness using the ts header.

Decrypt the symmetric key from the ek header using the server’s private key.

Verify the signature by recomputing the SHA‑256 hash of the concatenated parameters and comparing with the sign header.

Decrypt queryString and body using the recovered symmetric key.

Encrypt the response payload with the symmetric key and return the Base64 ciphertext.

Common Questions

Why reference HTTPS for API encryption design? HTTPS combines symmetric and asymmetric encryption, offering high security and acceptable performance.

What issues arise if only symmetric encryption is used? The client’s key can be exposed, rendering encryption ineffective.

What issues arise if only asymmetric encryption is used? RSA cannot encrypt long texts (max 117 bytes) and is slower.

Is signing still necessary when parameters are already encrypted? Yes, to prevent tampering and replay attacks even when encryption is not applied to every endpoint.

Why not use RSA‑SHA256 for signatures? It requires a private key for signing and a public key for verification; storing the public key on the client would add maintenance overhead, so a hash‑based approach is used instead.

How to protect the public key stored on the client? Use code obfuscation, store the key in encrypted segments, and rely on per‑request generation of symmetric keys.

How is efficiency maintained with hybrid encryption? Only the symmetric key is processed with asymmetric encryption; actual data uses fast symmetric AES, keeping performance comparable to pure symmetric schemes.

Is the scheme absolutely secure? No; if the client is compromised, attackers can mimic requests. There is currently no universally absolute client‑side security.

Security Analysis

The hybrid approach leverages the speed of symmetric encryption and the key‑exchange security of asymmetric encryption, providing confidentiality and integrity while keeping performance high. However, client‑side public key protection remains a concern.

Anti‑tampering: All parameters are signed; without the client’s public key, modifications are detectable.

Anti‑scraping: Signed and encrypted parameters prevent unauthorized request simulation; encrypted responses cannot be deciphered from captured traffic.

Anti‑replay: Timestamps in headers are signed, allowing the server to reject stale requests; short‑term replay may still be possible without additional caching checks.