RAFT consensus-based multi-authorization-party cooperation attribute and key management method with clear ownership

Abstract

The invention relates to a multi-authorization-party cooperation attribute and key management method with clear ownership based on RAFT consensus. In the system initialization stage, each attribute authorization agency (AA) registers and initializes an identity on a block chain, and then generates and broadcasts a global attribute public key and constructs an attribute block through multi-party cooperation. In a user registration process, a data user (DU) submits an identity and attribute request to a system, and after preliminary verification of a Leader AA, a consensus is achieved among the AA through an RAFT algorithm, so that the consistency and security of registration information are ensured. In the user attribute updating stage, a user or an organization needs to submit an attribute change request. And the system processes and verifies an update request through an RAFT consensus mechanism, so that the correctness and consistency of attribute change are ensured. And the new attribute key is generated after the update is confirmed, and the old key is replaced, so that the system security is ensured. According to the method, the RAFT consensus algorithm is utilized to improve the fault tolerance and data consistency of the system, and the block chain technology is combined to enhance the security and non-tampering property of the data.

Description

Technical Field

[0001] The present invention belongs to the field of information security technology, and in particular relates to a multi-authorized party collaborative attribute and key management method with clear ownership based on RAFT consensus. Background Art

[0002] The multi-authorized party attribute-based encryption scheme solves the performance bottleneck and single point failure problems of a single authorized party. However, in the traditional multi-authorized party scheme, each attribute is managed by only one attribute authorized party (AA). The above problems still exist at the attribute level. Threshold-based multi-authorized parties realize multi-authorized party collaborative key distribution. However, this results in the AA being able to issue keys for all attributes, which will lead to confusion in the ownership of key issuance. In particular, when the attributes of a data user (DU) are updated, any authorized party can update or revoke the attributes of the DU, which will cause new security threats. Therefore, designing a multi-authorized party collaborative attribute and key management scheme with clear ownership to ensure the secure and efficient issuance of keys during user registration and attribute update stages is an important part of ensuring the security of attribute-based encryption.

[0003] In addition, existing technologies only focus on the security and correctness of cryptography, without considering how AA collaborates and reaches consensus in actual scenarios. However, achieving secure collaborative consensus of AA is as important as the security of cryptography itself in actual industrial applications. Therefore, combining blockchain distributed consensus protocols to ensure that the solution achieves correct consensus in actual applications is crucial to promoting the better application of attribute-based encryption in actual scenarios. Summary of the invention

[0004] The purpose of the present invention is to improve the security and efficiency of attribute and key management through the RAFT consensus mechanism in the blockchain and the improved revocable multi-authorized collaborative attribute-based encryption scheme with clear ownership, and to provide a multi-authorized collaborative attribute and key management method with clear ownership based on RAFT consensus, which can solve the data consistency problem, authority verification complexity and security problem existing in attribute and key management in the current multi-authorized environment. By integrating the RAFT consensus algorithm with blockchain technology, the present invention can not only effectively improve the security and transparency of attribute management, but also realize dynamic attribute update and key management, thereby improving the operating efficiency and reliability of the entire system.

[0005] To achieve the above object, the technical solution of the present invention is: a multi-authorized party collaborative attribute and key management method with clear ownership based on RAFT consensus, comprising the following steps:

[0006] S1. System initialization: All attribute authorization agencies AA initialize their identities For the full set of attributes For each ai Assigning a subset of management attributes Then for each attribute in the set All AAs that manage the corresponding attributes generate their own authorized party attribute public and private keys {h i,u ,κ i,u}, collaborate to generate the corresponding attribute block AB u , generate the global attribute public key h u , negotiate to generate the public parameter PP; finally, AA generates the genesis block and stores the public parameters in the genesis block; AA is responsible for maintaining the blockchain. After all AAs are successfully connected to the blockchain network, the RAFT consensus mechanism is started to elect the leader LAA responsible for coordinating the entire system. All AAs participate in the election of the leader according to the RAFT consensus mechanism;

[0007] S2. User registration: Data user DU submits his / her identity information and related materials to LAA to submit a registration request. AA collaborates to verify DU's identity information and related materials, and issues identity du and attribute set S to DU. Then AA registers based on public parameters PP and the authorized party attribute private key managed by itself. Issue an initial attribute key AK for each attribute x∈S of DU du,0 ;

