Wireless communication security and verification cost control method and system

Abstract

The invention discloses a wireless communication security and verification cost control method and system, relates to the field of wireless communication networks, and aims to distribute an authentication period identifier for RBF (Radial Basis Function) equipment, select certification units from a certification knowledge base constructed based on a ZKP algorithm to form a certification sequence, and ensure the validity of the sequence by calculating the repetition rate with a historical sequence. And generating challenge information according to the valid proof sequence, sending the challenge information to the device, processing the challenge information by the device, returning a response without identity information, and judging whether the response is valid through a verification equation to complete device authentication. According to the method, the wireless communication security is improved, and the calculation cost of the verification process is reduced at the same time.

Description

Technical Field

[0001] This application belongs to the field of wireless communication networks, and in particular relates to a method and system for controlling the security and verification costs of wireless communication. Background Technology

[0002] With the widespread application of wireless communication technology, communication security issues have become increasingly prominent. Because wireless communication uses radio frequency signals that propagate through the air, the communication process is easily intercepted and eavesdropped on by third parties. Therefore, encryption technology is needed to protect communication security. Traditional encryption authentication methods typically require the transmission of password or key information between the communicating parties, which is vulnerable to eavesdropping and replay attacks.

[0003] Currently, a common solution is to use complex encryption algorithms to encrypt communication data, thereby increasing security by increasing the complexity of the algorithms. For example, asymmetric encryption algorithms can be used for authentication and data encryption, establishing a secure encrypted channel between the communicating parties.

[0004] However, while the aforementioned technologies can protect communication security to a certain extent, the high complexity of the algorithms means that the authentication process requires a large amount of computing resources. Many resource-constrained terminal devices cannot support complex encryption and authentication algorithms, which increases the power consumption and response latency of the devices. As a result, it is difficult to improve the security of wireless communication while reducing the computational cost of the verification process. Summary of the Invention

[0005] This application provides a method and system for controlling wireless communication security and verification costs, which can improve wireless communication security while reducing the computational cost of the verification process.

[0006] In the first aspect, this application provides a method for controlling wireless communication security and verification costs, which generates an authentication cycle identifier with an incrementing integer sequence number and assigns it to the RBF device when it is determined that an authentication request sent by an RBF device has been received; A proof knowledge base is constructed based on the lightweight zero-knowledge proof algorithm ZKP. The proof knowledge base contains multiple proof units, and each proof unit includes a set of preset mathematical transformation functions. Select at least two proof units from the proof knowledge base according to a preset probability distribution, and arrange the selected proof units into a proof sequence in chronological order; Obtain the historical proof sequence of the previous certification cycle based on the certification cycle identifier; Calculate the repetition rate between the proof sequence and the proof sequences of historical authentication cycles; When the repetition rate is not less than the preset repetition rate threshold, at least two proof units different from the proof sequence are selected to form a new proof sequence, and the new proof sequence is replaced by the proof sequence. Then, the step of calculating the repetition rate between the proof sequence and the proof sequence of the historical authentication period is performed. When the repetition rate is less than a preset repetition rate threshold, the proof sequence is deemed valid. Challenge information is generated based on the proof sequence, and the challenge information includes operational parameters generated based on the preset mathematical transformation function in the proof sequence; The challenge information is sent to the RBF device, which processes the challenge information based on the locally stored identity information to obtain the response information. The response information does not contain the identity information of the RBF device. If the difference between the calculated value obtained by substituting the response information into the preset verification equation and the preset value is within the preset range, the RBF device is deemed to have passed certification.

[0007] By adopting the above technical solution, an authentication cycle identifier with an incrementing integer sequence number is generated and assigned to the RBF device. Combined with a proof knowledge base built based on the lightweight zero-knowledge proof algorithm ZKP, proof units are selected from this knowledge base to form a proof sequence. This sequence is then compared and adjusted with historical proof sequences to generate a valid proof sequence and challenge information. The RBF device processes the challenge information based on locally stored identity information to obtain a response, which does not contain identity information. This eliminates the need to transmit the device's real identity information during authentication, reducing the risk of identity information leakage. Simultaneously, the repetition rate control and dynamic adjustment mechanism of the proof sequence improves the randomness and unpredictability of the authentication process, enhancing the ability to prevent replay attacks. The authentication method based on lightweight zero-knowledge proof reduces communication overhead and computational resource consumption, improves authentication efficiency, and achieves both enhanced wireless communication security and reduced computational costs in the verification process.

[0008] In conjunction with some implementations of the first aspect, in some implementations, challenge information is generated based on the proof sequence, specifically including: Map each pre-defined mathematical transformation function in the proof sequence to a corresponding polynomial function; Generate random variables and substitute them into a polynomial function to obtain multiple function values; Combine random variables and multiple function values ​​to generate computational parameters; The challenge information is obtained by arranging the computational parameters in chronological order according to the proof sequence.

[0009] By employing the above technical solution, the pre-defined mathematical transformation function in the proof sequence is mapped to a polynomial function, and function values ​​are generated through random variables. Finally, the random variables and function values ​​are combined in chronological order to generate operational parameters and challenge information, giving the challenge information strong mathematical properties and irreversibility. Introducing random variables increases the randomness of the challenge information, reducing the possibility of it being guessed and cracked. The computation process of polynomial functions is relatively simple, reducing the computational complexity of the challenge information generation process. The time-order-based parameter arrangement improves the temporal and integrity verification capabilities of the challenge information. This challenge information generation mechanism reduces the system's computational overhead while ensuring security.

[0010] In conjunction with some implementations of the first aspect, in some implementations, challenge information is generated based on the proof sequence, specifically including: Construct the corresponding state transition matrix based on each pre-defined mathematical transformation function in the proof sequence; An initial state vector is generated and then transformed sequentially through a state transition matrix to obtain multiple state vectors; Extract feature components from multiple state vectors as computational parameters; The challenge information is obtained by encoding the computational parameters.

[0011] By employing the above technical solution, a state transition matrix is ​​constructed based on a pre-defined mathematical transformation function in the proof sequence. Multiple state vectors are obtained through continuous transformation of the initial state vector, and feature components are extracted from these vectors as operational parameters and encoded to generate challenge information. Multi-dimensional information transformation is achieved through matrix operations, increasing the complexity of the challenge information. The continuous transformation process of the state vectors creates an information diffusion effect, increasing the information entropy of the challenge information. The feature component extraction mechanism reduces redundant information and the amount of challenge information data. The encoding process further improves the compression efficiency of the challenge information and reduces transmission overhead. This state transition-based scheme enhances security while improving the system's communication efficiency.

[0012] In conjunction with some implementations of the first aspect, in some implementations, before selecting at least two proof units from the proof knowledge base according to a preset probability distribution, the method further includes: Obtain location information including GPS coordinates sent by the RBF device; Within a circular area centered on the location information and with a preset distance as the radius, other RBF devices that send authentication requests are identified as neighboring devices; The authentication request time of the RBF device is recorded as the base time, and the time difference between the authentication request time of adjacent devices and the base time is calculated. When the number of adjacent devices whose time difference is less than the preset time threshold is not less than the preset number, the RBF device and its corresponding adjacent devices are identified as an authentication group. Assign a sequence number to each RBF device in the certification group according to the order of the certification request time; Based on the number of RBF devices within the certification group, adjust the selection probability of each proof unit in the preset probability distribution.

