API interface data security transmission method, system and medium

Abstract

The application relates to an API interface data secure transmission method, system and medium, wherein the API interface data secure transmission method comprises the following steps: when a client sends an API interface request to a server, generating a high-entropy key based on multi-source physical entropy of the client; encrypting the API interface request based on the high-entropy key to obtain encrypted data, and signing the encrypted data, wherein the signature comprises a random number; sending the encrypted data and the signature to the server; obtaining a receiving delay time of the server and a dynamic delay time window of the current request; if the receiving delay time is within the dynamic delay time window and the random number passes the uniqueness check, determining that the API interface request is a legal request; the server verifies the signature, and decrypts the encrypted data after the verification is passed, thereby improving the security of API interface data transmission.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of communication, in particular to an API interface data secure transmission method, system and medium. BACKGROUND

[0002] Under the background of current digital transformation acceleration, API interface as the key hub of data and service interaction between various systems, its security directly affects the stability of enterprise core business and the safety of data assets. The wide deployment of API greatly improves the flexibility and scalability of the system, but also brings unprecedented security challenges. The current API security system mainly faces the following outstanding problems:

[0003] 1) The key entropy generated by traditional random numbers (such as Java SecureRandom) is insufficient and easy to be brute-forced.

[0004] 2) Static key risk: For example, WeChat payment uses a fixed merchant key, which has no forward security, and once leaked, it will lead to systematic security collapse and historical communication can be decrypted.

[0005] 3) There are replay attack vulnerabilities. Many API security solutions use static rules or fixed parameters, which are difficult to cope with complex and variable network environments and attack methods. For example, the fixed time window anti-replay mechanism cannot adapt to network delay fluctuations and is easy to mislead normal requests or be evaded by attackers. The defense system lacks intelligent and dynamic adjustment capabilities, making it difficult to achieve the unity of security and usability. SUMMARY

[0006] Therefore, it is necessary to provide an API interface data secure transmission method, system and medium in view of the above technical problems.

[0007] In a first aspect, an API interface data secure transmission method is provided, which comprises:

[0008] When the client sends an API interface request to the server, a high-entropy key is generated based on the multi-source physical entropy of the client;

[0009] The API interface request is encrypted based on the high-entropy key to obtain encrypted data, and the encrypted data is signed, and the signature includes a random number; the encrypted data and the signature are sent to the server;

[0010] The receiving delay time of the server and the dynamic delay time window of the current request are obtained, if the receiving delay time is within the dynamic delay time window, and the random number passes the uniqueness check, it is determined that the API interface request is a legal request, the server verifies the signature, and after the verification is passed, the encrypted data is decrypted.

[0011] In one embodiment, the generating a high-entropy key based on the multi-source physical entropy of the client when the client sends an API interface request to the server comprises:

[0012] generating random noise based on the multi-source physical entropy of the client;

[0013] extracting and expanding the random noise by a key derivation function to generate a first pseudo-random sequence;

[0014] generating a second pseudo-random sequence by taking the first pseudo-random sequence as an initial condition of a chaotic system, and generating a third pseudo-random sequence based on a Logistic mapping;

[0015] generating a high-entropy key based on the second pseudo-random sequence and the third pseudo-random sequence.

[0016] In one embodiment, the obtaining the dynamic delay time window comprises:

[0017] obtaining a one-way delay baseline based on a first session between the client and the server;

[0018] obtaining a single delay time of each legitimate request passing the signature verification, and updating an average delay and an average delay jitter based on the single delay time;

[0019] obtaining a dynamic delay time window of the current API interface request based on the average delay and the average delay jitter.

[0020] In one embodiment, the obtaining a dynamic delay time window of the current API interface request based on the average delay and the average delay jitter comprises:

[0021] obtaining a dynamic security coefficient according to the trust rating of the client;

[0022] obtaining a network macro-environment factor according to the overall load or network health status of the server;

[0023] obtaining a dynamic delay time window of the current API interface request based on the average delay, the average delay jitter, the dynamic security coefficient, the network macro-environment factor, and a preset absolute reference window.

[0024] In one embodiment, the obtaining a dynamic delay time window of the current API interface request based on the average delay and the average delay jitter comprises:

[0025]

[0026] wherein, a dynamic delay time window requested by the current API interface, an average delay, an average delay jitter, a dynamic security coefficient, a network macro-environment factor, an absolute reference window.

