A multi-authorized collaborative attribute and key management method with clear ownership based on RAFT consensus

Abstract

The present invention relates to a multi-authorized party collaborative attribute and key management method with clear ownership based on RAFT consensus. During the system initialization phase, each attribute authorization agency (AA) registers and initializes its identity on the blockchain, and then generates and broadcasts a global attribute public key and constructs an attribute block through multi-party collaboration. During the user registration process, the data user (DU) submits an identity and attribute request to the system. After preliminary verification by the Leader AA, a consensus is reached among the AAs through the RAFT algorithm to ensure the consistency and security of the registration information. During the user attribute update phase, the user or organization needs to submit an attribute change request. The system processes and verifies the update request through the RAFT consensus mechanism to ensure the correctness and consistency of the attribute change. A new attribute key is generated after the update is confirmed and replaces the old key to ensure system security. The present invention utilizes the RAFT consensus algorithm to improve the system's fault tolerance and data consistency, and at the same time combines blockchain technology to enhance the security and immutability of the data.

Description

Technical Field

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

[0002] The multi-authorizer attribute-based encryption scheme solves the performance bottleneck and single point failure problems of a single-authorizer. However, in the traditional multi-authorizer scheme, each attribute is managed by only one attribute authority (AA). The above problems still exist at the attribute level. Threshold-based multi-authorizer realizes multi-authorizer collaborative key distribution. However, this results in the AA issuing 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-authorizer 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] Furthermore, existing technologies focus solely on cryptographic security and correctness, without considering how AAs collaborate and reach consensus in real-world scenarios. However, achieving secure AAs and consensus is as important as the security of cryptography itself in real-world industrial applications. Therefore, integrating blockchain-based distributed consensus protocols to ensure accurate consensus in real-world applications is crucial for promoting the application of attribute-based encryption in real-world 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 an improved revocable multi-authorizer collaborative attribute-based encryption scheme with clear ownership. It provides a multi-authorizer collaborative attribute and key management method with clear ownership based on RAFT consensus. This method can solve the data consistency problems, permission verification complexity, and security problems existing in attribute and key management in the current multi-authorization 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 updates and key management, thereby improving the operating efficiency and reliability of the entire system.

[0005] To achieve the above objectives, 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 own 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 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, the AA generates the genesis block and stores the public parameters in the genesis block; the 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 leader election according to the RAFT consensus mechanism;

[0007] S2. User registration: Data user DU submits his or 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 uses the public parameter PP and the authorized party attribute private key managed by itself to register. Issue an initial attribute key AK for each attribute x∈S of DU du,0 ;

[0008] S3. User attribute 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, the 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 preliminarily processed by the 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 broadcast to other AAs through the log replication mechanism in the RAFT consensus mechanism, ensuring that all AAs have the latest data and reach a 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 data of the attributes 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 a 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 for the system threshold t α , for each attribute u∈U, determine the total number n of all authorized parties 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 is calculated with identity aj AA's sharing in

[0019] Step S15: The i-th AA obtains the shared shares from other AAs From other n 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: Receive the other AA After that, the i-th AA calculates the global public key and reached a consensus with other AAs, among which