[0008] S3, User attributes and key update: When the DU attribute changes for the kth time, the DU submits its current attribute key AK du,k-1 AA updates the latest attribute set S' of DU according to the actual situation, and based on the public parameter PP and the authorized party attribute private key managed by itself Issue an update key AK for each new attribute x∈S' of DU du,k DU or its organization needs to submit an attribute update request to the system. The update request is first sent to LAA, which is responsible for preliminary review of these requests and verification of the format and data integrity. Approved requests will be created as a new log entry by LAA and begin to replicate the log entry among other AAs in the RAFT cluster. After each AA receives the new log entry, it will verify it to ensure that the information provided meets the system's security and operating standards.

[0009] In one embodiment of the present invention, DU submits a registration request to the system through the RAFT consensus mechanism, including a detailed description of its personal information and required attributes. This information is sent to the blockchain network in encrypted form to ensure the security of the transmission process. After the request is submitted, it is first processed by LAA, and then the request and verification results are broadcast to other AAs.

[0010] In one embodiment of the present invention, the request and verification results are broadcasted to other AAs through the log replication mechanism in the RAFT consensus mechanism, ensuring that all AAs have the latest data and reach consensus on the registration information of the DU.

[0011] In one embodiment of the present invention, the attribute update request submitted by the DU or its organization to the system includes the identity information of the DU, detailed attribute data to be updated, and corresponding certification materials.

[0012] In one embodiment of the present invention, for the attribute block AB of the global attribute u∈U u The structure is AB u : The specific contents are:

[0013] The attribute block contains attribute configuration and authorization party configuration. The attribute configuration AtC contains the attribute index u, name name and global public key h u ; The authorizer configures AuC and lists all attribute authorities AA that manage the corresponding attributes: Identity i and state st, and the total number of authorized parties n required to manage the corresponding attributes u and attribute threshold t u .

[0014] In one embodiment of the present invention, step S1 specifically includes the following steps:

[0015] Step S11: LAA selects two elliptic cyclic groups based on the security parameter λ and and a cyclic group The three groups have the same ordinal number, pe: is a bilinear map, g is Generator, LAA selects a random group element

[0016] Step S12: LAA negotiates with other n-1 AAs about the system threshold t α , for each attribute u∈U, determine the total number of authorized parties n that manage the corresponding attribute u And negotiate the attribute threshold t u ;

[0017] Step S13, the i-th AA from u∈U i Select random number And generate the corresponding (t u -1) random polynomial f i,u (x), where

[0018] Step S14: The i-th AA calculates and the identity is aj AA's sharing in

[0019] Step S15: The i-th AA obtains the shared shares from other AAs From other u - 1 AA;

[0020] Step S16, calculation of the i-th AA As its authorized party attribute private key, calculate As its authorized party attribute public key;

[0021] Step S17: receiving other AA's After that, the i-th AA calculates the global public key and reach consensus with other AAs, including

[0022] Step S18, LAA stores the global public key in the attribute block structure;

[0023] Step S19: LAA constructs a common parameter number And pack it into the genesis block, and send the genesis block to other AAs to reach consensus.

[0024] In one embodiment of the present invention, step S2 specifically includes the following steps:

[0025] Step S21, DU sends identity information to LAA, and LAA and other AAs assign attribute set S to it according to DU information;

[0026] Step S22: The i-th AA Choose a random number r from i ,calculate Send to LAA;

[0027] Step S23: LAA calculation Broadcast to other AAs;

[0028] Step S24: For the attribute x∈S of DU, the i-th AA calculates Send to LAA;

[0029] Step S25: LAA calculation Returns the attribute key AK du ={E 0 ,{Y x,0} x∈S}Give DU.

[0030] In one embodiment of the present invention, step S3 specifically includes the following steps:

[0031] Step S31: All AAs update the attribute set S' for the DU, and the DU submits the previous attribute key AK du,k-1 ;

[0032] Step S32: The i-th AA selects a random number calculate and sent to LAA;

[0033] Step S33: LAA is calculated for DU And broadcast to other AAs;

[0034] Step S34, the i-th AA is calculated for each x∈S' Send to LAA;

[0035] Step S35, LAA calculates for each x∈S' And returns the attribute key AK du,k =E k ,{Y x,k} x∈S'}Give DU.

