Unified security gateway dynamic encryption and decryption and data processing system and method

Abstract

The application provides a dynamic encryption and decryption and data processing system and method based on a unified security gateway, and belongs to the technical field of information security. The scheme aims to solve the problems of internal data plaintext exposure and rigid security policy. The system comprises a client, an API gateway, a backend service and a key management service. The client encrypts a business request to generate an encrypted request. The API gateway intercepts and decrypts the encrypted request to obtain a plaintext request, routes the plaintext request to the backend service, receives a plaintext response returned by the backend service, and performs dynamic desensitization and other processing on the plaintext response. The key management service implements automatic rotation of keys and distributes the keys. The application enhances internal data security, realizes centralized and dynamic management of security policy, simplifies backend business development, and realizes fine-grained access control.

Description

Technical Field

[0001] This invention relates to the field of information security technology, and in particular to a system and method for dynamic encryption / decryption and data processing based on a unified security gateway. Background Technology

[0002] In modern distributed information systems, communication between clients and servers typically employs Secure Hypertext Transfer Protocol (HTTP) to ensure security at the transport link layer. However, this method only protects the confidentiality of data during transmission over the public internet. When data traffic reaches the enterprise's network boundary, such as an Application Programming Interface (API) gateway, it is usually decrypted into plaintext form so that the gateway can perform operations such as routing, authentication, and rate limiting. Subsequently, this plaintext data circulates within the internal network until it reaches the final backend business service. This "secret outside, plain inside" model exposes sensitive data in plaintext form at multiple stages, including the API gateway, the internal network, and the backend business server, increasing the risk of internal data leakage. If any internal node is compromised, it could lead to a large-scale leakage of sensitive information.

[0003] To address some of the aforementioned issues, existing technologies have proposed several security solutions. For example, at the API gateway level, dynamic anonymization of response data returned by backend services is performed based on user roles and other information. While this approach centrally manages the data anonymization logic, it still has shortcomings. First, it primarily focuses on protecting downlink response data. Uplink request data from the client to the gateway may still be in plaintext at the application layer, or even if encrypted, its key management methods are relatively primitive. For instance, encryption keys are often statically configured or remain unchanged for a long period. Once the keys are leaked, both historical and future data are at risk of being compromised, lacking forward security. Second, for data access control, especially the control of sensitive data display, the policies and logic are often scattered across various independent backend business systems. This decentralized management approach not only makes it difficult to maintain and update policies uniformly but also prevents flexible and dynamic differentiation based on the request context, making it difficult to strike a balance between ensuring security and meeting business usability requirements. Summary of the Invention

[0004] To address the shortcomings of existing technologies, the purpose of this invention is to provide a dynamic encryption / decryption and data processing system and method based on a unified security gateway.

[0005] A system for dynamic encryption / decryption and data processing based on a unified security gateway, provided by the present invention, is characterized by comprising: The client is configured to encrypt business requests to generate encrypted requests; Backend services; API gateway, configured as follows: - Intercept and decrypt the encrypted request to obtain the plaintext request; - Route the plaintext request to the backend service; - Receive the plaintext response returned by the backend service; - Process the plaintext response to generate a processed response; A key management service is configured to automate key rotation and distribute keys for encryption and decryption to the client and the API gateway.

[0006] Preferably, the API gateway processes the plaintext response by including: Dynamic desensitization processing is performed on the plaintext response according to preset desensitization rules.

[0007] Preferably, the encryption request includes a user role; The API gateway is further configured to cache the user role after decrypting the encrypted request, and to perform the dynamic desensitization processing on the plaintext response based on the cached user role after receiving the plaintext response.

[0008] Preferably, the API gateway performs the dynamic de-identification process through a regular expression engine and / or a JSON path parsing engine.

[0009] Preferably, as part of the automated key rotation, the API gateway is configured to support the parallel use of at least two different versions of keys to decrypt encryption requests.

