SM9 key generation and attribute-based policy dynamic delivery method across mcu and server

Abstract

The application discloses an SM9 key generation and attribute-based policy dynamic distribution method across MCUs and servers, and belongs to the technical field of Internet of Things devices. The application deeply binds the multi-dimensional attributes such as the device type and the geographic position of the MCU terminal to the terminal private key based on the SM9 identity cryptography system, realizes fine-grained access control between the cloud and the massive MCU terminals based on the device attributes, can realize differentiated permission management and control for terminals of different types and different deployment areas, greatly reduces the data transmission amount and the terminal operation amount during attribute change and policy adjustment through the private key incremental update and the policy incremental distribution mechanism, adapts to the characteristics of the MCU terminal resource limitation, reduces the operation overhead of large-scale deployment, optimizes the bilinear pairing operation process in combination with the decryption pre-computation processing, reduces the performance consumption of the decryption operation on the MCU terminal, and improves the policy decryption execution efficiency.

Description

Technical Field

[0001] This invention relates to the field of Internet of Things (IoT) device technology, specifically to a method for dynamically distributing SM9 key generation and attribute base policies across MCUs and servers. Background Technology

[0002] With the large-scale deployment of IoT technology, various MCU terminals are widely deployed in scenarios such as park management, industrial monitoring, and smart cities, undertaking core functions such as data collection and equipment control. MCU terminals generally suffer from limited computing power, storage, and communication resources. Traditional certificate-based key management solutions based on PKI systems have complex deployment processes and high maintenance costs, making them unsuitable for the security management needs of massive numbers of terminals. SM9, as a domestically developed identifier cryptography algorithm, can achieve identity authentication and encrypted communication without relying on digital certificates. It can generate corresponding private keys solely through device identifiers, significantly simplifying the key management process and becoming one of the mainstream technology choices for security protection of resource-constrained IoT terminals.

[0003] In practical applications, different types of MCU terminals deployed in different regions often correspond to differentiated access permissions. Management modes based on a single device identifier cannot meet the needs of fine-grained permission division. Attribute-based access control policies based on multi-dimensional device attributes are gradually becoming the industry trend. Through a dynamic attribute-based policy delivery mechanism, the cloud can push access control rules based on the terminal's device type, geographical location, and other attributes, enabling flexible dynamic adjustment of permissions. However, existing solutions combining SM9 identifier cryptography with attribute-based access control generally suffer from high computational and transmission overhead during private key generation and attribute updates, high bandwidth consumption during full policy delivery, and heavy burden of bilinear pairing decryption operations on the terminal side. Furthermore, the policy delivery process lacks effective timeliness and integrity verification mechanisms, making it vulnerable to security risks such as replay attacks and policy tampering, and thus unable to fully adapt to large-scale MCU terminal deployment scenarios.

[0004] To address the aforementioned technical shortcomings, this invention proposes a method for dynamic distribution of SM9 key generation and attribute-based policies across MCUs and servers. Based on the SM9 identifier cryptosystem, it achieves deep binding between device attributes and terminal private keys, and includes incremental private key updates, incremental policy distribution, decryption pre-computation, and dual security verification mechanisms. This method ensures fine-grained access control capabilities while reducing terminal computation and transmission overhead, and improving the security of policy distribution. It is suitable for IoT security management scenarios involving a large number of MCU terminals. Summary of the Invention

[0005] The technical problem to be solved by this invention is: how to reduce terminal computing and transmission overhead and improve the security of policy distribution while ensuring fine-grained access control capabilities. It is applicable to IoT security management scenarios with a large number of MCU terminals and provides a method for dynamic distribution of SM9 key generation and attribute base policies across MCUs and servers.

[0006] The present invention solves the above-mentioned technical problems through the following technical solution, and the present invention includes the following steps: S1: The cloud-based key generation center completes the initialization of the SM9 identifier cryptosystem, generates the system master private key and the corresponding system master public key, and publishes the public parameters of the SM9 cryptosystem and the system master public key. S2: Collect the unique device identifier and multi-dimensional device attribute set including device type and geographical location of each MCU terminal in the cloud, map the multi-dimensional device attribute set into attribute fusion factor, generate attribute binding SM9 terminal private key based on system master private key, device identifier and attribute fusion factor, and double bind the device identifier and multi-dimensional device attributes, and distribute the attribute binding SM9 terminal private key to the local storage of the corresponding MCU terminal through a secure channel. S3: When the access control policy needs to be updated, the cloud determines the target access attribute structure corresponding to the policy to be issued, encrypts the plaintext access control policy based on the SM9 identifier cryptosystem and the target access attribute structure to generate policy ciphertext, and issues the policy ciphertext to the MCU terminal that meets the attribute matching conditions. S4: After receiving the policy ciphertext, the MCU terminal calls the locally stored attribute binding SM9 terminal private key, completes the decryption of the policy ciphertext through bilinear pairing operation, obtains the plaintext access control policy, and executes the corresponding access control logic.