[0036] The present invention also provides a multi-authorized party collaborative attribute and key management system with clear ownership based on RAFT consensus, including a memory, a processor, and computer program instructions stored in the memory and capable of being executed by the processor. When the processor executes the computer program instructions, the method steps described above can be implemented.

[0037] The present invention also provides a computer-readable storage medium, on which computer program instructions that can be executed by a processor are stored. When the processor executes the computer program instructions, the method steps described above can be implemented.

[0038] Compared with the prior art, the present invention has the following beneficial effects: The present invention ensures data consistency between all attribute authorization agencies (AA) by integrating the RAFT consensus mechanism. This mechanism reduces data conflicts and errors, especially in dynamic environments, such as scenarios where attributes and permissions are frequently updated. The fault tolerance of the RAFT algorithm ensures that the system can continue to operate stably even when some system nodes fail, avoiding problems such as key distribution failure or inconsistency caused by problems such as some AA being offline or failing, and greatly improving the reliability of the system. By using blockchain technology to record tamper-proof logs of all key operations (such as user registration and attribute key distribution), the present invention significantly enhances the security and auditing capabilities of the system. Each operation is verifiable and all records are transparent, thereby providing users with a higher level of trust assurance. Compared with the prior art, the present invention supports dynamic attribute management and real-time key updates. Through the RAFT consensus mechanism, when user attributes change, the system can respond quickly and update the relevant keys to ensure that users can access the resources they need at any time, while revoking keys that are no longer valid, increasing the system's protection against security threats. The user registration and attribute update process is coordinated by the leader (LeaderAA, LAA), reducing redundant communication and processing time. The efficient log replication and leader election mechanism of the RAFT algorithm makes the entire system more responsive and more efficient, especially in large-scale distributed environments. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] Figure 1 is a system architecture block diagram in one embodiment of the present invention.

[0040] Figure 2 It is a block diagram of the RAFT consensus principle in one embodiment of the present invention.

[0041] Figure 3 It is a block diagram of the authorization principle in one embodiment of the present invention. DETAILED DESCRIPTION

[0042] The technical solution of the present invention is described in detail below in conjunction with the accompanying drawings.

[0043] The present invention provides a multi-authorized party collaborative attribute and key management method with clear ownership based on RAFT consensus, comprising the following steps:

[0044] S1. System initialization: All attribute authorization agencies AA initialize their identities For the full set of attributes For each a i Assigning a subset of management attributes Then for each attribute in the set All AAs that manage the corresponding attributes generate their own authorized party attribute public and private keys {h i,u ,κ i,u}, collaborate to generate the corresponding attribute block AB u , generate the global attribute public key h u , negotiate to generate the public parameter PP; finally, AA generates the genesis block and stores the public parameters in the genesis block; AA is responsible for maintaining the blockchain. After all AAs are successfully connected to the blockchain network, the RAFT consensus mechanism is started to elect the leader LAA responsible for coordinating the entire system. All AAs participate in the election of the leader according to the RAFT consensus mechanism;

[0045] S2. User registration: Data user DU submits his / her identity information and related materials to LAA to submit a registration request. AA collaborates to verify DU's identity information and related materials, and issues identity du and attribute set S to DU. Then AA registers based on public parameters PP and the authorized party attribute private key managed by itself. Issue an initial attribute key AK for each attribute x∈S of DU du,0 ;

[0046] S3, User attributes and key update: When the DU attribute changes for the kth time, the DU submits its current attribute key AK du,k-1 AA updates the latest attribute set S' of DU according to the actual situation, and based on the public parameter PP and the authorized party attribute private key managed by itself Issue an update key AK for each new attribute x∈S' of DU du,k DU or its organization needs to submit an attribute update request to the system. The update request is first sent to LAA, which is responsible for preliminary review of these requests and verification of the format and data integrity. Approved requests will be created as a new log entry by LAA and begin to replicate the log entry among other AAs in the RAFT cluster. After each AA receives the new log entry, it will verify it to ensure that the information provided meets the system's security and operating standards.

[0047] The present invention also provides a multi-authorized party collaborative attribute and key management system with clear ownership based on RAFT consensus, including a memory, a processor, and computer program instructions stored in the memory and capable of being executed by the processor. When the processor executes the computer program instructions, the method steps described above can be implemented.

[0048] The present invention also provides a computer-readable storage medium, on which computer program instructions that can be executed by a processor are stored. When the processor executes the computer program instructions, the method steps described above can be implemented.