[0027] In one of the embodiments, the API interface request includes a request method, a request path, a request parameter, a request header, a request body, and request data, the API interface request is encrypted based on the high-entropy key to obtain encrypted data, and the encrypted data includes:

[0028] The API interface request is encrypted using the high-entropy key by adopting the national standard SM4 algorithm to obtain encrypted data.

[0029] The high-entropy key is encrypted using the public key of the national standard SM2 to obtain key ciphertext, and the key ciphertext is attached to the request header.

[0030] In one of the embodiments, the encrypted data is signed, and the signature is sent to the server, and the server verifies the signature, which includes:

[0031] The signature data of the Merkle tree root node is obtained by adopting the national standard SM3 algorithm.

[0032] The signature data is attached to the request header and sent to the server.

[0033] The server performs national standard SM3 calculation on each component of the signature data in parallel to obtain a root hash, and compares and verifies the root hash with the signature value of the client.

[0034] In one of the embodiments, the method further includes:

[0035] Judging whether the single delay time of each legal request passing the signature verification is abnormal.

[0036] If the number of abnormal times is greater than a preset value, the server triggers an alarm.

[0037] In a second aspect, the embodiments of the present application further provide an API interface data security transmission system, which includes a client and a server:

[0038] The client is configured to generate a high-entropy key based on the multi-source physical entropy of the client when sending an API interface request to the server, encrypt the API interface request based on the high-entropy key to obtain encrypted data, sign the encrypted data, the signature including a random number, send the encrypted data and the signature to the server, and perform national standard SM3 calculation on each component of the signature data in parallel to obtain a root hash, and compare and verify the root hash with the signature value of the client.

[0039] The server is configured to acquire a receiving delay time of the server and a dynamic delay time window of the current request, and determine that the API interface request is a legal request if the receiving delay time is within the dynamic delay time window and the random number passes the uniqueness verification. The server verifies the signature, and decrypts the encrypted data after the verification is passed.

[0040] In a third aspect, the embodiments of the present application further provide a computer readable storage medium, which stores a computer program. The computer program is executed by a processor to implement the method in the first aspect.

[0041] The API interface data security transmission method, system and medium described above generate a high-entropy key through the multi-source physical entropy of the client, encrypt the API interface request using the high-entropy key, and effectively guarantee data security. In the anti-replay attack, a dynamic delay time window is used instead of a fixed time window anti-replay mechanism, and whether the receiving delay time is within the dynamic delay time window is determined to prevent user replay attack behavior and improve the security of the API interface request.

[0042] The details of one or more embodiments of the present application are presented in the following drawings and description to make other features, objects and advantages of the present application more clear and easy to understand. BRIEF DESCRIPTION OF DRAWINGS

[0043] The drawings described herein are used to provide further understanding of the present application, and form a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application, and do not constitute an improper limitation on the present application. In the drawings:

[0044] Figure 1 FIG. 1 is a hardware structure block diagram of a terminal device of an API interface data security transmission method in an embodiment;

[0045] Figure 2 FIG. 4 is a flowchart of an API interface data security transmission method in an embodiment;

[0046] Figure 3 FIG. 7 is a flowchart of a dynamic delay time window judgment process in an embodiment;

[0047] Figure 4 FIG. 11 is a flowchart of full-feature encryption of an API interface request in an embodiment;

[0048] Figure 5 FIG. 14 is a flowchart of generation of a Merkle tree root node signature in an embodiment. DETAILED DESCRIPTION

[0049] In order to make the purpose, technical scheme and advantages of the present application clearer, the present application is described and explained below in combination with the drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and do not limit the present application.

[0050] The method embodiments provided in the embodiments can be applied to the application environment as shown in Figure 1 The client 102 is used to generate a high-entropy key based on the multi-source physical entropy of the client when sending an API interface request to the server; encrypt the API interface request based on the high-entropy key to obtain encrypted data, and sign the encrypted data, wherein the signature includes a random number; send the encrypted data and the signature to the server; and the server 104 is used to obtain the receiving delay time of the server and the dynamic delay time window of the current request, and if the receiving delay time is within the dynamic delay time window and the random number passes the uniqueness check, it is determined that the API interface request is a legal request, the server verifies the signature, and decrypts the encrypted data after the verification is passed.

[0051] The present application provides an API interface data security transmission method, as shown in Figure 2 The method comprises the following steps:

[0052] Step 201, when the client sends an API interface request to the server, a high-entropy key is generated based on the multi-source physical entropy of the client.

[0053] Specifically, the multi-source physical entropy of the client includes audio input white noise, high-precision time jitter, memory state entropy, CMOS image sensor noise, CPU hardware random instruction, etc. According to the actual scene requirements, the RDRAND instruction of the CPU, the linux blocking high-entropy source, and the BCryptGenRandom mode can be used to obtain.

[0054] Key entropy (Key Entropy) is a measure of how difficult it is to guess or find out through exhaustive attack. It is measured in bits, and the higher the value, the more random and unpredictable the key is, and therefore the more secure the corresponding encryption system is. It reflects the true "uncertainty" of the key generation process, and is a key indicator for evaluating the security of an encryption system. The high-entropy key generated by the multi-source physical entropy in this step effectively guarantees data security.

[0055] Step 202, encrypt the API interface request based on the high-entropy key to obtain encrypted data, and sign the encrypted data, wherein the signature includes a random number; send the encrypted data and the signature to the server.

[0056] Step 203, obtain the receiving delay time of the server and the dynamic delay time window of the current request. If the receiving delay time is within the dynamic delay time window and the random number passes the uniqueness check, it is determined that the API interface request is a legal request. The server verifies the signature, and after verification, the encrypted data is decrypted.

[0057] In the above API interface data security transmission method, a high-entropy key is generated by the multi-source physical entropy of the client, and the API interface request is encrypted using the high-entropy key, effectively ensuring data security. And in the anti-replay attack, instead of using a fixed time window anti-replay mechanism, a dynamic delay time window is used to determine whether the receiving delay time is within the dynamic delay time window, thereby preventing user replay attack behavior and improving the security of the API interface request.

[0058] In one embodiment, when the client sends an API interface request to the server, a high-entropy key is generated based on the multi-source physical entropy of the client, including the following steps:

[0059] Step 301, based on the multi-source physical entropy of the client, generate random noise.

[0060] By fusing several available physical entropies in the current scenario, random noise is generated.

[0061] Step 302, extract and expand the random noise through a key derivation function to generate a first pseudo-random sequence.

[0062] The key derivation function (HKDF) is divided into two stages, extraction and expansion. The present application uses the SM4 algorithm combined with the HKDF structure to realize entropy expansion, which expands the random noise obtained in step 301 above into a pseudo-random sequence of any length. Even if the attacker knows the algorithm and part of the output, it is impossible to reverse the seed or predict the subsequent value (to ensure forward security). At the same time, it supports anti-state recovery attack, even if the attacker obtains the internal state of DRBG (Deterministic Random Bit Generator), it is also impossible to trace back the historical output (backward security). The following is an example code:

[0063] # Use HKDF structure to enhance

[0064] def hkdf_sm4(ikm, salt, output_len):

[0065] prk = sm4_cmac(salt, ikm) # Extraction stage

[0066] return sm4_entropy_expansion(prk, output_len) # expansion phase

[0067] At step 303, the first pseudo-random sequence is taken as the initial condition of the chaotic system to generate a second pseudo-random sequence, and a third pseudo-random sequence is generated based on the Logistic mapping.

[0068] In the key generation process, the Logistic mapping and the Chen hyperchaotic system and other chaotic dynamic mechanisms are introduced, and the first random sequence after the physical entropy source is expanded is taken as the initial condition of the chaotic system. The chaotic system has high sensitivity and irreversibility, which can further improve the complexity and unpredictability of the key stream, effectively resisting brute force cracking and prediction attacks. The mathematical expression is:

[0069]

[0070] Wherein: is the initial value of the Chen hyperchaotic system, is the mapping function, represents the pseudo-random key sequence as the input of the chaotic system.

[0071] The Logistic mapping is a classical chaotic system model, and the third pseudo-random sequence is generated by the Logistic mapping, and the mathematical expression is:

[0072]

[0073] Wherein: is the control parameter, X n is the value of the nth iteration, X n+1 is the value of the n+1 iteration.

[0074] At step 304, a high-entropy key is generated based on the second pseudo-random sequence and the third pseudo-random sequence.

[0075] The application innovatively proposes a high-entropy key generation model based on a quantum-chaotic entropy fusion (QCEF) algorithm framework, which combines multiple physical entropy, chaotic dynamics and national encryption algorithm organically, significantly improves the randomness, unpredictability and dynamics of the key, and completely breaks through the security bottleneck of traditional static keys and low-entropy keys, providing a solid foundation for API interface data security transmission.