[0007] Furthermore, in step S2, the process of mapping the multi-dimensional device attribute set to attribute fusion factors and generating the attribute-bound SM9 terminal private key is specifically as follows: Each device attribute of the MCU terminal is uniquely encoded, with device type using classification hierarchical encoding and geographical location using administrative region hierarchical encoding. The encoded attributes are then mapped to the G1 group to obtain the corresponding attribute hash elements. Assign a corresponding weight coefficient to each device attribute, perform scalar multiplication on the hash element of each attribute and the corresponding weight coefficient, and then perform group addition on the G1 group to obtain the attribute fusion factor. The device identifier is hashed to generate an identifier hash element on the G1 group. The identifier hash element and the attribute fusion factor are added together to obtain the fusion element. The fusion element is multiplied by the system master private key to obtain the attribute-bound SM9 terminal private key. The attribute binding SM9 terminal private key is obtained by performing a multiplication of the fused elements with the master private key. The corresponding calculation formula is:

[0008] in, Bind the SM9 terminal private key to the attribute. The system's master private key. The hash mapping function from device identifier to G1 group. A unique device identifier for the MCU terminal. The number of attributes in the multidimensional device attribute set. For the first The weight coefficients corresponding to each device attribute A hash mapping function for encoding device attribute values ​​to the G1 group. For the first The encoded values ​​of each device attribute, covering device type encoding and geographic location encoding.

[0009] Furthermore, the weight coefficients corresponding to each device attribute are dynamically determined by the cloud based on the security level of the device type, the regional risk level of the geographical location, and the access permission level. When the weight coefficients corresponding to a device attribute need to be adjusted, the cloud performs a scalar multiplication operation on the weight change and the hash element of the corresponding attribute, and then performs a scalar multiplication operation on the system master private key. The cloud generates the corresponding private key weight update factor according to the scalar multiplication operation rules consistent with the attribute-bound SM9 terminal private key and encrypts and sends it to the corresponding MCU terminal. The MCU terminal performs a group addition operation on the G1 group on the private key weight update factor and the original attribute-bound SM9 terminal private key stored locally to complete the local update of the attribute-bound SM9 terminal private key.

[0010] Furthermore, when device attributes of the MCU terminal are added, deleted, or changed, including device type adjustment and geographical location migration, the cloud only needs to combine the code of the changed attribute item, the corresponding weight coefficient, and the system master private key to generate the corresponding private key increment factor according to the scalar multiplication operation rules consistent with the attribute-bound SM9 terminal private key and encrypt and send it to the corresponding MCU terminal; after receiving the private key increment factor, the MCU terminal performs group addition or inverse group addition operation on the G1 group with the original attribute-bound SM9 terminal private key stored locally to complete the local update of the attribute-bound SM9 terminal private key; The private key increment factor is obtained by multiplying the attribute hash element of the changed attribute item with the weight change, and then multiplying the result with the system master private key. The updated attribute-bound SM9 terminal private key is obtained by group operation between the original private key and the private key increment factor. The corresponding private key increment update calculation formula is as follows:

[0011] in, As the private key increment factor, For the set of attribute items that have changed, For the first The change in weight corresponding to each changed attribute Bind the updated attributes to the SM9 terminal private key. This is a group addition operation on the G1 group; in the scenario of attribute deletion, the weight change is negative, and the inverse group addition operation is performed accordingly.

[0012] Furthermore, in step S3, the process of generating policy ciphertext based on the SM9 identifier cryptosystem and the target access attribute structure is specifically as follows: Extract the required set of access attributes based on the target access attribute structure, where the set of access attributes includes device type attributes and geographic location attributes; Each attribute in the access attribute set is uniquely encoded and mapped to the G1 group to obtain the corresponding attribute hash element. After assigning weight coefficients to each attribute, scalar multiplication is performed, and then the summation is performed by group addition on the G1 group to generate the access attribute factor. Randomly select a random number factor that meets the group order requirement, and perform a scalar multiplication operation between the random number factor and the generator of the G2 group to obtain the first component of the ciphertext; Calculate the bilinear pairing value between the access attribute factor and the system master public key. After performing a random number factor power operation on the bilinear pairing value, input it into the hash function to generate the key stream. Perform an XOR operation between the key stream and the plaintext access control policy to obtain the second component of the ciphertext. The final strategy ciphertext is composed of the first ciphertext component and the second ciphertext component. The first component of the ciphertext is obtained directly through scalar multiplication of the random number factor and the generator of the G2 group. The second component of the ciphertext is obtained through bitwise XOR operation of the plaintext access control policy and the key stream. The corresponding policy ciphertext construction calculation formula is as follows:

[0013] in, The first component of the ciphertext. The random number factor is selected randomly. For generators of the G2 group, This is the second component of the ciphertext. For plaintext access control policy, This is a bitwise XOR operation. This is a hash mapping function from group elements to fixed-length bit strings. For bilinear pairing operations, For access attribute factors, This is the system's master public key.

[0014] Furthermore, in step S4, when the MCU terminal decrypts the ciphertext using bilinear pairing operations, it performs the decryption operation in a pre-calculation manner: When the MCU terminal receives and stores the attribute-bound SM9 terminal private key for the first time, it performs fixed component pre-calculation processing on the attribute-bound SM9 terminal private key for bilinear pairing operation, generates the pairing operation pre-calculation intermediate value corresponding to the private key, and forms the private key pre-calculation parameter table from the pre-calculation intermediate value and stores it locally. When decrypting the ciphertext of the decryption strategy, the pre-computed parameter table of the private key is called to perform a bilinear pairing operation with the first component of the ciphertext to obtain the decryption pairing value; Input the decryption pairing value into the hash function to generate the decryption key stream, and perform an XOR operation between the decryption key stream and the second component of the ciphertext to obtain the plaintext access control policy. The decryption pairing value is obtained by a bilinear pairing operation between the attribute-bound SM9 terminal private key and the first component of the ciphertext. The plaintext access control policy is restored by a bitwise XOR operation between the second component of the ciphertext and the decryption key stream. The corresponding decryption calculation formula is:

[0015] in, Bind the SM9 terminal private key to the attribute.

[0016] Furthermore, in step S3, when the access control policy is a partial content update, the cloud uses an incremental delivery method to complete the policy update: The cloud compares the content differences between the current latest version of the policy and the policy to be updated, and generates differential policy content; based on the target access attribute structure, the differential policy content is encrypted, and differential ciphertext is generated and sent to the corresponding MCU terminal along with the policy version number; After the MCU terminal decrypts the differential ciphertext, it combines the historical version policies and policy version numbers stored locally to perform differential replacement on the corresponding content in the historical version policies, completes the incremental merging and updating of the policies, and generates and stores the latest version of the access control policy.

[0017] Furthermore, in step S4, the policy ciphertext also embeds a policy version hash value and a timeliness timestamp. Before decrypting the policy ciphertext, the MCU terminal first compares the timeliness timestamp with the local current time to complete the timeliness verification. After the timeliness verification passes, the decryption operation is performed to obtain the plaintext access control policy. Then, based on the previously stored policy version hash value and the current plaintext access control policy obtained from the decryption operation, the current policy version hash value is calculated and compared with the policy version hash value embedded in the policy ciphertext to complete the chain hash verification and verify the version continuity of the plaintext access control policy. After both verifications pass, the corresponding access control logic is executed. The policy version hash value is generated by jointly calculating the policy version hash value of the previous plaintext access control policy and the current plaintext access control policy. The policy version hash value is generated by concatenating the policy version hash value of the previous plaintext access control policy with the policy version hash value of the current plaintext access control policy, and then iteratively calculating it using a hash function. The corresponding chained hash calculation formula is as follows:

[0018] in, For the first The policy version hash value of the plaintext access control policy. For the first The policy version hash value of the plaintext access control policy. This is a bit string concatenation operation. For the first Plaintext access control policy content, This is a hash mapping function used for version verification.

[0019] The present invention has the following advantages over the prior art: 1. Based on the SM9 identifier cryptography system, the device type, geographical location and other multi-dimensional attributes of the MCU terminal are deeply bound to the terminal private key, realizing fine-grained access control between the cloud and a large number of MCU terminals based on device attributes. Differentiated permission management can be achieved for terminals of different types and deployment areas. 2. The cloud can dynamically generate access policies based on access control requirements and distribute them with attribute encryption. The terminal can decrypt and execute the policies by binding the private key to the local attributes, without having to frequently interact with the key generation center. This enables real-time dynamic updates of access policies and improves the flexibility and response efficiency of authorization adjustments.

[0020] 3. By using the incremental update mechanism of private key and incremental policy distribution, the amount of data transmission and terminal computation during attribute changes and policy adjustments is greatly reduced, adapting to the resource-constrained characteristics of MCU terminals and reducing the operating overhead of large-scale deployment; combined with decryption pre-computation processing to optimize the bilinear pairing operation process, the performance consumption of decryption operations on MCU terminals is reduced, and the efficiency of policy decryption execution is improved.

[0021] 4. Simultaneously, it incorporates time-sensitive timestamp verification and chained version hash verification mechanisms to prevent replay attacks and policy version tampering risks, ensuring the timeliness of policy issuance and data integrity, and enhancing the security of the IoT device access control system. 5. It achieves precise and flexible access authorization and real-time policy updates for IoT devices, taking into account fine-grained permission control, dynamic adjustment capabilities and terminal resource adaptability, and is suitable for security access control scenarios of large-scale IoT terminals. Attached Figure Description

[0022] Figure 1 This is a flowchart illustrating the SM9 key generation and attribute base policy dynamic distribution method across MCUs and servers according to the present invention. Detailed Implementation

[0023] The embodiments of the present invention are described in detail below. These embodiments are implemented based on the technical solution of the present invention, and provide detailed implementation methods and specific operation processes. However, the scope of protection of the present invention is not limited to the following embodiments.

[0024] like Figure 1 As shown, this embodiment provides a technical solution: a method for dynamically distributing SM9 key generation and attribute base policies across MCUs and servers, including the following steps: Step 1: The cloud-based key generation center completes the initialization of the SM9 identifier cryptosystem, generates the system master private key and the corresponding system master public key, and publishes the public parameters of the SM9 cryptosystem and the system master public key.

[0025] In this embodiment, taking a campus IoT system that includes multiple MCU terminals such as environmental monitoring and access control as an example, the specific implementation process of this step is as follows: The cloud-based key generation center first selects the common parameters of the SM9 cryptosystem conforming to the GM / T 0044 standard, determines the three cyclic groups G1, G2, and GT of order q, and selects the generator of group G1. generators of the G2 group Define a bilinear pairing mapping At the same time, the identifier hash function is agreed upon. Attribute hash function Key-derived hash function Version check hash function The above parameters together constitute the publicly available cryptographic parameters of the system.

[0026] Subsequently, the key generation center was at A random number is randomly selected from the integer range as the system master private key. The system master public key is calculated using scalar multiplication based on the generators of the G2 group. The corresponding calculation formula is as follows:

[0027] in, For the system master public key, The system's master private key. is a generator of the G2 group, and scalar multiplication is performed on the G2 group.