[0049] The following is the specific implementation process of the present invention.

[0050] like Figure 1 As shown, the method of the present invention involves the following participants:

[0051] The Attribute Authority (AA) is responsible for generating and managing the public-private key pairs associated with the attributes it assigns. This includes generating the corresponding attribute keys when users register and update attributes, and ensuring the secure distribution of the keys. The AA participates in verifying the user information in the registration request to ensure the authenticity and accuracy of the identity information of the data user (DU). In the RAFT consensus mechanism, the AA participates in the leader election and log replication process as a node to ensure the consistency of the system consensus and the synchronization of data;

[0052] The Leadership Authority (LAA) plays a coordinating and leading role in the AA and is the leader in the RAFT consensus mechanism. The LAA is responsible for coordinating and leading the creation, replication, and submission of log entries during the RAFT consensus process to ensure data consistency and effective execution of operations throughout the system. The LAA sets global parameters, including security parameters and operating policies, during the system initialization phase and is responsible for distributing these parameters to all AAs. The LAA oversees the operation of the entire system, including monitoring of key generation and distribution, and evaluation of system security and performance;

[0053] Data users (DUs) are end users of the system and primarily use the services provided by the system to access protected resources. DUs submit requests to the system for attribute access or update, including registration information and attribute information that needs to be updated. DUs receive attribute keys assigned to them from the system and use these keys to access corresponding resources or services. DUs are responsible for protecting the security of their own keys and personal information to prevent unauthorized access.

[0054] like Figure 1-3 As shown, the specific implementation steps of the method of the present invention are as follows:

[0055] Step S01: Each AA registers its identity on the blockchain through secure communication and participates in generating public parameters and attribute blocks (AB), starting the RAFT consensus mechanism;

[0056] Step S02: Each AA starts in the follower state and waits for a message from the leader;

[0057] Step S03: If any AA does not receive a heartbeat signal from any leader within a preset timeout period, it will change to a candidate state and start a new round of leader election;

[0058] Step S04: The AA that becomes a candidate will increase its current term number and send messages to all other AAs requesting votes. These messages contain information about the candidate, such as the term number and the status of the log entry;

[0059] Step S05: After receiving the voting request, each AA will decide whether to vote for the candidate according to the rules of the RAFT protocol. Generally, if the candidate's log is at least as new as its own, and the AA has not voted for other candidates in the current term, it will vote for the candidate;

[0060] Step S06: If an AA obtains votes from the majority of AAs, the candidate is selected as the new leader LAA, and the LAA immediately starts sending heartbeat messages to all AAs to confirm its leadership and prevent other AAs from timing out and initiating a new election;

[0061] Step S11: LAA selects two elliptic cyclic groups based on the security parameter λ and and a cyclic group The three groups have the same ordinal number, pe: is a bilinear map, g is Generator, LAA selects a random group element

[0062] Step S12: LAA sends a negotiation request to other n-1 AAs to negotiate the system threshold t α And written into the genesis block, for each system attribute u∈U, determine all authorized parties AA that manage the attribute, the total number is n u , negotiated attribute threshold t u And send LAA to be written into the genesis block;

[0063] Step S13: The i-th AA is from u∈U i Random number selected And generate the corresponding (t u -1) random polynomial f i,u (x), where

[0064] Step S14: The i-th AA calculates the identity a j AA's sharing in

[0065] Step S15: The i-th (i∈[1,n]) AA obtains the shared shares from other AAs From other u - 1 AA;

[0066] Step S16: Calculation of the i-th AA As its authorized party global attribute private key, calculate As the global attribute public key of its authorized party;

[0067] Step S17: Receive other AA After that, the i-th AA calculates the global attribute public key and reach consensus with other AAs, including

[0068] Step S18: LAA stores the global attribute public key in the attribute block structure. Attribute block AB of global attribute u∈U u The structure is AB u :

[0069] Step S19-1: LAA constructs common parameters Pack it into the genesis block and send the genesis block to other AAs to reach consensus;

[0070] Step S19-2: After receiving the genesis block, other AA nodes will verify and accept the genesis block through the voting mechanism of the RAFT consensus mechanism;

[0071] Step S19-3: Once the genesis block is approved by the majority of AA nodes, it will be officially added to the blockchain, and the entire network will begin to operate;

[0072] Step S21-1: Subsequently, the data user (DU) submits a registration request including its personal information to the system;