[0013] By adopting the above technical solution, the GPS coordinate information of the RBF device is obtained to identify adjacent devices within a preset distance range. Authentication groups are formed based on the time difference of authentication requests, and the selection probability of the proof unit is then adjusted. This location- and time-based group authentication mechanism reduces the number of independent device authentications and improves batch authentication efficiency. The preset distance and time thresholds reduce the risk of fraudulent device access. The dynamic adjustment of the proof unit selection probability based on the authentication group size improves the adaptability of the authentication process. The sequential numbering mechanism of the devices enhances the orderliness of the authentication process and improves authentication management efficiency. This group authentication scheme improves authentication efficiency while reducing the system's authentication processing overhead.

[0014] In conjunction with some implementation methods of the first aspect, in some implementation methods, the selection probability of each proof unit in the preset probability distribution is adjusted based on the number of RBF devices within the certification group, specifically including: Determine the computational complexity of each proof unit in the proof knowledge base; Proof units with computational complexity in the first preset range are classified as Level 1, and proof units with computational complexity in the second preset range are classified as Level 2. When the number of RBF devices in the certification group is greater than the first preset number, the selection probability of the first-level proof unit is set to the first preset probability, and the selection probability of the second-level proof unit is set to the second preset probability, with the first preset probability being greater than the second preset probability. When the number of RBF devices in the certification group is not greater than the first preset number, the selection probability of the first-level proof unit is set to the second preset probability, and the selection probability of the second-level proof unit is set to the first preset probability.

[0015] By adopting the above technical solution, the proof units are divided into different levels according to their computational complexity, and the selection probability of different levels of proof units is dynamically adjusted based on the number of RBF devices in the authentication group. When there are many devices, the first-level proof units with lower computational complexity are selected first, and when there are few devices, the second-level proof units with higher computational complexity are selected first. This allows the system to adaptively adjust the computational cost of the authentication process according to the actual load. When a large number of devices request authentication simultaneously, selecting proof units with lower computational complexity can reduce the computational pressure on the server and improve authentication efficiency; when there are few authentication devices, selecting proof units with higher computational complexity can improve authentication security. This dynamic adjustment mechanism achieves a good balance between ensuring authentication security and system processing efficiency, improving system resource utilization.

[0016] In conjunction with some implementation methods of the first aspect, in some implementation methods, the computational complexity of each proof unit in the proof knowledge base is determined, specifically including: Obtain the number of preset mathematical transformation functions in each proof unit; Count the number of mathematical operators in each preset mathematical transformation function; The mathematical operators in each preset mathematical transformation function are divided into addition operators, multiplication operators, and exponentiation operators; Calculate the weighted sum based on the number of addition operators, the number of multiplication operators, and the number of exponentiation operators; The weighted sum of all preset mathematical transformation functions in each proof unit is used as the corresponding computational complexity.

[0017] By employing the aforementioned technical solution, statistical analysis of the types and quantities of mathematical operators in the proof units, and using weighted calculation to evaluate the computational complexity of the proof units, the system can more accurately quantify the computational overhead of different proof units. Since different types of mathematical operators have different computational complexities, categorizing operators into addition, multiplication, and exponentiation operations and statistically analyzing them separately can more accurately reflect the actual computational load of the proof units. The complexity evaluation results obtained based on weighted calculations have a strong correlation with the actual execution overhead, helping the system make more rational decisions when selecting proof units, improving the accuracy of computational resource allocation, and reducing system resource waste.

[0018] In conjunction with some implementations of the first aspect, in some implementations, after calculating the repetition rate between the proof sequence and the proof sequence of historical authentication cycles, the method further includes: Obtain the proof sequence for the most recent preset number of historical authentication periods; Calculate the number of times each proof unit is used in the proof sequence of a preset number of historical authentication cycles; Identify the proof unit that is used most frequently; When the proof sequence contains the proof unit with the most usage times, and the number of usage times is greater than the second preset number of times, select any other proof unit that is different from the proof unit with the most usage times from the proof knowledge base according to the preset probability distribution; The most frequently used proof unit in the proof sequence is replaced with other proof units to obtain the replaced proof sequence. The replaced proof sequence is used as the proof sequence, and the step of calculating the repetition rate between the proof sequence and the proof sequence of the historical authentication cycle is performed.

[0019] By adopting the above technical solution, and through statistical analysis of the usage of proof units in historical authentication cycles, frequently used proof units are replaced, reducing the probability of proof units being reused in a short period. When the usage frequency of a proof unit exceeds a preset threshold, the system selects other less frequently used proof units for replacement. This dynamic adjustment mechanism based on usage frequency increases the randomness of the authentication process and enhances the unpredictability of the authentication sequence. Simultaneously, by avoiding frequent reuse of proof units, the possibility of attackers predicting subsequent authentication processes by analyzing historical authentication data is reduced, thus improving the security of the authentication process.

[0020] Secondly, embodiments of this application provide a wireless communication security and verification cost control system, which includes: one or more processors and a memory; the memory is coupled to one or more processors, and the memory is used to store computer program code, the computer program code including computer instructions, and one or more processors call the computer instructions to cause the system to perform the method described in the first aspect and any possible implementation thereof.

[0021] Thirdly, embodiments of this application provide a computer-readable storage medium including instructions that, when executed on a system, cause the system to perform the method described in the first aspect and any possible implementation thereof.

[0022] Fourthly, embodiments of this application provide a computer program product that, when run on a system, causes the system to execute the method described in any possible implementation of the first aspect.

[0023] One or more technical solutions provided in the embodiments of this application have at least the following technical effects or advantages: 1. This application provides a method for controlling wireless communication security and verification costs. It generates and assigns incrementally incrementing authentication cycle identifiers to RBF devices. Combined with a proof knowledge base built based on the lightweight zero-knowledge proof algorithm ZKP, proof units are selected to form a proof sequence. This sequence is then compared and adjusted with historical proof sequences to generate a valid proof sequence and challenge information. The RBF device processes the challenge information based on locally stored identity information to obtain a response, which does not contain identity information. This eliminates the need to transmit the device's real identity information during authentication, reducing the risk of identity leakage. Simultaneously, the repetition rate control and dynamic adjustment mechanism of the proof sequence improves the randomness and unpredictability of the authentication process, enhancing the ability to prevent replay attacks. The authentication method based on lightweight zero-knowledge proof reduces communication overhead and computational resource consumption, improves authentication efficiency, and achieves both enhanced wireless communication security and reduced computational costs in the verification process.

[0024] 2. This application provides a method for controlling wireless communication security and verification costs. By acquiring the GPS coordinates of RBF devices, neighboring devices are identified within a preset distance range. Authentication groups are formed based on the time difference of authentication requests, and the selection probability of the proof unit is adjusted. This location- and time-based group authentication mechanism reduces the number of independent device authentications and improves batch authentication efficiency. The preset distance and time thresholds reduce the risk of fraudulent device access. The dynamic adjustment of the proof unit selection probability based on the authentication group size improves the adaptability of the authentication process. The sequential numbering mechanism of devices enhances the orderliness of the authentication process and improves authentication management efficiency. This group authentication scheme improves authentication efficiency while reducing the system's authentication processing overhead.