[0010] Preferably, the keys distributed by the key management service have an expiration date, and the client is configured to proactively request a new version of the key from the key management service before the expiration date of the currently used key.

[0011] Preferably, the client is implemented through an integrated software development kit (SDK), and the SDK integrates anti-debugging technology.

[0012] Preferably, the client is further configured as follows: When generating the encryption request, a timestamp and signature are appended to the encryption request to prevent replay attacks.

[0013] A method for dynamic encryption / decryption and data processing based on a unified security gateway, provided by the present invention, includes the following steps: A key management service that implements automated rotation provides keys for encryption and decryption to clients and API gateways; The client encrypts the business request to generate an encrypted request; The API gateway intercepts and decrypts the encrypted request to obtain the plaintext request; The API gateway routes the plaintext request to the backend service; The API gateway receives a plaintext response returned by the backend service; The API gateway processes the plaintext response and generates a processed response.

[0014] Preferably, the step of the API gateway decrypting the encrypted request includes: Attempts to decrypt the encryption request are made in parallel using at least two different versions of the key.

[0015] Compared with the prior art, the present invention has the following beneficial effects: 1. Enhanced internal data security: By encrypting requests on the client side and performing unified decryption and response processing at the API gateway, it ensures that data exists in encrypted or controlled form in the internal links from the client to the gateway and from the gateway to the backend service. This effectively prevents information leakage caused by the plaintext exposure of internal node data and significantly reduces the data attack surface.

[0016] 2. Centralized and dynamic management of security policies is achieved: The encryption and decryption logic and dynamic de-identification policies are centrally implemented in the API gateway, decoupled from the backend business system. Combined with the dynamic rotation of keys and the hot update capability of de-identification rules, the security policies can be managed and adjusted in a unified and flexible manner, improving the robustness and response speed of the system.

[0017] 3. Improved system maintainability: Backend business services do not need to worry about security details such as encryption / decryption and desensitization, but only need to handle plaintext business logic, which greatly reduces the implementation and maintenance costs of security capabilities, enabling new businesses to be connected quickly and securely.

[0018] 4. Fine-grained access control is achieved: Differentiated data anonymization can be performed at the gateway layer based on context information such as user roles. It can return partially masked sensitive data to low-privilege users without affecting the use of high-privilege users, thus achieving a fine balance between security and business needs. Attached Figure Description

[0019] Other features, objects, and advantages of the present invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 A schematic diagram of a system architecture for dynamic encryption / decryption and data processing based on a unified security gateway, provided for embodiments of this application; Figure 2 A timing diagram of a data processing flow provided in an embodiment of this application; Figure 3 A flowchart illustrating a method for dynamic encryption / decryption and data processing based on a unified security gateway, as provided in this application embodiment; Figure 4 This is a timing diagram for an automated key rotation provided in an embodiment of this application. Detailed Implementation

[0020] The present invention will now be described in detail with reference to specific embodiments. These embodiments will help those skilled in the art to further understand the present invention, but do not limit the invention in any way. It should be noted that those skilled in the art can make several changes and improvements without departing from the concept of the present invention. These all fall within the scope of protection of the present invention.

[0021] Example 1 This application provides a dynamic encryption / decryption and data processing system and its working method based on a unified security gateway. It aims to comprehensively demonstrate how the system achieves end-to-end application layer data security protection from the client to the backend service, and performs dynamic, context-aware processing of response data.

[0022] Reference Figure 1 The figure illustrates a system architecture diagram provided in an embodiment of this application. Specifically, the system may mainly include a client 10, an API gateway 20, a backend service 30, and an independent key management service 40. In a distributed or microservice architecture, auxiliary facilities such as a logging system 50 may also be included.

