Multi-mechanism attribute access control method supporting authority entrustment and revocation

Abstract

The invention discloses a multi-mechanism attribute access control method supporting authority entrustment and revocation, which realizes fine-grained authority control, cross-domain collaborative management and efficient and safe revocation through distributed attribute management, dynamic policy entrustment and an incremental revocation mechanism. The defects of a traditional CP-ABE system in the aspects of expandability, delegation flexibility and revocation efficiency are overcome.

Description

Technical Field

[0001] The present invention relates to the technical field of Internet of Things, and in particular to a multi-organization attribute access control solution that supports authority delegation and revocation. Background Art

[0002] The Internet of Things (IoT) connects physical devices such as sensors and smart terminals through wireless communication technologies, generating massive amounts of data and enabling a wide range of applications. Access control, a core IoT security technology, relies on attribute-based encryption (ABE) to implement fine-grained permission management. ABE is primarily categorized into key-policy attribute-based encryption (KP-ABE) and cipher-policy attribute-based encryption (CP-ABE). CP-ABE effectively implements fine-grained data access control by binding user private keys to attribute sets and embedding access policies during the encryption phase.

[0003] However, existing CP-ABE systems suffer from poor scalability, insufficient key delegation flexibility, and high overhead and insufficient granularity in revocation mechanisms. To address these issues, researchers have proposed improvements such as multi-authority management, flexible key delegation mechanisms, and efficient revocation mechanisms. However, further optimization is still needed to meet the needs of scenarios such as the Internet of Things.

[0004] Therefore, a multi-organization attribute access control method that supports permission delegation and revocation is desired. Summary of the Invention

[0005] To address the above technical issues, this application proposes a multi-organization attribute access control method that supports permission delegation and revocation, which is used to improve the scalability of the CP-ABE system, increase the granularity of key delegation, and improve the granularity, efficiency, and security of revocation.

[0006] According to one aspect of the present application, a multi-institution attribute access control method that supports authority delegation and revocation is provided, which includes: S101, the central server initializes the system and registers the entity, the attribute agency generates an attribute key for the entity, and the group manager generates a group key; S102, the data owner generates a ciphertext according to the access policy and uploads it to the cloud server; S103, the data user initiates an access request, and the group manager verifies its capability list and forwards it to the central server; S104, the central server makes a decision based on the user attributes and policy, verifies the ciphertext update status and then authorizes access; S105, the group manager partially decrypts the ciphertext and sends it to the data user, and updates the capability list.

[0007] The multi-organization attribute access control method provided in this application supports permission delegation and revocation. Through a multi-organization collaborative management mechanism, it significantly reduces computational overhead while ensuring system security and revocation timeliness. Compared to traditional CP-ABE systems, this application supports more fine-grained key delegation capabilities, which can flexibly adapt to complex and changing access control requirements.

[0008] Preferably, key delegation includes: S201, the delegating party generates a delegation key and a conversion key based on the information of the delegate; S202, the delegation key is sent to the delegate, and the conversion key is sent to the group manager; S203, the group manager stores the control conditions of the conversion key in the capability list to limit the access rights of the delegate.

[0009] Preferably, revocation includes: S301, the central server receives the revocation request and broadcasts the update material; S302, the cloud server re-encrypts the ciphertext according to the update material; S303, the attribute agency and the group manager update the key and verify the revocation information in subsequent accesses to reject illegal requests.

[0010] According to one aspect of the present application, a multi-institution attribute access control system that supports authority delegation and revocation is also provided, including: a central server module, used for registration of system entities, release of update materials, ciphertext update check and verification; a data user module, used for accessing data from a cloud server after attribute verification, and supporting key delegation requests; a data owner module, used for generating ciphertext embedded with access policies and uploading it to a cloud server; an attribute institution module, used for separately managing key generation and revocation of different attributes; a cloud server module, used for storing encrypted data and performing ciphertext re-encryption based on the update materials of the central server; a group manager module, used for issuing group keys to group members, managing capability lists and performing partial decryption of ciphertexts.

[0011] Preferably, the central server module includes: an entity information management unit, which is used to review the registration requests of users and group managers, and manage the data and attribute information of users and group managers; an update material unit, which is used to broadcast version materials, attribute update materials, and user update materials; a verification unit, which is used to verify whether the cloud server updates the ciphertext in time and whether the user complies with the policy.