[0025] 3. This application provides a method for controlling wireless communication security and verification costs. By statistically analyzing the usage of proof units in historical authentication cycles and replacing frequently used proof units, the probability of proof units being reused in a short period is reduced. When the usage frequency of a proof unit exceeds a preset threshold, the system will select other less frequently used proof units for replacement. This dynamic adjustment mechanism based on usage frequency increases the randomness of the authentication process and improves the unpredictability of the authentication sequence. At the same time, by avoiding the frequent reuse of proof units, the possibility of attackers predicting subsequent authentication processes by analyzing historical authentication data is reduced, thereby improving the security of the authentication process. Attached Figure Description

[0026] Figure 1 This is a flowchart illustrating a wireless communication security and verification cost control method in an embodiment of this application.

[0027] Figure 2This is another flowchart illustrating a wireless communication security and verification cost control method in the embodiments of this application.

[0028] Figure 3 This is another flowchart illustrating a wireless communication security and verification cost control method in the embodiments of this application.

[0029] Figure 4 This is a schematic diagram of the physical device structure of a wireless communication security and verification cost control system provided in an embodiment of this application. Detailed Implementation

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

[0031] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature, and in the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more.

[0032] The following example is used in conjunction with Figure 1 The present application describes a method for controlling wireless communication security and verification costs in its embodiments: Please see Figure 1 This is a flowchart illustrating a wireless communication security and verification cost control method in an embodiment of this application.

[0033] S101. If it is determined that an authentication request sent by the RBF device has been received, an authentication cycle identifier with an incrementing integer sequence number is generated and assigned to the RBF device. An authentication request is the initial signal initiated by an RBF device, intending to establish a secure communication connection with the system. The authentication cycle identifier is an integer sequence number that increments with each new authentication cycle or time period, similar in function to a session ID but emphasizing its sequential and non-repeatable nature. Assigning this identifier to an RBF device means the system binds this newly generated identifier to the specific RBF device that initiated the request, used to track and manage the device's authentication status within the current authentication cycle. This assignment is not limited to explicitly sending the identifier to the RBF device; it can also be a logical association within the system, where the system records that "at the current time, identifier Y has been assigned to device X."

[0034] The first approach to this step involves maintaining a global authentication cycle counter internally. When the system's network interface detects an authentication request packet conforming to a predetermined format sent by any RBF device, the system first reads the current value of the global counter, increments it by one, and then uses this new value as the authentication cycle identifier for this authentication. Simultaneously, the system creates a temporary session record in memory, associating this identifier with the physical address of the request source (such as a MAC address) or a temporary network identifier for subsequent lookups. The second, more refined approach involves maintaining an independent authentication cycle counter for each registered RBF device. When the system receives an authentication request from a known RBF device, it first identifies the device (preliminarily through physical layer features or other out-of-band information), then queries the device's dedicated counter, increments its value by one, and uses this as the authentication cycle identifier for this authentication.

[0035] S102. Construct a proof knowledge base based on the lightweight zero-knowledge proof algorithm ZKP; The system constructs a proof knowledge base based on the lightweight zero-knowledge proof algorithm ZKP. The knowledge base contains multiple proof units, each consisting of a set of pre-defined mathematical transformation functions. Lightweight zero-knowledge proof algorithms (ZKP) refer to a class of cryptographic protocols designed specifically for resource-constrained environments. They allow a prover (the RBF device in this case) to prove to a verifier (the system in this case) that they know a secret (such as identity information) without revealing the secret itself. Compared to traditional ZKPs (such as zk-SNARKs), lightweight ZKP significantly reduces computational complexity and communication overhead in the proof generation and verification process. The proof knowledge base is a pre-built and stored dataset by the system. It does not contain any actual identity information of any device, but rather a series of basic elements used to construct authentication challenges. The proof unit is the basic building block of the knowledge base, and each unit contains a set of pre-defined mathematical transformation functions. These functions are essentially a set of mathematical rules or algorithms designed to be computed in conjunction with the identity information of the RBF device. Without limitation, these mathematical transformation functions can be polynomial evaluation, matrix multiplication, elliptic curve dot product over a finite field, or simple hash chain operations, etc.

[0036] To implement a proof knowledge base, the system can adopt two approaches. First, the system can predefine a series of multivariate polynomial functions with different algebraic properties as mathematical transformation functions. For example, the system can generate 100 different ternary quadratic polynomials. Then, the system randomly groups these polynomials, for example, five polynomials per proof unit. Thus, if 20 proof units are generated, the proof knowledge base is complete. The coefficients of these functions are secretly stored by the system. Second, the system can utilize the concept of a finite state machine. The system pre-designs multiple state transition matrices, each representing a state transition rule. For example, in an 8-dimensional vector space, dozens of different 8x8 matrices can be defined. Each proof unit can contain one or more such state transition matrices. The identity information of the RBF device can be encoded into an initial state vector. The subsequent challenge is for the device to sequentially multiply this vector using the matrices in the proof units to prove that it knows the correct initial vector.

[0037] S103. Select at least two proof units from the proof knowledge base according to a preset probability distribution, and arrange the selected proof units into a proof sequence in chronological order. The selection based on a preset probability distribution indicates that the selection process is not entirely random but rather strategic. This probability distribution can be non-uniform; for example, the probability of selecting more complex or newly added proof units can be set higher to increase the difficulty of analysis for attackers. Selecting at least two proof units ensures sufficient complexity in the authentication process, as a single proof unit challenge might be too simple and easily brute-forced. Arranging the selected proof units into a proof sequence according to chronological order means that these challenges are not issued simultaneously but executed in a sequential order, and this order itself constitutes part of the challenge.

[0038] One specific implementation involves assigning a weight value to each proof unit in the proof knowledge base. This weight value can be comprehensively evaluated based on factors such as the unit's computational complexity, historical usage frequency, or creation time. For example, newly created units have higher weights, while frequently used units have dynamically lower weights. When a proof unit needs to be selected, the system runs a weighted random sampling algorithm (such as Fitness proportionate selection or Stochastic universal sampling) to determine the probability of selection based on each unit's weight, and then performs N (N≥2) non-repeating samplings to obtain N proof units. Subsequently, the system arranges these N units in the order obtained from the sampling to form a proof sequence. Another simpler approach is to not assign complex weights to the proof units, but instead divide them into several categories, such as easy, medium, and hard. The preset probability distribution is defined as the number of units drawn from each category; for example, a single authentication must include one hard unit, two medium units, and one easy unit. The system performs uniform random sampling in each class, and then arranges all the sampled units in a random order or in a fixed order of easy-medium-difficulty to form a proof sequence.

[0039] S104. Obtain the historical proof sequence of the previous certification cycle based on the certification cycle identifier; The authentication cycle identifier is the incrementing integer generated in step S101. The previous authentication cycle refers to the successfully completed authentication session immediately preceding the current authentication cycle. For example, if the current authentication cycle identifier is N, then the previous authentication cycle identifier is N-1. The historical proof sequence is the proof sequence generated in step S103 and ultimately used for authentication in that (N-1)th authentication cycle. The system needs to have at least one place storing the most recent authentication history in order to execute this step. The retrieval operation involves precisely finding the corresponding data from storage based on the given identifier.