[0023] Client 10, acting as a front-end application for user interaction with the system, is an application installed on a smartphone, tablet, or personal computer. In one specific implementation of this application, client 10 implements its core security functions by integrating a Software Development Kit (SDK). This SDK encapsulates encryption algorithms, communication logic with the key management service 40, and synchronization and caching mechanisms for security policies. Accordingly, client 10 is responsible for capturing the user's business operation intent, constructing it into a business request, and encrypting the key parts of the business request (e.g., the request body) using a key obtained from the key management service 40, thereby generating an encrypted request.

[0024] API Gateway 20, serving as the sole traffic entry point between Client 10 and all backend services 30, is the core hub of the entire system. Logically or physically deployed between Client 10 and backend services 30, it is responsible for intercepting all requests from Client 10. Figure 1As shown, the API gateway 20 can integrate multiple functional modules, such as an authentication module 21 for authentication, an encryption / decryption module 22 for encryption / decryption operations, a key management module 23 for smooth key transition, and a service load balancing component 24 for distributing requests to different backend service instances. The core functions of the API gateway 20 include: receiving and decrypting encrypted requests from client 10, restoring them to plaintext; performing necessary verification and routing on the plaintext requests; receiving plaintext responses returned by backend services 30; processing the plaintext responses according to preset policies, such as performing dynamic data anonymization; and finally, securely returning the processed response to client 10.

[0025] Backend service 30 is used to carry the actual business logic, and it can be one or more microservices, for example Figure 1 The diagram shows business services 1 and 2. These services focus on handling their own business functions, such as user management, order processing, and information retrieval. In the solution provided in this application, the design of backend service 30 is simplified. It only needs to process plaintext business requests and return plaintext business responses, without needing to worry about complex security-related logic such as data encryption / decryption and data anonymization, thereby achieving effective decoupling of security capabilities from business logic.

[0026] Key Management Service 40, as a highly available centralized service independent of business flows, is primarily responsible for the full lifecycle management of encryption keys, including key generation, storage, distribution, rotation, and destruction. A key feature is that Key Management Service 40 is configured to automate key rotation, for example, by generating a new key version daily through a scheduled task. It securely distributes keys for encryption and decryption to registered client 10 and API gateway 20 instances to ensure that both communicating parties use consistent and dynamically updated keys.

[0027] The logging system 50 is used to record key events and data during system operation, such as request processing logs of API gateway 20, success and failure records of encryption and decryption operations, policy execution status, etc., providing a basis for system monitoring, auditing and troubleshooting.

[0028] The following will combine Figure 3 The method flowchart shown is Figure 2 The data processing flow timing diagram shown below provides a detailed explanation of the working method of this embodiment.

[0029] During system initialization or client 10 startup, the SDK integrated in client 10 will proactively communicate with the key management service 40. This process can employ secure handshake methods such as asymmetric encryption to verify the legitimacy of client 10. Upon successful communication, the SDK will obtain the latest version of the data encryption key (DEK) and related security policies from the key management service 40, such as a whitelist of API interfaces requiring encryption, the key version identifier (KeyID), and its expiration date. The obtained key and policies will be securely cached locally on client 10.

[0030] When a user performs a business operation on client 10 that requires interaction with the backend (e.g., querying personal account details), the method proceeds to step S100: the client uses the SDK to encrypt the business request. Specifically, the SDK intercepts network requests issued by the application layer and first checks whether the target interface of the request exists in the previously synchronized encrypted interface whitelist. If encryption is required, the SDK calls its internal encryption module to encrypt the business data (such as a JSON object containing query conditions) in the request body using a locally cached, currently valid DEK (e.g., using a high-strength symmetric encryption algorithm such as AES-256-GCM). After encryption, the SDK constructs the final HTTPS request. The request body is the encrypted ciphertext, and additional information is appended to the request header, such as... Figure 2 As shown, this information includes at least a user token for authentication (e.g., a JWT token) and a KeyID indicating the version of the encryption key used. Furthermore, to enhance security, a timestamp and request signature can be appended to prevent replay attacks. Client 10 then sends this crafted encrypted request to API gateway 20.