[0076] In one of the embodiments, obtaining the dynamic delay time window comprises the following steps:

[0077] Step 401, based on the first session of the client and the server, obtain the one-way delay baseline.

[0078] Specifically, when the client and the server establish a new session or periodic calibration, the session is associated through an access token (AccessToken), and a one-way delay baseline detection is first performed to solve the problem of no historical data available when the system "cold start", which includes the following steps:

[0079] 1. The client records the local sending timestamp in the first request or calibration request .

[0080] 2. After the server receives it, it immediately returns a special response containing its receiving timestamp and processing completion timestamp .

[0081] 3. After the client receives the response, it records the local receiving timestamp .

[0082] Through this interaction, the initial round-trip time (RTT) can be calculated:

[0083]

[0084] The initial one-way delay baseline can be estimated as , which will be used as the initial input value for subsequent dynamic calculation, providing a personalized starting point for each client.

[0085] Step 402, obtain the single delay time of each legal request verified by signature, and update the average delay and average delay jitter based on the single delay time.

[0086] For each legal request verified by signature, the system continuously learns and updates the client's delay profile, which includes:

[0087] The server records the time when the (i-th) request is received , and extracts the client's sending timestamp from the request, and calculates the single delay time :

[0088]

[0089] Update the average delay : use the exponential weighted moving average (EWMA) algorithm to smoothly update the average delay, so that it can reflect the latest network trend rather than instantaneous jitter, the formula is as follows:

[0090] ​

[0091] wherein a is a smoothing coefficient (e.g. 0.2) that determines the weight of the new data point, is the average latency of the (i-1)th request, is the average latency of the ith request.

[0092] Update the average latency jitter Similarly, update the average absolute deviation to quantify the stability of the network latency.

[0093]

[0094] wherein b is a jitter smoothing coefficient. The average latency of the ith request and the average latency jitter together constitute the real-time network latency profile of the client, and are cached in Redis in association with the access token (AccessToken).

[0095] Step 403, based on the average latency and the average latency jitter, obtain a dynamic latency time window for the current API interface request.

[0096] based on the average latency of the ith request and the average latency jitter to obtain a dynamic latency time window for the current API interface (i+1th) request.

[0097] In one embodiment, based on the average latency and the average latency jitter, obtaining a dynamic latency time window for the current API interface request comprises: obtaining a dynamic security coefficient according to the trust rating of the client; obtaining a network macro-environment factor according to the overall load or network health status of the server; based on the average latency, the average latency jitter, the dynamic security coefficient, the network macro-environment factor, and a preset absolute reference window, obtaining a dynamic latency time window for the current API interface request.

[0098] The dynamic latency time window of the embodiments of the present application is not simply based on the latency profile, but is dynamically generated by integrating multiple dimensions, specifically including the dynamic security coefficient of the client, the network macro-environment factor of the server, and the absolute reference window. Among them:

[0099] Dynamic security coefficient : related to the trust rating of the client, the initial value is a standard value (e.g. 3). If the client has continuous signature verification failures, illegal requests, etc. in the near future, its trust rating will decrease, The value of the verification window is also dynamically reduced, thereby tightening the verification window and taking more stringent precautions against suspicious clients. Conversely, for long-term well-behaved clients, the verification window can be appropriately relaxed.

[0100] Network macro-environment factor (≥1): Provided by the server global monitoring module, reflecting the overall load or network health of the current server cluster. In the case of DDoS attacks or large-scale network congestion, the verification window of all clients can be appropriately relaxed to avoid "avalanche effect" caused by systemic problems, reflecting the resilience of the system.

[0101] Absolute reference window (e.g. 500ms): As the last line of defense of the system, it ensures that the window will not be compressed to an unreasonable extent under any extreme calculation result.

[0102] In one embodiment, based on the average delay and the average delay jitter, the dynamic delay time window of the current API interface request is obtained using the following formula:

[0103]

[0104] wherein, is the dynamic delay time window of the current API interface request (i+1th), is the updated average delay of the client request (ith), is the updated average delay jitter of the client request (ith), is the dynamic security factor, is the network macro-environment factor, is the absolute reference window.

[0105] After the server receives the request, based on the current dynamic delay time window the final decision is made:

[0106]

[0107] wherein, is the time when the server receives the current request (i th), is the timestamp when the client sends the request (i th). Only requests that meet this condition and pass the nonce uniqueness check are considered legitimate requests, and then the server performs signature verification, dynamic key negotiation, and API secure communication.

[0108] The traditional anti-replay mechanism adopts a fixed time window (for example, 5 seconds). Such a "one-size-fits-all" strategy has inherent defects in a complex network environment: a too long window will give attackers an opportunity; a too short window will cause a large number of legitimate requests to be misjudged as timeout due to network jitter or server processing delay, affecting system availability. The embodiments of the present application completely abandon the static window mode and propose a dynamic time window mechanism based on multi-dimensional factor adaptive learning. The mechanism can establish an independent and real-time evolving network delay portrait for each client, and dynamically calculate the optimal verification window in combination with the network macro state and the client trust rating, thereby realizing the high unification of security and stability.

[0109] In one of the embodiments, the method further comprises: judging whether the single delay time of each legitimate request passing the signature verification is abnormal; if the number of abnormal times is greater than a preset value, the server triggers an alarm.

[0110] To ensure high performance, the update calculation and storage operation of the delay portrait are executed asynchronously in the background and do not block the normal API request processing link. In addition, the server also performs abnormal monitoring. If the single delay time calculated in step 402 deviates from the historical model by a large margin, for example, satisfies:

[0111]

[0112] wherein N is a set threshold value, for example, 5, and if , the server will mark it as a single delay abnormal event. When a certain client triggers multiple such events in a short period of time, even if its request finally falls within the dynamic delay window, the system can actively trigger an alarm or list the client in a high-risk observation list, automatically down-regulate the trust rating (i.e., reduce the dynamic security coefficient value) of the client, and realize the leap from passive defense to active threat perception.

[0113] As shown in Figure 3 , the client sends an API interface request to the server, including the timestamp of sending the request and a random number, and sends the API interface request encrypted by a high-entropy key to the server. After receiving the request, the server performs dynamic window judgment. If the receiving delay time is within the dynamic delay time window and the random number passes the uniqueness verification, the API interface request is determined to be a legitimate request. If the receiving delay time is not within the dynamic delay time window or the random number does not pass the uniqueness verification, the API interface request is determined to be an illegal request, and the illegal request is intercepted. At the same time, the server updates the dynamic delay time window based on the method described in the above embodiments.

[0114] ​With the wide application of API interface in financial, government affairs, Internet of Things and other high security demand scenarios, the security protection means of traditional API interface has been difficult to cope with the increasingly complex attack threats. The existing API interface usually exposes the key elements such as request method, path, parameter, header information, request body in plaintext form, which is extremely easy to be detected and attacked by attackers through traffic analysis, interface crawling, parameter tampering and other means, and there is a serious security risk.

[0115] The API interface request based on the http protocol usually includes the following components: ① interface request method, such as GET / POST / PUT / PATCH / DELETE; ② interface request parameters (Query Param), such as '?deivceId=35010201001320000100&streamId=0'; ③ interface request header information, that is, Http header information, such as Authorization, AccessToken, nonce, timestamp; ④ interface request body, that is, requestBody, which can be in the format of json, xml, form-data, x-www-form-urlencoded, raw; ⑤ interface request path, that is, resource path: such as / api / v1 / users.

[0116] In one of the embodiments, the API interface request includes request method, request path, request parameter, request header, request body and request data. The present application uses the national SM4 algorithm to encrypt the API interface request (request method, request path, request parameter, request header, request body and request data) using the high-entropy key, obtains the encrypted data; uses the public key of the national SM2 to encrypt the high-entropy key, obtains the key ciphertext, and attaches the key ciphertext to the request header.

[0117] Specifically, all key elements of the API interface are encrypted and hidden in the embodiments of the present application, such as Figure 4 As shown in the figure, the client sends the API interface request after full feature encryption to the server gateway, and the server performs decryption and feature restoration. Since the real path / parameter / method is hidden, the attacker cannot identify the interface features, which greatly improves the security protection capability of the interface, including:

[0118] Step one: hide the interface request method, and use POST interface request method in the client, and add request parameter_m in the Query Parm to mark the real interface request method. The server gateway intercepts the POST request of the client and performs unified conversion, and then distributes it to the specific interface processing unit. Table 1:

[0119] Table 1

[0120]

[0121] Step two: hide the interface path. Assuming the original interface path is , using the SM4 algorithm, the request parameters are encrypted by high-entropy keys and converted into Hex characters to obtain ciphertext . The client requests the / api interface on the server, and the encrypted path is transmitted through the request parameter , for example: '?ACT=2C9EE3FD467BF4CB570E96418831', due to the temporary nature of high-entropy keys and backward security, each request is different, and the real interface path can be hidden accordingly.

[0122] Step three: hide the interface request parameters. Assuming the original interface request parameters are , note that this includes the _m parameter in step one, we use the SM4 algorithm to encrypt the request parameters by high-entropy keys and convert them into Hex characters to obtain ciphertext .

[0123] Step four: hide the interface request header information. Assuming the original interface request header information (Key-Value format) is , using high-entropy keys, the request header information is encrypted by the SM4 algorithm and converted into Hex characters to obtain .

[0124] Step five: hide the interface request body. Assuming the original interface request body is , using high-entropy keys, the request body information is encrypted by the SM4 algorithm and converted into Hex characters to obtain .

[0125] The client encrypts the high-entropy key by the public key of the SM2 algorithm to obtain , Secret refers to the high-entropy key, ensuring the temporary nature and unique value of the key stream. When requesting, attach to the request header and send it to the server gateway.

[0126] The embodiments of the application realize the SM encryption and hiding of all factors of the API interface, completely eliminate the exposure of the interface in the network transmission process, and greatly improve the anti-attack ability and security protection level of the API system. Through request method camouflage, path parameter encryption, request header encryption, and high-entropy key temporary, all-round and three-dimensional API interface security protection is realized.

[0127] The existing API signature mechanism generally has problems of fragile structure, high collision probability, poor expansibility, etc., and is difficult to meet the actual needs in high security and high concurrency scenarios. First, the signature string structure is fragile, and the field order and null value processing are prone to errors. Second, there is a lack of request integrity verification. Third, the anti-replay relies only on the timestamp, which is risky. Fourth, the algorithm expansibility is poor. Fifth, the actual collision probability of ordinary signature methods such as MD5 is much higher than the theoretical value. Sixth, the key strength is insufficient and is easy to be cracked by rainbow table.

[0128] In one of the embodiments, the signing of the encrypted data and the sending of the signature to the server for verification include: obtaining signature data of a Merkle tree root node by using a national secret SM3 algorithm; and appending the signature data to the request header and sending it to the server. The server performs national secret SM3 calculation on each component of the signature data in parallel to obtain a root hash, and compares and verifies the root hash with the signature value of the client.

[0129] Specifically, the embodiments of the present application use a multi-layer dynamic signature algorithm (SM3-Merkle-based Dynamic Signature, SMDS) based on the national secret algorithm and the Merkle tree structure to systematically improve the security threshold and concurrent processing capability of the API signature. The specific implementation steps are as follows:

[0130] Step one: the client performs key exchange with the server through the ECDHE protocol to obtain a temporary AppSecret. The calculation complexity of the elliptic curve discrete logarithm problem (ECDLP) is exponential, which is difficult to crack by a classical computer. The ECDHE protocol provides forward secrecy to resist the risk of session key leakage. The server binds the temporary AppSecret to the unique attributes (such as accessToken) of the client for future signature verification. The temporary AppSecret is used as a signature item during communication, and the ECDHE protocol is re-negotiated every interval T to generate a new key.

[0131] Step two: innovate the signature structure by changing the traditional linear signature string to a Merkle tree structure, using the national secret security algorithm SM3 to solve the field order sensitivity problem and support parallel computing. The Merkle tree structure naturally eliminates the field order sensitivity and inconsistency in null value processing, avoiding the signature invalidation caused by the order or null value in the traditional signature method, and improving the robustness and ease of use of the signature mechanism. At the same time, the Merkle tree structure naturally has anti-collision and anti-tamper capabilities, which can effectively prevent the overall signature from being invalidated due to malicious modification of a single field, greatly improving the integrity and security of the signature. Due to the particularity of the interface request, the tree nodes are almost flat, and there are fewer intermediate nodes connecting the leaves to the root, so less data is needed to generate the proof. The steps of generating the signature of the Merkle tree root node in the present application are as follows:Figure 5 The signature of the Merkle tree root node is obtained by the following formula:

[0132]