[0040] S105. Calculate the repetition rate between the proof sequence and the proof sequence of the historical authentication cycle; A proof sequence is a list of multiple proof units arranged sequentially. A historical proof sequence is a list of similar units obtained in the previous step and used for the previous authentication. The repetition rate is a numerical metric used to represent the degree of overlap between two sequences. This calculation can be based on the degree of overlap of elements or on the degree of overlap of order. For example, if the old sequence is [A, B, C] and the new sequence is [A, D, E], then they share a common element A. If the new sequence is [C, B, A], then their elements are exactly the same, but in reverse order.

[0041] There are at least two specific methods for calculating the repetition rate. The first method is based on the Jaccard similarity coefficient of sets. The system treats both the proof sequence and the historical proof sequence as sets of proof units (ignoring their internal order). The Jaccard similarity coefficient is calculated as the number of identical proof units in the two sequences divided by the total number of all unique proof units in both sequences. For example, if the historical sequence is {A, B, C} and the current sequence is {A, D, B}, then their intersection is {A, B} (number of units is 2), and their union is {A, B, C, D} (number of units is 4). Therefore, the repetition rate is 2 / 4 = 0.5. This method is simple and fast, only concerned with whether the constituent elements are repeated. The second method goes a step further, considering the order of elements, and can use an edit distance algorithm (such as Levenshtein distance). The system calculates the minimum number of single-element edit operations (insertion, deletion, or replacement) required to transform the historical proof sequence into the current proof sequence. Then, this edit distance is normalized to obtain a repetition rate index. For example, the repetition rate can be defined as 1 - (edit distance / length of the longer sequence). If the historical sequence is [A, B, C] and the current sequence is [A, D, C], their edit distance is 1 (replacing B with D). Assuming the sequence length is 3, the repetition rate can be calculated as 1 - (1 / 3) ≈ 0.67. This method can more accurately measure the structural similarity of sequences.

[0042] S106. When the repetition rate is not less than the preset repetition rate threshold, at least two proof units that are different from the proof sequence are reselected to form a new proof sequence, and the new proof sequence is replaced by the proof sequence. When the repetition rate is not less than a preset repetition rate threshold, the system reselects at least two proof units different from the proof sequence to form a new proof sequence, replaces the old one with the new proof sequence, and re-executes step S105. The preset repetition rate threshold is a pre-set critical value, such as 0.5 or 0.33. This threshold represents the maximum similarity between the new and old authentication challenges that the system can tolerate. A repetition rate not less than the threshold means that the newly generated proof sequence is too similar to the previous sequence, posing a risk of prediction or replay. In this case, the system must discard the current proof sequence and initiate a reselection process. Reselecting different proof sequences emphasizes that the new selection must exclude those proof unit combinations that previously led to the high repetition rate. After forming a new proof sequence, it replaces the old one, and the system returns to S105 for a new round of repetition rate calculation, forming a check-correction loop until the generated proof sequence meets the low repetition rate requirement.

[0043] S107. When the repetition rate is less than the preset repetition rate threshold, the proof sequence is determined to be valid. When the repetition rate calculated in S105 is confirmed to be less than the preset repetition rate threshold by the judgment in S106, it means that the currently generated proof sequence is significantly different from the sequence of the previous authentication, satisfying the system's requirements for randomness and unpredictability. Therefore, the system determines that this proof sequence is "valid" and can be used to construct the actual challenge of this authentication.