[0012] Preferably, the data user module includes: a ciphertext access request unit, which is used for the data user to request ciphertext access from the central server and obtain the ciphertext after verification; and a key delegation request unit, which is used for the data user to request key delegation from the data owner.

[0013] Preferably, the data owner module includes: a ciphertext upload unit, which is used by the data owner to generate a ciphertext embedded with an access policy and upload it to the cloud server; and a key delegation unit, which is used by the data owner to generate a delegation key according to the information required to be delegated.

[0014] Preferably, the attribute organization is a distributed architecture, in which specific attributes are independently managed by different management organizations, and there is no single point of dependence between the central server and the attribute organization. Specifically, it includes: an attribute key generation unit, which is used for multiple attribute organizations to be responsible for generating attribute keys for users; an attribute key update unit, which is used for attribute organizations to calculate updated attribute keys.

[0015] Preferably, the cloud server module includes: a data storage unit for storing encrypted data uploaded by the data owner; and a ciphertext re-encryption unit for re-encrypting the ciphertext according to the update material broadcast by the central server.

[0016] Preferably, the group manager module includes: a group key issuance unit, which is used by the group manager to issue group keys to group members; a ciphertext partial decryption unit, which is used to partially decrypt the ciphertext obtained from the cloud server and send it to the corresponding user; and a capability list management unit, which is responsible for storing, updating and managing the capability list to limit user access.

[0017] This invention addresses existing issues in existing CP-ABE systems and improves their scalability. It employs a multi-attribute authority (ABE) scheme, where multiple attribute authorities manage attribute key generation and revocation. It also improves the granularity of key delegation and designs a fine-grained key delegation scheme that supports flexible control of specific delegation content and permissions by the principal, as well as key delegation between user groups. It also improves the granularity, efficiency, and security of revocation. Public information is used to instruct the CSP to update encrypted data, and the AA uses broadcast communication to distribute updated attribute keys, enabling revocation at multiple granularities. A ciphertext verification scheme is proposed to address the unreliability of CSPs.

[0018] Specifically, the beneficial technical effects brought about by the present invention are:

[0019] Supporting multi-attribute organizations improves the stability and scalability of the IoT access control system, enabling it to better adapt to the needs of different scenarios.

[0020] A fine-grained key delegation system with a flexible management mechanism is designed to improve the usability of the access control system.

[0021] Compared with the traditional revocation mechanism, it reduces overhead while ensuring system security and timely revocation.

[0022] Compared with other CP-ABE systems, it provides more fine-grained key delegation and can meet more complex access control requirements. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] The above and other purposes, features, and advantages of the present application will become more apparent through a more detailed description of the embodiments of the present application in conjunction with the accompanying drawings. The accompanying drawings are intended to provide a further understanding of the embodiments of the present application and constitute a part of the specification. Together with the embodiments of the present application, they are used to explain the present application and do not constitute a limitation of the present application. In the drawings, the same reference numerals generally represent the same components or steps.

[0024] Figure 1 This is a flowchart of a multi-organization attribute access control method that supports authority delegation and revocation according to an embodiment of the present application.

[0025] Figure 2 This is a flowchart of key delegation in a multi-organization attribute access control method that supports authority delegation and revocation according to an embodiment of the present application.

[0026] Figure 3 This is a flowchart of revocation in a multi-organization attribute access control method that supports authority delegation and revocation according to an embodiment of the present application.

[0027] Figure 4 This is an architecture diagram of a multi-organization attribute access control system that supports authority delegation and revocation according to an embodiment of the present application.

[0028] Figure 5 A diagram of the system architecture for user access control according to an embodiment of the present application.

[0029] Figure 6 A diagram of the system architecture for user key delegation according to an embodiment of the present application.

[0030] Figure 7 This is a system architecture diagram for user revocation according to an embodiment of the present application. DETAILED DESCRIPTION

[0031] Various exemplary embodiments, features, and aspects of the present application will be described in detail below with reference to the accompanying drawings. The same reference numerals in the accompanying drawings represent elements with the same or similar functions. Although various aspects of the embodiments are shown in the accompanying drawings, the drawings are not necessarily drawn to scale unless otherwise indicated.

[0032] The word “exemplary” is used exclusively herein to mean “serving as an example, example, or illustration.” Any embodiment described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments.

[0033] In addition, numerous specific details are provided in the following detailed description to better illustrate the present application. Those skilled in the art will appreciate that the present application can be practiced without certain specific details. In some instances, methods, means, components, and circuits well known to those skilled in the art are not described in detail in order to highlight the main purpose of the present application.