[0028] After initialization, the cloud-based key generation center will generate the system's master and private keys. The data is stored in a hardware security module for isolation and protection, and all public parameters are also stored with the system master public key. The policy is synchronized to all MCU terminals and policy distribution modules within the park; subsequently, the attribute binding of all MCU terminals, the generation of SM9 terminal private keys, and the encryption and decryption operations of access control policies are all performed based on this unified set of parameters, eliminating the need for each MCU terminal to separately negotiate keys with the cloud.

[0029] Step Two: The cloud collects the unique device identifier and multi-dimensional device attribute set (including device type and geographical location) of each MCU terminal. This multi-dimensional device attribute set is mapped to an attribute fusion factor. Based on the system master private key, device identifier, and attribute fusion factor, an attribute-bound SM9 terminal private key is generated, doubly bound to both the device identifier and the multi-dimensional device attributes. This attribute-bound SM9 terminal private key is then distributed to the local storage of the corresponding MCU terminal through a secure channel. By deeply binding multi-dimensional attributes such as device type and geographical location to the terminal private key through weighted fusion, the private key inherently carries device attribute permission characteristics, providing cryptographic support for fine-grained access control based on attributes. It also supports incremental updates of the private key when attributes change, reducing the transmission overhead of managing and updating massive amounts of terminal keys.

[0030] In this step, the process of mapping the multi-dimensional device attribute set to attribute fusion factors and generating attribute-bound SM9 terminal private keys is as follows: Each device attribute of the MCU terminal is uniquely encoded, with device type using classification hierarchical encoding and geographical location using administrative region hierarchical encoding. The encoded attributes are then mapped to the G1 group to obtain the corresponding attribute hash elements. Assign a corresponding weight coefficient to each device attribute, perform scalar multiplication on the hash element of each attribute and the corresponding weight coefficient, and then perform group addition on the G1 group to obtain the attribute fusion factor. The device identifier is hashed to generate an identifier hash element on the G1 group. The identifier hash element and the attribute fusion factor are added together to obtain the fusion element. The fusion element is multiplied by the system master private key to obtain the attribute-bound SM9 terminal private key. The attribute binding SM9 terminal private key is obtained by performing a multiplication of the fused elements with the master private key. The corresponding calculation formula is:

[0031] in, Bind the SM9 terminal private key to the attribute. The system's master private key. The hash mapping function from device identifier to G1 group. A unique device identifier for the MCU terminal. The number of attributes in the multidimensional device attribute set. For the first The weight coefficients corresponding to each device attribute A hash mapping function for encoding device attribute values ​​to the G1 group. For the first The encoded values ​​of each device attribute, covering device type encoding and geographic location encoding.

[0032] In this embodiment, taking an access control MCU terminal deployed in area A of the park as an example, the specific implementation process of this step in the above-mentioned park IoT system is as follows: The cloud assigns a unique code to two core attributes of the terminal: the device type "access control terminal" is coded as follows: The geographical location "Area A of the Park" is coded as follows: Input the two encoded values ​​into the hash function respectively. Mapping to the G1 group yields the corresponding attribute hash element. and .

[0033] Assign weight coefficients to device type attributes Assign weight coefficients to geographic location attributes After performing scalar multiplication on each attribute hash element and its corresponding weight coefficient, the attribute fusion factor is obtained by summing the results using group addition on the G1 group. .

[0034] Retrieve the unique device identifier of the terminal After hash function Mapping generates identifier hash elements on the G1 group Perform group addition on the identifier hash element and the attribute fusion factor to obtain the fusion element, then add it to the system master private key. Perform scalar multiplication to generate a private key for the SM9 terminal, which is unique to this terminal and has its attributes bound to it. The calculation formula is as follows:

[0035] Once generated, the private key is sent to the local storage of the corresponding access control MCU through a secure channel, serving as the exclusive key for subsequent decryption and access strategies.

[0036] It should be noted that the weight coefficients corresponding to each device attribute are dynamically determined by the cloud based on the security level of the device type, the regional risk level of the geographical location, and the access permission level. When the weight coefficients corresponding to a device attribute need to be adjusted, the cloud performs a scalar multiplication operation on the weight change and the hash element of the corresponding attribute, and then performs a scalar multiplication operation on the system master private key. Following the same scalar multiplication rules as the SM9 terminal private key bound to the attribute, a corresponding private key weight update factor is generated and encrypted and sent to the corresponding MCU terminal. The MCU terminal performs a group addition operation on the G1 group with the original attribute-bound SM9 terminal private key stored locally, completing the local update of the attribute-bound SM9 terminal private key. By dynamically adjusting attribute weights based on the device type security level and the regional risk level of the geographical location, it is not necessary to regenerate all terminal private keys; local updates of terminal private keys can be completed simply by sending the private key weight update factor. This adapts to scenarios with dynamic adjustment of access permission levels, reduces key update overhead, and improves the flexibility of access permission management.

[0037] In this embodiment, when Area A of the park is temporarily upgraded to a high-control area, and it is necessary to increase the weight of the geographic location attribute of the terminal in this area, the specific implementation process is as follows: The cloud platform confirmed that the original weight of the geographical location attribute of the access control MCU terminal was... The adjusted target weight is The change in weights is calculated. .

[0038] The cloud uses the hash element corresponding to the weight change and geographic location attribute. With the system master private key Generate the private key weight update factor, calculated using the following formula:

[0039] The cloud encrypts and sends the private key weight update factor to the corresponding access control MCU terminal. The terminal binds it with the original attribute stored locally and performs a group addition operation on the G1 group to obtain the updated terminal private key, thus completing the local update of the private key after weight adjustment.

[0040] It should be noted that when device attributes of the MCU terminal are added, deleted, or changed, including device type adjustment and geographical location migration, the cloud only generates the corresponding private key increment factor based on the code of the changed attribute item, the corresponding weight coefficient, and the system master private key, according to the scalar multiplication operation rules consistent with the attribute-bound SM9 terminal private key, and encrypts and sends it to the corresponding MCU terminal; after receiving the private key increment factor, the MCU terminal performs group addition or inverse group addition operation on the G1 group with the original attribute-bound SM9 terminal private key stored locally, and completes the local update of the attribute-bound SM9 terminal private key; The private key increment factor is obtained by multiplying the attribute hash element of the changed attribute item by the weight change, and then multiplying it by the system master private key. The updated attribute-bound SM9 terminal private key is obtained by group operation between the original private key and the private key increment factor. The corresponding private key increment update calculation formula is as follows:

[0041] in, As the private key increment factor, For the set of attribute items that have changed, For the first The change in weight corresponding to each changed attribute Bind the updated attributes to the SM9 terminal private key. This is a group addition operation on the G1 group; in the scenario of attribute deletion, the weight change is negative, and the inverse group addition operation is performed accordingly.

[0042] In this embodiment, when the access control MCU terminal originally deployed in Zone A of the park is migrated to Zone B of the park and its geographical location attribute changes, the specific implementation process is as follows: The cloud-based location tracking shows the changed attribute of this terminal: the original geolocation attribute code is... (Corresponding to Area A of the park), the new geographic location attribute code after the change is as follows: (Corresponding to Area B of the park), weighting coefficient of geographical location attribute It remains unchanged.

[0043] Based on the difference in attribute hashes before and after the change, the corresponding weights, and the system master private key, the cloud calculates and generates a private key increment factor. The corresponding calculation formula is as follows:

[0044] in, As the private key increment factor, The system's master private key. A hash mapping function for encoding device attribute values ​​to the G1 group.

[0045] The cloud encrypts and sends the private key increment factor to the corresponding MCU terminal. After receiving it, the terminal performs a group addition operation on the G1 group with the original attribute-bound SM9 terminal private key stored locally to obtain the updated attribute-bound SM9 terminal private key. There is no need to re-execute the full private key generation process.

[0046] Step 3: When the access control policy needs to be updated, the cloud determines the target access attribute structure corresponding to the policy to be issued, encrypts the plaintext access control policy based on the SM9 identifier cryptosystem and the target access attribute structure to generate policy ciphertext, and issues the policy ciphertext to the MCU terminal that meets the attribute matching conditions.

[0047] In this step, the process of generating policy ciphertext based on the SM9 identifier cryptosystem and the target access attribute structure is as follows: Extract the required set of access attributes based on the target access attribute structure, where the set of access attributes includes device type attributes and geographic location attributes; Each attribute in the access attribute set is uniquely encoded and mapped to the G1 group to obtain the corresponding attribute hash element. After assigning weight coefficients to each attribute, scalar multiplication is performed, and then the summation is performed by group addition on the G1 group to generate the access attribute factor. Randomly select a random number factor that meets the group order requirement, and perform a scalar multiplication operation between the random number factor and the generator of the G2 group to obtain the first component of the ciphertext; Calculate the bilinear pairing value between the access attribute factor and the system master public key. After performing a random number factor power operation on the bilinear pairing value, input it into the hash function to generate the key stream. Perform an XOR operation between the key stream and the plaintext access control policy to obtain the second component of the ciphertext. The final strategy ciphertext is composed of the first ciphertext component and the second ciphertext component. The first component of the ciphertext is obtained directly through scalar multiplication of the random number factor and the generator of the G2 group. The second component of the ciphertext is obtained through bitwise XOR operation of the plaintext access control policy and the key stream. The corresponding policy ciphertext construction calculation formula is as follows:

[0048] in, The first component of the ciphertext. The random number factor is selected randomly. For generators of the G2 group, This is the second component of the ciphertext. For plaintext access control policy, This is a bitwise XOR operation. This is a hash mapping function from group elements to fixed-length bit strings. For bilinear pairing operations, For access attribute factors, This is the system's master public key.

[0049] This invention encrypts access control policies based on target access attribute structures. Only MCU terminals with matching attributes can decrypt and execute the policies, enabling targeted and fine-grained policy distribution without the need for individual encryption for each terminal. This improves the efficiency of policy distribution in scenarios with a large number of terminals while ensuring the confidentiality of policy transmission.

[0050] In this embodiment, when the cloud needs to issue an access control policy that can only be executed by access control MCU terminals within Area A of the park, the specific implementation process is as follows: The cloud determines the set of access attributes corresponding to the target access attribute structure, including device type attributes (access control terminal, encoding). ) and geographical location attributes (Area A of the park, code) The same weighting coefficients used when generating the terminal private key are employed. , Calculate the access attribute factor using the following formula:

[0051] In the cloud Random number factor is randomly selected within the range The first and second components of the ciphertext are calculated separately to form the strategy ciphertext. The corresponding ciphertext construction calculation formula is as follows:

[0052]

[0053] in, This is a plaintext access control policy for traffic management; all other parameters are consistent with the definitions used during system initialization. After the policy is distributed in ciphertext, only MCU terminals that simultaneously match the corresponding device type and geographical location attributes can decrypt it using their local private key.

[0054] It should be noted that the attribute fusion factor and access attribute factor are calculated in the same way because only by using the exact same encoding rules, hash function, weight coefficient, and group operation rules can we guarantee that: when the actual attributes of the terminal meet the policy's access attributes, the attribute fusion component in the terminal's private key and the access attribute factor in the ciphertext strictly correspond in terms of group elements, the bilinear pairing operation is successful, and the ciphertext can be correctly decrypted; if the terminal attributes do not meet the policy requirements, the pairing operation cannot restore the correct key, and the ciphertext cannot be decrypted, thus achieving fine-grained control of "access is granted only if attributes match".

[0055] In this step, when the access control policy is for partial content updates, the cloud uses an incremental delivery method to update the policy: The cloud compares the content differences between the current latest version of the plaintext access control policy and the plaintext access control policy to be updated, and generates differential policy content; based on the target access attribute structure, the differential policy content is encrypted, and differential ciphertext is generated and sent to the corresponding MCU terminal along with the policy version number; After the MCU terminal decrypts the differential ciphertext, it combines the historical plaintext access control policies and policy version numbers stored locally to perform differential replacement on the corresponding content in the historical plaintext access control policies, completes the incremental merging and updating of the policies, and generates and stores the latest version of the plaintext access control policy.

[0056] In this invention, for scenarios involving partial adjustments to access control policies, there is no need to send out the complete policy ciphertext. Instead, differential policy content is generated and encrypted according to the original attribute encryption rules before being sent out. The terminal completes the incremental merging update locally, which significantly reduces the amount of data transmission for policy updates, reduces bandwidth usage, and adapts to the limited computing power and storage resources of MCU terminals.

[0057] In this embodiment, the original access control policy for Area A of the park was a unified access rule throughout the day. Now, only the access permissions during the evening peak hours need to be adjusted, while all other contents remain unchanged. The specific implementation process is as follows: The cloud-based system compares the latest version of the complete plaintext access control policy with the version to be updated, extracting the changes to the evening peak traffic rules as the differential policy content, denoted as... .

[0058] The cloud uses the access attribute factors corresponding to the original strategy. The differential policy content is encrypted according to the same encryption rules as the full policy ciphertext to generate differential ciphertext. The corresponding calculation formula is as follows:

[0059]

[0060] in, The random number factor selected for this differential encryption This is the first component of the differential ciphertext, which is the result of the scalar multiplication of the random number factor on the G2 group during differential encryption. Its function corresponds to the first component of the full ciphertext and is used in the bilinear pairing operation during decryption. The second component of the differential ciphertext is the encrypted differential policy content, generated by bitwise XOR operations between the differential policy plaintext and the derived key stream. Together they form a differential ciphertext, and the definitions of the remaining parameters remain consistent with those during the system initialization phase.

[0061] The cloud sends the differential ciphertext along with the latest policy version number to the access control MCU terminal in Area A of the park; the terminal decrypts the ciphertext to obtain the differential policy content. Then, differential replacement is performed on the rules for the corresponding time period in the historical plaintext access control policy stored locally, incremental merging is completed, and the latest version of the plaintext access control policy is generated and stored.

[0062] Step 4: After receiving the policy ciphertext, the MCU terminal calls the locally stored attribute binding SM9 terminal private key, completes the decryption of the policy ciphertext through bilinear pairing operation, obtains the plaintext access control policy, and executes the corresponding access control logic.

[0063] In this step, when the MCU terminal decrypts the ciphertext using bilinear pairing operations, it performs the decryption operation in a pre-calculation manner: When the MCU terminal receives and stores the attribute-bound SM9 terminal private key for the first time, it performs fixed component pre-calculation processing on the attribute-bound SM9 terminal private key for bilinear pairing operation, generates the pairing operation pre-calculation intermediate value corresponding to the private key, and forms the private key pre-calculation parameter table from the pre-calculation intermediate value and stores it locally. When decrypting the ciphertext of the decryption strategy, the pre-computed parameter table of the private key is called to perform a bilinear pairing operation with the first component of the ciphertext to obtain the decryption pairing value; Input the decryption pairing value into the hash function to generate the decryption key stream, and perform an XOR operation between the decryption key stream and the second component of the ciphertext to obtain the plaintext access control policy. The decryption pairing value is obtained by a bilinear pairing operation between the attribute-bound SM9 terminal private key and the first component of the ciphertext. The plaintext access control policy is restored by a bitwise XOR operation between the second component of the ciphertext and the decryption key stream. The corresponding decryption calculation formula is:

[0064] in, Bind the SM9 terminal private key to the attribute.

[0065] In this invention, by pre-calculating the fixed components of bilinear pairing on the SM9 terminal private key bound to the attribute, a pre-calculated parameter table is generated and stored locally. During decryption, intermediate values ​​are directly called to complete the pairing operation, effectively reducing the amount of real-time computation and lowering the consumption of MCU computing power for decryption. This makes it suitable for resource-constrained IoT terminal deployment scenarios. In this embodiment, taking the access control MCU terminal deployed in Area A of the park as an example, the terminal has limited computing power and the bilinear pairing operation has a high computational load. The specific implementation process of this step is as follows: The terminal receives and stores the attribute-bound SM9 terminal private key for the first time. At that time, a fixed component pre-computation process of bilinear pairing operation is performed on the private key to generate the pre-computation intermediate value of the pairing operation corresponding to the private key. The intermediate value is then stored in the private key pre-computed parameter table and stored locally.

