Information Security 10 min read

Securing Enterprise Data: Inside WKMS’s Scalable Key Management and Encryption Architecture

This article explains how WKMS addresses rising data‑protection regulations by offering a hierarchical key‑management service, masking SDK, AES‑based encryption, robust disaster‑recovery, and high‑throughput performance testing, illustrating a secure yet scalable solution for modern enterprises.

Weimob Technology Center
Weimob Technology Center
Weimob Technology Center
Securing Enterprise Data: Inside WKMS’s Scalable Key Management and Encryption Architecture

Product Background

Amid increasing governmental regulation of enterprise data, exemplified by China’s Personal Information Protection Law effective from 2021‑11‑01, Weimeng built WKMS (Weimeng Key Management Service) to provide fast, compliant data masking and encryption.

Product Overview

WKMS is a secure, compliant key‑management system whose core functions are data masking and data encryption/decryption. For masking, WKMS offers an abstract‑rule SDK that applications can call directly. For encryption, two models exist: a centralized service with high security but potential bottlenecks, and a client‑side model with better performance but less absolute key secrecy. WKMS adopts a hybrid client‑plus‑key‑provision model, enforcing strict authentication for key retrieval and reserving future key‑upgrade mechanisms.

Data Masking Masking operations (truncation, encryption, hiding, replacement) protect sensitive fields such as names and phone numbers; WKMS provides a basic masking SDK with no API interaction.

Uses truncation and replacement operations. Provides a basic masking SDK for upper‑layer use.

Data Encryption Encryption is reversible and relies on algorithm choice and key management. WKMS selects symmetric AES (over SM4) to support both domestic and overseas business.

Provides a basic encryption SDK for upper‑layer use. Interacts securely with wkms‑server to obtain and cache keys. Client‑side de‑centralized encryption ensures performance and stability.

Key Management Service The service manages, maintains, and provides all core keys.

Hierarchical key structure (RootKey, BEK, DEK) ensures recoverability. Key derivation, backup, and hardware‑encrypted storage protect against loss. RootKey stored in HSM; derived keys encrypted in storage. High‑performance, low‑latency key generation/get interfaces with authentication.

Product Architecture

The architecture focuses on secure key storage and fast, reliable key retrieval. WKMS uses a three‑level key hierarchy (RootKey → BEK → DEK) and an authentication mechanism to protect key access, with full‑layer caching for high throughput.

Key Hierarchy

Three layers: RootKey (stored in HSM), Business Encryption Key (BEK), Data Encryption Key (DEK). RootKey operations stay within HSM, invisible externally. BEK derived from RootKey, stored encrypted in DB. DEK derived from BEK, stored encrypted in DB. As long as RootKey and derivation data are retained, all keys can be recovered.

Overall Architecture

Data security: RootKey only in HSM; BEK/DEK stored as ciphertext in DB. Request authentication: Only the owning application can obtain its private key; public keys are openly accessible; wkms validates request signatures. Permission control: DEK sub‑business read/write rights granted via permission requests. High performance, low latency: Two‑level caching (local + Redis) boosts throughput and reduces latency; service scales horizontally. Extensibility: Reserved key‑upgrade hooks; encrypted payload headers include key version.

Encrypted Data Format A well‑defined format enables features such as idempotent decryption and future extensions.

Magic data: 4‑byte header indicating encrypted data. Meta length: 4‑byte length of extension metadata. Meta: actual extension metadata. Decrypt data length: 4‑byte ciphertext length. Decrypt data: ciphertext content. V1: metadata protocol version. Protocol version: for future upgrades. DEK version: key version for rotation.

Disaster Recovery Key loss would cripple enterprise data, so WKMS implements multi‑layer backup.

BEK/DEK: daily cold DB backups, multi‑region storage, Redis hot backup for recent three days. RootKey: password‑box backup by authorized personnel. HSM failure: soft encryption service with manual activation by key custodians.

Performance Testing

Service Resources

Resource Type Configuration Pod 8 × 8C 8G DB 2C 4G Redis 3 × 2G

Cache Usage

150 W DEK entries occupy ~400 MB memory.

Performance Metrics

Scenario TPS Avg (ms) 95th line (ms) 99th line (ms) Notes DEK Generation 2500 30 75 111 DB saturated DEK Query 99 610 5.97 15.36 23.28 None

Conclusion

Key security—secure storage and loss prevention—is the cornerstone of data encryption; WKMS’s architecture and performance tests demonstrate it meets current and near‑future demands. Future iterations will focus on improving client‑side usability and supporting evolving business requirements.

Cloud Nativeperformance testingInformation Securitysecurity architecturedata encryptionkey management
Weimob Technology Center
Written by

Weimob Technology Center

Official platform of the Weimob Technology Center

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.