Communication method, communication system and storage medium

Abstract

The invention relates to a communication method and system and a storage medium. The method comprises the following steps: receiving an encrypted service request encrypted by a client according to a dynamic session key of a current session, and performing multi-dimensional dynamic verification on the encrypted service request, the multi-dimensional dynamic verification comprises two or more of space-time verification, secondary identity verification, quantum chain verification, integrity verification, business logic verification and quantum shield signature verification; when the multi-dimensional dynamic verification of the encrypted service request is passed, acquiring a risk level of the encrypted service request; and determining an encryption algorithm according to the risk level, and encrypting response data responding to the encrypted service request by adopting the encryption algorithm. According to the scheme provided by the invention, the encryption strategy can be dynamically adjusted according to the encryption service request, accurate matching of the encryption strategy and the service is realized, and the security strength of communication is improved.

Description

Technical Field

[0001] This application relates to the field of network security technology, and in particular to a communication method, communication system and storage medium. Background Technology

[0002] In related technologies, a secure communication system is built based on the Transport Layer Security (TLS) protocol (e.g., TLS 1.3) and combined with a centralized key management system (KMS).

[0003] The secure communication systems of related technologies employ fixed-policy security verification mechanisms. These single-dimensional anti-replay mechanisms are poorly robust in complex network environments. Relying on fixed timestamp windows (e.g., ±30 seconds) or static nonces (Number Used Once) for single-dimensional anti-replay attacks results in poor adaptability to network jitter and an inability to handle complex scenarios such as network latency fluctuations and time zone spoofing, leading to frequent false positives or false negatives. Data integrity verification relies on static HMAC (Keyed-hash message authentication code) keys bound to the session, lacking an independent, dynamically updated verification system. Furthermore, these secure communication systems use fixed-period key management; KMS rotates keys at fixed intervals (e.g., monthly), failing to adapt to real-time business risk status and the load on the secure communication system, making it neither secure nor economical. In contrast, after a successful handshake between the server and client, a long-lifecycle static session key (e.g., an AES key) is generated. This session key is continuously used for periods of several hours or even days, ensuring its long-term validity. The long-term reuse of session keys means that if the key is leaked within its validity period, attackers can decrypt all communication data within that period, resulting in the decryption of all historical communication data during the entire session. This leads to a wide-ranging security risk, jeopardizes the security of a large amount of historical data, and fails to guarantee forward security.

[0004] Furthermore, in the secure communication system of related technologies, the key negotiation at the server-side center employs the ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) algorithm, with the server leading the key exchange. The server generates parameters and a temporary public key and distributes them to the client via a certificate. The client then calculates the pre-master key based on the parameters and the temporary public key. This process results in a high computational load on the server, with measured latency exceeding 150 milliseconds for a single handshake, creating a performance bottleneck. Centralized key management suffers from performance bottlenecks and single-point-of-failure risks. Key negotiation and management rely on a centralized server node, which is prone to computational overload in high-concurrency scenarios, and the failure of a single node carries the risk of disrupting the entire communication link.

[0005] The static security architecture of related secure communication systems cannot adapt to dynamic business risks. The transport layer security protocol is completely isolated from the upper-layer business logic, forcibly separating communication security from business logic without interaction. This makes it impossible to understand the true intent of the upper-layer business, creating security silos. Furthermore, these systems use the same encryption strength and verification strategy for business requests of different risks (e.g., "log query" and "transfer transaction" requests), leading to a severe mismatch of security resources. This causes unnecessary performance overhead for low-risk services while leaving high-risk services with insufficient protection. Therefore, these static, predefined security strategies cannot adapt to dynamically changing operating environments, modern high-frequency, multi-modal business scenarios, or implement precise and intelligent security strategies based on business needs. This results in a disconnect between security strategies and business requirements, and insufficient communication security strength. Summary of the Invention

[0006] To address or partially address the problems existing in related technologies, this application provides a communication method, communication system, and storage medium that can dynamically adjust encryption strategies according to encrypted service requests, achieving precise matching between encryption strategies and services, and improving the security strength of communication.

[0007] A first aspect of this application provides a communication method, the method comprising: Receive encrypted service requests from clients that are encrypted using the dynamic session key of the current session, and perform multi-dimensional dynamic verification on the encrypted service requests. The multi-dimensional dynamic verification includes two or more of the following: spatiotemporal verification, two-factor authentication, quantum chain verification, integrity verification, business logic verification, and quantum shield signature verification. When the multi-dimensional dynamic verification of the encrypted service request passes, the risk level of the encrypted service request is obtained; Based on the risk level, an encryption algorithm is determined, and the response data for the encrypted service request is encrypted using the encryption algorithm.

[0008] In one implementation, the spatiotemporal verification includes: The time window is dynamically calculated based on the network latency of historical encrypted service requests. Obtain the first timestamp of the client sending the encrypted service request; if the first time difference between the first timestamp and the current time exceeds the time window, the encrypted service request has expired; if the first time difference is within the time window, the encrypted service request has not expired; and / or, Obtain the second timestamp of the quantum random number that generated the encrypted service request. If the second time difference between the second timestamp and the current time exceeds the time window, the encrypted service request has expired. If the second time difference is within the time window, the encrypted service request has not expired.

[0009] In one implementation, obtaining the risk level of the encrypted service request includes: parsing the service context of the request body of the encrypted service request to obtain the client IP, device ID, and service type of the encrypted service request; and obtaining the risk level of the encrypted service request based on the client IP, device ID, service type, and the verification result of the multi-dimensional dynamic verification.

[0010] In one implementation, the method further includes key threshold verification of the dynamic session key, including: Obtain the cumulative usage count of the dynamic session key. If the cumulative usage count is greater than or equal to a rolling count threshold, include a key update notification in the response data for the encrypted service request, so that the client updates the dynamic session key based on the key update notification; and / or, The cumulative usage time of the dynamic session key is obtained. If the cumulative usage time is greater than or equal to the rolling duration threshold, a key update notification is carried in the response data of the encrypted service request so that the client updates the dynamic session key according to the key update notification.

[0011] In one implementation, the threshold for the number of scrolling times is T, where T = B × R × log 10 (N+1), where B represents the baseline value; N represents the activity level of the client, which is the number of encrypted service requests made by the client within a set time period; and R represents the real-time risk coefficient.

[0012] In one implementation, the dynamic session key is a symmetric key generated by the client based on a 32-byte true random number, with the client's device ID as the salt and the session ID of the current session as the information field.

[0013] In one implementation, the encrypted service request includes a request body, the request body including an encryption key, wherein the encryption key is a key generated by the client using an asymmetric encryption public key to encrypt data concatenated with a 16-byte true random number and the dynamic session key.

[0014] In one implementation, determining an encryption algorithm based on the risk level, and using the encryption algorithm to encrypt the response data responding to the encrypted service request, includes: If the risk level is high risk, the encryption algorithm is determined to be AES-256-GCM encryption algorithm, and the response data of the encrypted service request is encrypted using the AES-256-GCM encryption algorithm. If the risk level is medium risk, then the encryption algorithm is determined to be AES-128-GCM encryption algorithm, and the response data of the encrypted service request is encrypted using the AES-128-GCM encryption algorithm. If the risk level is low, the encryption algorithm is determined to be the ChaCha20-Poly1305 encryption algorithm, and the response data of the encrypted service request is encrypted using the ChaCha20-Poly1305 encryption algorithm.

[0015] A second aspect of this application provides a communication system, the communication system including a client and a server; wherein, the client is configured to generate an encrypted service request based on the dynamic session key of the current session, and send the encrypted service request to the server; The server is configured to receive the encrypted service request sent by the client and perform multi-dimensional dynamic verification on the encrypted service request; when the multi-dimensional dynamic verification of the encrypted service request passes, the server obtains the risk level of the encrypted service request; based on the risk level, the server determines an encryption algorithm and uses the encryption algorithm to encrypt the response data responding to the encrypted service request; wherein, The multi-dimensional dynamic verification includes two or more of the following: spatiotemporal verification, two-factor authentication, quantum blockchain verification, integrity verification, business logic verification, and quantum shield signature verification.

[0016] A third aspect of this application provides an electronic device, comprising: Processor; and A memory that stores executable code, which, when executed by the processor, causes the processor to perform the method described above.

[0017] A fourth aspect of this application provides a computer-readable storage medium having executable code stored thereon, which, when executed by a processor of an electronic device, causes the processor to perform the method described above.

[0018] The fifth aspect of this application provides a computer program product comprising computer instructions that, when executed by a processor, implement the method described above.