[0066] After the terminal receives the policy ciphertext, it calls the intermediate value from the pre-computed parameter table. , and the first component of the ciphertext Quickly perform bilinear pairing operations to obtain the decrypted pairing value; input the decrypted pairing value into the hash function. Generate a decryption keystream, then combine it with the second component of the ciphertext. Performing a bitwise XOR operation restores the plaintext access control policy, and the corresponding decryption calculation formula is:

[0067] Bilinear pairing operation The process is completed quickly based on pre-computed intermediate values, without the need to perform the full private key pairing operation in real time. The definitions of other parameters remain consistent with the full ciphertext encryption stage.

[0068] In this step, the policy ciphertext also embeds a policy version hash value and a time-sensitive timestamp. Before decrypting the policy ciphertext, the MCU terminal first compares the time-sensitive timestamp with the local current time to complete the time-sensitive verification. After the time-sensitive verification passes, the decryption operation is performed to obtain the plaintext access control policy. Then, based on the previously stored policy version hash value and the current plaintext access control policy obtained from the decryption operation, the current policy version hash value is calculated and compared with the policy version hash value embedded in the policy ciphertext to complete the chain hash verification and verify the version continuity of the plaintext access control policy. After both verifications pass, the corresponding access control logic is executed. The policy version hash value is generated by jointly calculating the policy version hash value of the previous plaintext access control policy and the current plaintext access control policy. The policy version hash value is generated by concatenating the policy version hash value of the previous plaintext access control policy with the policy version hash value of the current plaintext access control policy, and then iteratively calculating it using a hash function. The corresponding chained hash calculation formula is as follows:

[0069] in, For the first The policy version hash value of the plaintext access control policy. For the first The policy version hash value of the plaintext access control policy. This is a bit string concatenation operation. For the first Plaintext access control policy content, This is a hash mapping function used for version verification.

[0070] In this embodiment, when the cloud sends the kth version of the access control policy to the access control MCU of Area A in the park, it embeds a time-sensitive timestamp and the hash value of the kth version of the policy into the policy ciphertext. The specific verification process is as follows: After receiving the policy ciphertext, the terminal first extracts the embedded time-sensitive timestamp and compares it with the local current time. If the time difference is within the preset valid window, the time-sensitive verification passes.

[0071] After the timeliness check passes, the terminal decrypts the plaintext access control policy to obtain version k. The terminal retrieves the (k-1)th version hash of the policy from local storage. , and the decrypted After concatenating the bit strings, input them into the hash function. The hash value of the current policy version is calculated using the following formula: .

[0072] The terminal will calculate the hash value of the kth version of the policy. The hash value of the policy version embedded in the ciphertext is compared with the hash value of the policy version. If the two match, the chain hash verification passes, confirming that the policy has not been tampered with and the versions are continuous. Then, the plaintext access control policy version is executed.

[0073] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention.

Claims

1. A method for dynamically distributing SM9 key generation and attribute base policies across MCUs and servers, characterized in that, The steps include the following: S1: The cloud-based key generation center completes the initialization of the SM9 identifier cryptosystem, generates the system master private key and the corresponding system master public key, and publishes the public parameters of the SM9 cryptosystem and the system master public key. S2: Collect the unique device identifier and multi-dimensional device attribute set including device type and geographical location of each MCU terminal in the cloud, map the multi-dimensional device attribute set into attribute fusion factor, generate attribute binding SM9 terminal private key based on system master private key, device identifier and attribute fusion factor, and double bind the device identifier and multi-dimensional device attributes, and distribute the attribute binding SM9 terminal private key to the local storage of the corresponding MCU terminal through a secure channel. S3: When the access control policy needs to be updated, the cloud determines the target access attribute structure corresponding to the policy to be issued, encrypts the plaintext access control policy based on the SM9 identifier cryptosystem and the target access attribute structure to generate policy ciphertext, and issues the policy ciphertext to the MCU terminal that meets the attribute matching conditions. S4: After receiving the policy ciphertext, the MCU terminal calls the locally stored attribute binding SM9 terminal private key, completes the decryption of the policy ciphertext through bilinear pairing operation, obtains the plaintext access control policy, and executes the corresponding access control logic.

2. The method for dynamic distribution of SM9 key generation and attribute base policy across MCUs and servers according to claim 1, characterized in that, In step S2, the process of mapping the multi-dimensional device attribute set to attribute fusion factors and generating the attribute-bound SM9 terminal private key is as follows: Each device attribute of the MCU terminal is uniquely encoded, with device type using hierarchical coding and geographic location using hierarchical coding of administrative regions. The encoded attributes are then mapped to the G1 group to obtain the corresponding attribute hash elements. Assign a corresponding weight coefficient to each device attribute, perform scalar multiplication on the hash element of each attribute and the corresponding weight coefficient, and then perform group addition on the G1 group to obtain the attribute fusion factor. The device identifier is hashed to generate an identifier hash element on the G1 group. The identifier hash element and the attribute fusion factor are added together to obtain the fusion element. The fusion element is multiplied by the system master private key to obtain the attribute-bound SM9 terminal private key.