[0034] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of the technical features being referred to. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of the features. Throughout the description of this application, "plurality" means two or more, unless otherwise specifically defined.

[0035] The existing CP-ABE key delegation scheme still has the following shortcomings:

[0036] Poor scalability. Most existing solutions issue and revoke attribute keys, which are highly centralized in nature. They suffer from the problem of authorization by a single attribute authority and cannot meet the development needs of practical applications. In addition, the different attributes in many application scenarios are caused by different environments. For example, the attribute of whether or not a person has a driver's license is managed by the traffic management department, while the attribute of computer science students is managed by the school.

[0037] Key delegation suffers from poor flexibility. The delegator may not wish to share the key associated with its complete attribute set with the delegatee, but instead desires greater flexibility in delegation implementation, allowing for the specification of the scope of delegation and subsequent restrictions. Existing solutions provide resource delegation in a more granular manner by assigning permissions to read, write, and update operations separately. However, this approach is complex to manage when multiple users require similar access rights. Existing solutions allow the delegator to access all resources, allowing the delegator with delegation attributes to access all rights on the resources. However, in reality, users prefer more flexibility in delegation.

[0038] Revocation is insufficiently granular and expensive. Revocation refers to the ability to revoke access rights and decryption capabilities granted to a user or entity. Revocation can be categorized as user revocation or attribute revocation. Attribute revocation is the most granular revocation method. Attributes can change frequently due to demand. When a user or entity has an attribute revoked, the corresponding access rights and decryption capabilities should be revoked promptly. Existing solutions implement revocation by updating the keys of all non-revoked users and re-encrypting the corresponding ciphertext. This complex operation incurs significant computational and communication overhead.

[0039] Therefore, this application aims to improve the scalability of the CP-ABE system. A multi-attribute agency ABE scheme is adopted, in which multiple attribute agencies manage the generation and revocation of attribute keys. The central server CA and the attribute agency AAs are responsible for issuing identity keys and attribute keys respectively. Solve the security and efficiency problems existing in the authorization of a single attribute agency, while improving the scalability of the system. Improve the granularity of key delegation. The key delegation mechanism can improve the flexibility and applicability of the CP-ABE scheme, and a more fine-grained key delegation scheme is designed. It not only supports the delegator's flexible control over specific delegation content and permissions, but also supports key delegation between user groups. When multiple users need to delegate, key delegation becomes simpler and more efficient. Improve the granularity, efficiency and security of revocation. In actual cloud storage scenarios, there are different requirements for revocation granularity, efficiency, and security. The CA uses public information to instruct the CSP to update encrypted data, and the AA can distribute the updated attribute keys through broadcast communication, which can realize revocation at the user, attribute, and group granularity. To address the problem of untimely ciphertext updates due to unreliable CSPs, a ciphertext verification scheme is proposed. The CA can verify the re-encrypted ciphertext, thereby effectively ensuring that the CSP can update the ciphertext in a timely manner.

[0040] Specifically, if Figure 1 As shown, Figure 1 The flowchart of the multi-institution attribute access control method supporting authority delegation and revocation according to the embodiment of the present application. According to the multi-institution attribute access control method supporting authority delegation and revocation according to the present application, more specifically, includes: S101, the central server initializes the system and registers the entity, each attribute institution generates corresponding attribute key information for the registered entity, and the group manager generates a group key based on the relevant information; S102, the data owner calculates the ciphertext according to the access policy, and then sends the ciphertext to the cloud server; S103, the data user initiates a data acquisition request, and the manager of the group to which the data user belongs first verifies the user's ability to access the data and whether the key is updated in time according to the capability list, and if so, continues to send it to the central server; S104, the central server receives the request message, and then makes a decision on the application based on the user attribute information and the access control policy; S105, if the verification and decision are passed, the central server obtains the ciphertext and checks whether the cloud server has updated the ciphertext in time, and if the check is passed, verifies the group revocation information, and if both verifications are passed, sends the ciphertext to the manager of the group to which the user belongs; S106, the group manager decrypts the ciphertext part and sends it to the corresponding user, and records the information in the capability list.