[0044] S108. Generate challenge information based on the proof sequence; The system generates challenge information based on the proof sequence. The challenge information includes computational parameters generated from preset mathematical transformation functions in the proof sequence. Specifically, the system maps each preset mathematical transformation function in the proof sequence to a corresponding polynomial function; generates random variables and substitutes them into the polynomial functions to obtain multiple function values; combines the random variables and multiple function values ​​to generate computational parameters; and arranges the computational parameters according to the chronological order of the proof sequence to obtain the challenge information. Each proof unit in the proof sequence corresponds to a polynomial function secretly stored by the system, for example, f(x, s), where s is the secret identity information of the RBF device. The system first generates a truly random number as the variable x. Then, the system iterates through each polynomial function f1, f2, ..., f in the proof sequence. n Calculate the function values ​​y1=f1(x, s'), y2=f2(x, s'), ..., y n =f n(x, s'). It's important to note that when generating the challenge, the system uses a pseudo-identity s' or simply doesn't use identity information (i.e., f(x)), instead of the actual device identity s. Subsequently, the system combines the random variable x with all the calculated function values ​​y1, y2, ..., y... n These parameters are combined to form the computational parameters. Arranged in the order of the proof sequence, these parameters are encoded as the challenge information. After receiving x and these y values, the RBF device needs to use its real identity s to verify or calculate certain relationships.

[0045] Preferably, the system can also construct a corresponding state transition matrix based on each preset mathematical transformation function in the proof sequence; generate an initial state vector and transform it sequentially through the state transition matrix to obtain multiple state vectors; extract feature components from the multiple state vectors as operation parameters; and encode the operation parameters to obtain challenge information. Each proof unit in the proof sequence corresponds to a state transition matrix M. The system first generates a random initial state vector v0. Then, the system performs matrix multiplication transformations sequentially according to the order of the proof sequence: v1=M1*v0, v2=M2*v1, ..., v n =M n *v n ₋1. After calculating this series of state vectors, the system extracts partial components from each vector vᵢ (e.g., the 1st, 3rd, and 5th elements of each vector) as operational parameters. Finally, these extracted parameters are serialized and encoded to generate the final challenge information.

[0046] S109. Send the challenge information to the RBF device, so that the RBF device can process the challenge information based on the locally stored identity information to obtain the response information; The system sends challenge information to the RBF device, which processes the challenge information based on its locally stored identity information to obtain a response. The response does not contain the RBF device's identity information. The challenge information is a structured data packet generated in the previous step. This data packet is transmitted to the RBF device via an underlying wireless communication protocol (such as LoRaWAN, NB-IoT, Wi-Fi, etc.). The RBF device's processing of the challenge information based on its locally stored identity information describes its behavior. Before leaving the factory or during initialization, the RBF device has unique, secret identity information (such as a high-entropy key or a set of parameters) pre-installed in its internal secure storage unit (such as a protected area of ​​the Secure Element SE or Flash). After receiving the challenge information, the device invokes a zero-knowledge proof algorithm in its firmware, using the computational parameters from the challenge information and the locally stored identity information as input to perform a series of calculations. The response information is the output of this calculation process.

[0047] The processing method on the RBF device side and the generation method in the S108 system are designed in pairs. Taking the aforementioned polynomial function-based method as an example, the challenge information includes a random number x and a series of function values ​​{yᵢ}. The RBF device locally stores its secret identity information as s. The device firmware also stores the mathematical transformation function corresponding to the proof knowledge base in the system. After receiving the challenge information, the device uses its own secret s and the received x to calculate its own version of the function value {y'ᵢ=fᵢ(x, s)}. Then, it does not send y'ᵢ back directly, but according to the protocol, it performs a certain combination operation on y'ᵢ and the received yᵢ to obtain the final response information. For example, the response information may be the modulus of the sum of all (y'ᵢ-yᵢ) divided by a large prime number, or a commitment, etc. Taking the state transition matrix method as another example, the RBF device receives a series of extracted operation parameters. Its secret identity information s may be encoded as an initialization vector. The device uses the matrices M1, M2, ... corresponding to the proof sequence to calculate the complete state vector sequence, then extracts the feature components at the same positions, and compares or combines them with the received operation parameters to generate the final response.

[0048] S110. If the difference between the value obtained by substituting the response information into the preset verification equation and the preset value is within the preset range, the RBF device is determined to be certified.

[0049] The response information is the calculation result returned by the RBF device. The preset verification equation is a mathematical formula defined internally by the system. It strictly corresponds to the challenge generation method in S108 and the device processing method in S109, and is the verification end of the entire zero-knowledge proof protocol. Substituting the response information into this equation for calculation yields a numerical value. The preset value is usually an expected ideal result, most commonly zero. The preset range is designed for fault tolerance. In some ZKP schemes (especially those based on approximate calculations, such as range proofs), due to rounding or approximation during the calculation process, the result is not necessarily exactly equal to the ideal value, but fluctuates within a small range around it. Therefore, the judgment condition is not calculated value == preset value, but |calculated value - preset value| < fault tolerance ε, that is, whether the absolute value of the difference is within a very small preset range. If this condition is met, the system determines that the device has passed authentication and allows its subsequent business communication.

[0050] The specific implementation of this step is tightly coupled with the implementation of the preceding steps. In the example based on polynomial functions, assume the response information is a combination of a series of differences. The preset verification equation might be very simple: determine whether the response information itself is equal to a preset value (e.g., 0). If the protocol is designed as response information R = Σ(y'ᵢ-yᵢ)modP, then the verification equation checks whether R is equal to 0. Here, the preset value is 0, and the preset interval can be [0, 0], requiring complete equality. In the example based on the state transition matrix, if the response information is a encrypted combination of feature components calculated by the device itself and parameters in the challenge, then the verification equation might be a decryption or inverse operation process. The system uses its stored secret information to process the response information to see if it can reconstruct a certain expected intermediate value. For example, if the verification equation is Verify(Response, Secret)->value, then the system calculates this value and checks whether it falls within a preset interval.

[0051] In the above embodiments, authentication cycle identifiers with incrementing integer sequences are generated and assigned to RBF devices. Combined with a proof knowledge base built based on the lightweight zero-knowledge proof algorithm ZKP, proof units are selected to form a proof sequence. This sequence is then compared and adjusted with historical proof sequences to ultimately generate a valid proof sequence and challenge information. The RBF device processes the challenge information based on locally stored identity information to obtain response information, which does not contain identity information. This eliminates the need to transmit the device's real identity information during authentication, reducing the risk of identity information leakage. Simultaneously, the repetition rate control and dynamic adjustment mechanism of the proof sequence improves the randomness and unpredictability of the authentication process, enhancing the ability to prevent replay attacks. The authentication method based on lightweight zero-knowledge proof reduces communication overhead and computational resource consumption, improves authentication efficiency, and achieves both enhanced wireless communication security and reduced computational costs in the verification process.

[0052] The above embodiments introduced a basic authentication process. To further optimize authentication efficiency and achieve device group management, this application also provides another method for wireless communication security and verification cost control. This method identifies devices that are spatially close and whose authentication request times are similar, groups them into authentication groups for batch processing, thereby improving system processing efficiency while ensuring authentication security. The following section combines... Figure 2 Another method for controlling wireless communication security and verification costs in the embodiments of this application is described below: Please see Figure 2 This is another flowchart illustrating a wireless communication security and verification cost control method in this application embodiment.

[0053] S201. Obtain location information containing GPS coordinates sent by the RBF device; Location information represents any data that can be used to determine the device's geographic coordinates, not limited to GPS coordinates. The location information including GPS coordinates sent by the RBF device means that when constructing and sending the authentication request data packet, the device encapsulates its own location data as a field. When the system receives and parses this authentication request, it extracts this location information to provide a basis for subsequent spatial proximity determination.

[0054] There are two specific ways to implement this step. The first method involves the RBF device itself integrating a GPS, BeiDou, or other Global Navigation Satellite System (GNSS) receiver module. The firmware on the device periodically, or before initiating authentication, drives the positioning module to obtain the current latitude and longitude coordinates. Then, when assembling the authentication request data packet sent to the system, this pair of latitude and longitude values ​​(usually floating-point numbers) is encoded and filled into a predefined location in the data packet payload. After receiving the data packet, the system parses the coordinate values ​​according to the protocol specification to obtain the location information. The second method is suitable for RBF devices without a GPS module, which can obtain location through network-assisted positioning. For example, in cellular IoT (such as NB-IoT), the device can report the ID of the base station it is connected to and its signal strength information; in Wi-Fi networks, it can report the MAC address (BSSID) and Received Signal Strength Indicator (RSSI) of nearby Wi-Fi hotspots it scans. The device sends this network environment information as location information to the system. The system maintains a network fingerprint-geographic coordinate database. By querying the received base station ID or Wi-Fi fingerprint, it uses triangulation or fingerprint matching algorithms to reverse-parse the approximate geographic coordinates of the device.

[0055] S202. Within a circular area centered on the location information and with a preset distance as the radius, identify other RBF devices that send authentication requests as neighboring devices; The preset distance is a system-defined length value, such as 50 meters, which defines the radius of this virtual circle. This circular area represents a spatial neighborhood. Other RBF devices that send authentication requests refer to other devices that, within a similar time period, also initiated authentication requests to the system, and whose location information the system successfully obtained. Determining a device as a neighbor means that the system will iterate through these other devices, calculate the geographical distance between their respective locations and the aforementioned circle's center, and mark any device whose distance is less than or equal to the preset distance as a neighbor of the initiating device.

[0056] To implement this step, the system needs a data structure capable of processing and querying device locations in real time. One approach is for the system to maintain an in-memory list of device states, storing the IDs and GPS coordinates of all devices that have recently (e.g., within the past minute) sent authentication requests but have not yet completed authentication. When processing a request from device A, the system uses device A's coordinates as the center and a preset distance R as the radius. Then, the system iterates through all other devices B, C, D... in this state list, and for each device, uses a spherical distance calculation function such as Haversine's formula or Vincenty's formulae to accurately calculate the actual geographical distance between its coordinates and device A's coordinates. If the calculated distance is less than or equal to R, the device is added to device A's neighbor candidate set. The second approach is more efficient, especially when dealing with a large number of devices. The system can load the location coordinates of all devices to be authenticated into a spatial index structure in real time, such as an R-tree or quadtree. When it needs to find neighboring devices for device A, the system no longer linearly traverses all devices but directly performs a range query within this spatial index. The query scope is a circular area centered on the coordinates of device A with a preset radius. The spatial index can quickly return all device points falling within this area, thus efficiently determining adjacent devices.

[0057] S203. Record the authentication request time of the RBF device as the base time, and calculate the time difference between the authentication request time of adjacent devices and the base time. The authentication request time of the RBF device refers to the precise timestamp recorded by the system clock when the system receives the authentication request data packet from that device. This timestamp is selected as a reference point for this packet operation and is called the base time. Neighboring devices are the set of devices spatially close to the RBF device, selected in the previous step S202. Calculating the time difference involves subtracting this base time from the authentication request timestamp of each neighboring device in the set, resulting in a time interval. The absolute value of this difference reflects the time synchronization between each neighboring device and the base RBF device in initiating the authentication action.

[0058] S204. When the number of adjacent devices whose time difference is less than the preset time threshold is not less than the preset number, the RBF device and its corresponding adjacent devices are identified as an authentication group. The preset time threshold is a system-defined time length, such as 2 seconds, which defines the maximum time window that can be considered as simultaneous requests. Adjacent devices with a time difference less than the preset time threshold refer to those that are spatially close and initiate requests almost simultaneously with the baseline device. The preset quantity is an integer, such as 5, which defines the minimum number of members required to form a valid authentication group. The overall meaning of this condition is: the grouping mechanism will only be triggered when a sufficient number of other requesting devices gather around a device within a sufficiently close spatial range (defined by S202) and a sufficiently short time window (defined by this step). Once the condition is met, this device (as the initiator) and all adjacent devices that meet the condition are formally grouped together to form an authentication group for subsequent batch processing.

[0059] S205. Assign a sequence number to each RBF device in the certification group according to the order of certification request time; The order of authentication request timestamps refers to the ascending order based on the precise authentication request timestamps of each device recorded in S203. The sequence number is an integer sequence starting from 1 (or starting from 0, depending on the implementation). Assigning a number means that the system binds this integer to a specific device ID within the authentication group.

[0060] To implement this step, a pre-established authentication group is needed, containing the device IDs of all members and their respective authentication request timestamps. One approach is for the system to place all member objects (including device IDs and timestamps) into a list or array. Then, a standard sorting algorithm (e.g., quicksort or mergesort) is called to sort the list in ascending order using the authentication request timestamp as the sorting key. After sorting, the devices in the list are naturally arranged according to their request times. Next, the system iterates through the sorted list from beginning to end, assigning each device an incrementing integer as its sequence number, starting from 1 (or 0). This number can be stored as a new attribute of the device session object. Another approach, if the number of members in the authentication group is small, is to use a simpler insertion sort approach. In S204's authentication group construction process, it doesn't simply place the matching device IDs into a set, but maintains a consistently ordered list. Whenever a matching adjacent device is found, it is inserted into the correct position in the list based on its request time to maintain the list's order. Once the group is built, the list is already sorted by time, so you can simply iterate through it again to assign numbers.

[0061] S206. Based on the number of RBF devices in the certification group, adjust the selection probability of each proof unit in the preset probability distribution.

[0062] The system adjusts the selection probability of each proof unit in the preset probability distribution based on the number of RBF devices in the certification group. Specifically, this includes: determining the computational complexity of each proof unit in the proof knowledge base; classifying proof units with computational complexity in a first preset interval as Level 1 and proof units with computational complexity in a second preset interval as Level 2; when the number of RBF devices in the certification group is greater than a first preset number, setting the selection probability of Level 1 proof units to the first preset probability and the selection probability of Level 2 proof units to the second preset probability, with the first preset probability being greater than the second preset probability; when the number of RBF devices in the certification group is not greater than the first preset number, setting the selection probability of Level 1 proof units to the second preset probability and the selection probability of Level 2 proof units to the first preset probability.

[0063] Specifically, determining the computational complexity of each proof unit in the proof knowledge base includes: obtaining the number of preset mathematical transformation functions in each proof unit; counting the number of mathematical operators in each preset mathematical transformation function; classifying the mathematical operators in each preset mathematical transformation function into addition operators, multiplication operators, and exponentiation operators; calculating a weighted sum based on the number of addition operators, multiplication operators, and exponentiation operators; and using the sum of the weighted sums of all preset mathematical transformation functions in each proof unit as the corresponding computational complexity.

[0064] The number of RBF devices within the certification group, i.e., the total number of devices to be certified in batches as determined in the preceding steps, is the direct input for this strategy adjustment. Adjusting the preset probability distribution means that the random sampling model used by the system to select proof units from the proof knowledge base is not static but variable. Proof units are the basic modules constituting the certification challenge, and they differ in computational cost. Computational complexity is a quantitative indicator used to evaluate the computational resources required to process a proof unit. The system classifies difficulty by dividing proof units whose complexity values ​​fall into different preset intervals into different levels (e.g., Level 1, Level 2). Level 1 typically corresponds to lightweight units with low computational cost, while Level 2 corresponds to heavyweight units with high computational cost. The first preset quantity is a critical value used to determine whether the certification group is large-scale or small-scale. The first preset probability and the second preset probability are two specific probability weights, with the former being greater than the latter. This relationship is the core of the strategy: setting a high probability for units of a certain level means that there will be a greater probability of selecting units of that level during random selection. The essence of this step lies in a trade-off: when the authentication group is large, to avoid excessive overall authentication delays caused by a massive number of devices performing complex calculations, the system prioritizes the computationally simple Level 1 proof unit; conversely, when the authentication group is small, the system no longer prioritizes efficiency, but instead maximizes the security strength of a single authentication by prioritizing the computationally complex Level 2 proof units. The detailed scheme of this step further clarifies the quantification method of computational complexity: by statically analyzing the composition of the mathematical transformation functions within the proof unit, a score representing its computational cost is calculated for each unit. This analysis delves into the mathematical operators within the functions, distinguishing between operations with different overheads such as addition, multiplication, and exponentiation, and by using a weighted summation method, the complexity of all functions within a proof unit is accumulated to obtain the final complexity evaluation value.

[0065] Specifically, a detailed technical solution for determining the computational complexity of each proof unit in the proof knowledge base can be implemented using the following two methods. The first method is to use an offline static code analysis script. When deploying or updating the proof knowledge base, an analysis script can be run, acting like a code reviewer. It parses each proof unit in the knowledge base one by one. For a proof unit, it opens each preset mathematical transformation function it contains. If these functions are stored in some structured form (such as XML or JSON) or domain-specific language (DSL), the parser can directly traverse its syntax tree. During the traversal, it counts the number of various mathematical operators encountered: recording how many times the addition (or subtraction) operator appears, how many times the multiplication (or division) operator appears, and how many times the exponentiation (or more complex operators such as square root, logarithm, etc.) operator appears. The script configuration presets the weights of different operators; for example, an addition operation has a weight of 1, a multiplication operation has a weight of 5, and an exponentiation operation has a weight as high as 20. The script multiplies the number of operators of each type by their corresponding weights, then sums all the results to obtain the weighted sum of the functions. Finally, the script sums the weighted sums of all functions within the proof unit, and this final sum is used as the computational complexity of the proof unit, stored as metadata along with the unit. The second method is a simulation-based dynamic evaluation. The system can configure a standard virtual RBF device environment that simulates the typical computing power of the target device. When evaluating the complexity of a proof unit, the system has this virtual device actually execute all the mathematical transformation functions corresponding to the proof unit once. The system accurately measures and records the number of CPU clock cycles consumed to complete this series of calculations, or the actual time consumed (e.g., in microseconds). This measured consumption value is directly used as the computational complexity of the proof unit. Compared to static analysis, this dynamic evaluation method more realistically reflects the execution overhead of different instruction combinations on actual hardware, and its results are more accurate, especially when the function contains complex logical branches or memory access patterns.

[0066] In the above embodiments, by acquiring the GPS coordinate information of the RBF device, adjacent devices are identified within a preset distance range, and authentication groups are formed based on the time difference of authentication requests. Then, the selection probability of the proof unit is adjusted. This location- and time-based group authentication mechanism reduces the number of independent device authentications and improves batch authentication efficiency. The preset distance and time thresholds reduce the risk of fraudulent device access. The method of dynamically adjusting the proof unit selection probability based on the authentication group size improves the adaptability of the authentication process. The sequential numbering mechanism of the devices enhances the orderliness of the authentication process and improves authentication management efficiency. This group authentication scheme improves authentication efficiency while reducing the system's authentication processing overhead.

[0067] Building upon the aforementioned packet authentication scheme, this application also provides a further method for controlling wireless communication security and verification costs to further enhance the security and randomness of the authentication process. This method dynamically adjusts the composition of the proof sequence by analyzing the historical usage frequency of proof units, avoiding frequent reuse of proof units, thereby increasing the unpredictability of the authentication process. The following section combines... Figure 3 This application describes yet another method for controlling wireless communication security and verification costs in its embodiments: Please see Figure 3 This is another flowchart illustrating a wireless communication security and verification cost control method in the embodiments of this application.

[0068] S301. Obtain the proof sequence of the most recent preset number of historical authentication cycles; Historical authentication cycles refer to past authentication sessions. A proof sequence is an ordered list of one or more proof units actually used to generate challenge information in these historical sessions. The preset number is an integer set by the system administrator, such as 1000, defining the depth of the historical records the system needs to trace back. The retrieval operation means that the system needs to precisely retrieve all proof sequence data used in the most recent 1000 authentication sessions counting backwards from the current time from its historical authentication logs or cache.

[0069] S302. Calculate the number of times each proof unit is used in the proof sequence of a preset number of historical authentication cycles; The set of proof sequences for a predetermined number of historical authentication periods is the dataset obtained by S301. Each proof unit refers to the basic element that constitutes these sequences. Usage count refers to the total number of times a specific proof unit ID appears in all sequences of this dataset. This calculation process is essentially a word count task, which will produce a mapping table (or dictionary) where the key is the ID of all proof units in the proof knowledge base, and the value is their usage frequency count in recent history.

[0070] S303. Determine the proof unit with the highest number of uses; The proof unit with the highest usage count refers to the proof unit with the highest count value in the frequency mapping table calculated in S302. The output of this step is unique, namely, the ID of a proof unit. This identified proof unit will be used as a potential target for subsequent replacement operations. If multiple proof units have the same highest usage count, a preset rule can be used to select one of them, for example, selecting the one with the smallest ID, or selecting one randomly, to ensure the determinism of the decision.

[0071] S304. When the proof sequence contains the proof unit with the most usage times, and the number of usage times is greater than the second preset number of times, select any other proof unit that is different from the proof unit with the most usage times from the proof knowledge base according to the preset probability distribution. The proof sequence refers to the newly generated sequence for this certification that has not yet been verified by this process. The proof unit with the highest usage frequency is the most popular unit ID determined in S303. The second preset frequency is a frequency threshold set by the system, such as 500 (assuming the preset number in S301 is 1000), which represents the maximum tolerable usage frequency of a proof unit in recent history. This judgment condition is an AND logic: first, check whether the currently generated proof sequence contains the most popular unit; second, check whether the popularity of this popular unit has exceeded the system's tolerance threshold. Only when both conditions are met will the replacement mechanism be activated. Once activated, the system needs to find a substitute. The selection of this substitute (other proof units) cannot be arbitrary; it still needs to follow the preset probability distribution defined in S103 / S206 (which may have been adjusted) to maintain the overall security characteristics of the certification challenge. The key constraint is that the newly selected unit cannot be the one that was just determined to have the highest usage frequency to avoid invalid replacement.

[0072] S305. Replace the most frequently used proof unit in the proof sequence with other proof units to obtain the replaced proof sequence; The replacement operation involves filling the positions of all the most frequently used proof units in the original proof sequence with new, different proof units. The resulting proof sequence is the new version after this correction. This new sequence inherits the structure of the original sequence, but its constituent elements have been changed, eliminating the known highest-frequency risk points.

[0073] S306. Use the replaced proof sequence as the proof sequence and perform the step of calculating the repetition rate between the proof sequence and the proof sequence of the historical certification period.

[0074] The replaced proof sequence is the output of S305. Using it as the proof sequence means that in subsequent processes of the current authentication session, all system operations will be based on this modified sequence, while the original sequence containing popular units is discarded. The step of calculating the repetition rate between the proof sequence and the proof sequences of historical authentication periods is an explicit instruction requiring the program flow to jump back to step S105 defined in the first embodiment. This means that even if a proof sequence passes the popular unit check (or passes the check after modification), it still needs to undergo a repetition rate check with the previous period's sequence. These two checks constitute two independent, complementary security checkpoints: S301-S305 focus on the long-term statistical risk of individual components, while S105 focuses on the short-term structural repetition risk of the entire sequence. Only when both pass can a proof sequence be ultimately confirmed as valid.

[0075] A potential technical problem in this step's design is that the replacement operation itself might unintentionally increase the repetition rate with the historical sequence. For example, the original sequence might have a low repetition rate with the historical sequence, but to replace a popular unit A, a less popular unit D is introduced, which happens to also exist in the historical sequence. This could cause the repetition rate of the replaced sequence to exceed the limit, resulting in rejection in the S105 check and unnecessary recalculation. To solve this problem, an additional constraint can be added when selecting other proof units in S304. When selecting substitutes, the system should not only follow the probability distribution and exclude popular units, but also query the historical proof sequence of the previous certification period and add all units contained in the historical sequence to a temporary forbidden list. In this way, the selected substitutes are guaranteed to be neither current popular units nor existing units from the previous period.

[0076] In the above embodiments, by statistically analyzing the usage of proof units in historical authentication cycles and replacing frequently used proof units, the probability of proof units being reused in a short period of time is reduced. When the number of times a proof unit is used exceeds a preset threshold, the system will select other less frequently used proof units to replace it. This dynamic adjustment mechanism based on usage frequency increases the randomness of the authentication process and improves the unpredictability of the authentication sequence. At the same time, by avoiding the frequent reuse of proof units, the possibility of attackers predicting subsequent authentication processes by analyzing historical authentication data is reduced, thereby improving the security of the authentication process.

[0077] The system in the embodiments of this invention is described below from the perspective of hardware processing. Please refer to [link / reference needed]. Figure 4 This is a schematic diagram of the physical device structure of a wireless communication security and verification cost control system provided in an embodiment of this application.

[0078] It should be noted that, Figure 4 The structure of the system shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

[0079] like Figure 4 As shown, the system includes a Central Processing Unit (CPU) 401, which can perform various appropriate actions and processes based on a program stored in Read-Only Memory (ROM) 402 or a program loaded from storage portion 408 into Random Access Memory (RAM) 403, such as executing the methods described in the above embodiments. The RAM 403 also stores various programs and data required for system operation. The CPU 401, ROM 402, and RAM 403 are interconnected via a bus 404. An Input / Output (I / O) interface 405 is also connected to the bus 404.

[0080] The following components are connected to I / O interface 405: input section 406 including a camera, infrared sensor, etc.; output section 407 including a liquid crystal display (LCD) and speakers, etc.; storage section 408 including a hard disk, etc.; and communication section 409 including a network interface card such as a LAN (Local Area Network) card and a modem, etc. Communication section 409 performs communication processing via a network such as the Internet. Drive 410 is also connected to I / O interface 405 as needed. Removable media 411, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 410 as needed so that computer programs read from it can be installed into storage section 408 as needed.

[0081] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing computer programs for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 409, and / or installed from removable medium 411. When the computer program is executed by central processing unit (CPU) 401, it performs the various functions defined in the present invention.

[0082] It should be noted that the computer-readable medium shown in the embodiments of the present invention can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In the present invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In the present invention, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, wherein a computer-readable computer program is carried. The transmitted data signal can take many forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof.

[0083] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. Each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0084] In another aspect, the present invention also provides a computer-readable storage medium, which may be included in the system described in the above embodiments; or it may exist independently and not assembled into the system. The storage medium carries one or more computer programs that, when executed by a processor of a system, cause the system to implement the methods provided in the above embodiments.

[0085] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

[0086] As used in the above embodiments, depending on the context, the term "when..." can be interpreted as "if...", "after...", "in response to determining...", or "in response to detecting...". Similarly, depending on the context, the phrase "when determining..." or "if (the stated condition or event) is interpreted as "if determining...", "in response to determining...", "when (the stated condition or event) is detected", or "in response to detecting (the stated condition or event)".

[0087] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive), etc.

