Baidu bdtls: A TLS 1.3‑Based Secure Communication Protocol for Mini Programs

Baidu mini‑programs run on many host apps. To protect the communication between the mini‑program framework, the mini‑program itself, and the host app from malicious attacks and abuse, Baidu's R&D team designed a dedicated security communication protocol called bdtls , built on the latest TLS 1.3 standard.

Threat landscape : static attacks (reverse‑engineering, repackaging, phishing), dynamic attacks (emulators, injection, debugging, device tampering), and business cheating (mass registration, automated activity). These attacks can compromise server trust and user data.

Design goals :

Security – mutual authentication, encrypted traffic, forward secrecy.

Low latency – encryption overhead < 10 % of total request time.

Availability – graded downgrade and fast recovery.

Extensibility – support for multi‑business, multi‑app authentication and protocol upgrades.

Analysis of TLS 1.2 revealed several shortcomings (2‑RTT handshake, weak PRF, outdated ciphers such as RC4/DES, insecure hash functions, lack of compression avoidance). TLS 1.3 addresses these with a 1‑RTT handshake and modern cipher suites, making it a suitable foundation for bdtls.

Protocol architecture – bdtls retains four sub‑protocols from TLS 1.3:

Record – basic data unit, handles segmentation, MAC, encryption.

Handshake – negotiates version, randoms, cipher suite, certificates, and derives the session key.

Application – carries encrypted business data on top of Record.

Alert – warning/fatal notifications.

Handshake details :

Key exchange uses DHE (Diffie‑Hellman Ephemeral). Example: both parties agree on a prime P and base G (e.g., G=5, P=17 ), each selects a private exponent ( A , B ), computes public values G^A % P and G^B % P , exchanges them, and derives the shared secret K = (G^B)^A % P = (G^A)^B % P .

Server generates an RSA key pair; the public key is sent to the client.

Client encrypts its DH public key with the server’s RSA public key and sends it.

Server decrypts, generates its own DH key pair, signs the DH parameters with its RSA private key, and returns the signed data.

Client verifies the signature, computes the shared master secret, and both sides derive the symmetric key for the business phase.

Digital signature – RSA is used for signing DH parameters, providing non‑repudiation and protection against man‑in‑the‑middle attacks. Only the client is authenticated in the current implementation.

Alert protocol – mirrors TLS alerts with warning and fatal levels, informing the peer of trust issues or handshake failures.

Application layer – uses AES‑128‑GCM for encryption and SHA‑256 for integrity, forming the suite AES‑128‑GCM‑SHA256 . All HTTP/HTTPS bodies are encrypted; symmetric encryption is chosen for performance.

Server implementation :

Handshake service – validates host identity (different key pairs per host), verifies package signatures, and checks business authorization.

Encryption service – decrypts the skr (encrypted session key), checks expiration, and performs AES‑GCM encryption/decryption of business payloads.

Client strategies :

Multi‑handshake merging – each business task owns a dedicated handshake channel, preventing redundant handshakes under high concurrency.

Key‑data caching – after a successful handshake, the secret key, skr , expiration time, and DH group ID are persisted (e.g., in local storage). On app cold‑start, the cached key is reused if still valid, avoiding an extra handshake.

Best practices & adoption – bdtls is now a core infrastructure component for Baidu mini‑programs and other internal services (payment, search, video transcoding, etc.). It has passed rigorous external security drills (e.g., HVV national cyber‑defense exercise) and demonstrates reliable protection.

Conclusions – bdtls offers a lightweight, secure, highly available, and extensible solution. Compared with TLS 1.2 it reduces handshake latency, removes unnecessary fields, and uses only modern, vetted cryptographic primitives. Future work includes upgrading the key‑exchange suite to ECDHE‑RSA for even better performance.