[0073] Step S21-2: The registration request is first sent to the Lead Attribute Authority (LAA), which is responsible for preliminarily verifying the format and integrity of the request to ensure that there are no errors or missing data, and broadcasting the request to all Attribute Authorities (AA) in the form of a new log entry;

[0074] Step S21-3: All AAs issue attribute set S to DU according to the identity information of DU;

[0075] Step S22: Each AA Select one of the i ,calculate Sent to LAA, if the threshold t is met α AA nodes submit E i This indicates that the DU registration request is approved, and the log entry for DU registration is considered to have reached consensus;

[0076] Step S23: LAA collects responses from other AA nodes and calculates Broadcast to other AAs;

[0077] Step S24: For the attribute x∈S of DU, the i-th AA calculates Send to LAA;

[0078] Step S25: LAA calculation Returns the attribute key AK du ={E 0 ,{Y x,0} x∈S} to data user DU;

[0079] Step S31-1: DU requests to update the attribute key, and the request includes the DU's previous attribute key AK du,k-1 ,The request is first sent to the Leadership Attribute Authority (LAA);

[0080] Step S31-2: The LAA is responsible for initially verifying the format and integrity of the request to ensure that there are no errors or missing data, and broadcasts the request to all attribute authorities (AA) in the form of a new log entry;

[0081] Step S31-3: All AAs issue the latest attribute set S' to DU according to the actual situation;

[0082] Step S32: The i-th AA selects a random number calculate And sent to LAA, if the threshold t is met α AA nodes submit E i ′ indicates that the verification is successful and the attribute key update request is supported, and the log entry of the user attribute key update is considered to have reached consensus;

[0083] Step S33: LAA is calculated for DU And broadcast to other AAs;

[0084] Step S34: The i-th AA calculates for each x∈S' and sent to LAA;

[0085] Step S35: LAA calculates for each x∈S' And returns the attribute key AK du,k ={E k ,{Y x,k} x∈S'}Give DU.

[0086] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application may adopt the form of a computer program product implemented in one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) that include computer-usable program code.

[0087] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0088] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0089] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0090] The above is only a preferred embodiment of the present invention, and does not limit the present invention in other forms. Any technician familiar with the profession may use the above disclosed technical content to change or modify it into an equivalent embodiment with equivalent changes. However, any simple modification, equivalent change and modification made to the above embodiment according to the technical essence of the present invention without departing from the technical solution of the present invention still belongs to the protection scope of the technical solution of the present invention.

Claims

1. A multi-authorized party collaborative attribute and key management method with clear ownership based on RAFT consensus, characterized in that: The steps include: S1. System initialization: All attribute authorization agencies AA initialize their identities For the full set of attributes For each a i Assigning a subset of management attributes Then for each attribute in the set All AAs that manage the corresponding attributes generate their own authorized party attribute public and private keys {h i,u ,κ i,u }, collaborate to generate the corresponding attribute block AB u , generate the global attribute public key h u , negotiate to generate public parameters PP; finally, AA generates the genesis block and stores the public parameters in the genesis block; AA is responsible for maintaining the blockchain. After all AAs are successfully connected to the blockchain network, the RAFT consensus mechanism is started to elect the leader LAA responsible for coordinating the entire system. All AAs participate in the election of the leader according to the RAFT consensus mechanism. S2. User registration: Data user DU submits his / her identity information and related materials to LAA to submit a registration request. AA collaborates to verify DU's identity information and related materials, and issues identity du and attribute set S to DU. Then AA registers based on public parameters PP and the authorized party attribute private key managed by itself. Issue an initial attribute key AK for each attribute x∈S of DU du,0 ; S3, User attributes and key update: When the DU attribute changes for the kth time, the DU submits its current attribute key AK du,k-1 AA updates the latest attribute set S' of DU according to the actual situation, and based on the public parameter PP and the authorized party attribute private key managed by itself Issue an update key AK for each new attribute x∈S' of DU du,k DU or its organization needs to submit an attribute update request to the system. The update request is first sent to LAA, which is responsible for preliminary review of these requests and verification of the format and data integrity. Approved requests will be created as a new log entry by LAA and begin to replicate the log entry among other AAs in the RAFT cluster. After each AA receives the new log entry, it will verify it to ensure that the information provided meets the system's security and operating standards.