[0088] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM or random access memory (RAM), magnetic disks, or optical disks.

Claims

1. A method for controlling wireless communication security and verification costs, characterized in that, include: Upon confirming that an authentication request has been received from an RBF device, an authentication cycle identifier with an incrementing integer sequence number is generated and assigned to the RBF device; A proof knowledge base is constructed based on the lightweight zero-knowledge proof algorithm ZKP. The proof knowledge base contains multiple proof units, and each proof unit includes a set of preset mathematical transformation functions. At least two proof units are selected from the proof knowledge base according to a preset probability distribution, and the selected proof units are arranged into a proof sequence in chronological order. Obtain the historical proof sequence of the previous authentication cycle based on the authentication cycle identifier; Calculate the repetition rate between the proof sequence and the proof sequence of the historical authentication period; When the repetition rate is not less than a preset repetition rate threshold, at least two proof units different from the proof sequence are selected to form a new proof sequence, and the new proof sequence is replaced with the proof sequence. Then, the step of calculating the repetition rate between the proof sequence and the proof sequence of the historical authentication period is performed. When the repetition rate is less than the preset repetition rate threshold, the proof sequence is determined to be valid; Challenge information is generated based on the proof sequence, and the challenge information includes operational parameters generated based on the preset mathematical transformation function in the proof sequence; The challenge information is sent to the RBF device, which processes the challenge information based on locally stored identity information to obtain response information. The response information does not contain the identity information of the RBF device. If the difference between the value obtained by substituting the response information into the preset verification equation and the preset value is within a preset range, the RBF device is determined to be certified.