[0031] Subsequently, the method proceeds to step S200: the API gateway intercepts and decrypts the request. As a unified entry point, the API gateway 20, upon receiving an encrypted request from client 10, first performs authentication. Specifically, its authentication module 21 parses the user token in the request header to verify its legitimacy and validity. After successful authentication, the encryption / decryption module 22 begins its work, extracting the key identifier KeyID from the request header. Figure 2As shown, API Gateway 20 will initiate a query request to Key Management Service 40 based on the KeyID to obtain the corresponding decryption key (DEK). After verifying the identity of API Gateway 20, Key Management Service 40 returns the corresponding DEK. Upon obtaining the DEK, the encryption / decryption module 22 of API Gateway 20 uses this key to decrypt the ciphertext in the request body, restoring the plaintext business request. If decryption fails, a decryption error response is returned to client 10. During the decryption process, API Gateway 20 can cache key context information parsed from the request token, such as user ID and user role, for use in subsequent steps.

[0032] After successful decryption, the method proceeds to step S300: The API gateway routes the plaintext request to the backend service. The API gateway 20 forwards the decrypted and verified plaintext request to the corresponding backend service 30 (e.g., business service 1) through its internal service load balancing component 24, according to preset routing rules (e.g., based on the request path or service name). At this point, the internal network communication between the API gateway 20 and the backend service 30 transmits plaintext data, allowing the backend service 30 to process the request directly without any decryption.

[0033] After receiving a plaintext request, the backend service 30 executes its own business logic, such as querying the database and calling other services, and finally generates a plaintext response containing complete and original business data, and returns it to the API gateway 20.

[0034] Subsequently, the method proceeds to step S400: The API gateway receives the plaintext response from the backend service. After receiving the plaintext response, the API gateway 20 does not directly forward it to the client 10, but instead initiates subsequent processing procedures.

[0035] The method proceeds to the crucial step S500: the API gateway performs dynamic data masking based on user roles. This step is the core component of this application's implementation of fine-grained access control and data protection. Understandably, the policy engine or a dedicated data masking module within the API gateway 20 utilizes the user role information cached in step S200 and matches a preset, associated set of data masking rules based on that user role. For example, for the "regular user" role, the rules might require masking the middle four digits of the "phone number" field in the response and partially masking the "ID number" field; while for the "administrator" role, there might be no data masking rules, allowing them to view all plaintext information. The gateway's data masking module parses the plaintext response body (usually in JSON format), locates the fields requiring data masking, and performs corresponding masking, replacement, or truncation operations according to the rules, thereby generating a processed response.

[0036] Finally, the method proceeds to step S600: the API gateway returns the processed response to the client. API gateway 20 returns the response data processed (e.g., de-identified) in step S500 to the requesting client 10. In a more secure variant, API gateway 20 may further encrypt the processed response body before returning it, using either the DEK previously used to decrypt the request or a different key negotiated based on the session. Upon receiving the response, client 10's SDK decrypts it if it is encrypted, ultimately presenting the de-identified, displayable data to the user.

[0037] In summary, the technical solution of this embodiment constructs a closed-loop secure data processing flow. Data is encrypted upon leaving client 10 and remains secure throughout the entire public network transmission link before reaching API gateway 20. Within API gateway 20, data is temporarily decrypted for routing and business processing, but critical response data undergoes rigorous, role-based dynamic desensitization before being returned to client 10, ensuring that even if a user receives a response, the data they see is subject to access control. The backend service 30 is completely decoupled from the security logic, significantly improving system maintainability and business iteration efficiency.

[0038] Example 2 This embodiment focuses on how the system achieves automated key rotation and ensures a smooth transition of services during the rotation period. This scheme aims to achieve forward security, and periodic, automatic key rotation is one of the key means to achieve this goal.