[0019] The technical solution provided in this application may include the following beneficial results: The technical solution of this application performs multi-dimensional dynamic verification of encrypted service requests from clients. When the multi-dimensional dynamic verification of an encrypted service request passes, the risk level of the encrypted service request is obtained. Based on the risk level of the encrypted service request, an encryption algorithm is determined, and the response data of the encrypted service request is encrypted using the encryption algorithm. By parsing the business context of the encrypted service request, and based on the business context of the encrypted service request and the verification results of the multi-dimensional dynamic verification, the risk level of the encrypted service request is evaluated in real time, and encryption strategies are scheduled according to the risk level of the encrypted service request. This achieves dynamic and accurate matching between encryption strategies and business risks, solving the fundamental problem of security resource mismatch. Determining the encryption algorithm for the encrypted response data of the encrypted service request based on its risk level saves server-side computing resources while ensuring the highest level of protection for high-risk services. The communication method of this application embodiment dynamically generates and distributes differentiated data encryption strategies based on the risk assessment results of encrypted service requests, achieving accurate matching between security strategies and business risks. It can dynamically adjust encryption strategies according to encrypted service requests, achieving accurate matching between encryption strategies and services, and improving the security strength of communication.

[0020] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0021] The above and other objects, features and advantages of this application will become more apparent from the more detailed description of exemplary embodiments thereof in conjunction with the accompanying drawings, wherein the same reference numerals generally represent the same components in the exemplary embodiments thereof.

[0022] Figure 1 This is a schematic flowchart illustrating the communication method in an embodiment of this application; Figure 2 This is another schematic flowchart illustrating the communication method shown in the embodiments of this application; Figure 3 This is a schematic diagram of the communication system shown in the embodiments of this application; Figure 4This is another schematic diagram of the communication system shown in the embodiments of this application; Figure 5 This is a schematic diagram of the structure of an electronic device shown in an embodiment of this application. Detailed Implementation

[0023] Embodiments of this application will now be described in more detail with reference to the accompanying drawings. While embodiments of this application are shown in the drawings, it should be understood that this application may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided to make this application more thorough and complete, and to fully convey the scope of this application to those skilled in the art.

[0024] The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The singular forms “a,” “the,” and “the” used in this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more of the associated listed items.

[0025] It should be understood that although the terms "first," "second," "third," etc., may be used in this application to describe various information, this information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this application, "multiple" means two or more, unless otherwise explicitly specified.

[0026] This application provides a communication method that can dynamically adjust the encryption strategy according to the encryption service request, so as to achieve accurate matching between the encryption strategy and the service and improve the security of communication.

[0027] The technical solutions of the embodiments of this application are described in detail below with reference to the accompanying drawings.

[0028] Figure 1 This is a schematic flowchart illustrating the communication method shown in an embodiment of this application. See also... Figure 1 A communication method, comprising: Step 101: Receive the encryption service request from the client, which is encrypted using the dynamic session key of the current session, and perform multi-dimensional dynamic verification on the encryption service request.

[0029] In one embodiment, at the start of the current session between the client and the server, the client encrypts the user-initiated business request using the dynamic session key of the current session, generates an encrypted business request, and sends the encrypted business request to the server. The server receives the encrypted business request sent by the client and decrypts and performs multi-dimensional dynamic verification on the encrypted business request. The multi-dimensional dynamic verification includes two or more of the following: spatiotemporal verification, two-factor authentication, quantum blockchain verification, integrity verification, business logic verification, and quantum shield signature verification.

[0030] Step 102: When the multi-dimensional dynamic verification of the encrypted business request passes, obtain the risk level of the encrypted business request.

[0031] In one embodiment, when the multi-dimensional dynamic verification of the encrypted business request passes, the server parses the encrypted business request, obtains the context (biz_context) of the encrypted business request, and calls the risk control module to assess the risk level of the encrypted business request based on the context (biz_context) and the verification result of the multi-dimensional dynamic verification of the encrypted business request.

[0032] Step 103: Determine the encryption algorithm based on the risk level of the encrypted service request, and use the encryption algorithm to encrypt the response data of the encrypted service request.

[0033] In one embodiment, the risk level of the encrypted service request includes high risk, medium risk, and low risk. If the risk level of the encrypted service request is high risk, the server selects the AES-256-GCM (16-byte authentication tag) encryption algorithm as the encryption algorithm for responding to the encrypted service request, generates an encryption policy, writes the encryption policy into the response header, and sends it to the service processing service. The response data for responding to the encrypted service request is then encrypted using the AES-256-GCM (16-byte authentication tag) encryption algorithm and a dynamic session key.

[0034] In one embodiment, if the risk level of the encrypted service request is medium risk, the server selects the AES-128-GCM (12-byte authentication tag) encryption algorithm as the encryption algorithm for responding to the encrypted service request, generates an encryption policy, writes the encryption policy into the response header, and sends it to the service processing service. The response data for responding to the encrypted service request is encrypted using the AES-128-GCM (12-byte authentication tag) encryption algorithm and the dynamic session key.

[0035] In one embodiment, if the risk level of the encrypted service request is low, the server selects the ChaCha20-Poly1305 (12-byte authentication tag) encryption algorithm as the encryption algorithm for responding to the encrypted service request, generates an encryption policy, writes the encryption policy into the response header, and sends it to the service processing service. The response data for responding to the encrypted service request is encrypted using the ChaCha20-Poly1305 (12-byte authentication tag) encryption algorithm and the dynamic session key.

[0036] The communication method of this application embodiment performs multi-dimensional dynamic verification of encrypted service requests from clients. When the multi-dimensional dynamic verification of an encrypted service request passes, the risk level of the encrypted service request is obtained. Based on the risk level of the encrypted service request, an encryption algorithm is determined, and the response data of the encrypted service request is encrypted using the encryption algorithm. By parsing the business context of the encrypted service request, and based on the business context of the encrypted service request and the verification results of the multi-dimensional dynamic verification, the risk level of the encrypted service request is evaluated in real time, and encryption strategies are scheduled according to the risk level of the encrypted service request. This achieves dynamic and accurate matching between encryption strategies and business risks, solving the fundamental problem of security resource mismatch. Determining the encryption algorithm for the encrypted response data of the encrypted service request based on its risk level saves server-side computing resources while ensuring the highest level of protection for high-risk services. The communication method of this application embodiment dynamically generates and distributes differentiated data encryption strategies based on the risk assessment results of encrypted service requests, achieving accurate matching between security strategies and business risks. It can dynamically adjust encryption strategies according to encrypted service requests, achieving accurate matching between encryption strategies and services, and improving the security strength of communication.

[0037] Figure 2 This is another schematic flowchart illustrating the communication method in an embodiment of this application. Figure 2 Compared to Figure 1 The scheme of this application is described in more detail. See also Figure 2 A communication method, comprising: Step 200: Receive the client's encryption service request, which is encrypted based on the dynamic session key of the current session.

[0038] In one embodiment, the client and server establish a current session. At the start of this session, the client can generate a dynamic session key through zero-trust initialization and dynamic key self-determination. Based on this dynamic session key, the client encrypts the user-initiated business request, generating an encrypted business request, which is then sent to the server. The encrypted business request includes a request body. The request body includes business request data (enc_data), an encryption key (enc_key), a quantum nonce, a timestamp, and a business context (biz_context). Through the zero-trust initialization and dynamic key self-determination mechanism, the computational burden of generating the dynamic session key is distributed to the client. This completely eliminates the server's performance bottleneck during the key negotiation phase. Actual test data shows that the key negotiation handshake latency is reduced from an average of 158 milliseconds to 74 milliseconds, a reduction of 53%; the key negotiation interruption rate due to server failure is reduced from 15% to below 0.1%, significantly improving the server's horizontal scalability and performance.

[0039] In one embodiment, at the start of the current session between the client and the server, the client can call the QTRE (Quantum True Random Entropy Engine) API (Application Programming Interface) to obtain a 32-byte true random number generated by QTRE. Using a HKDF (Hash-Based Key Derivation Function), with the client's device ID as the salt and the session ID of the current session as the information field, an AES-256 symmetric key is generated. This AES-256 symmetric key serves as the dynamic session key for the current session. The generation process of the AES-256 symmetric key is verified according to the NIST SP 800-108 Key Derivation Function (KDF) standard, ensuring the unpredictability of the dynamic session key.

[0040] In one embodiment, the client can use a dynamic session key to generate encrypted business data (enc_data) for the request body. The client can use a symmetric encryption algorithm to encrypt specific business parameters based on the dynamic session key of the current session, generating encrypted business data (enc_data) to ensure the confidentiality of the business data. The symmetric encryption algorithm can be AES (Advanced Encryption Standard)-GCM symmetric encryption algorithm. GCM (Galois / Counter Mode) is a block cipher mode that combines Counter Mode and Galois domain authentication, providing efficient encryption services and enabling message authentication to verify message integrity and authenticity.

[0041] In one embodiment, the encryption key (enc_key) of the request body is an encrypted dynamic session key. The client's RSA-Shield Padding Encryption (RISPE) module can call the QTRE API to obtain a 16-byte true random number generated by QTRE. Using this 16-byte true random number as a 16-byte dynamic mask, the 16-byte dynamic mask is concatenated with the dynamic session key for the current session. The server's RSA (asymmetric encryption algorithm) public key is extracted from the server's certificate. Based on the RSA public key, RSA-Shield Padding Encryption is used to encrypt the concatenated 16-byte dynamic mask and the dynamic session key (16-byte dynamic mask + dynamic session key) to generate an encryption key (enc_key). This encryption key (enc_key) is then used to transmit the dynamic session key for the current session to the server.