2. The method according to claim 1, characterized in that, The step of generating challenge information based on the proof sequence specifically includes: Map each of the preset mathematical transformation functions in the proof sequence to a corresponding polynomial function; Generate random variables and substitute the random variables into the polynomial function to obtain multiple function values; The random variable and the multiple function values ​​are combined to generate operational parameters; The challenge information is obtained by arranging the computational parameters in chronological order according to the proof sequence.

3. The method according to claim 1, characterized in that, The step of generating challenge information based on the proof sequence specifically includes: Construct a corresponding state transition matrix based on each of the preset mathematical transformation functions in the proof sequence; An initial state vector is generated and then transformed sequentially through the state transition matrix to obtain multiple state vectors; Feature components are extracted from the multiple state vectors and used as computational parameters; The computational parameters are encoded to obtain challenge information.

4. The method according to claim 1, characterized in that, Before selecting at least two proof units from the proof knowledge base according to a preset probability distribution, the method further includes: Obtain the location information, including GPS coordinates, sent by the RBF device; Within a circular area centered on the location information and with a preset distance as the radius, other RBF devices that send authentication requests are identified as neighboring devices; The authentication request time of the RBF device is recorded as the base time, and the time difference between the authentication request time of the adjacent device and the base time is calculated. When the number of adjacent devices whose time difference is less than a preset time threshold is not less than a preset number, the RBF device and the corresponding adjacent devices are identified as an authentication group. Assign a sequence number to each RBF device in the authentication group according to the order of the authentication request times; Based on the number of RBF devices in the certification group, the selection probability of each of the proof units in the preset probability distribution is adjusted.