[0039] Reference Figure 4 The figure is a timing diagram of an automated key rotation, in which the main participants may include a scheduled task 401, a key management service 40, an API gateway 20, and a client SDK 404.

[0040] As one implementation, a key rotation strategy, such as "daily rotation", can be pre-configured in the key management service 40, and a scheduled task 401 can be set to trigger according to a predetermined period (e.g., 0:00 AM every day).

[0041] At a predetermined time, scheduled task 401 sends a "generate new key" instruction to key management service 40. In response, key management service 40 executes key generation logic, such as using an algorithm that includes variables such as date and random salt, to generate a brand new, globally unique symmetric encryption key and assign it a new version number, such as V_new. This newly generated key V_new is stored in the key management service 40's key repository and marked as "active," indicating that it is the latest key currently recommended for use.

[0042] Meanwhile, to ensure a smooth transition, the status of the previous version's key V_old will change from "active" to "pending obsolescence" or "reserved," and it will not be deleted immediately. Instead, it will be reserved for a period of time, such as 24 hours. During this reservation period, V_old remains valid and can be used for decryption.

[0043] After generating the new key V_new, the key management service 40 needs to notify all relevant service instances of this update. For example... Figure 4 As shown, the key management service 40 can broadcast key update notifications to all online API gateway 20 instances via a broadcast mechanism, such as using message queues like RabbitMQ or Kafka, or leveraging the configuration push functionality of service registries like Nacos or Consul. Upon receiving the notification, the API gateway 20 instance will immediately retrieve the details of the new key V_new from the key management service 40 and load it into its own memory cache for subsequent decryption operations.

[0044] To avoid a large number of request failures during key switching, this application employs a client-initiated update strategy for the client SDK 404. When distributing keys, the key management service 40 includes their validity period information; for example, a daily rotating key has a validity period of 24 hours. The internal logic of the client SDK 404 periodically, or before each network request, checks the validity period of its locally cached key V_old. When it detects that the remaining validity period of V_old is less than a preset threshold (e.g., less than 2 hours), the SDK proactively initiates a key update request to the key management service 40. Upon receiving the request, the key management service 40 returns the latest "active" key V_new to the client SDK 404. The SDK securely stores the new key locally and uses V_new in subsequent encryption requests.

[0045] Understandably, during the key switching transition period (i.e., within the 24-hour retention period of V_old), requests encrypted with both the old and new keys will exist simultaneously on the network. Some client SDKs that have proactively updated will use V_new to encrypt requests, while some clients that have not yet updated or are offline may still be using V_old. To accommodate this situation, the decryption logic of API Gateway 20 is designed to support parallel decryption.

[0046] like Figure 4As shown, when API Gateway 20 receives an encryption request, it can perform parallel decryption processing. Specifically, the gateway first extracts the KeyID from the request header. In a preferred implementation, API Gateway 20 first attempts to decrypt using the latest key version, V_new. If decryption succeeds, the process continues; if decryption using V_new fails (e.g., a padding error or authentication tag mismatch), it usually means that the request was encrypted by a client that has not yet updated its key, using an old key, V_old. In this case, API Gateway 20 does not immediately return failure, but initiates a backtracking mechanism to query its internally cached previous version key, V_old, which is still within its retention period, and attempts to decrypt again using that key. If this decryption succeeds, the entire request processing flow can continue normally, unnoticed by the business logic. Only after trying all possible, valid key versions (e.g., V_new and V_old) and still failing to decrypt will API Gateway 20 ultimately determine that the key is invalid or the ciphertext is corrupted, and return the corresponding error code to the client.

[0047] By leveraging this mechanism of automated key rotation, client-initiated updates, and parallel decryption of multiple keys via the API gateway, the system of this application can achieve regular and seamless replacement of encryption keys without interrupting service or affecting user experience. This greatly enhances the forward security of the system, meaning that even if a key is unfortunately leaked on a certain day, it will only affect the data within the validity period of that key, without endangering the security of past and future data.