[0042] In one embodiment, the RSA private key and RSA public key used for RSA-Shield padding encryption can be an RSA-2048 / 4096 key pair conforming to the NIST FIPS 186-5 standard (digital signature standard). The RSA public key is stored in the server certificate, and the RSA private key is stored in the HSM (Hardware Security Module) to prevent leakage of the RSA private key and RSA public key. IntelliShield, based on OAEP (Optimal Asymmetric Encryption Padding), introduces a "dynamic mask generation" mechanism. The 16-byte dynamic mask is obtained by XORing a 16-byte truly random number generated by QTRE with the plaintext hash value (SHA-256), rather than being generated by a fixed algorithm. Encryption padding, by introducing a 16-byte truly random number, ensures that the same plaintext yields different ciphertexts after encryption, enhancing resistance to decryption oracle attacks and preventing replay attacks.

[0043] In one embodiment, the client can call the QTRE API to obtain a 12-byte true random number generated by QTRE, and then use the 12-byte true random number as the request body to generate a quantum random number (quantum_nonce).

[0044] In one embodiment, QTRE can use the quantum random number generator (QRNG, hardware model: Quantum QRNG 1200) of the quantum entropy source service cluster to generate one-time true random numbers. The generated true random numbers are tested according to 15 tests of NIST SP 800-22Rev.1a (e.g., frequency test P value ≥ 0.01, sequence test P value ≥ 0.01) to ensure the true randomness of the true random numbers and prevent prediction attacks.

[0045] In one embodiment, the client can obtain the timestamp of sending the encrypted service request to the server. The timestamp can be a 13-bit millisecond timestamp. The 13-bit millisecond timestamp is written into the timestamp field of the request body, and the 13-bit millisecond timestamp is used as the timestamp of the request body.

[0046] In one embodiment, the business context (biz_context) of the request body may include the client IP, device ID, and service type. When constructing an encrypted service request, the client can include the "client IP, device ID, and service type" as part of the business context (biz_context) in the request header. The "client IP, device ID, and service type" are then passed to the server all at once through the business context.

[0047] In one embodiment, the quantum nonce of the encrypted service request can be stored in a distributed verification storage cluster using blockchain-style random number storage. The quantum nonce, its generation timestamp (13-bit millisecond timestamp), the request ID, and the client IP are stored in the Hyperledger Fabric distributed ledger. Each block of the blockchain contains the hash value of the previous block, forming a chain structure to prevent the quantum nonce from being tampered with. The ledger nodes employ the PBFT (Practical Byzantine Fault Tolerance) consensus mechanism to ensure data consistency.

[0048] In one embodiment, QTRE utilizes quantum mechanical principles (e.g., quantum superposition, quantum entanglement) to generate truly random numbers, unlike classical pseudo-random algorithms. The truly random numbers generated by the quantum entropy source are unpredictable and non-repeatable, satisfying the stringent requirements of cryptography for true randomness. Pseudo-random number generators (PRNGs) rely on algorithms and seeds and can be predicted or broken; the quantum entropy source extracts randomness directly from physical processes. As a core module continuously outputting high-entropy random numbers, QTRE can be integrated into cryptographic systems, blockchains, or security chips, providing a fundamental random source (truly random numbers) for TLS (Transport Layer Security) encryption, digital signatures, or key generation.

[0049] In one embodiment, after receiving the encrypted service request sent by the client, the server initiates and coordinates multi-dimensional dynamic verification and key threshold control verification (key lifecycle verification) of the encrypted service request through the business-aware intelligent decision engine (spin key matrix scheduling center) and the intelligent business logic verification engine (E-ABLVE). The multi-dimensional dynamic verification includes two or more of the following: spatiotemporal verification, two-factor authentication, quantum chain verification, integrity verification, business logic verification, and quantum shield signature verification.

[0050] In one embodiment, the server can use a centralized business-aware intelligent decision engine to collect, analyze, and schedule multi-dimensional security elements such as dynamic session keys, quantum nonces, and business contexts (biz_context) for encrypted business requests in real time. The business-aware intelligent decision engine and the intelligent business logic verification engine form a dynamically rotating and adjustable security defense plane. The decisions of the business-aware intelligent decision engine and the intelligent business logic verification engine rely on a multi-dimensional input matrix composed of real-time network data, historical behavior data, quantum random sources, business risk control data, and load data, thus achieving matrix-based decision input. This matrix-based approach integrates multiple security verification dimensions, including spatiotemporal verification, two-factor authentication, quantum chain verification, integrity verification, business logic verification, quantum shield signature verification, and key lifecycle verification. It also integrates multi-dimensional dynamic verification and key threshold control verification into an ordered, interlocked verification process, constructing a proactive immune security system with defense-in-depth that can withstand diverse attacks. A single-dimensional breach cannot undermine overall security, achieving a matrix-based defense system. This three-dimensional, dynamic defense system proactively defends against replay, tampering, prediction, and forgery attacks. Based on actual testing of 100,000 attack samples, the interception rate against the above threats reached 100%; combined with a one-time dynamic session key, forward security is fully guaranteed.

[0051] In one embodiment, the server-side business-aware intelligent decision-making engine and intelligent business logic verification engine serve as the core, connecting security and business; each dimension of the multi-dimensional dynamic verification and key threshold control verification supports dynamic parameter adjustment; the multi-dimensional dynamic verification and key threshold control verification can be strictly ordered according to security dependencies, constructing a three-dimensional defense system with defense depth through multi-dimensional dynamic verification and key threshold control verification. The multi-dimensional dynamic verification and key threshold control verification for encrypted business requests include: Step 201: Determine whether the encryption service request has expired based on the first timestamp of the client sending the encryption service request; if yes, proceed to step 202; if no, proceed to step 203.

[0052] In one embodiment, the server can use a business-aware intelligent decision engine and a spatiotemporal dynamic adaptive timestamp verification mechanism to determine whether the encrypted business request has expired based on the first timestamp of the encrypted business request sent by the client, i.e., the timestamp of the request body. If the encrypted business request has expired, step 202 is executed; if the encrypted business request has not expired, step 203 is executed.

[0053] In one embodiment, the server can obtain the first timestamp of the encrypted service request sent by the client through a business-aware intelligent decision engine; calculate the first time difference between the first timestamp and the server's current time based on the first timestamp and the server's current time; determine whether the first time difference is within a time window; if the first time difference exceeds the time window, the encrypted service request has expired, triggering a quantum random number (quantum_nonce) secondary verification, and proceeding to step 202. If the first time difference is within the time window, the encrypted service request has not expired, and proceeding to step 203.

[0054] In one embodiment, the server can obtain the location of the requesting IP of the encrypted service request through a business-aware intelligent decision engine; determine the network latency of the encrypted service request based on the location of the requesting IP; and dynamically calculate the time window based on the network latency of the encrypted service request.

[0055] In one embodiment, the server can use a business-aware intelligent decision engine to dynamically calculate the time window based on the network latency of historical encrypted business requests and dynamically adjust the timestamp tolerance range (e.g., ±15s to ±120s), instead of a fixed time window; the historical request pattern statistics period is 24 hours, and the network latency is taken as the 95th percentile value (e.g., if the latency of 95% of requests in the past 24 hours is ≤30s, then the time window is initially set to ±45s).

[0056] In one embodiment, the dynamically calculated time window replaces the fixed time window of related technologies, which can effectively adapt to network fluctuations, significantly reduce the false rejection of legitimate requests due to network latency while ensuring security, and improve the robustness of the communication system and user experience.

[0057] Step 202: Determine whether the encrypted service request has expired based on the second timestamp of the quantum random number generated by the client. If yes, proceed to step 300; otherwise, proceed to step 203.

[0058] In one embodiment, if the encrypted service request is determined to have expired based on the first timestamp of the client sending the encrypted service request, the server can trigger a secondary quantum random number (quantum_nonce) verification through the business-aware intelligent decision engine. This involves performing a secondary quantum random number time verification on the encrypted service request, extracting the quantum random number (quantum_nonce), querying the 13-bit second timestamp recorded in the distributed ledger that generated the quantum random number (quantum_nonce), and calculating a second time difference based on the 13-bit second timestamp and the server's current time. The server then determines whether the encrypted service request has expired based on the second time difference. If the second time difference exceeds the time window, the encrypted service request has expired, and step 300 is executed. If the second time difference is within the time window, the encrypted service request has not expired, and step 203 is executed.

[0059] In one embodiment, if the encrypted service request sent by the client is determined to have expired based on the first timestamp of the encrypted service request sent by the client, the business-aware intelligent decision engine can trigger a secondary verification of the quantum nonce of the encrypted service request. By querying the distributed ledger, the generation timestamp of the quantum nonce (a 13-bit millisecond timestamp) can be obtained.

[0060] Step 203: Determine whether the location of the requesting IP of the encrypted service request is consistent with the location of the historical requesting IP; if yes, proceed to step 205; if no, proceed to step 204.