2. According to claim 1, a multi-authorized party collaborative attribute and key management method with clear ownership based on RAFT consensus, characterized in that: DU submits a registration request to the system through the RAFT consensus mechanism, including a detailed description of its personal information and required attributes. This information is sent to the blockchain network in encrypted form to ensure the security of the transmission process. After the request is submitted, it is first processed by LAA, and then the request and verification results are broadcast to other AAs.

3. According to claim 2, a multi-authorized party collaborative attribute and key management method with clear ownership based on RAFT consensus is characterized in that: Broadcasting the request and verification results to other AAs is accomplished through the log replication mechanism in the RAFT consensus mechanism, ensuring that all AAs have the latest data and reach consensus on the registration information of the DU.

4. According to claim 1, a multi-authorized party collaborative attribute and key management method with clear ownership based on RAFT consensus, characterized in that: The attribute update request submitted by DU or its organization to the system includes the identity information of DU, detailed data of the attributes to be updated and corresponding supporting materials.

5. According to claim 1, a multi-authorized party collaborative attribute and key management method with clear ownership based on RAFT consensus, characterized in that: For the attribute block AB with global attribute u∈U u The structure is AB u : The specific contents are: The attribute block contains attribute configuration and authorization party configuration. The attribute configuration AtC contains the attribute index u, name name and global public key h u ; The authorizer configures AuC and lists all attribute authorities AA that manage the corresponding attributes: Identity i and state st, and the total number of authorized parties n required to manage the corresponding attributes u and attribute threshold t u .

6. According to claim 5, a multi-authorized party collaborative attribute and key management method with clear ownership based on RAFT consensus is characterized in that: Step S1 specifically includes the following steps: Step S11: LAA selects two elliptic cyclic groups based on the security parameter λ and and a cyclic group The three groups have the same order, pe: is a bilinear map, g is Generator, LAA selects a random group element Step S12: LAA negotiates with other n-1 AAs about the system threshold t α , for each attribute u∈U, determine the total number of authorized parties n that manage the corresponding attribute u And negotiate the attribute threshold t u ; Step S13, the i-th AA from u∈U i Select random number And generate the corresponding (t u -1) random polynomial f i,u (x), where Step S14: The i-th AA calculates and the identity is a j AA's sharing in Step S15: The i-th AA obtains the shared shares from other AAs From other u - 1 AA; Step S16, calculation of the i-th AA As its authorized party attribute private key, calculate As its authorized party attribute public key; Step S17: receiving other AA's After that, the i-th AA calculates the global public key and reach consensus with other AAs, including Step S18, LAA stores the global public key in the attribute block structure; Step S19: LAA constructs common parameters And pack it into the genesis block, and send the genesis block to other AAs to reach a consensus.

7. According to claim 6, a multi-authorized party collaborative attribute and key management method with clear ownership based on RAFT consensus is characterized in that: Step S2 specifically includes the following steps: Step S21, DU sends identity information to LAA, and LAA and other AAs assign attribute set S to it according to DU information; Step S22: The i-th AA Choose a random number r from i , where the calculation Send to LAA; Step S23: LAA calculation Broadcast to other AAs; Step S24: For the attribute x∈S of DU, the i-th AA calculates Send to LAA; Step S25: LAA calculation Returns the attribute key AK du ={E0,{Y x,0 } x∈S }Give DU.

8. According to claim 7, a multi-authorized party collaborative attribute and key management method with clear ownership based on RAFT consensus is characterized in that: Step S3 specifically includes the following steps: Step S31: All AAs update the attribute set S' for the DU, and the DU submits the previous attribute key AK du,k-1 ; Step S32: The i-th AA selects a random number calculate and sent to LAA; Step S33: LAA is calculated for DU And broadcast to other AAs; Step S34, the i-th AA is calculated for each x∈S' Send to LAA; Step S35, LAA calculates for each x∈S' And returns the attribute key AK du,k ={E k ,{Y x,k } x∈S' }Give DU.

9. A multi-authorized collaborative attribute and key management system with clear ownership based on RAFT consensus, characterized in that: The method comprises a memory, a processor and computer program instructions stored in the memory and executable by the processor. When the processor executes the computer program instructions, the method steps as claimed in any one of claims 1 to 8 can be implemented.

10. A computer-readable storage medium storing computer program instructions that can be executed by a processor, wherein when the processor executes the computer program instructions, the method steps according to any one of claims 1 to 8 can be implemented.

Images