[0048] Example 3 This embodiment aims to illustrate in detail how the API gateway 20 utilizes a "regular expression engine" and a "JSON path parsing engine" to achieve efficient, accurate, and dynamic desensitization processing of complex and diverse backend response data, thereby providing a specific technical implementation solution for the relevant claims.

[0049] In modern applications, backend services typically return data in JSON format with deeply nested structures. Desensitizing this type of data requires addressing two core issues: first, how to accurately locate the fields requiring desensitization; and second, how to apply different desensitization rules based on different types of sensitive information (such as phone numbers, ID cards, and bank card numbers).

[0050] In this embodiment, the API gateway 20 internally implements a "de-identification tagger" plugin or module. The core of this plugin is a dual-engine collaborative working mechanism, which is tightly integrated with an external configuration center such as Nacos or Apollo, as well as an access control system.

[0051] First, regarding the definition and dynamic loading of data masking rules, as an optional implementation method, system or security administrators can define their own data masking rules for different user roles (e.g., NORMAL_USER, VIP_USER, INTERNAL_ADMIN) in an external configuration center. These rules are typically defined in a structured JSON format, offering good readability and extensibility. An example rule defined for the NORMAL_USER role is as follows: [ { "path": "$.data.userInfo.phone", "type": "REGEX_REPLACE", "pattern": "(\\d{3})\\d{4}(\\d{4})", "replacement": "$1****$2" }, { "path": "$.data.userInfo.idCard", "type": "MASK_FIXED_LENGTH", "prefix": 6, "suffix": 4, "maskChar": "*" }, { "path": "$.data.transactionList[*].cardNo", "type": "MASK_ALL" } ] It should be noted that in the rule examples above, each object represents a de-identification rule. The `path` field is a JSON path expression used to locate the target field. For example, `$.data.userInfo.phone` can precisely locate the `phone` field under the `userInfo` sub-object of the `data` object in the JSON response, while `$.data.transactionList[*].cardNo` can match the `cardNo` field of all elements in the `transactionList` array. The `type` field defines the type of de-identification operation. For example, `REGEX_REPLACE` indicates that a regular expression is used for replacement, `MASK_FIXED_LENGTH` indicates that the specified length of characters before and after the field is retained and the middle part is masked, and `MASK_ALL` indicates that the entire field value is replaced with a mask.

[0052] When API Gateway 20 starts up, it loads the de-identification rules for all roles from the configuration center and caches them in memory. Simultaneously, it listens for change events in the configuration center. Once an administrator modifies or adds a rule in the configuration center, API Gateway 20 receives the notification in real time and dynamically updates its in-memory rule cache. The entire process does not require a service restart, thus achieving hot rule updates.

[0053] When the request-response process reaches step S500 (perform dynamic de-identification), the de-identification tagger plugin begins to work. Its specific processing is as follows: The plugin first obtains the user role from the context of the current request. This role information is usually parsed from the JWT token after the request is decrypted. Assume the current user's role is NORMAL_USER. Then, based on the NORMAL_USER role, the plugin searches for and matches the corresponding de-identification rule set in the memory cache. After obtaining the rule set, the plugin begins to traverse the plaintext JSON response body returned by the backend service and performs location and processing operations on each rule in the rule set: 1. Location: The plugin first calls the integrated JSON path parsing engine (such as the Jayway JsonPath library or a similar library), taking the path value in the rule (such as $.data.userInfo.phone) as input, and queries the JSON response body. This engine can efficiently parse complex JSON structures and quickly return all fields matching the path and their values. 2. Processing: After locating the target field, the plugin checks the rule's type. If `type` is `REGEX_REPLACE`, the plugin uses the integrated regular expression engine to process the field values ​​according to the pattern and replacement defined in the rules, for example, processing "123456789" into "123****89". If `type` is `MASK_FIXED_LENGTH`, the plugin truncates and concatenates the fields based on the values ​​of `prefix` and `suffix`, generating a de-identified result such as "111111********1111". If `type` is `MASK_ALL`, the plugin directly replaces the field values ​​with a string of mask characters. The processed result will replace the corresponding field values ​​in the original JSON response body.