[0041] It should be noted that in IoT or cloud storage scenarios, the system must first complete an initialization process to register entities (such as users, devices, and groups) and assign keys to them. By assigning identity keys and attribute keys to a central server (CA) and multiple attribute authorities (AAs), respectively, this solution implements a distributed key management architecture, effectively avoiding the performance bottlenecks and single points of failure risks associated with a single authority. This improves system scalability while ensuring the security and efficiency of key generation and management. Data owners encrypt data according to access policies and send the ciphertext to the cloud server. This encryption method ensures that only users who meet the access policy can decrypt the data, protecting data confidentiality. This implements fine-grained access control and ensures secure data storage and sharing. When a data user initiates a request, the group manager first verifies the user's access rights and checks whether their key is up to date. This step avoids the central server from directly processing a large number of inefficient requests and leverages the group manager's local verification capabilities to improve system efficiency. This improves system responsiveness and efficiency while reducing the burden on the central server. The central server makes decisions based on the user's attribute information and access control policies. This step is the core security mechanism of the system, ensuring that only users who meet the policy can access the data. Implement fine-grained access control to ensure the security and policy consistency of the system. The central server verifies whether the cloud server has updated the ciphertext in a timely manner and checks the group revocation information. This step solves the problem that the cloud server may not update the ciphertext in a timely manner, and ensures that the revoked user or attribute cannot access the data. Improve the granularity and security of the revocation mechanism to ensure the dynamic and security of the system. The group manager partially decrypts the ciphertext before sending it to the user and records the relevant information in the capability list. This design utilizes the local processing power of the group manager and records the user's access behavior to facilitate subsequent auditing and management. Improve the flexibility and efficiency of the system while enhancing traceability. In order to solve the problems existing in the traditional CP-ABE system, such as insufficient scalability, poor flexibility of key delegation and low efficiency of the revocation mechanism. By introducing multi-attribute agency management, local verification and partial decryption mechanism of the group manager, and ciphertext verification of the cloud server, this process improves the system efficiency while enhancing the security and dynamics of the system.

[0042] Accordingly, according to one embodiment of the present invention, Figure 2 As shown, Figure 2This is a flowchart of key delegation in a multi-organization attribute access control method supporting authority delegation and revocation according to an embodiment of the present application. The key delegation in the multi-organization attribute access control method supporting authority delegation and revocation according to an embodiment of the present application includes: S201, when the delegating party needs to delegate part of the attribute key to the delegatee or a designated user group, a delegation key and a conversion key are generated based on the information of the delegatee or group; S202, the delegating party sends the delegation key to the corresponding delegatee and group manager, and sends the conversion key to the group manager; S203, after receiving the conversion key, the group manager stores the information in a capability list.

[0043] It's important to understand that the delegator wishes to delegate the decryption capabilities of some attribute keys to the delegatee or user group, but does not want to fully share its own private key to avoid security risks. Therefore, the delegator generates a delegation key and a transformation key based on the delegatee and group information to achieve fine-grained delegation control. By generating specific delegation keys and transformation keys, the delegation process is ensured to be secure and flexible, while also limiting the scope of the delegatee's permissions. The delegator needs to send the delegation key to the delegatee and the group manager so that the delegatee can use it for decryption operations. Simultaneously, the delegator sends the transformation key to the group manager for subsequent key management and updates. Proper delivery of the delegation key ensures that the delegatee can use the decryption capabilities as intended by the delegator. Management of the transformation key by the group manager improves system manageability and security. After receiving the transformation key, the group manager needs to store it in the capability list for subsequent key management and access control of the user group. This design allows the group manager to track and manage delegation relationships and permission changes among group members. By storing the transformation key in the capability list, the group manager can efficiently manage delegation relationships among group members and support flexible permission adjustment and revocation. By generating and managing delegation keys and conversion keys, a fine-grained key delegation mechanism is implemented, which not only meets the entrusting party's needs for permission control, but also improves the flexibility and security of the system.

[0044] Accordingly, according to one embodiment of the present invention, Figure 3 As shown, Figure 3 This is a flowchart of revocation in a multi-organization attribute access control method supporting authority delegation and revocation according to an embodiment of the present application. Revocation in a multi-organization attribute access control method supporting authority delegation and revocation according to an embodiment of the present application includes: S301, if it is necessary to revoke the access rights of an entity and revoke a certain attribute of the entity, a revocation message is generated and sent to a central server; S302, after the central server receives the message and verifies it, it broadcasts version update materials, user update materials, and attribute update materials; S303, the cloud server re-encrypts the ciphertext based on the update materials, and the attribute organization and group manager update the key based on the update materials.