[0061] In one embodiment, if the encrypted service request sent by the client has not expired, the server can use the service-aware intelligent decision engine to obtain the location of the requesting IP of the encrypted service request using IP positioning or GPS information; based on the location of the requesting IP of the encrypted service request and the location of the historical requesting IP, a spatiotemporal dynamic adaptive timestamp verification mechanism is used to determine whether the location of the requesting IP of the encrypted service request is consistent with the location of the historical requesting IP; if the location of the requesting IP of the encrypted service request is consistent with the location of the historical requesting IP, then step 205 is executed; if the location of the requesting IP of the client's encrypted service request is inconsistent with the location of the historical requesting IP, then step 204 is executed.

[0062] In one embodiment, the server-side business-aware intelligent decision engine can call the Gaode Map IP location API or GPS information (the client is a mobile device) to obtain the location of the requesting IP of the encrypted service request. The request IP location refers to the geographical location information inferred from the IP address of the client that sent the encrypted service request. The historical request IP location can be the request IP location of the user's last encrypted service request sent through the client, or it can be the user's frequently used request IP location. The user's frequently used request IP location can be the request IP location of the user's encrypted service requests sent through the client a set number of times in a recent period, for example, the request IP location of 80% or more of the user's encrypted service requests in the past 30 days.

[0063] Step 204: Determine whether the two-factor authentication is successful; if yes, proceed to step 205; if no, proceed to step 300.

[0064] In one embodiment, if the IP address of the encrypted service request is inconsistent with the IP address of a historical request, the server-side business-aware intelligent decision engine triggers two-factor authentication (e.g., SMS verification code verification, login password verification) to perform two-factor authentication on the encrypted service request and determine whether the two-factor authentication passes. If the two-factor authentication passes, step 205 is executed; if the two-factor authentication fails, step 300 is executed. Performing two-factor authentication on the encrypted service request can prevent time zone spoofing attacks.

[0065] Step 205: Determine whether the quantum random number for the encrypted service request has been used; if yes, proceed to step 300; if no, proceed to step 206.

[0066] In one embodiment, if the two-factor authentication passes, the server-side business-aware intelligent decision engine can trigger quantum random number (quantum_nonce) verification based on the quantum random number (quantum_nonce) of the encrypted business request, and perform quantum chain verification (E-QC-TRVM). The business-aware intelligent decision engine queries the distributed verification storage cluster (e.g., a RedisCluster cluster) to see if the quantum random number (quantum_nonce) of the encrypted business request has been used; if the quantum random number (quantum_nonce) of the encrypted business request has been used, then step 300 is executed; if the quantum random number (quantum_nonce) of the encrypted business request has not been used, then step 206 is executed.

[0067] In one embodiment, the business-aware intelligent decision engine can use the Redis Cluster's SET keyvalue NX EX seconds atomic command to register the quantum nonce of the encrypted business request. If the quantum nonce of the encrypted business request is successfully registered, it means that the quantum nonce of the encrypted business request is being used for the first time and has not been used before, so step 206 is executed. If the quantum nonce of the encrypted business request fails to register (the key already exists), it means that the quantum nonce of the encrypted business request has been used, so the encrypted business request is determined to be a replay attack, and step 300 is executed.

[0068] In one embodiment, the client can use a high-performance distributed in-memory database cluster (e.g., a Redis Cluster cluster) with master-slave replication and a sentinel mechanism to store the quantum nonce (quantum_nonce) of the encrypted business request, the timestamp of the quantum nonce's generation, the request ID, and the client's IP address into the high-performance distributed in-memory database cluster, and set the time-to-live (TTL) value (Time To Live, which is the remaining time for a key from its creation or update until automatic deletion; the TTL command can be used to query the remaining time of a key, in seconds). Atomic operations within the Redis Cluster cluster ensure that the same quantum nonce can only be successfully registered once at a time, thus achieving global replay protection. The master-slave replication and sentinel mechanism of the Redis Cluster cluster ensure high data availability and consistency.

[0069] Step 206: Determine whether the encrypted service request has been tampered with; if yes, proceed to step 300; if no, proceed to step 207.

[0070] In one embodiment, the server-side business-aware intelligent decision engine can determine whether an encrypted business request has been tampered with based on the hash value carried in the encrypted business request. The business-aware intelligent decision engine can read the pre-shared key from the HSM and use HMAC (Keyed-hash message authentication code) - SHA (Secure Hash)... The algorithm (secure hash algorithm) uses the SHA-384 algorithm. Based on the request body of the encrypted service request, including all fields of the request body (enc_data, enc_key, quantum_nonce, timestamp, biz_context), a SHA-384 hash value is recalculated. The recalculated SHA-384 hash value is compared with the hash value (integrity_hash) carried in the encrypted service request to determine whether the recalculated SHA-384 hash value is consistent with the hash value (integrity_hash) carried in the encrypted service request, thus determining whether the encrypted service request has been tampered with. If the recalculated SHA-384 hash value is consistent with the hash value carried in the encrypted service request, the encrypted service request has not been tampered with, and step 207 is executed. If the recalculated SHA-384 hash value is inconsistent with the hash value carried in the encrypted service request, the encrypted service request has been tampered with, and step 300 is executed.

[0071] In one embodiment, the client can use the HMAC-SHA 384 algorithm to perform keyed hash calculation of the pre-shared key on all fields of the request body (Body) of the encrypted service request: service request data (enc_data), dynamic session key (enc_key), quantum random number (quantum_nonce), timestamp (timestamp), and service context (biz_context), to obtain the hash value (integrity_hash) of the request body (Body).

[0072] In one embodiment, the pre-shared key between the client and server can be a 256-bit symmetric key independent of the dynamic session key, which is periodically updated through quantum key distribution to enhance the security of the hash value. The pre-shared key is stored in a hardware security module (HSM, model: Utimaco HSM SE 400) to prevent forgery attacks caused by key leakage.

[0073] In one embodiment, the client and server use the same pre-shared key and field range to calculate the hash value. The range of the hash value calculation covers all fields of the request body (including enc_data, enc_key, quantum_nonce, timestamp, and biz_context). The hash value is used to verify the encrypted business request and to perform integrity verification on the encrypted business request, which can ensure the data integrity of the overall encrypted business request.

[0074] In one embodiment, hash value verification (integrity verification) can be used in conjunction with API interfaces (e.g., RESTful API or gRPC) to integrate a standardized verification process that includes "hash calculation → hash transmission → hash comparison → result feedback" into a RESTful (Representational State Transfer) API or gRPC (Google Remote Procedure Call, a high-performance open-source remote procedure call framework) to adapt to different business systems.

[0075] Step 207: Determine whether the encrypted service request passes the business logic verification; if yes, proceed to step 208; if no, proceed to step 300.

[0076] In one embodiment, the server-side Intelligent Business Logic Verification Engine (E-ABLVE) can perform business logic verification on encrypted business requests through a rule engine (e.g., the Drools 8.0 rule engine). The intelligent business logic verification engine can parse the business context (biz_context) of the encrypted business request body, and obtain the client IP, device ID, business type (obtained from the action field of the context), and risk level (obtained from the risk_level field of the context) of the encrypted business request from the business context (biz_context). It dynamically loads business verification rules based on the business type, and verifies user permissions and login status based on the client IP, device ID, business type, and risk level of the business context (biz_context). It also verifies whether the encrypted business request exhibits risky behavior and assesses the risk score of the encrypted business request, combining the rule engine and the risk control module. Finally, it determines whether the encrypted business request conforms to the business verification rules. If the encrypted business request conforms to the business verification rules, the business logic verification of the encrypted business request passes, and step 208 is executed; if the encrypted business request does not conform to the business verification rules, the business logic verification of the encrypted business request fails, and step 300 is executed. Business verification rules support visual configuration (e.g., "New device login + high-risk operation → trigger secondary verification"); updates to business verification rules do not require restarting the rule engine and are pushed in real time via API to adapt to rapidly changing business needs.

[0077] In one embodiment, when a client generates an encrypted service request, it can call the server's risk query API to pass the client's IP, device ID, and service type of the encrypted service request to the server and obtain the real-time risk coefficient R and risk level of the encrypted service request returned by the server.

[0078] In one embodiment, the intelligent business logic verification engine ensures that the business rules (such as order processes and payment conditions) of encrypted business requests are correctly executed, preventing business risks caused by business logic vulnerabilities. The intelligent business logic verification engine can be deployed on the server side using a microservice architecture, supporting over 100,000 verifications of encrypted business requests per second; it provides a circuit breaker mechanism, automatically activating locally cached risk rules (cache validity period of 5 minutes) when the risk control module fails to call, ensuring uninterrupted business operations.

[0079] Step 208: Mark the risk level of the encrypted service request.

[0080] In one embodiment, the risk level of an encrypted service request can include high-risk, medium-risk, and low-risk levels. The business-aware intelligent decision engine can invoke the risk control module to perform a risk assessment on the encrypted service request based on the business logic verification result of the intelligent business logic verification engine, the business type obtained from the `action` field of the context (`biz_context`), and the risk level obtained from the `risk_level` field of the context (`biz_context`), thus evaluating the risk score of the encrypted service request. Based on the estimated risk score, the risk level of the encrypted service request is determined. For example, encrypted service requests with a risk score greater than or equal to a set risk score threshold (e.g., a risk score greater than or equal to 80) are classified as high-risk.