[0133] Wherein, SM3 is a national algorithm, , HTTP method, Authorization, AccessToken, nonce, timestamp, Accept, Key fields such as value; The temporary key obtained in the previous step; HTTP method (such as GET, POST, PUT, DELETE, etc.); Authorization is the HTTP request header field; AccessToken is a short-term token; nonce is a one-time number or random string; timestamp is the timestamp; Accept is the HTTP request header field.

[0134] Step three: the client attaches the signature result in the request header and sends it to the server gateway.

[0135] Step four: the server does not use the traditional string splicing comparison method, but uses multi-core CPU resources to perform national SM3 calculation on each component of the request in parallel, and quickly reconstructs the Merkle tree. Finally, the calculated root hash is compared with the signature value of the client. This greatly reduces the calculation delay of the signature verification process, especially in high concurrency scenarios.

[0136] The embodiments of the application deeply integrate the national SM3 algorithm and the Merkle tree structure, propose a multi-layer dynamic signature and efficient parallel signature verification mechanism, and significantly improve the anti-collision ability, integrity verification efficiency and high concurrency processing capability of API signature. Through dynamic key negotiation, structural innovation and parallel computing and other technical breakthroughs, a solid signature protection barrier is provided for API interface security, greatly improving the system's security threshold and practical value.

[0137] ​The application further provides an API interface data security transmission system, which comprises a client and a server.

[0138] It should be noted that the embodiments of the API interface data security transmission method and system provided by the application are not limited to the traditional http / https protocol environment, and have strong protocol adaptability and scene universality. The core security mechanism can be seamlessly applied to mainstream Internet and Internet of Things protocols such as websocket, gRPC, MQTT, COAP, SOAP and QUIC, and even supports various custom protocols based on tcp / udp. When designing the scheme, the structural differences and data transmission characteristics of different network protocols are fully considered, and the key management, interface hiding, dynamic signature and anti-replay core security mechanism modules are innovatively modularized and protocol-independent. Whether it is a connection-oriented http or websocket, or a message-oriented MQTT or gRPC, the security capability can be quickly integrated through simple adaptation, greatly reducing the technical threshold of cross-protocol security protection. The scheme not only supports encryption and decryption of common structured data such as JSON and XML, but also can flexibly adapt to custom protocol formats such as TLV (Type-Length-Value), and even support efficient encryption transmission of unstructured data such as large files, audio and video streams, to meet the security needs of diversified scenes such as Internet of Things, video monitoring and intelligent terminals.

[0139] The API interface data security transmission method and system provided by the application have wide application in different fields. In a financial payment system, the transmission efficiency can be effectively improved and the security protection can be improved by encrypting transmission based on the national standard SM2 / SM3 / SM4 algorithm; in a government affair data opening platform, end-to-end security can be realized through layered defense. It is also applicable to high-concurrency scenes such as the Internet of Things field. The technical combination can be flexibly adjusted according to the requirements of different fields, while meeting the performance and compliance requirements, to provide a domestic solution for API security in the post-quantum era.

[0140] In one embodiment, a computer readable storage medium is provided, having stored thereon a computer program, which, when executed by a processor, implements the steps of any of the above API interface data security transmission method embodiments.

[0141] A person of ordinary skill in the art can understand that all or part of the processes in the above-mentioned embodiments can be completed by a computer program instructing related hardware, and the computer program can be stored in a non-volatile computer readable storage medium. When the computer program is executed, the computer program can include the processes of the above-mentioned embodiments. Any reference to memory, storage, database or other medium used in the embodiments provided in the present application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory or optical memory. Volatile memory can include random access memory (RAM) or external cache memory. As an illustration but not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM).

[0142] The technical features of the above-mentioned embodiments can be combined arbitrarily. In order to make the description simple, all possible combinations of the technical features in the above-mentioned embodiments are not described, however, as long as the combinations of the technical features do not contradict, they should be considered as the scope of the present application.

[0143] The above-mentioned embodiments only express several implementation manners of the present application, and the description is more specific and detailed, but it should not be understood as a limitation on the scope of the patent. It should be pointed out that for a person of ordinary skill in the art, without departing from the concept of the present application, a number of modifications and improvements can be made, which are all within the scope of the present application. Therefore, the scope of the patent of the present application should be subject to the appended claims.

Claims