[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 based on the DU information;

[0026] Step S22, the i-th AA from 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 ={E0,{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 to existing technologies, the present invention offers the following advantages: By integrating the RAFT consensus mechanism, it ensures data consistency across all attribute authorization authorities (AAs). This mechanism reduces data conflicts and errors, particularly in dynamic environments, such as those with frequent attribute and permission updates. The fault-tolerance of the RAFT algorithm ensures stable system operation even if some system nodes fail, avoiding key distribution failures or inconsistencies caused by offline or faulty AA nodes, significantly improving system reliability. By utilizing blockchain technology to create an immutable log of all key operations (such as user registration and attribute key distribution), the present invention significantly enhances system security and auditability. Every operation is verifiable, and all records are transparent, providing users with a higher level of trust. Compared to existing technologies, the present invention supports dynamic attribute management and real-time key updates. Through the RAFT consensus mechanism, when user attributes change, the system can rapidly respond and update the relevant keys, ensuring that users can access the resources they need at any time. Furthermore, the revocation of invalid keys enhances the system's protection against security threats. The user registration and attribute update process is coordinated by a leader (LeaderAA, LAA), reducing redundant communication and processing time. The RAFT algorithm's efficient log replication and leader election mechanism make the entire system more responsive and efficient, especially in large-scale distributed environments. BRIEF DESCRIPTION OF THE DRAWINGS

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

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

[0041] Figure 3 This 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 will be described in detail below with reference to 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 own 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 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, the AA generates the genesis block and stores the public parameters in the genesis block; the 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 leader election according to the RAFT consensus mechanism;

[0045] S2. User registration: Data user DU submits his or 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 uses the public parameter PP and the authorized party attribute private key managed by itself to register. Issue an initial attribute key AK for each attribute x∈S of DU du,0 ;

[0046] S3. User attribute 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 a 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 its assigned attributes. This includes generating corresponding attribute keys during user registration and attribute updates, and ensuring the secure distribution of keys. The AA participates in verifying user information in registration requests, ensuring the authenticity and accuracy of the identity information of the data user (DU). In the RAFT consensus mechanism, the AA participates as a node in the leader election and log replication process, ensuring the consistency of the system consensus and the synchronization of data;

[0052] The Leadership Authority (LAA) plays a coordinating and leading role within 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, ensuring data consistency and efficient execution of operations across the entire system. The LAA sets global parameters, including security parameters and operational policies, during system initialization and is responsible for distributing these parameters to all AAs. The LAA oversees the operation of the entire system, including monitoring key generation and distribution, and evaluating system security and performance.

[0053] Data users (DUs) are the end users of the system, primarily utilizing the system's services to access protected resources. DUs submit attribute access or update requests to the system, including registration information and the attribute information to be updated. DUs receive attribute keys assigned to them from the system and use these keys to access the corresponding resources or services. DUs are responsible for protecting their 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 transition to the Candidate state and start a new round of leader election;

[0058] Step S04: The AA that becomes a candidate increases its current term number and sends a message to all other AAs requesting a vote. 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 recent 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 elected as the new leader LAA. The LAA immediately starts sending heartbeat messages to all AAs to confirm its leadership and prevent other AAs from timing out and initiating new elections.

[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 the 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 this 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 starts 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 is calculated with 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 n u -1 AA;

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

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

[0068] Step S18: LAA stores the global attribute public key into 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 is officially added to the blockchain, and the entire network begins to operate;

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

[0073] Step S21-2: The registration request is first sent to the Lead Attribute Authority (LAA). The LAA is responsible for preliminary verification of the format and integrity of the request to ensure that there are no errors or missing data, and then broadcasts 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 based on DU's identity information;

[0075] Step S22: Each AA Select one r 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 is calculated Send to LAA;

[0078] Step S25: LAA calculation Returns the attribute key AK du ={E0,{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 there are no errors or missing data, and broadcasts the request to all Attribute Authorities (AAs) in the form of a new log entry.

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

[0082] Step S32: The i-th AA selects a random number calculate And send it 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 is calculated 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 can be provided as methods, systems, or computer program products. Therefore, the present application can 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 can adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) that contain 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 produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the steps in the process. 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 that can direct a computer or other programmable data processing device to work 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 The 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 operational steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing the instructions executed on the computer or other programmable device for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0090] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any other manner. Any person skilled in the art may utilize the above-disclosed technical content to modify or modify the present invention into equivalent embodiments. However, any simple modifications, equivalent variations, and modifications to the above embodiments that do not depart from the technical content of the present invention and are based on the technical essence of the present invention shall still fall within the scope of protection of the present invention.

Claims

1. A multi-authorized collaborative attribute and key management method with clear ownership based on RAFT consensus, characterized by: The steps include: S1. System initialization: All attribute authorization agencies AA initialize their own 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 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 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 leader election according to the RAFT consensus mechanism. S2. User registration: Data user DU submits his or 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 uses the public parameter PP and the authorized party attribute private key managed by itself to register. Issue an initial attribute key AK for each attribute x∈S of DU du,0 ; S3. User attribute 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 the 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 the LAA and begin to replicate the log entry among other AAs in the RAFT cluster. After receiving the new log entry, each AA will verify it to ensure that the information provided meets the system's security and operational standards. 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 p, is a bilinear map, g is Generator, LAA selects a random group element Step S12: LAA negotiates with other n-1 AAs for the system threshold t α , for each attribute u∈U, determine the total number n of all authorized parties 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 is calculated with identity a j AA's sharing in All attribute authorities AA representing the corresponding attributes; Step S15: The i-th AA obtains the shared shares from other AAs From other n 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: Receive the other AA After that, the i-th AA calculates the global public key and reached a consensus with other AAs, among which Step S18: LAA stores the global public key in the attribute block structure; Step S19: LAA constructs common parameters Pack it into the genesis block and send the genesis block to other AAs to reach consensus; 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 based on the DU information; Step S22, the i-th AA from 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; 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.

2. A multi-authorized collaborative attribute and key management method with clear ownership based on RAFT consensus according to claim 1, 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 the LAA, and then the request and verification results are broadcast to other AAs.

3. A multi-authorized collaborative attribute and key management method with clear ownership based on RAFT consensus according to claim 2, 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 a consensus on the DU's registration information.

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

5. The multi-authorized party collaborative attribute and key management method with clear ownership based on RAFT consensus according to claim 1 is characterized in that: For the attribute block AB of the global attribute u∈U u The structure is 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 a 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. A multi-authorized collaborative attribute and key management system with clear ownership based on RAFT consensus, characterized by: The method comprises 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 according to any one of claims 1 to 5 can be implemented.

7. 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 5 can be implemented.

Images