[0045] It should be understood that when an entity's access rights or one of its attributes needs to be revoked, the system's central management organization (central server) must be notified to centrally manage and coordinate the revocation operation. This ensures the authority and systematic nature of the revocation operation, avoiding security risks associated with partial revocation. After verifying the legitimacy of the revocation request, the central server must broadcast the updated information (such as version updates, user updates, and attribute updates) to relevant parties (cloud servers, attribute organizations, group managers, etc.) for synchronized updates. This implements an efficient and fine-grained revocation mechanism, ensuring that the key and ciphertext states of all relevant parties in the system remain consistent while reducing the overhead of revocation operations. The cloud server re-encrypts the ciphertext based on the updated information, ensuring that users whose access rights have been revoked can no longer decrypt the relevant data. Simultaneously, the attribute organization and group managers update the keys based on the updated information, ensuring that users whose access rights have been revoked can still access the data. Through re-encryption and key updates, fine-grained attribute revocation is achieved, ensuring the security, flexibility, and dynamic nature of the system. Through unified management and coordination of revocation operations by a central server, combined with the ciphertext re-encryption of the cloud server and the key update mechanism of the attribute agency, fine-grained attribute revocation is achieved, solving the problems of coarse revocation granularity and high revocation overhead in the traditional CP-ABE scheme.

[0046] Furthermore, a multi-organization attribute access control system that supports authority delegation and revocation is Figure 4 As shown, the system consists of a central server, data users, data owners, an attribute agency, a cloud server, and a group manager. 1) The central server is responsible for registering system entities, publishing update materials, checking ciphertext updates, and preventing unauthorized decryption. 2) Data users can access data uploaded to the cloud server if their attributes meet the access policy. 3) Data owners generate ciphertext embedded with the access policy and upload it to the cloud server. 4) The attribute agency is responsible for generating attribute keys for users. 5) The cloud server, acting as storage, executes update operations after receiving update materials from the central server. 6) The group manager issues group keys to its group members, manages capability lists, partially decrypts ciphertexts, and performs key delegation checkpoints.

[0047] Specifically, in an embodiment of the present application, the central server module includes: an entity information management unit for reviewing registration requests from users and group managers and managing user and group manager data and attribute information; an update material unit for broadcasting version materials, attribute update materials, and user update materials; and a verification unit for verifying whether the cloud server has updated ciphertext in a timely manner and whether the user complies with the policy. It should be understood that as the central management node of the system, it ensures the overall security and consistency of the system. By publishing updated materials, an efficient revocation mechanism is implemented, reducing the overhead of revocation operations. Ciphertext updates are checked to ensure that the cloud server responds to revocation operations in a timely manner to prevent data leakage.

[0048] Specifically, in this embodiment of the present application, the data user module includes: a ciphertext access request unit, which is used by data users to request ciphertext access from a central server and obtain the ciphertext after verification; and a key delegation request unit, which is used by data users to request key delegation from the data owner. It should be understood that the access rights of data users are based on their attributes and access policies, ensuring fine-grained access control. Through the attribute-based encryption (CP-ABE) mechanism, data users do not need to interact directly with the data owner, which improves the flexibility of the system.

[0049] Specifically, in this embodiment of the present application, the data owner module includes: a ciphertext upload unit, which is used by the data owner to generate ciphertext embedded with an access policy and upload it to the cloud server; and a key delegation unit, which is used by the data owner to generate a delegation key based on the information required for delegation. It should be understood that the data owner controls access rights to the data through the ciphertext embedded with the access policy. Storing the ciphertext on the cloud server enables efficient data sharing while leveraging the storage and computing capabilities of the cloud server.

[0050] Specifically, in the embodiment of the present application, the attribute mechanism module includes: an attribute key generation unit, which is used by multiple attribute mechanisms to generate attribute keys for users; and an attribute key update unit, which is used by attribute mechanisms to calculate updated attribute keys. It should be understood that distributed management of attribute keys avoids bottlenecks caused by a single mechanism and improves system scalability. Attribute mechanisms can manage attributes according to different management domains (such as schools, transportation departments, etc.), adapting to complex real-world scenarios.

[0051] Specifically, in this embodiment of the present application, the cloud server module includes a data storage unit for storing encrypted data uploaded by the data owner; and a ciphertext re-encryption unit for re-encrypting the ciphertext based on updated data broadcast by the central server. It should be understood that leveraging the storage and computing capabilities of the cloud server enables efficient data storage and dynamic updates. Coordination by the central server ensures that the cloud server responds promptly to revocation operations, improving system security.