3. The method for dynamic distribution of SM9 key generation and attribute base policy across MCUs and servers according to claim 2, characterized in that, The weight coefficients corresponding to each device attribute are dynamically determined by the cloud based on the security level of the device type, the regional risk level of the geographical location, and the access permission level. When the weight coefficients corresponding to a device attribute need to be adjusted, the cloud performs a scalar multiplication operation on the weight change and the hash element of the corresponding attribute, and then performs a scalar multiplication operation on the system master private key. The cloud generates the corresponding private key weight update factor according to the scalar multiplication operation rules consistent with the attribute-bound SM9 terminal private key, and encrypts and sends it to the corresponding MCU terminal. The MCU terminal performs a group addition operation on the G1 group on the private key weight update factor and the original attribute-bound SM9 terminal private key stored locally, and completes the local update of the attribute-bound SM9 terminal private key.

4. The method for dynamic distribution of SM9 key generation and attribute base policy across MCUs and servers according to claim 2, characterized in that, When device attributes of the MCU terminal are added, deleted, or changed, including device type adjustment and geographical location migration, the cloud only uses the code of the changed attribute item, the corresponding weight coefficient, and the system master private key to generate the corresponding private key increment factor according to the scalar multiplication operation rules consistent with the attribute-bound SM9 terminal private key, and encrypts and sends it to the corresponding MCU terminal. After receiving the private key increment factor, the MCU terminal performs group addition or inverse group addition operation on the G1 group with the original attribute-bound SM9 terminal private key stored locally to complete the local update of the attribute-bound SM9 terminal private key.

5. The method for dynamic distribution of SM9 key generation and attribute base policy across MCUs and servers according to claim 2, characterized in that, In step S3, the process of generating policy ciphertext based on the SM9 identifier cryptosystem and target access attribute structure is as follows: Extract the required set of access attributes based on the target access attribute structure, where the set of access attributes includes device type attributes and geographic location attributes; Each attribute in the access attribute set is uniquely encoded and mapped to the G1 group to obtain the corresponding attribute hash element. After assigning weight coefficients to each attribute, scalar multiplication is performed, and then the sum is obtained by group addition on the G1 group to generate the access attribute factor. Randomly select a random number factor that meets the group order requirement, and perform a scalar multiplication operation between the random number factor and the generator of the G2 group to obtain the first component of the ciphertext; Calculate the bilinear pairing value between the access attribute factor and the system master public key. After performing a random number factor power operation on the bilinear pairing value, input it into the hash function to generate the key stream. Perform an XOR operation between the key stream and the plaintext access control policy to obtain the second component of the ciphertext. The final strategy ciphertext is composed of the first ciphertext component and the second ciphertext component.

6. The method for dynamic distribution of SM9 key generation and attribute base policy across MCUs and servers according to claim 5, characterized in that, In step S4, when the MCU terminal decrypts the ciphertext using bilinear pairing operations, it performs the decryption operation in a pre-calculation manner: When the MCU terminal receives and stores the attribute-bound SM9 terminal private key for the first time, it performs fixed component pre-calculation processing on the attribute-bound SM9 terminal private key for bilinear pairing operation, generates the pairing operation pre-calculation intermediate value corresponding to the private key, and forms the private key pre-calculation parameter table from the pre-calculation intermediate value and stores it locally. When decrypting the ciphertext of the decryption strategy, the pre-computed parameter table of the private key is called to perform a bilinear pairing operation with the first component of the ciphertext to obtain the decryption pairing value; The decryption pairing value is input into the hash function to generate the decryption key stream. The decryption key stream is XORed with the second component of the ciphertext to obtain the plaintext access control policy.

7. The method for dynamic distribution of SM9 key generation and attribute base policy across MCUs and servers according to claim 1, characterized in that, In step S3, when the access control policy is a partial content update, the cloud uses an incremental delivery method to complete the policy update: The cloud compares the content differences between the current latest version of the plaintext access control policy and the plaintext access control policy to be updated, and generates differential policy content; based on the target access attribute structure, the differential policy content is encrypted, and differential ciphertext is generated and sent to the corresponding MCU terminal along with the policy version number; After the MCU terminal decrypts the differential ciphertext, it combines the historical plaintext access control policies and policy version numbers stored locally to perform differential replacement on the corresponding content in the historical plaintext access control policies, completes the incremental merging and updating of the policies, and generates and stores the latest version of the plaintext access control policy.

8. The method for dynamic distribution of SM9 key generation and attribute base policy across MCUs and servers according to claim 5, characterized in that, In step S4, the policy ciphertext also embeds a policy version hash value and a timeliness timestamp; before decrypting the policy ciphertext, the MCU terminal first compares the timeliness timestamp with the local current time to complete the timeliness verification. After the timeliness verification passes, a decryption operation is performed to obtain the plaintext access control policy. Then, based on the hash value of the previous version of the policy stored locally and the current version of the plaintext access control policy obtained from the decryption operation, the hash value of the current version of the policy is calculated. This current version of the policy is compared with the policy version hash value embedded in the policy ciphertext to complete the chain hash verification and verify the version continuity of the plaintext access control policy. After both verifications pass, the corresponding access control logic is executed. The policy version hash value is generated by jointly calculating the policy version hash value of the previous version of the plaintext access control policy and the current version of the plaintext access control policy.

Images