1. An API interface data secure transmission method, characterized in that, The method comprises: When the client sends an API interface request to the server, a high-entropy key is generated based on the multi-source physical entropy of the client; The API interface request is encrypted based on the high-entropy key to obtain encrypted data, and the encrypted data is signed, wherein the signature includes a random number; the encrypted data and the signature are sent to the server; The receiving delay time of the server and the dynamic delay time window of the current API interface request are obtained, and if the receiving delay time is within the dynamic delay time window and the random number passes the uniqueness verification, it is determined that the API interface request is a legal request; the server verifies the signature, and after the verification is passed, the encrypted data is decrypted; wherein obtaining the dynamic delay time window of the current API interface request comprises: Obtaining a one-way delay baseline based on the first session between the client and the server; Obtaining the single delay time of each legal request verified by signature, and updating the average delay and the average delay jitter based on the single delay time; According to the trust rating of the client, a dynamic security coefficient is obtained; According to the overall load or network health status of the server, a network macro-environment factor is obtained; Based on the average delay, the average delay jitter, the dynamic security coefficient, the network macro-environment factor and the preset absolute reference window, the dynamic delay time window of the current API interface request is obtained.

2. The method of claim 1, wherein, When the client sends an API interface request to the server, a high-entropy key is generated based on the multi-source physical entropy of the client, which comprises: Based on the multi-source physical entropy of the client, random noise is generated; The random noise is extracted and expanded by a key derivation function to generate a first pseudo-random sequence; The first pseudo-random sequence is used as the initial condition of a chaotic system to generate a second pseudo-random sequence; and a third pseudo-random sequence is generated based on the Logistic mapping; Based on the second pseudo-random sequence and the third pseudo-random sequence, a high-entropy key is generated.

3. The method of claim 1, wherein, Based on the average delay and the average delay jitter, the dynamic delay time window of the current API interface request is obtained, which comprises: ； wherein, is a dynamic delay time window requested by the current API interface, is an average delay, is an average delay jitter, is a dynamic safety factor, is a network macro-environment factor, is an absolute reference window.

4. The method of claim 1, wherein, The API interface request includes request method, request path, request parameter, request header, request body and request data, and the API interface request is encrypted based on the high-entropy key to obtain encrypted data, which comprises: Using the national SM4 algorithm, the API interface request is encrypted using the high-entropy key to obtain encrypted data; The high-entropy key is encrypted using the public key of the national SM2 to obtain key ciphertext, and the key ciphertext is attached to the request header.

5. The method of claim 1, wherein, The encrypted data is signed, and the signature is sent to the server, and the server verifies the signature, which comprises: Using the national SM3 algorithm, the signature data of the Merkle tree root node is obtained; The signature data is attached to the request header and sent to the server; The server performs national SM3 calculation on each component of the signature data in parallel to obtain the root hash, and compares the root hash with the signature value of the client for verification.

6. The method of claim 1, wherein, The method further comprises: determine whether a single delay time of each legal request passing signature verification is abnormal; if the number of abnormal times is greater than a preset value, the server triggers an alarm.

7. An API interface data secure transmission system, characterized by, The system comprises a client and a server: The client is configured to generate a high-entropy key based on a multi-source physical entropy of the client when sending an API interface request to the server, encrypt the API interface request based on the high-entropy key to obtain encrypted data, sign the encrypted data, the signature comprising a random number, and send the encrypted data and the signature to the server. The server is configured to obtain a receiving delay time of the server and a dynamic delay time window of a current API interface request, determine that the API interface request is a legal request if the receiving delay time is within the dynamic delay time window and the random number passes a uniqueness check, verify the signature by the server, decrypt the encrypted data after the verification is passed, wherein obtaining the dynamic delay time window of the current API interface request comprises obtaining a one-way delay baseline based on a first session between the client and the server, obtaining a single delay time of each legal request passing signature verification, and updating an average delay and an average delay jitter based on the single delay time, obtaining a dynamic security coefficient according to a trust rating of the client, obtaining a network macro-environment factor according to an overall load or a network health status of the server, and obtaining the dynamic delay time window of the current API interface request based on the average delay, the average delay jitter, the dynamic security coefficient, the network macro-environment factor, and a preset absolute reference window.

8. A computer-readable storage medium having stored thereon a computer program, characterized in that, The computer program is executed by a processor to implement the method of any one of claims 1-6. The computer program is executed by a processor to implement the method of any one of claims 1-6.

Images