[0052] Specifically, in an embodiment of the present application, the group manager module includes: a group key issuance unit, used by the group manager to issue group keys to group members; a ciphertext partial decryption unit, used to partially decrypt ciphertext obtained from the cloud server and send it to the corresponding user; and a capability list management unit, responsible for storing, updating, and managing capability lists to restrict user access. It should be understood that local management achieved through the group manager reduces the burden on the central server and improves system efficiency. The partial decryption mechanism and capability list management enhance the flexibility and security of the system. Key delegation and revocation operations are supported to ensure the system's dynamic and adaptable nature.

[0053] Accordingly, in the first embodiment, access control based on multiple attribute mechanisms is performed. Figure 5 FIG. 1 shows a specific embodiment of user access control.

[0054] 1. User Alice, a department manager at a partner company, submits her personal information (name, contact information, etc.) and attribute information (Department: Development, Identity: Department Manager) to the central server via her mobile device (e.g., mobile phone). The central server collaborates with the attribute agency to complete the verification and registration process: the Development Department's attributes are verified by the company's Human Resources Department's attribute agency, while the department manager's identity is verified by the partner company's senior management department's attribute agency.

[0055] 2. User Alice uploads data collected by the company's IoT devices and sets access policies (e.g., Department: Development Department, Identity: Employee) to the cloud server.

[0056] 3. User Bob, an employee of the development department and a member of the IoT group, requests access to the company's IoT device data. The request first passes through his group manager. The group manager verifies in its capability list whether Bob has the ability to access the data and whether Bob has updated the key in a timely manner. If so, the request continues to be sent to the central server. Otherwise, the request fails.

[0057] 4. The central server receives Bob's request and makes a decision based on the access control policy to determine whether Bob and his team can obtain access to the company's IoT device data.

[0058] 5. After the decision is passed, the central server will check whether the data ciphertext in the cloud server is updated in time. If the check is passed, the ciphertext data will be sent to the manager of Bob's group.

[0059] 6. The group manager will initially decrypt the ciphertext and send it to Bob, and update the information record in the capability list.

[0060] Example 2: Fine-grained key delegation based on group management, such as Figure 6 FIG. 1 shows a specific embodiment of user key delegation.

[0061] 1. Continuing with Example 2, user Bob has access to the company's IoT device data. He now wants to grant all or part of the content and access rights (for example, the right to read some content) to user Jack or Jack's group (or Jack makes a delegation request to Bob). First, Bob obtains and verifies the identity information of Jack or the group.

[0062] 2. After verification, Bob generates a delegation key and a conversion key for Jack based on the information submitted by Jack. The delegation key indicates that Jack can access specified content with specified permissions (such as read-only camera device data) with Bob's delegation. The conversion key can indicate the access permission control information obtained by Jack (such as the number of times the data can be accessed). Bob sends the delegation key and the conversion key to the manager of Jack's group.

[0063] 3. The manager of Jack's group receives the delegation key and sends it to Jack, and stores the information on the converted key in the capability list. When Jack wants to access data, the access process is the same as in the first embodiment.

[0064] Example 3: Efficient and fine-grained revocation based on broadcast, such as Figure 7 FIG. 2 shows a specific embodiment of user revocation.

[0065] 1. Continuing from Example 2, revocation can be categorized into three types: user attribute revocation, user revocation, and group revocation. In attribute revocation, a revoked user loses only one or more attributes; as long as their remaining attributes satisfy the access policy, they can continue to access data. In user revocation, the user is deleted from the system, meaning they cannot access any data. In group revocation, the group is deleted from the system, meaning all members of the group cannot access any data.

[0066] 2. To revoke user Jack's attributes, a revocation message is sent to the central server. After receiving and verifying the message, the central server broadcasts the version and attribute update materials. The cloud server then updates the ciphertext based on the updated materials. The corresponding attribute mechanism generates an attribute update key based on the updated materials and sends it to the corresponding user or group. The corresponding user uses the attribute update key and the original key to generate an update key. When the user requests access to the ciphertext, the central server verifies the revocation information in the ciphertext. If the attributes required by the user to access the ciphertext are included in the revocation information, the access fails.