[0081] For example, for an encrypted service request with the business type "package_upgrade" ("package upgrade"), the rule engine (e.g., Drools 8.0 rule engine) can verify "whether the user has package upgrade permission", "whether the login device is a frequently used login device" (comparing the user's device login records for the past 30 days), and "whether the encrypted service request contains risky behavior". The risk control module combines the business logic verification results of the encrypted service request from the rule engine, as well as "package_upgrade" and the risk level, to assess the risk score of the encrypted service request. If the risk score of the encrypted service request with the business type "package_upgrade" ("package upgrade") is greater than or equal to 80, the risk level of the encrypted service request with the business type "package_upgrade" is determined to be high risk.

[0082] Step 209: Determine whether the signature verification of the encrypted service request has passed; if yes, proceed to step 210; if no, proceed to step 300.

[0083] In one embodiment, the server-side business-aware intelligent decision engine can trigger Quantum Shield signature verification (EQ-Shield) to perform Quantum Shield signature verification (EQ-Shield) on encrypted business requests. The business-aware intelligent decision engine can extract the signature of the encrypted business request, split the signature, and obtain the quantum factor of the signature and the RSA signature; call QTRE to generate a new quantum factor, compare the new quantum factor with the quantum factor obtained from the splitting; if the new quantum factor is consistent with the quantum factor obtained from the splitting, the quantum factor verification passes; if the new quantum factor is inconsistent with the quantum factor obtained from the splitting, the quantum factor verification fails, and step 300 is executed; the business-aware intelligent decision engine uses the RSA signature private key (read from QSM) to generate a new RSA signature, and compares the new RSA signature with the RSA signature obtained from the splitting; if the new RSA signature is consistent with the RSA signature obtained from the splitting, the RSA signature verification passes; if the new RSA signature is inconsistent with the RSA signature obtained from the splitting, the RSA signature verification fails, and step 300 is executed. If both the RSA signature verification and the quantum factor verification pass, the signature of the encrypted service request is valid overall, and the signature verification of the encrypted service request passes, proceeding to step 210. If the RSA signature verification fails and / or the quantum factor verification fails, the signature of the encrypted service request is invalid, and the signature verification of the encrypted service request fails, proceeding to step 300.

[0084] In one embodiment, the server-side business-aware intelligent decision engine can read the RSA private key from the HSM to decrypt the encrypted business request, extract the signature of the encrypted business request, the encryption key (enc_key) of the request body, and the timestamp. Based on the signature of the encrypted business request, the engine performs Quantum Shield signature verification (EQ-Shield) on the encrypted business request to verify whether the signature of the encrypted business request is valid as a whole. If the signature of the encrypted business request is valid as a whole, the signature verification of the encrypted business request passes. The server-side business-aware intelligent decision-making engine uses the RSA signature private key (read from QSM) to decrypt the signature of the encrypted business request, obtains the quantum factor and RSA signature of the signature, and uses the RSA signature key to perform RSA-PSS signing and regenerate a new RSA signature based on the quantum factor, the encryption key (enc_key) of the request body, and the timestamp. The regenerated RSA signature is compared with the RSA signature obtained from decrypting the signature of the encrypted business request. If the new RSA signature matches the RSA signature obtained from decrypting the signature of the encrypted business request, the RSA signature is valid, and the RSA signature verification of the encrypted business request passes. If the new RSA signature does not match the RSA signature obtained from decrypting the signature of the encrypted business request, the RSA signature is invalid, and the RSA signature verification of the encrypted business request fails. The process then proceeds to step 300.

[0085] In one embodiment, the server can call QTRE to generate a new quantum factor and compare it with the quantum factor obtained from the signature of the encrypted service request. If the new quantum factor matches the quantum factor obtained from the signature of the encrypted service request, the quantum factor verification of the encrypted service request passes; if the new quantum factor does not match the quantum factor obtained from the signature of the encrypted service request, the quantum factor verification of the encrypted service request fails, and the signature verification of the encrypted service request also fails, proceeding to step 300; if both the RSA signature verification and the quantum factor verification of the encrypted service request pass, the signature verification of the encrypted service request passes, proceeding to step 210. During the signature verification of the encrypted service request, both the consistency of the quantum factor and the validity of the RSA signature are verified simultaneously, achieving dual protection against forgery.

[0086] In one embodiment, an RSA signature key is generated based on a quantum key distribution (QKD) protocol. The RSA signature key generation process utilizes the property of quantum entanglement, ensuring that each pair of RSA signature keys is used only once, thus avoiding the risk of RSA signature keys being reused. The RSA signature key is stored in a quantum secure module (QSM) to prevent physical theft. The quantum key distribution protocol ensures the security of RSA signature key transmission and prevents man-in-the-middle attacks.

[0087] In one embodiment, when the client generates the signature of the encrypted service request, it calls QTRE to generate a 16-byte true random number. The 16-byte true random number is used as the quantum factor and concatenated with the encryption key (enc_key) and timestamp of the request body to form a complete signature input of quantum factor + encryption key (enc_key) + timestamp. The client then performs RSA-PSS signing using the RSA signing private key to generate a two-layer signature of "quantum factor + RSA signature". This two-layer signature of "quantum factor + RSA signature" is used as the signature of the encrypted service request.

[0088] Step 210: Determine whether the cumulative number of times the dynamic session key has been used is greater than or equal to the rolling number threshold; if yes, proceed to step 212; if no, proceed to step 211.

[0089] In one embodiment, the server-side business-aware intelligent decision engine can use the DK-STC (Dynamic Key Security Threshold Control) mechanism to record the cumulative number of times the dynamic session key is used, and determine whether the cumulative number of times the dynamic session key is used is greater than or equal to the rolling number threshold; if the cumulative number of times the dynamic session key is used is greater than or equal to the rolling number threshold, then step 212 is executed; if the cumulative number of times the dynamic session key is used is less than the rolling number threshold, then step 211 is executed.

[0090] In one embodiment, the business-aware intelligent decision engine can calculate the scroll count threshold T using the following formula: T = B × R × log 10 (N+1), where B represents the baseline value; N represents the client's activity level, which is the number of encrypted service requests made by the client within a set time period; and R represents the real-time risk coefficient.

[0091] In one embodiment, when a client generates an encrypted service request, it can call the server's risk query API, passing the client's IP address, device ID, and service type to the server to obtain the real-time risk coefficient R and risk level of the encrypted service request returned by the server. The baseline value B can be a fixed value (e.g., 1000). The number N of encrypted service requests made by the client within a set time period can be obtained from the Redis Cluster statistics; the number N can be the number of encrypted service requests made by the client in 24 hours. The real-time risk coefficient R can be obtained by the risk control module based on the encrypted service request, and the value range of the real-time risk coefficient R is 0.5-2.0.

[0092] Step 211: Determine whether the cumulative usage time of the dynamic session key is greater than or equal to the rolling duration threshold; if yes, proceed to step 212; if no, proceed to step 213.

[0093] In one embodiment, the server-side business-aware intelligent decision engine can use the DK-STC mechanism to record the cumulative usage time of the dynamic session key and determine whether the cumulative usage time of the dynamic session key is greater than or equal to the rolling duration threshold. If the cumulative usage time of the dynamic session key is greater than or equal to the rolling duration threshold (e.g., 8 hours, 12 hours, 24 hours), then step 212 is executed; if the cumulative usage time of the dynamic session key is less than the rolling duration threshold, then step 213 is executed.

[0094] In one embodiment, the rolling frequency of the dynamic session key can be determined by real-time security metrics. These metrics may include the cumulative number of times the dynamic session key is used (the number of encrypted business requests within a single session), the time interval (the cumulative usage duration of the dynamic session key), threat detection results (e.g., whether an SQL injection attack is detected), and risk scenarios (risk level, e.g., the risk level of the encrypted business request is high-risk). If an SQL injection attack is detected, or the risk level of the encrypted business request is high-risk, the business-aware intelligent decision engine can increase the rolling frequency of the dynamic session key by 2 times.

[0095] In one embodiment, the client and / or server can provide a lifecycle monitoring panel for dynamic session keys, which displays in real time the number of times the dynamic session key has been used (cumulative number of uses), cumulative usage duration, remaining validity period (remaining usage duration), rolling count threshold T, and rolling duration threshold. It also supports manual emergency rolling of dynamic session keys. When a risk of dynamic session key leakage is detected, the administrator can trigger a dynamic session key update for the entire communication system through the panel.

[0096] Step 212: Include a key update notification in the response data of the encrypted service request so that the client can update the dynamic session key based on the key update notification.

[0097] In one embodiment, if the cumulative number of times the dynamic session key is used is greater than or equal to the rolling number threshold, a key update notification is carried in the response data of the encrypted service request so that the client updates the dynamic session key according to the key update notification.

[0098] In one embodiment, if the cumulative usage time of the dynamic session key is greater than or equal to the rolling duration threshold, a key update notification is carried in the response data of the encrypted service request so that the client updates the dynamic session key according to the key update notification.

[0099] In one embodiment, if the cumulative usage count of the dynamic session key is greater than or equal to the rolling count threshold, or if the cumulative usage duration of the dynamic session key is greater than or equal to the rolling duration threshold, the business-aware intelligent decision engine marks "key rolling needs to be triggered" in the response data of the encrypted business request, includes a "key update notification" in the server's response header, and encrypts and transmits the response data carrying the "key update notification" to the client. The client receives the response data, and based on the "key update notification" carried in the response data, calls QTRE to generate a new dynamic session key, updates the dynamic session key, and encrypts the new dynamic session key before sending it back to the server. After verifying the validity of the new dynamic session key, the server updates the dynamic session key, completing the dynamic session key rolling. After the server's business processing service completes the response to the encrypted business request, it immediately calls the memory clearing function to destroy the dynamic session key in memory; persistent storage of the dynamic session key is not supported.

[0100] Step 213: Determine the encryption algorithm based on the risk level of the encryption service request, and use the encryption algorithm to encrypt the response data of the encryption service request.

[0101] In one embodiment, the business-aware intelligent decision engine can obtain the risk level of an encrypted business request and determine the encryption algorithm based on the risk level. The response data for the encrypted business request is then encrypted using the encryption algorithm. The risk levels of the encrypted business request include high-risk, medium-risk, and low-risk levels. If the risk level of the encrypted business request is high-risk, the server selects the AES-256-GCM (16-byte authentication tag) encryption algorithm as the encryption algorithm for responding to the encrypted business request, generates an encryption policy, writes the encryption policy into the response header, and sends it to the business processing service. The response data for the encrypted business request is then encrypted using the AES-256-GCM encryption algorithm and a dynamic session key. AES-256 is a symmetric encryption algorithm that uses a 256-bit key.

[0102] In one embodiment, if the risk level of the encrypted service request is medium risk, the server selects the AES-128-GCM (12-byte authentication tag) encryption algorithm as the encryption algorithm for responding to the encrypted service request, generates an encryption policy, writes the encryption policy into the response header, and sends it to the service processing service. The response data for responding to the encrypted service request is then encrypted using the AES-128-GCM encryption algorithm and a dynamic session key. AES-128 is a symmetric encryption algorithm that uses a 128-bit key.

[0103] In one embodiment, if the risk level of the encrypted service request is low, the server selects the ChaCha20-Poly1305 (12-byte authentication tag) encryption algorithm as the encryption algorithm for responding to the encrypted service request, generates an encryption policy, writes the encryption policy into the response header, and sends it to the service processing service. The response data for responding to the encrypted service request is then encrypted using the ChaCha20-Poly1305 encryption algorithm and a dynamic session key. ChaCha20 is a symmetric encryption algorithm, and Poly1305 is an authentication algorithm.

[0104] In one embodiment, the server reads the RSA private key from the HSM, uses RISPE to decrypt the encryption key enc_key of the encrypted service request to obtain the dynamic session key; processes the business logic (e.g., package upgrade, updating the user package database, generating order records); encrypts the response data (e.g., order number, effective time) of the encrypted service request according to the encryption strategy (e.g., using the AES-256-GCM (16-byte authentication tag) encryption algorithm) and the dynamic session key, and returns the encrypted response data to the client.

[0105] In one embodiment, during a client-server session, the client can use its local DK-STC module to record the cumulative number of times the dynamic session key is used via the DK-STC mechanism. The client then checks at set time intervals (e.g., every 30 seconds) whether the cumulative number of times the dynamic session key is used is greater than or equal to a rolling threshold. If the cumulative number of times the dynamic session key is used is greater than or equal to the rolling threshold, the client actively triggers a dynamic session key update. The updated dynamic session key is then used to encrypt user-initiated service requests, generating encrypted service requests. If the cumulative number of times the dynamic session key is used is less than the rolling threshold, the client continues to use the dynamic session key to encrypt user-initiated service requests, generating encrypted service requests.

[0106] In one embodiment, during a client-server session, the client can use its local DK-STC module to record the cumulative usage time of the dynamic session key using the DK-STC mechanism. The client then checks at set time intervals (e.g., every 30 seconds) whether the cumulative usage time is greater than or equal to a rolling duration threshold. If the cumulative usage time is greater than or equal to the rolling duration threshold, the client proactively triggers a dynamic session key update. The updated dynamic session key is then used to encrypt user-initiated service requests, generating encrypted service requests. If the cumulative usage time is less than the rolling duration threshold, the client continues to use the dynamic session key to encrypt user-initiated service requests, generating encrypted service requests. By proactively triggering dynamic session key updates during the client-server session, the client avoids dynamic session key desynchronization caused by lost key update notifications from the server.

[0107] Step 300: Deny encrypted service request.

[0108] In one embodiment, if an encrypted service request expires, the encrypted service request is rejected. If two-factor authentication fails, the encrypted service request is rejected. If the quantum nonce of the encrypted service request has been used, the encrypted service request is determined to be a replay attack and is rejected. If the SHA-384 hash value recalculated by the server is inconsistent with the integrity hash value carried in the encrypted service request, the encrypted service request is determined to have been tampered with and is rejected. If the encrypted service request does not meet the business verification rules, the business logic verification of the encrypted service request fails and is rejected. If the signature verification of the encrypted service request fails, the encrypted service request is rejected. When the server rejects an encrypted service request, it can return the corresponding error code (e.g., 401: Signature verification failed, 402: Nonce used) and record it in the security log. The security log is recorded to a security log database based on Security Information and Event Management (SIEM).

[0109] The communication method of this application embodiment uses a business-aware intelligent decision engine and an intelligent business logic verification engine as its core architecture. It supports the client's proactive and dynamic generation of dynamic session keys, possesses multi-dimensional dynamic verification, and can automatically adjust security policies according to business risks. This achieves multi-dimensional dynamic security verification and business risk-adaptive secure communication. Through systematic process design, it fundamentally solves the problems of security policies being disconnected from business operations and insufficient communication security strength in related technologies. The communication method of this application embodiment is applicable to scenarios with extremely high requirements for communication security and performance, such as telecommunications business support systems and core financial transaction systems.

[0110] Furthermore, the communication method in this embodiment, based on a business-aware intelligent decision engine and an intelligent business logic verification engine, can parse the business context of encrypted business requests and assess the risk level of encrypted business requests in real time. Based on the risk level of the encrypted business requests, it schedules encryption strategies, achieving dynamic and accurate matching between encryption strategies and business risks, thus solving the fundamental problem of security resource mismatch. If the risk level of the encrypted business request is medium risk, the response data is encrypted using the AES-128-GCM (12-byte authentication tag) encryption algorithm; if the risk level is low risk, the response data is encrypted using the ChaCha20-Poly1305 (12-byte authentication tag) encryption algorithm. This allows low-risk businesses to be downgraded to use either the AES-128-GCM encryption algorithm or the ChaCha20-Poly1305 encryption algorithm, saving more than 35% of server-side computing resources while ensuring the highest level of protection for high-risk businesses. The communication method of this application determines the encryption algorithm of the response data of the encrypted service request based on the risk level of the encrypted service request. The security verification strategy and encryption strength are dynamically adjusted according to the business risk situation. This enables dynamic adjustment of the encryption strategy, freeing the security strategy from a fixed and predefined rigid mode. It can be intelligently and flexibly adjusted according to real-time business risks and system status, achieving efficient on-demand allocation of security resources and balancing security and performance.

[0111] Furthermore, in the communication method of this application embodiment, if the cumulative usage count of the dynamic session key is greater than or equal to the rolling count threshold, a key update notification is carried in the response data of the encrypted service request so that the client updates the dynamic session key according to the key update notification; and / or, if the cumulative usage duration of the dynamic session key is greater than or equal to the rolling duration threshold, a key update notification is carried in the response data of the encrypted service request so that the client updates the dynamic session key according to the key update notification. The dynamic session key is generated autonomously by the client, is destroyed after use, and is not stored or reused. It is dynamically adjusted according to the real-time calculated rolling count threshold or actively rolled updates. The dynamic adjustment of the encryption policy and the dynamic session key frees dynamic session key management and encryption policy management from the rigid mode of fixed periods, enabling intelligent adjustments based on the real-time load and threat situation of the communication system, thus achieving intelligent and highly flexible dynamic session key management and encryption policy management. The impact of dynamic session key leakage has been strictly limited from "all sessions within 7 days" to "a single session"; the rolling response time for dynamic session keys in high-risk scenarios has been shortened from 10 seconds to 5 seconds.

[0112] Corresponding to the aforementioned application function implementation method embodiments, this application also provides a communication system, an electronic device, and corresponding embodiments.

[0113] Figure 3 This is a schematic diagram of the communication system shown in the embodiments of this application.

[0114] See Figure 3 The communication system 3000 includes a client 310 and a server 320. The communication system 3000 is a dynamic and adaptive security policy coordination and execution system.

[0115] In one embodiment, the client 310 is configured to generate an encrypted service request based on the dynamic session key of the current session, and send the encrypted service request to the server 320.

[0116] In one embodiment, the server 320 is configured to receive an encrypted service request sent by the client 310 and perform multi-dimensional dynamic verification on the encrypted service request; when the multi-dimensional dynamic verification of the encrypted service request passes, the server obtains the risk level of the encrypted service request; based on the risk level, the server determines an encryption algorithm and uses the determined encryption algorithm to encrypt the response data of the encrypted service request; wherein, the multi-dimensional dynamic verification includes two or more of the following: spatiotemporal verification, two-factor authentication, quantum blockchain verification, integrity verification, business logic verification, and quantum shield signature verification.

[0117] See Figure 4The communication system 3000 can be a secure communication system with a business-aware intelligent decision-making engine and an intelligent business logic verification engine as its core architecture, including a client 310, a server 320, a distributed verification storage cluster 330, and a quantum entropy source service cluster 340. The client 310 includes a client security agent. The server 320 includes the business-aware intelligent decision-making engine and the intelligent business logic verification engine.

[0118] In one embodiment, during each session between client 310 and server 320, the client security agent of client 310 actively generates a dynamic session key based on the quantum entropy source using QTRE, and constructs an encrypted service request based on the dynamic session key. The client security agent can be embedded in the client (e.g., mobile APP, web browser) as a lightweight security component in the form of an integrated SDK, performing zero-trust initialization and dynamic key self-determination, generating true random numbers through the integrated QTRE, generating a dynamic session key based on the true random numbers, performing RISPE encryption (RSA-Smart Shield Fill Encryption) based on the dynamic session key, and generating an encrypted service request.

[0119] In one embodiment, after receiving an encrypted service request from the client 310, the server 320 performs multi-dimensional dynamic verification through a business-aware intelligent decision engine (i.e., a key matrix scheduling center). This multi-dimensional dynamic verification includes two or more of the following: spatiotemporal verification, two-factor authentication, quantum blockchain verification, integrity verification, business logic verification, and quantum shield signature verification. After successful multi-dimensional dynamic verification, an elastic encryption strategy is generated based on the risk level of the encrypted service request to process the service and respond. Throughout the entire session lifecycle, the dynamic session key is subject to security thresholding and rolling based on dynamically calculated rolling count thresholds and / or rolling duration thresholds.

[0120] In one embodiment, the business-aware intelligent decision engine (spin key matrix scheduling center) can embed multi-dimensional dynamic verification, run business risk analysis algorithms, issue elastic encryption policies, and be deployed at the business gateway or API gateway layer. As the "security brain" of the communication system 3000 and the entity of the spin key matrix, it is responsible for coordinating all security verification modules and making the final decision. The business-aware intelligent decision engine can take the form of an independently deployable microservice or a sidecar (auxiliary container) in a service mesh.

[0121] In one embodiment, the distributed verification storage cluster 330 (e.g., a Redis Cluster cluster) can be a distributed in-memory database cluster, providing highly available and high-performance distributed storage for achieving global consensus on instantaneous tokens (the shared state storage layer of the business-aware intelligent decision engine). The distributed verification storage cluster 330 can store and verify quantum random numbers (quantum_nonce) and maintain historical encrypted business request data with dynamic time windows.

[0122] In one embodiment, the quantum entropy source service cluster 340 can be a cloud-callable API service or a local hardware module that continuously outputs a high-entropy random number stream through QTRE to provide the entire communication system 3000 with true random numbers based on the principles of quantum mechanics.

[0123] In one embodiment, the communication system 3000 can adopt a microservice architecture, where each security component can scale independently and communicate through clearly defined APIs, naturally supporting cloud-native deployment. The business-aware intelligent decision engine and intelligent business logic verification engine of the server 320 serve as core microservices, and can interact with the client 310, the distributed verification storage cluster 330, and the quantum entropy source service cluster 340 through APIs to achieve dynamic scheduling of security capabilities.

[0124] The following uses the high-risk service of "users upgrading their service packages" as an example to illustrate the service-aware telecommunications service security communication system of this application embodiment. It demonstrates how the server-side service-aware intelligent decision-making engine and intelligent business logic verification engine transform service risks into specific security actions, including: Step 510: The user selects a package in the client's APP and clicks the "Upgrade Now" button.

[0125] Step 520: The client performs zero-trust initialization and dynamic key self-determination, generates an encrypted business request, and sends the encrypted business request to the server.

[0126] In one embodiment, the client, through a client security proxy, uses a zero-trust initialization and dynamic key self-determination mechanism to request a 32-byte true random number from the QTRE vector quantum entropy source service cluster; based on this 32-byte true random number, it generates an AES-256 symmetric key (i.e., a dynamic session key) for the current session using a key derivation function.

[0127] In one embodiment, the client security agent requests a 16-byte true random number from the quantum entropy source service cluster via QTRE. Using RISPE encryption (RSA-Smart Shield Padding Encryption) and the server's RSA public key, the agent encrypts the dynamic session key based on the 16-byte true random number, obtaining an encryption key (enc_key). Based on the dynamic session key, the client security agent encrypts business data (e.g., user ID, target package ID) using AES-GCM mode, obtaining encrypted business data enc_data and an authentication tag. The client security agent calls QTRE to obtain a one-time quantum random number (quantum_nonce) from the quantum entropy source service cluster and records the current timestamp accurate to 13 digits in milliseconds. The client security agent constructs a complete request body based at least on the encryption key (enc_key), the business data enc_data, and the quantum random number (quantum_nonce).

[0128] In one embodiment, the forward security of the dynamic session key and the unpredictability of encrypted business requests provide high-quality input for the encrypted business request verification of the server-side business-aware intelligent decision engine.

[0129] In one embodiment, an example of a request body is as follows: json { "enc_data": "aes_gcm_ciphertext_base64", "enc_key": "rsa_oaep_ciphertext_base64", "quantum_nonce": "q_7F83B1657FF1FC53...", "timestamp": 1722546800123, "biz_context": {"action": "package_upgrade", "risk_level": "high"} } Step 530: Intelligent decision-making and verification by the server-side business-aware intelligent decision-making engine.

[0130] In one embodiment, the server receives an encrypted service request sent by the client. The server's service-aware intelligent decision engine sequentially initiates and coordinates multi-dimensional dynamic verification and key threshold control verification, including: Step 531, spatiotemporal verification of encrypted business requests.

[0131] In one embodiment, the server can employ a spatiotemporal dynamic adaptive timestamp verification mechanism through a business-aware intelligent decision engine. This mechanism determines whether the client's encrypted service request has expired based on the first timestamp of the client's encrypted service request (timestamp) and / or the second timestamp of the quantum random number generated by the client for the encrypted service request, as well as the time window dynamically calculated by the business-aware intelligent decision engine. By replacing the fixed time window with a dynamically calculated time window, the problem of spatiotemporal verification of encrypted service requests being unable to adapt to network fluctuations is resolved.

[0132] In one embodiment, the server can use a business-aware intelligent decision engine to employ a spatiotemporal dynamic adaptive timestamp verification mechanism to determine whether the IP address of the client's encrypted business request is consistent with the IP address of the historical requests, based on the IP address of the client's encrypted business request and the IP address of the historical requests.

[0133] In one embodiment, the server uses a business-aware intelligent decision engine to determine whether the encrypted service request has expired and the location of the request IP, thereby achieving spatiotemporal verification of the encrypted service request.

[0134] Step 532: Perform secondary authentication on encrypted service requests.

[0135] Step 533: Verify the encrypted service request using QuantumChain.

[0136] In one embodiment, the server can query the distributed verification storage cluster (e.g., a Redis Cluster cluster) through a business-aware intelligent decision engine to see if the quantum nonce of the encrypted business request has already been used. The business-aware intelligent decision engine uses the Redis Cluster cluster's atomic command `SET key value NX EX seconds` to register the quantum nonce of the encrypted business request. If registration is successful, it indicates that the quantum nonce of the encrypted business request is being used for the first time, and verification is passed. If registration fails (the key already exists), it is determined to be a replay attack, and the request is rejected. Quantum chain verification is performed on the encrypted business request to achieve efficient and global instantaneous token anti-replay protection.

[0137] Step 534: Perform integrity verification on the encrypted service request.

[0138] Step 535: Perform business logic verification on the encrypted business request.

[0139] In one embodiment, the server-side Intelligent Business Logic Verification Engine (E-ABLVE) can perform business logic verification on encrypted business requests through a rules engine. The E-ABLVE parses the business context (biz_context) of the encrypted business request, identifies the business type as package_upgrade, and the risk level as high. The E-ABLVE then calls the risk control module to check, based on the business context (biz_context), whether the user has frequently conducted business within a short period, whether it is a new device login, or other risky behavior, and assesses the risk score of the encrypted business request.

[0140] Step 536: Perform Quantum Shield signature verification on the encrypted service request.

[0141] In one embodiment, the server can trigger Quantum Shield signature verification (EQ-Shield) through the business-aware intelligent decision engine to perform Quantum Shield signature verification (EQ-Shield) on encrypted business requests, verifying whether the signature of the encrypted business request is valid as a whole, and verifying whether the signature verification of the encrypted business request passes.

[0142] Step 540: Based on the verification results of the encrypted business request, the business logic verification results of the encrypted business request by the intelligent business logic verification engine, and the risk score of the encrypted business request, the business perception intelligent decision engine determines the risk level of the encrypted business request to be "high risk level". The business perception intelligent decision engine determines that the encryption algorithm for responding to the encrypted business request is the AES-256-GCM encryption algorithm and uses the AES-256-GCM encryption algorithm for response encryption.

[0143] In one embodiment, the business-aware intelligent decision engine outputs a comprehensive security status code and a clear, flexible encryption policy instruction. Through multi-process collaboration, the business-aware intelligent decision engine upgrades the static verification of related technologies to context-based, multi-dimensional dynamic verification and dynamic intelligent decision-making.

[0144] Step 550: Encryption of business processing and dynamic response.

[0145] In one embodiment, the business-aware intelligent decision engine sends the multi-dimensional dynamic verification results of the encrypted business request and the encryption strategy of encrypting the response using the AES-256-GCM encryption algorithm to the server-side business processing service. The business processing service uses the server's private key to decrypt the encryption key enc_key of the encrypted business request to obtain the dynamic session key generated by the client; processes the package upgrade business logic; and encrypts the business response data according to the encryption strategy issued by the business-aware intelligent decision engine and the dynamic session key obtained by decrypting the encryption key enc_key, generating the final encrypted response data to ensure the highest level of confidentiality of high-risk business data during transmission.

[0146] Step 560: Perform key threshold verification on the dynamic session key to achieve dynamic destruction and dynamic rolling of the dynamic session key.

[0147] In one embodiment, the service-aware intelligent decision engine immediately destroys the decrypted dynamic session key in memory upon completion of the current session response. The engine can employ a DK-STC mechanism to record the cumulative usage count of the dynamic session key in the current session. When the cumulative usage count is greater than or equal to the rolling count threshold T calculated by the engine, a key update notification is included in the encrypted response data to notify the client to update the dynamic session key. This enables one dynamic session key per session and proactive rolling, minimizing the exposure window of the dynamic session key and achieving intelligent, adaptive management of its lifecycle, significantly improving the performance and security of the communication system.

[0148] Regarding the communication system in the above embodiments, the specific ways in which each module, each unit, and each component performs operations have been described in detail in the embodiments related to the method, and will not be elaborated further here.

[0149] Figure 5 This is a schematic diagram of the structure of an electronic device shown in an embodiment of this application.

[0150] See Figure 5 The electronic device 1000 includes a memory 1010 and a processor 1020.

[0151] The processor 1020 can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor.

[0152] Memory 1010 may include various types of storage units, such as system memory, read-only memory (ROM), and permanent storage devices. ROM may store static data or instructions required by processor 1020 or other modules of the computer. Permanent storage devices may be read-write storage devices. Permanent storage devices may be non-volatile storage devices that retain stored instructions and data even when the computer is powered off. In some embodiments, permanent storage devices use mass storage devices (e.g., magnetic or optical disks, flash memory) as permanent storage devices. In other embodiments, permanent storage devices may be removable storage devices (e.g., floppy disks, optical drives). System memory may be a read-write storage device or a volatile read-write storage device, such as dynamic random access memory. System memory may store some or all of the instructions and data required by the processor during operation. Furthermore, memory 1010 may include any combination of computer-readable storage media, including various types of semiconductor memory chips (e.g., DRAM, SRAM, SDRAM, flash memory, programmable read-only memory), and disks and / or optical disks may also be used. In some embodiments, memory 1010 may include a removable storage device that is readable and / or writable, such as a laser disc (CD), a read-only digital multifunction optical disc (e.g., DVD-ROM, dual-layer DVD-ROM), a read-only Blu-ray disc, a high-density optical disc, a flash memory card (e.g., SD card, mini SD card, Micro-SD card, etc.), a magnetic floppy disk, etc. Computer-readable storage media do not contain carrier waves or transient electronic signals transmitted wirelessly or via wire. Executable code is stored on memory 1010, which, when processed by processor 1020, can cause processor 1020 to perform some or all of the methods described above.

[0153] Furthermore, the method according to this application can also be implemented as a computer program or computer program product, which includes computer program code instructions for performing some or all of the steps in the method described above.

[0154] Alternatively, this application may also be implemented as a computer-readable storage medium (or a non-transitory machine-readable storage medium or a machine-readable storage medium) storing executable code (or computer program or computer instruction code) that, when executed by a processor of an electronic device (or server, or communication system, etc.), causes the processor to perform part or all of the steps of the methods described above according to this application.

[0155] This application also provides a computer program product, which includes computer instructions that, when executed by a processor, implement the method described above.

[0156] The various embodiments of this application have been described above. These descriptions are exemplary and not exhaustive, nor are they limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles, practical application, or improvement of the technology in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. A communication method characterized by comprising: The method comprises the following steps: Receiving an encrypted service request encrypted by a dynamic session key of a current session according to a client, and performing multi-dimensional dynamic verification on the encrypted service request, wherein the multi-dimensional dynamic verification comprises two or more of time-space verification, secondary identity verification, quantum chain verification, integrity verification, service logic check, and quantum shield signature verification; When the multi-dimensional dynamic verification of the encrypted service request is passed, obtaining the risk level of the encrypted service request; According to the risk level, determining an encryption algorithm to encrypt response data responding to the encrypted service request by using the encryption algorithm.

2. The method of claim 1, wherein, The time-space verification comprises the following steps: According to the network delay of the historical encrypted service request, dynamically calculating a time window; Obtaining a first timestamp of sending the encrypted service request by the client, if a first time difference value between the first timestamp and the current time exceeds the time window, the encrypted service request is overdue, if the first time difference value is within the time window, the encrypted service request is not overdue; and / or, Obtaining a second timestamp of generating a quantum random number of the encrypted service request, if a second time difference value between the second timestamp and the current time exceeds the time window, the encrypted service request is overdue, if the second time difference value is within the time window, the encrypted service request is not overdue.

3. The method of claim 1, wherein, The method further comprises key threshold control verification on the dynamic session key, wherein the key threshold control verification comprises the following steps: Obtaining the cumulative use frequency of the dynamic session key, if the cumulative use frequency is greater than or equal to a rolling frequency threshold, carrying a key update notification in the response data responding to the encrypted service request, so that the client updates the dynamic session key according to the key update notification; and / or, Obtaining the cumulative use duration of the dynamic session key, if the cumulative use duration is greater than or equal to a rolling duration threshold, carrying a key update notification in the response data responding to the encrypted service request, so that the client updates the dynamic session key according to the key update notification.

4. The method of claim 1, wherein, B represents a reference value; N represents the activity of the client, which is the number of encrypted service requests of the client in a set duration; R represents a real-time risk coefficient. The dynamic session key is a symmetric key generated by the client according to a 32-byte true random number, taking the device ID of the client as a salt value, and taking the session ID of the current session as an information field. The encrypted service request comprises a request body, and the request body comprises an encryption key, wherein the encryption key is a key generated by encrypting the data of concatenating a 16-byte true random number and the dynamic session key by using an asymmetric encryption public key by the client.

5. The method of claim 4, wherein: The threshold of the number of rolls is T, where T = B x R x log 10 (N+1) ​ 6. The method of claim 1, wherein: ​ 7. The method of claim 2, wherein: ​ 8. The method of claim 1, wherein, The determining the encryption algorithm according to the risk level comprises: if the risk level is a high risk level, determining the encryption algorithm as an AES-256-GCM encryption algorithm to encrypt response data responding to the encrypted service request by using the AES-256-GCM encryption algorithm; if the risk level is a medium risk level, determining the encryption algorithm as an AES-128-GCM encryption algorithm to encrypt the response data responding to the encrypted service request by using the AES-128-GCM encryption algorithm; if the risk level is a low risk level, determining the encryption algorithm as a ChaCha20-Poly1305 encryption algorithm to encrypt the response data responding to the encrypted service request by using the ChaCha20-Poly1305 encryption algorithm.

9. A communication system, characterized by The system comprises a client and a server. The client is configured to generate an encrypted encrypted service request according to a dynamic session key of a current session, and send the encrypted encrypted service request to the server. The server is configured to receive the encrypted encrypted service request sent by the client, and perform multi-dimensional dynamic verification on the encrypted encrypted service request; when the multi-dimensional dynamic verification on the encrypted encrypted service request is passed, obtain a risk level of the encrypted encrypted service request; determine an encryption algorithm according to the risk level, and encrypt response data responding to the encrypted encrypted service request by using the encryption algorithm; wherein The multi-dimensional dynamic verification comprises two or more of time-space verification, secondary identity verification, quantum chain verification, integrity verification, business logic check, and quantum shield signature verification.

10. A computer-readable storage medium, characterized in that, The non-transitory computer-readable medium has stored thereon executable code that, when executed by a processor, causes the processor to perform the method of any one of claims 1-8.

Images