5. The method according to claim 4, characterized in that, The step of adjusting the selection probability of each proof unit in the preset probability distribution based on the number of RBF devices in the certification group specifically includes: Determine the computational complexity of each proof unit in the proof knowledge base; The proof units with computational complexity in the first preset range are classified as the first level, and the proof units with computational complexity in the second preset range are classified as the second level. When the number of RBF devices in the certification group is greater than the first preset number, the selection probability of the first-level proof unit is set to the first preset probability, and the selection probability of the second-level proof unit is set to the second preset probability, wherein the first preset probability is greater than the second preset probability. When the number of RBF devices in the certification group is not greater than the first preset number, the selection probability of the first-level proof unit is set to the second preset probability, and the selection probability of the second-level proof unit is set to the first preset probability.

6. The method according to claim 5, characterized in that, Determining the computational complexity of each proof unit in the proof knowledge base specifically includes: Obtain the number of the preset mathematical transformation functions in each of the proof units; Count the number of mathematical operators in each of the preset mathematical transformation functions; The mathematical operators in each of the preset mathematical transformation functions are divided into addition operators, multiplication operators, and exponentiation operators; Calculate the weighted sum based on the number of addition operators, the number of multiplication operators, and the number of exponentiation operators; The weighted sum of all preset mathematical transformation functions in each proof unit is used as the corresponding computational complexity.

7. The method according to claim 1, characterized in that, After calculating the repetition rate between the proof sequence and the proof sequence of the historical authentication period, the method further includes: Obtain the proof sequence of the most recent preset number of the historical authentication cycles; Calculate the number of times each proof unit is used in the proof sequence of the preset number of historical authentication cycles; Determine the proof unit that is used the most times; When the proof sequence contains the proof unit with the most usages, and the number of usages is greater than the second preset number of usages, any other proof unit different from the proof unit with the most usages is selected from the proof knowledge base according to the preset probability distribution; The other proof units are used to replace the most frequently used proof unit in the proof sequence to obtain a replaced proof sequence. The replaced proof sequence is used as the proof sequence, and the step of calculating the repetition rate between the proof sequence and the proof sequence of the historical authentication period is performed.

8. A wireless communication security and verification cost control system, characterized in that, The system includes: One or more processors and a memory; the memory is coupled to the one or more processors, the memory being used to store computer program code, the computer program code including computer instructions, the one or more processors invoking the computer instructions to cause the system to perform the method as described in any one of claims 1-7.

9. A computer-readable storage medium comprising instructions, characterized in that, When the instructions are executed on the system, the system performs the method as described in any one of claims 1-7.

10. A computer program product, characterized in that, When the computer program product is run on the system, the system performs the method as described in any one of claims 1-7.

Images