[0054] By decoupling the "location" and "processing" stages of a field and employing optimized engines for each (i.e., using a JSON path parsing engine for structure traversal and a regular expression engine for pattern matching and replacement), this embodiment achieves high-performance and highly flexible de-identification of arbitrarily complex JSON responses. Administrators can adjust the de-identification strategy simply by modifying external configurations, without altering any code, greatly improving the response speed and maintainability of the security policy.

[0055] Example 4 This embodiment focuses on the security hardening measures for client 10, aiming to detail the internal implementation mechanism of the client software development kit (SDK) to support the relevant claims. It is understood that ensuring client-side security is the starting point of the entire security system; if the client's keys and encryption logic can be easily obtained, then the encryption of the entire chain will be meaningless.

[0056] In this embodiment, the client software development kit (SDK) can be designed as a multi-layered defense-in-depth system, which may mainly include a secure storage module, a policy caching module, an encryption and signing module, and a runtime protection module.

[0057] First, regarding SDK initialization and secure key storage. When an application integrating this SDK is launched for the first time on a user's device, the SDK performs a secure initialization process. This process may include: generating a unique device identifier (DeviceID) based on device hardware information or other stable characteristics; performing a secure handshake with the key management service 40 using the asymmetric encryption public key pre-embedded within the SDK to obtain the initial data encryption key (DEK); and storing the obtained DEK in a hardware-level secure area provided by the operating system. It is important to note that this secure storage step is crucial to prevent the key from being easily read. For example, in Android systems, the Keystore system can be used; in Apple's iOS systems, the Keychain service can be used. These system services can store keys in a hardware-protected, isolated environment, so even the application itself cannot directly read the plaintext key; it can only request encryption and decryption operations using the key through system-provided APIs, thus greatly improving the security of key storage.

[0058] Secondly, regarding the synchronization and caching of security policies, the SDK periodically synchronizes the latest security policies from the key management service 40 (e.g., each time the application starts or the network status switches from offline to online). These policies include a list of API interfaces that need to be encrypted, the version number of the currently active key, and the version of the de-identification rules. To prevent these policies from being tampered with locally, the SDK encrypts or signs them before caching them in the local database.

[0059] Secondly, regarding request encryption and replay protection: When an application initiates a network request, the SDK can intercept the request using techniques such as method injection. The SDK first queries the local caching policy to determine if the target API of the request is in the list requiring encryption. If encryption is required, the SDK requests the secure storage module to encrypt the request body using the DEK stored in the hardware secure area. To prevent replay attacks, i.e., to prevent attackers from intercepting legitimate encrypted requests and resending them, the SDK's encryption and signing module can attach anti-replay parameters to the request when generating the encrypted request, such as the precise timestamp of the current time and the request signature. The timestamp can be used by the API gateway 20 to determine the freshness of the request; for example, the gateway can refuse to process requests whose timestamp differs from the server's current time by more than a preset threshold (e.g., 10 seconds). The request signature is calculated based on several key parts of the request (such as the request method, URI, encrypted request body, timestamp, device identifier, etc.) using a secure hash message authentication code algorithm (e.g., HMAC-SHA256). Accordingly, upon receiving a request, API Gateway 20 will recalculate the signature in the same manner and compare it with the signature carried in the request. Only when the signatures match can it be proven that the request has not been tampered with during transmission and was issued by a legitimate client, providing a concrete implementation scheme for the relevant claims.