[0067] 3. If you want to revoke a user or group, send a revocation message to the central server. After the central server receives the message and verifies it, it broadcasts the version update materials and user update materials. The cloud server updates the ciphertext based on the updated materials. When the user / group requests access to the ciphertext, the central server verifies the revocation information in the ciphertext. If the user / group is in the revocation information, the access fails.

[0068] While various embodiments of the present disclosure have been described above, the above descriptions are illustrative, non-exhaustive, and not intended to be limiting of the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is selected to best explain the principles of the embodiments, their practical applications, or improvements to existing technologies, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. A multi-organization attribute access control method supporting authority delegation and revocation, characterized in that: include: S101, the central server initializes the system and registers the entity, the attribute agency generates an attribute key for the entity, and the group manager generates a group key; S102, the data owner generates ciphertext according to the access policy and uploads it to the cloud server; S103: The data user initiates an access request, and the group manager verifies its capability list and forwards it to the central server; S104: The central server makes a decision based on user attributes and policies, verifies the ciphertext update status, and then authorizes access; S105: The group manager partially decrypts the ciphertext and sends it to the data user, and updates the capability list.

2. The multi-organization attribute access control method supporting authority delegation and revocation according to claim 1 is characterized in that: Key delegation includes: S201, the entrusting party generates a delegation key and a conversion key based on the entrustee's information; S202, the delegation key is sent to the delegate, and the conversion key is sent to the group manager; S203: The group manager stores the control conditions for converting the key into a capability list to limit the access rights of the delegate.

3. The multi-organization attribute access control method supporting authority delegation and revocation according to claim 2 is characterized in that: Revocation includes: S301, the central server receives the revocation request and broadcasts the update material; S302, the cloud server re-encrypts the ciphertext based on the updated material; S303: The attribute authority and the group manager update the key and verify the revocation information in subsequent accesses to reject illegal requests.

4. A multi-organization attribute access control system that supports authority delegation and revocation, characterized in that: include: The central server module is used for registration of system entities, release of update materials, and ciphertext update checking and verification; The data consumer module is used to access data from the cloud server after attribute verification and supports key delegation requests; The data owner module is used to generate ciphertext embedded with access policies and upload it to the cloud server; Attribute mechanism module, used to manage the generation and revocation of keys for different attributes respectively; A cloud server module, used to store encrypted data and perform ciphertext re-encryption based on updated materials from the central server; The group manager module is used to issue group keys to group members, manage capability lists, and perform partial decryption of ciphertext.

5. The multi-organization attribute access control system supporting authority delegation and revocation according to claim 4 is characterized in that: The central server module includes: Entity information management unit, used to review registration requests from users and group managers, and manage user and group manager profiles and attribute information; Update material unit, used for broadcasting version materials, attribute update materials, and user update materials; The verification unit is used to verify whether the cloud server updates the ciphertext in a timely manner and whether the user complies with the policy.

6. The multi-organization attribute access control system supporting authority delegation and revocation according to claim 5 is characterized in that: The data user module includes: The ciphertext access request unit is used by data users to request ciphertext access from the central server and obtain the ciphertext after verification; The key delegation request unit is used for the data user to request key delegation from the data owner.

7. The multi-organization attribute access control system supporting authority delegation and revocation according to claim 6 is characterized in that: The data owner module includes: The ciphertext upload unit is used by the data owner to generate ciphertext embedded with access policy and upload it to the cloud server; The key delegation unit is used by the data owner to generate a delegation key based on the information required to be delegated.

8. The multi-organization attribute access control system supporting authority delegation and revocation according to claim 7 is characterized in that: The attribute organization is a distributed architecture, with different management organizations independently managing specific attributes, and there is no single point of dependency between the central server and the attribute organization. Specifically, Generate attribute key unit, used by multiple attribute agencies to generate attribute keys for users; The attribute key update unit is used by the attribute mechanism to calculate the updated attribute key.

9. The multi-organization attribute access control system supporting authority delegation and revocation according to claim 8, characterized in that: The cloud server module includes: A data storage unit, used to store encrypted data uploaded by the data owner; The ciphertext re-encryption unit is used to re-encrypt the ciphertext according to the update material broadcast by the central server.

10. The multi-organization attribute access control system supporting authority delegation and revocation according to claim 9, characterized in that: The group manager module includes: A group key issuing unit, used by the group manager to issue group keys to group members; A ciphertext partial decryption unit, used to partially decrypt the ciphertext obtained from the cloud server and send it to the corresponding user; The capability list management unit is responsible for storing, updating and managing the capability list to limit user access.

Images