[0060] Finally, regarding runtime anti-debugging protection, this is the core embodiment of the anti-debugging technology in the relevant claims. To combat attackers using dynamic debugging tools such as Frida and GDB to attach to application processes and steal sensitive information, the SDK's runtime protection module can integrate various anti-debugging and anti-tampering technologies. These technologies may include, but are not limited to: debugging detection by checking the TracerPid value or calling the ptrace system call; detecting whether the device has been privileged (i.e., rooted or jailbroken); and verifying the integrity of the SDK itself and the host application's code to prevent repackaging or injection of malicious code. Once the runtime protection module detects any of the above-mentioned anomalies, it will immediately take preset defensive measures, such as clearing all sensitive information in memory, refusing to perform any encryption or decryption operations, reporting the abnormal event to the risk control backend, or, in extreme cases, forcing the application to exit, to prevent further attacks to the greatest extent possible.

[0061] Through the aforementioned client-side security hardening measures, this application has built a solid defense line from the source, ensuring the security of encryption keys and encryption logic on the client side. Together with the security measures on the API gateway side, it constitutes a complete end-to-end application layer data security protection system.

[0062] Specific embodiments of the present invention have been described above. It should be understood that the present invention is not limited to the specific embodiments described above, and those skilled in the art can make various changes or modifications within the scope of the claims, which do not affect the essence of the present invention. Unless otherwise specified, the embodiments and features described in this application can be arbitrarily combined with each other.

Claims

1. A system for dynamic encryption / decryption and data processing based on a unified security gateway, characterized in that, include: The client is configured to encrypt business requests to generate encrypted requests; Backend services; API gateway, configured as follows: - Intercept and decrypt the encrypted request to obtain the plaintext request; - Route the plaintext request to the backend service; - Receive the plaintext response returned by the backend service; - Process the plaintext response to generate a processed response; A key management service, configured to automate key rotation, and further configured to distribute keys for encryption and decryption to the client and the API gateway; The API gateway processes the plaintext response in the following ways: Dynamic desensitization processing is performed on the plaintext response according to preset desensitization rules; The encrypted request includes the user role; The API gateway is further configured to cache the user role after decrypting the encrypted request, and to perform the dynamic desensitization processing on the plaintext response based on the cached user role after receiving the plaintext response.

2. The system for dynamic encryption / decryption and data processing based on a unified security gateway according to claim 1, characterized in that, The API gateway performs the dynamic de-identification process through a regular expression engine and / or a JSON path parsing engine.

3. The system for dynamic encryption / decryption and data processing based on a unified security gateway according to claim 1, characterized in that, As part of the automated key rotation, the API gateway is configured to support the parallel use of at least two different versions of keys to decrypt encryption requests.

4. The system for dynamic encryption / decryption and data processing based on a unified security gateway according to claim 3, characterized in that, The keys distributed by the key management service have an expiration date, and the client is configured to actively request a new version of the key from the key management service before the expiration date of the currently used key.

5. The system for dynamic encryption / decryption and data processing based on a unified security gateway according to claim 1, characterized in that, The client is implemented through an integrated software development kit (SDK), and the SDK integrates anti-debugging technology.

6. The system for dynamic encryption / decryption and data processing based on a unified security gateway according to claim 1, characterized in that, The client is also configured as follows: When generating the encryption request, a timestamp and signature are appended to the encryption request to prevent replay attacks.

7. A processing method for a dynamic encryption / decryption and data processing system based on a unified security gateway according to any one of claims 1-6, characterized in that, Includes the following steps: A key management service that implements automated rotation provides keys for encryption and decryption to clients and API gateways; The client encrypts the business request to generate an encrypted request; The API gateway intercepts and decrypts the encrypted request to obtain the plaintext request; The API gateway routes the plaintext request to the backend service; The API gateway receives a plaintext response returned by the backend service; The API gateway processes the plaintext response and generates a processed response.

8. The method for dynamic encryption / decryption and data processing based on a unified security gateway according to claim 7, characterized in that, The steps for the API gateway to decrypt the encrypted request include: Attempts to decrypt the encryption request are made in parallel using at least two different versions of the key.

Images