File security sharing method, sharing scene processing method and related products

Abstract

The application discloses a file security sharing method, a sharing scene processing method and related products, relates to the technical field of data security, and constructs a file security sharing scheme suitable for multiple roles by combining cloud key technology. The scheme mainly comprises that a creator has the ownership of a sharing scene, the creator authorizes one or more different publishers to sign a third authorization for a subscriber and / or publish a file in a sharing point by giving the publishers the use right of a first cloud key for signing the third authorization for the subscriber and the use right of a second cloud key for publishing the file in the sharing point. The scheme is suitable for application scenes containing multiple roles, can perform more flexible and fine permission management on the multiple roles, improves the management ability and management efficiency of a file owner and other possible roles on the shared file, and improves the security and controllability of the shared file.

Description

Technical Field

[0001] This application relates to the field of data security technology, and in particular to a method for secure file sharing and a method for handling sharing scenarios. Furthermore, this application also relates to a server-side system, a client, a computer-readable storage medium, and a computer program product. Background Technology

[0002] Traditional file-sharing technologies involve relatively simple user roles. For example, in some cloud storage products, if user U1 wants to share a file with user U2, the process typically involves: user U1 encrypting the file to be shared using a key and uploading it to the cloud storage, then sending a sharing link to user U2; user U2 then retrieves the encrypted file from the cloud storage via the sharing link, and receives or separately receives the decryption key to decrypt the file, thus obtaining the plaintext version, which can then be viewed, edited, and performed other operations.

[0003] In this scheme, once user U1 shares a file, it is difficult for them to control the behavior of user U2, making it hard to ensure that the file is only shared with the intended user and not with other users. The security of the shared file is also difficult to guarantee. In other words, the file owner has relatively weak control over the shared file.

[0004] Furthermore, the inventors discovered that in some file-sharing applications, the user roles involved are more complex and diverse. In such cases, traditional file-sharing technologies cannot meet the need for more granular control over multiple roles. Summary of the Invention

[0005] One objective of this application is to provide a file sharing solution that, while ensuring that files are securely shared with designated users, also meets the needs of multiple roles for flexible and granular control over files, thereby improving the ability to manage shared files.

[0006] The first aspect of this application provides a secure file sharing method, characterized in that a service side creates a sharing scenario belonging to a creator, the sharing scenario including a first sharing point in which file publishing is permitted; the service side stores at least a first cloud key and a third cloud key; wherein the first cloud key corresponds to the sharing scenario and belongs to the creator; the third cloud key corresponds to the first sharing point, and the authorization issuance of the third cloud key is controlled by the first cloud key; the method includes: the service side receiving a first request from a first publisher, the first request being used to request the issuance of authorization for a specified subscriber, wherein the first publisher possesses a first authorization, the first authorization indicating that the first publisher is allowed to invoke the first cloud key of the service side; the service side responding to the first request, based on the first authorization, invoking the first cloud key to issue a third authorization for the subscriber, so that the subscriber has permission to open files published in the first sharing point; wherein the third authorization indicates that the subscriber is allowed to invoke the third cloud key of the service side.

[0007] In conjunction with the first aspect, in one possible implementation, the third cloud key is used to encrypt a fourth key to obtain a fourth key ciphertext, the fourth key being used to encrypt a file published in the first sharing point.

[0008] In conjunction with the first aspect, in one possible implementation, the service side further stores a second cloud key, which corresponds to the sharing scenario and belongs to the creator. The second cloud key is allowed to access the third cloud key for at least decryption. The method includes: the service side receiving a second request from a second publisher, the second request requesting the publication of a first file to be published to the first sharing point, wherein the second publisher has a second authorization, which allows the second publisher to call the second cloud key of the service side; the service side responding to the second request, based on the second authorization, accessing the third cloud key through the second cloud key, using the third cloud key to decrypt the fourth key ciphertext to obtain the fourth key; the service side storing the first file ciphertext in the first sharing point, the first file ciphertext being obtained by encrypting the first file with the fourth key; wherein the second publisher and the first publisher are the same or different users.

[0009] In conjunction with the first aspect, in one possible implementation, the service side includes a server and a cloud key management system, wherein the first cloud key, the second cloud key, and the third cloud key are stored in the key management system;

[0010] Before the step of storing the first file ciphertext in the first sharing point, the method further includes: the cloud key management system returning the decrypted fourth key to the second publisher; and the server receiving the first file ciphertext from the second publisher.

[0011] In conjunction with the first aspect, in one possible implementation, the method further includes: the server receiving a third request from the subscriber, the third request being for requesting to open a specified second file, the second file being any file in the first sharing point; the server responding to the third request, based on the third authorization possessed by the subscriber, calling the third cloud key to decrypt the fourth key ciphertext to obtain a fourth key, the fourth key being able to be used to decrypt the second file ciphertext to allow the subscriber to open the second file.

[0012] In conjunction with the first aspect, in one possible implementation, the service side includes a server and a cloud key management system, and the method includes: the server sending the second file ciphertext to the subscriber; the cloud key management system sending the decrypted fourth key to the subscriber, so that the subscriber can use the fourth key to decrypt the second file ciphertext, obtain and open the second file.

[0013] In conjunction with the first aspect, in one possible implementation, the method further includes: the service side receiving an eighth request from the first publisher or creator, the eighth request being used to request the deletion of the subscriber; and the service side revoking the third authorization.

[0014] In conjunction with the first aspect, in one possible implementation, the method further includes: the service side receiving a ninth request from the creator, the ninth request being for requesting the deletion of the first publisher and / or the second publisher; the service side revoking the first authorization and / or the second authorization.

[0015] In conjunction with the first aspect, in one possible implementation, the service side also stores a fifth cloud key corresponding to the sharing scenario, wherein the first cloud key and the second cloud key belong to the fifth cloud key, and the fifth cloud key belongs to the creator.

[0016] In conjunction with the first aspect, in one possible implementation, the method further includes: the service side receiving a seventh request from the creator, the seventh request being used to request a change of the owner of the sharing scenario to a new owner; the service side modifying the fifth cloud key to belong to the new owner.

[0017] In conjunction with the first aspect, in one possible implementation, the method further includes: the service side receiving a fourth request, the fourth request being used to request the creation of a sharing scenario for the creator; the service side responding to the fourth request by creating a sharing scenario for the creator; and the service side generating a first cloud key and a second cloud key corresponding to the sharing scenario.

[0018] In conjunction with the first aspect, in one possible implementation, the method further includes: the server receiving a fifth request from the creator, the fifth request being used to request authorization of the use rights of the first cloud key and / or the second cloud key to a designated user; the server responding to the fifth request issuing a corresponding authorization for the designated user, the authorization indicating that the designated user is allowed to invoke the first cloud key and / or the second cloud key of the server.

[0019] In conjunction with the first aspect, in one possible implementation, the method further includes: the service side issuing a self-authorization to the creator, the self-authorization indicating that the creator is allowed to invoke the first cloud key and / or the second cloud key.

[0020] In conjunction with the first aspect, in one possible implementation, the method further includes: the service side receiving a sixth request from a second publisher or creator, the sixth request being used to request the creation of a sharing point in a sharing scenario; the service side responding to the sixth request and creating a first sharing point in the sharing scenario; the service side generating a third cloud key corresponding to the first sharing point; and the service side using the third cloud key to encrypt a fourth key to obtain the fourth key ciphertext.

[0021] In conjunction with the first aspect, in one possible implementation, the service side includes a server and a cloud key management system, and the method includes: the server receiving a sixth request from a second publisher or creator, the sixth request being used to request the creation of a sharing point in a sharing scenario; the server responding to the sixth request and creating a first sharing point in the sharing scenario; the cloud key management system generating a third cloud key corresponding to the first sharing point; the cloud key management system receiving a fourth key from the second publisher or creator; the cloud key management system encrypting the fourth key using the third cloud key to obtain a fourth key ciphertext; and the server storing the fourth key ciphertext.

[0022] A second aspect of this application provides a secure file sharing method, comprising: a client obtaining description information of a first sharing point in a sharing scenario managed by a first publisher from a service side; wherein the sharing scenario is created by the service side and belongs to the creator; the sharing scenario has a corresponding first cloud key, the first cloud key being stored on the service side and belonging to the creator; the first publisher possesses a first authorization, the first authorization indicating that the first publisher is allowed to invoke the first cloud key; file publishing is permitted in the first sharing point; the client, in response to a first operation by the first publisher on the first sharing point, generates a first request, wherein the first operation includes an operation specifying a subscriber, the first request being used to request the issuance of an authorization for the specified subscriber; the client sends the first request to the service side, causing the service side, in response to the first request, to invoke the first cloud key based on the first authorization to issue a third authorization for the subscriber; wherein the third authorization grants the subscriber permission to open files in the first sharing point.

[0023] In conjunction with the second aspect, in one possible implementation, the method further includes: the client responding to the first publisher's eighth operation regarding the third authorization by generating an eighth request; the client sending the eighth request to the service side, so that the service side responding to the eighth request by revoking the third authorization based on the first authorization.

[0024] In conjunction with the second aspect, in one possible implementation, the first publisher also possesses a second authorization, which indicates that the first publisher is permitted to invoke a second cloud key on the service side; the second cloud key corresponds to the sharing scenario and belongs to the creator; the method further includes: the client responding to the second publisher's second operation on the first sharing point by generating a second request, wherein the second request is used to request that the first file to be published be published to the first sharing point; the client sending the second request to the service side, so that the service side responds to the second request and, based on the second authorization, stores the encrypted first file in the first sharing point, wherein the encrypted first file is obtained by encrypting the first file.

[0025] A third aspect of this application provides a secure file sharing method, comprising: a client obtaining description information of a first sharing point in a sharing scenario managed by a second publisher from a service side; wherein the sharing scenario is created by the service side and belongs to the creator; the sharing scenario has a corresponding second cloud key, the second cloud key being stored on the service side and belonging to the creator; the second publisher possesses a second authorization, the second authorization indicating permission for the second publisher to invoke the second cloud key; file publishing is permitted in the first sharing point; the client, in response to a second operation by the second publisher on the first sharing point, generates a second request, wherein the second request is used to request the publishing of a first file to be published to the first sharing point; the client sends the second request to the service side, causing the service side, in response to the second request, to store encrypted first file text in the first sharing point based on the second authorization; wherein the encrypted first file text is obtained by encrypting the first file.

[0026] In conjunction with the third aspect, in one possible implementation, before the step of the client obtaining the description information of the first sharing point in the sharing scenario managed by the second publisher from the service side, the method further includes: the client obtaining the description information of the sharing scenario managed by the second publisher from the service side; the client generating a sixth request in response to a sixth operation of the second publisher for the sharing scenario, wherein the sixth request is used to request the creation of a sharing point in the sharing scenario; the client sending the sixth request to the service side, so that the service side responds to the sixth request and creates the first sharing point in the sharing scenario; wherein the first sharing point has a corresponding third cloud key, the third cloud key is used to encrypt a fourth key, the fourth key is used to encrypt files published in the first sharing point, and the third cloud key is allowed to be accessed by the second cloud key for at least decryption.

[0027] In conjunction with the third aspect, in one possible implementation, the service side includes a server and a cloud key management system, and the method further includes: a client receiving a fourth key from the cloud key management system; wherein the cloud key management system stores a second cloud key and a third cloud key, and the fourth key is obtained by the cloud key management system based on the second authorization, accessing the third cloud key through the second cloud key, and decrypting the fourth key ciphertext using the third cloud key; the client encrypting a first file to be published using the fourth key to obtain the first file ciphertext; and the client sending the first file ciphertext to the server on the service side.

[0028] A fourth aspect of this application provides a secure file sharing method, characterized by comprising: a client obtaining description information of a first sharing point from a server side, to which the subscriber has opening permissions; wherein the first sharing point has a corresponding third cloud key, the third cloud key being stored on the server side, and the first sharing point allowing the publication of files encrypted with a fourth key; the subscriber possessing a third authorization, the third authorization indicating permission for the subscriber to invoke the third cloud key; the client, in response to the subscriber's third operation on a second file in the first sharing point, generating a third request, the third request being used to request opening a specified second file, the second file being any file in the first sharing point; sending the third request to the server side, so that the server side, in response to the third request, based on the third authorization, invokes the third cloud key to decrypt the fourth key ciphertext, obtaining a fourth key, the fourth key being usable for decrypting the second file ciphertext; and the client opening the second file.

[0029] In conjunction with the fourth aspect, in one possible implementation, the service side includes a server and a cloud key management system, and the method further includes: a client receiving a fourth key from the cloud key management system; wherein the cloud key management system stores the third cloud key, and the fourth key is obtained by the cloud key management system decrypting the fourth key ciphertext using the third cloud key based on the third authorization; the client receiving the second file ciphertext from the server; and the client using the fourth key to decrypt the second file ciphertext to obtain the second file.

[0030] The fifth aspect of this application provides a method for processing a sharing scenario for secure file sharing, comprising: a client responding to a fourth operation by sending a fourth request to a server, the fourth request being used to request the creation of a sharing scenario for the creator; the client receiving from the server description information of the sharing scenario created for the creator, as well as description information of a first cloud key and a second cloud key, wherein the sharing scenario allows the creation of at least one sharing point, and the sharing point allows file publishing; the first cloud key and the second cloud key correspond to the sharing scenario respectively, both belong to the creator, and are stored on the server; the client responding to the creator's fifth operation by generating a fifth request, wherein the fifth operation includes an operation to specify at least one publisher; the fifth request being used to request authorization of the use rights of the first cloud key and / or the second cloud key to the at least one publisher; the client sending the fifth request to the server to enable the server to issue a corresponding authorization for the at least one publisher, the authorization indicating that the at least one publisher is allowed to call the first cloud key and / or the second cloud key of the server, so that the at least one publisher can issue authorizations for subscribers of the sharing point and / or publish files in the sharing point.

[0031] In conjunction with the fifth aspect, in one possible implementation, the method further includes: a client responding to a sixth operation by the creator for the sharing scenario, generating a sixth request, wherein the sixth request is used to request the creation of a sharing point in the sharing scenario; the client sending the sixth request to the service side, causing the service side to respond to the sixth request and create a first sharing point in the sharing scenario; wherein the first sharing point has a corresponding third cloud key, the third cloud key is used to encrypt a fourth key, the fourth key is used to encrypt files published in the first sharing point, and the third cloud key is accessible by a second cloud key for at least decryption.

[0032] In conjunction with the fifth aspect, in one possible implementation, the method further includes: the client generating an eighth request in response to the creator's eighth operation regarding the authorization held by the subscriber; the client sending the eighth request to the service side to cause the service side to revoke the authorization held by the subscriber;

[0033] In conjunction with the fifth aspect, in one possible implementation, the method further includes: the client responding to the creator's ninth operation on the publisher by generating a ninth request, the ninth request being used to request the deletion of the publisher; the client sending the ninth request to the service side so that the service side revokes the authorization held by the publisher.

[0034] In conjunction with the fifth aspect, in one possible implementation, the service side further stores a fifth cloud key corresponding to the sharing scenario, the first cloud key and the second cloud key belong to the fifth cloud key, and the fifth cloud key belongs to the creator. The method further includes: the client responding to the creator's seventh operation for the sharing scenario by generating a seventh request, wherein the seventh request is used to request a change of the owner of the sharing scenario to a new owner; the client sending the seventh request to the service side so that the service side modifies the fifth cloud key to belong to the new owner.

[0035] The sixth aspect of this application provides a method for processing a sharing scenario for secure file sharing, comprising: a server receiving a fourth request, the fourth request being used to request the creation of a sharing scenario for a creator; the server responding to the fourth request by creating a sharing scenario for the creator; and the server generating a first cloud key and a second cloud key corresponding to the sharing scenario.

[0036] In conjunction with the sixth aspect, in one possible implementation, the method further includes: the service side sending a description of the sharing scenario, as well as descriptions of the first cloud key and the second cloud key, to the client.

[0037] In conjunction with the sixth aspect, in one possible implementation, the method further includes: the service side issuing a self-authorization to the creator, the self-authorization indicating that the creator is allowed to invoke the first cloud key and / or the second cloud key.

[0038] In conjunction with the sixth aspect, in one possible implementation, the method further includes: the service side receiving a fifth request from the creator, the fifth request being used to request authorization of the use rights of the first cloud key and / or the second cloud key to a designated user; the service side responding to the fifth request issuing a corresponding authorization for the designated user, the authorization indicating that the designated user is allowed to invoke the first cloud key and / or the second cloud key of the service side.

[0039] In conjunction with the sixth aspect, in one possible implementation, the method includes: the service side receiving a sixth request from a second publisher or creator, the sixth request being used to request the creation of a sharing point in a sharing scenario; the service side responding to the sixth request and creating a first sharing point in the sharing scenario; the service side generating a third cloud key corresponding to the first sharing point; and the service side using the third cloud key to encrypt a fourth key to obtain a fourth key ciphertext.

[0040] In conjunction with the sixth aspect, in one possible implementation, the service side includes a server and a cloud key management system. The method includes: the server receiving a sixth request from a creator, the sixth request being used to request the creation of a sharing point in a sharing scenario; the server responding to the sixth request and creating a first sharing point in the sharing scenario; the cloud key management system generating a third cloud key corresponding to the first sharing point; the cloud key management system receiving a fourth key from a second publisher or creator; the cloud key management system encrypting the fourth key using the third cloud key to obtain a fourth key ciphertext; and the server storing the fourth key ciphertext.

[0041] In conjunction with the sixth aspect, in one possible implementation, the method further includes: the service side receiving a ninth request from the creator, the ninth request being used to request the deletion of a specified publisher; the service side revoking the publisher's authorization regarding the first cloud key and / or the second cloud key.

[0042] In conjunction with the sixth aspect, in one possible implementation, the method further includes: the service side receiving a seventh request from the creator, the seventh request being used to request a change of the owner of the sharing scenario to a new owner; the service side modifying the first cloud key and the second cloud key to belong to the new owner.

[0043] In conjunction with the sixth aspect, in one possible implementation, the service side further stores a fifth cloud key corresponding to the sharing scenario, wherein the first cloud key and the second cloud key belong to the fifth cloud key, and the fifth cloud key belongs to the creator; the method further includes: the service side receiving a seventh request from the creator, the seventh request being used to request a change of the owner of the sharing scenario to a new owner; the service side modifying the fifth cloud key to belong to the new owner.

[0044] A seventh aspect of this application provides a server-side system, comprising: a storage unit configured to store predetermined computer instructions; and a processing unit configured to execute the predetermined computer instructions to implement any of the possible methods of the first aspect.

[0045] An eighth aspect of this application provides a client comprising: a storage unit configured to store predetermined computer instructions; and a processing unit configured to execute the predetermined computer instructions to implement any one of the possible methods of the second, third, fourth, or fifth aspect.

[0046] The ninth aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, causes the processor to perform any one of the methods of the first aspect, the second aspect, the third aspect, the fourth aspect, or the fifth aspect.

[0047] The tenth aspect of this application provides a computer program product, including a computer program that, when run, causes a computer to perform any one of the methods of the first aspect, the second aspect, the third aspect, the fourth aspect, or the fifth aspect. Attached Figure Description

[0048] Figure 1 This is a schematic diagram of the system architecture for an exemplary application scenario of this application.

[0049] Figure 2 This is a schematic diagram of the system architecture for another exemplary application scenario of this application.

[0050] Figure 3 This is a flowchart illustrating an exemplary method for processing a file sharing scenario for secure sharing, provided as an embodiment of this application.

[0051] Figure 4 This is an exemplary flowchart illustrating the process of creating a shared point in a new sharing scenario, provided as an embodiment of this application.

[0052] Figure 5 This is a flowchart illustrating an exemplary secure file sharing method provided in an embodiment of this application.

[0053] Figure 6 This is a flowchart illustrating another exemplary file secure sharing method provided in an embodiment of this application. Detailed Implementation

[0054] To clearly and completely describe the technical solution of this application, further explanation will be provided below in conjunction with embodiments and accompanying drawings.

[0055] As mentioned earlier, the user roles involved in some file-sharing applications can be more complex and diverse, going beyond just the sharer (user A) and recipient (user B) in the previous example. For instance, in some cases, the file owner may not have the time to share with different users and manage the shared files, and instead wants to delegate some permissions to others (such as user C) to share and manage them on their behalf. In this scenario, at least three user roles are involved. User A needs to grant user C sufficient permissions to share and manage the shared files, while also retaining control over users C and B. In other, more complex applications, there may be more than three user roles. Traditional file-sharing technologies cannot meet the need for fine-grained management of multiple roles.

[0056] Cloud key technology, previously developed by the applicant, primarily refers to storing keys on the server side (rather than on the terminal side) and managing key usage to improve key security without affecting key usage. This application's secure file sharing solution introduces cloud key technology to enhance file sharing security. Furthermore, considering multi-role application scenarios, it is further optimized to construct a multi-role-based secure file sharing architecture and implementation scheme. This scheme is not only suitable for application scenarios involving multiple roles but also allows for more flexible and granular permission management for multiple roles, improving the control and management efficiency of shared files by file owners and other potential roles, thereby enhancing the security and controllability of shared files.

[0057] To facilitate understanding, the following will first introduce an exemplary application scenario architecture diagram of the file sharing method of this application, and then introduce the steps performed by each interactive terminal in the file sharing scheme in the application scenario.

[0058] See Figure 1 and Figure 2 This application scenario can include both the client and the server side.

[0059] The client in this application embodiment can take the form of an app, mini-program, web page, desktop client, etc., and can be installed, set up, or embedded on a terminal. The terminal can include, but is not limited to, terminal devices such as mobile phones, tablets, personal computers (PCs), wearable devices, Internet of Things devices, vehicle networking devices, augmented reality (AR) / virtual reality (VR) devices, personal digital assistants (PDAs), etc. This application does not limit the specific product form / type of the client and terminal.

[0060] Since users in the application scenario may have multiple roles, for ease of description and differentiation, in this application embodiment, the user who owns the file, that is, the owner of the file, is called the creator; the user who publishes the file is called the second publisher; the user who shares the file with specific subscribers is called the first publisher; and the user whose file is shared is called the subscriber.

[0061] It should be noted that the second publisher and the first publisher can be the same user or different users. In some cases, the second publisher and the first publisher are the same user, meaning the same user publishes the file and shares it with specific subscribers; this user can also be called the publisher. Figure 1 As shown. For ease of description and distinction, the client used by the creator in this scenario is called the first client, the client used by the publisher is called the second client, and the client used by the subscriber is called the third client. In some cases, the second publisher and the first publisher are different users; in this case, their respective clients can be second client B and second client A, as shown. Figure 2 As shown.

[0062] Understandably, in some cases, the creator can publish files and / or share them with specific subscribers, in which case the creator, the second publisher, and / or the first publisher can be the same user. In this scenario, the creator's first client can correspondingly execute the steps performed by the first client and the second client B and / or the second client A.

[0063] It is also understandable that, in addition to the user roles and clients mentioned above, other roles and corresponding clients may be involved in some application scenarios, and this application does not limit them.

[0064] In this application embodiment, the service side can establish a communication connection with the client to provide services to the client. The service side can be located on an independent physical server, or in a server cluster or distributed system composed of multiple physical servers. It can also be located on a cloud server or cloud computing service center that provides services such as cloud services, cloud databases, cloud computing, cloud storage, network services, cloud communication, middleware services, security services, content distribution services, big data and artificial intelligence platforms. This application does not limit the specific product form and deployment method of the service side.

[0065] In some possible implementations, the service side may include a server and a cloud key management system, such as... Figure 2 As shown.

[0066] The server primarily provides business services to the client. For example, in a software product with data asset sharing capabilities, the client can be developed as an app for users to download and use, while the server provides business services to the client to enable user registration, login, creation and / or management of user data asset repositories, as well as app functions such as file uploading, downloading, and sharing. Different users can register and log in on the server through the client, and then use the various business functions in the client according to their needs. Optionally, the server can be divided according to business functions, etc., as necessary. For example, the server may include an authentication service module, a user service module, etc.

[0067] The cloud key management system is mainly used to provide services such as cloud key generation, storage, authorization, and usage management for clients and servers.

[0068] It is understood that the server can establish a communication connection with the cloud key management system. The client can establish a communication connection with the server to interact, and interact with the cloud key management system through the server; the client can also establish communication connections with both the server and the cloud key management system separately and interact separately, which is not limited in this application.

[0069] For example, in order to invoke services provided by the cloud key management system, the server can first register in the cloud key management system using a server key that identifies itself, and store the public key of the server key in the cloud key management system. Then, the server uses the private key of the server key to issue a ticket to the client user. The ticket may contain the user's ID and other identity information in the cloud key management system, and the server returns the ticket to the client. In this way, when the client needs to interact with the cloud key management system, it can include the aforementioned ticket in the interaction information if necessary, so that the cloud key management system can identify and verify which server the client corresponds to, and generate and return a user token. In the following period, if the client needs to invoke some functional services in the cloud key management system or request the cloud key management system to perform some operations, it can include the user token so that the cloud key management system can provide the necessary services.

[0070] Each user, including creators, publishers, and subscribers, can possess their own personal key to identify themselves and allow other interacting parties to verify their identity and permissions. A personal key can be an asymmetric key pair, consisting of a public key and a private key. Before use, the public key of the personal key can be sent to the server for registration.

[0071] For example, with Figure 2 Taking the system described above as an example, after a user logs into the server using a client, when registering their personal key in the cloud key management system, the client can generate a pair of asymmetric keys locally as the user's personal key. Then, the client includes the public key from the user's personal key and the aforementioned user token in the interaction information, so that the cloud key management system can register the public key of the user's personal key and return the corresponding personal key identifier (keyLabel) to the client. This personal key identifier can, for example, be a string processed by the cloud key management system and signed with its private key. Subsequently, during interactions between the client and the cloud key management system, if necessary, the client can include this personal key identifier in the interaction information to identify itself and facilitate verification by the cloud key management system.

[0072] The following example illustrates the process of (i) creating a sharing scenario, (ii) the creator authorizing the publisher, (iii) creating a shared point within the sharing scenario, (iv) the second publisher publishing a file in the shared point, (v) the first publisher authorizing the subscriber, (vi) the subscriber viewing the file in the shared point, (vii) revoking authorization, and (viii) the creator changing the owner of the sharing scenario. It should be noted that the above sequence numbers do not define the order in which these processes and their steps are executed; their execution order is determined by the internal logic of the scheme.

[0073] (I) Creating a sharing scenario

[0074] See Figure 3 , Figure 3 This is a flowchart illustrating an exemplary method for processing a file sharing scenario for secure sharing, provided as an embodiment of this application.

[0075] S101, the first client responds to the fourth operation by sending a fourth request to the server.

[0076] S102, the server responds to the fourth request by creating a sharing scenario for the creator.

[0077] When a creator wants to create a shared scene, they can perform an operation on the first client (referred to as the fourth operation in this embodiment for easy distinction), such as clicking the "Add Scene" control displayed on the client interface of the first client. In response to this operation by the creator, the first client sends a fourth request to the server.

[0078] It should be noted that the operations performed by the user on the client in the embodiments of this application (such as the fourth operation here, and the first to ninth operations below, etc.) may include one operation step or multiple operation steps, and this application does not limit them.

[0079] The fourth request is used to request the creation of a sharing scenario for the creator. In some possible implementations, the fourth request may include the creator's identity information. The creator's identity information may, for example, include one or more pieces of information such as the creator's account registered on the server side or server side, the creator's name, and the creator's personal key identifier, which can uniquely identify the creator's identity, either individually or in combination.

[0080] In some possible implementations, the server establishes a sharing scenario, assigns a scenario ID to the sharing scenario to uniquely identify the scenario, and associates the scenario ID with the creator's identity information (such as the creator's account registered on the server, the creator's personal key identifier, etc.). In other words, the owner information of the sharing scenario is configured as the creator's identity information, thereby granting ownership of the sharing scenario to the creator.

[0081] In some possible implementations, the fourth request may also include other information, such as the name of the sharing scenario. This allows the service to name the created sharing scenario using the name carried in the fourth request, enabling users to easily define their own sharing scenario names.

[0082] As mentioned earlier, each user has their own personal key. When sending a request to the server, the client can use the private key of the corresponding user's personal key to sign some important information in the request, and then send the signature along with the request to the server. Upon receiving the request, the server can first verify the signature carried in the request using the public key of the user's personal key. If the verification passes, it can be assumed that the request was indeed initiated by that user, and that the signed information in the request has not been tampered with. The server then proceeds with the other steps required to respond to the request.

[0083] For example, the creator has their own personal key. The first client can use the private key from the creator's personal key to sign certain information in the fourth request (such as the creator's identity information), and then send the signature along with the fourth request to the server. The server can obtain the creator's public key based on the creator's identity information, such as the creator's personal key identifier, and first use the public key to verify the signature carried in the fourth request. If the verification is successful, it can be considered that the fourth request was indeed initiated by the creator, and that the signed information in the fourth request has not been tampered with. Then, a sharing scenario can be created for the creator.

[0084] It is understandable that, in the following text, for requests initiated by users such as the first publisher, the second publisher, and subscribers, the corresponding client can also sign them with the private keys of each user's personal key. The implementation process can be referred to the above introduction and will not be repeated in the following text.

[0085] S103, the service side generates and shares the first cloud key and the second cloud key corresponding to the scenario, and the first cloud key and the second cloud key belong to the creator.

[0086] Although both the first and second cloud keys correspond to sharing scenarios and both belong to the creator, their uses differ.

[0087] The secondary cloud key is primarily used for data encryption. The creator can delegate the use of the secondary cloud key to other users (e.g., issue a secondary authorization to a secondary publisher), enabling the secondary publisher to use the secondary cloud key and thus publish encrypted files in sharing scenarios on behalf of the creator. Simultaneously, since the secondary cloud key belongs to the creator, the creator can also control the secondary publisher and their publishing behavior through control of the secondary cloud key.

[0088] The primary purpose of the first cloud key is for authorization issuance. The creator can delegate the use of the first cloud key to other users (e.g., issuing a first authorization for the first publisher), enabling the first publisher to use the first cloud key to issue third authorizations to subscribers on behalf of the creator. This allows subscribers to decrypt and open files published in shared scenarios. Furthermore, since the first cloud key belongs to the creator, the creator can also control the first publisher and their signing behavior through control of the first cloud key, and indirectly control the third authorizations issued by them.

[0089] Other relevant features of these two cloud keys and their usage in different processes will be explained further later.

[0090] It should be noted that the service side can generate the first cloud key and the second cloud key simultaneously, or they can be generated separately; this application does not limit this.

[0091] In some possible implementations, the owner information for the first and second cloud keys can be configured as the creator's identity information, such as the creator's personal key identifier. In this way, the first and second cloud keys can be controlled by the creator's personal key, thereby realizing the function of transferring ownership of the first and second cloud keys to the creator.

[0092] In some possible implementations, the service side can first generate a fifth cloud key corresponding to the sharing scenario and belonging to the creator. Then, it configures the generated first and second cloud keys to belong to the fifth cloud key. In this way, the first and second cloud keys can be controlled by the fifth cloud key, which in turn is controlled by the creator, thus indirectly achieving the function of transferring ownership of the first and second cloud keys to the creator. For example, the service side can configure the owner information of the fifth cloud key as the creator's identity information, such as the creator's personal key identifier; and then configure the owner information of the first and second cloud keys as the identifier of the fifth cloud key.

[0093] It should be noted that the service side can independently generate the fifth cloud key, the first cloud key, and the second cloud key, or it can use the fifth cloud key to generate the first cloud key and the second cloud key. This application does not limit this.

[0094] Optionally, the server may also perform the following steps:

[0095] S104, the server will share the scenario description information, as well as the description information of the first cloud key and the second cloud key, and return them to the first client.

[0096] The description information of the shared scene may include, for example, scene ID, scene name, scene creation time, etc.

[0097] The description information of the cloud key may, for example, include the key identifier of the cloud key. It is understood that when the implementation method of indirect control using a fifth cloud key is adopted, the server side may also return the description information of the fifth cloud key to the first client.

[0098] The server can return this descriptive information to the first client separately or together; this application does not limit this. The first client stores this descriptive information and can use it in subsequent interactions with the server, or display certain information to the user of the first client when necessary, such as displaying the scene name and scene creation time.

[0099] In some possible implementations, the service side may include, for example: Figure 2 The server and cloud key management system shown above, in this case, step S102 can be performed by the server, and step S103 can be performed by the cloud key management system. Optionally, the server can store sharing scenario records, such as the creator's identity information (e.g., the account the creator registered on the server), the corresponding sharing scenario description information (e.g., scenario ID), and the cloud key description information (e.g., the key identifier of the cloud key), for subsequent querying and use.

[0100] It should be noted that the above examples illustrate some implementation methods for a creator to create a sharing scenario for themselves. In addition, others (such as any first user) can also request the service side to create a sharing scenario for the creator. Their implementation methods can be similar to or different from those described above, and this application does not limit their scope. For example, a first user can create a sharing scenario for themselves using the aforementioned method, and then transfer ownership of the sharing scenario to the creator using the method described later for changing the owner of the sharing scenario. As another example, a first user can perform the aforementioned fourth operation on their client, including the creator's identity information (and possibly their own identity information) in the fourth request sent to the service side. In this way, after receiving the fourth request, the service side can also create a sharing scenario for the creator and generate the corresponding cloud key.

[0101] (ii) Authorization granted by the creator to the publisher

[0102] S105, the first client responds to the creator's fifth operation and generates the fifth request.

[0103] When a creator wants to set a user as a publisher and authorize them, the creator can perform an operation on the first client (referred to as the fifth operation in this embodiment for ease of distinction). The fifth operation includes specifying at least one publisher. For example, the creator clicks the "Add Administrator" control displayed in the user interface on the first client and then selects one or more users as publishers. In response to this operation by the creator, the first client generates a fifth request.

[0104] The fifth request is used to request that the right to use the first cloud key and / or the second cloud key be granted to the specified user. In some implementations, the first client can obtain the identity information of the specified user from the server side, such as the account registered by the specified user on the server side or server, the personal key identifier of the specified user, etc., and then put the identity information of the specified user, the key identifier of the first cloud key and / or the key identifier of the second cloud key, and the creator's personal key identifier, etc., into the fifth request.

[0105] S106, the first client sends the fifth request to the server.

[0106] S107, in response to the fifth request, the service side issues a corresponding authorization for the designated user, which indicates that the designated user is allowed to invoke the service side's first cloud key and / or second cloud key.

[0107] The authorization issued by the server can have various data structures. For example, in some implementations, the authorization includes: an authorization ID, an authorization target key identifier, and the authorized person's personal key identifier. The authorization may also include one or more pieces of information such as the authorizer's personal key identifier, the authorization ID, and the authorization terms.

[0108] The authorization ID is primarily used to uniquely identify an authorization.

[0109] The authorized target key identifier is mainly used to describe which cloud key's usage rights have been authorized.

[0110] The authorized person's personal key identifier is mainly used to describe who has been authorized to use the cloud key. It can be understood that the authorized person here can be a user, device, other key, etc.

[0111] The authorizing person's personal key identifier is mainly used to describe which authorizing person requested the issuance of the authorization;

[0112] Based on the authorization ID, it is mainly used to describe which authorization ID the authorizer used to request the issuance of the authorization, that is, which authorization the authorizer is using to request the issuance of the current authorization.

[0113] The authorization terms are mainly used to describe the scope and restrictions that the authorized person is allowed to use the cloud key, such as time information, number of times information, and operation restriction information.

[0114] It should be noted that in some implementations, when the authorizer is the owner of the target key, they do not need to provide the authorization ID; that is, the authorization ID in the issued authorization can be empty. In other implementations, if the service side first issues the corresponding self-authorization for the creator by default, then the authorization ID can also be the self-authorization ID issued to the creator for controlling the cloud key.

[0115] As can be seen, if a request is made to authorize the first cloud key to the first publisher and the second cloud key to the second publisher, the service side will issue a first authorization for the first publisher and a second authorization for the second publisher accordingly.

[0116] The first authorization indicates that the first publisher is permitted to invoke the first cloud key on the service side. For example, the authorization target key identifier is the key identifier of the first cloud key; the authorized person's personal key identifier is the personal key identifier of the first publisher; and the authorizing person's personal key identifier is the personal key identifier of the creator.

[0117] The second authorization indicates that the second publisher is permitted to invoke the second cloud key on the service side. For example, the authorization target key identifier in the second authorization is the key identifier of the second cloud key; the personal key identifier of the authorized party is the personal key identifier of the second publisher; and the personal key identifier of the authorizer is the personal key identifier of the creator.

[0118] If a request is made to authorize the first cloud key and the second cloud key to the same user, that is, the first publisher and the second publisher are designated as the same user, then the service side will issue the first authorization and the second authorization to that user accordingly.

[0119] Understandably, the creator can also use this implementation to request authorization of the first cloud key and / or the second cloud key to other users, and the user with the corresponding authorization becomes the corresponding publisher. In other words, for a sharing scenario, it can be authorized to multiple publishers, and these publishers can manage the sharing scenario.

[0120] Optionally, in some possible implementations, the service side can issue a self-authorization to the creator before issuing an authorization to the publisher. That is, after step S103 above, it may also include:

[0121] S108, the service side issues self-authorization to the creator, which means that the creator is allowed to call the first cloud key and the second cloud key.

[0122] In some implementations, self-authorization can include self-authorization of a first cloud key and self-authorization of a second cloud key. Here, self-authorization of the first cloud key indicates that the creator is allowed to invoke the first cloud key on the service side; self-authorization of the second cloud key indicates that the creator is allowed to invoke the second cloud key on the service side. The permissions granted by self-authorization of the first and second cloud keys are clearly greater than the first and second authorizations issued to the first and second publishers, respectively.

[0123] In other implementations, where indirect control is employed using a fifth key, self-authorization includes fifth cloud key self-authorization, which indicates permission for the creator to invoke the service-side fifth cloud key. The service-side also issues usage authorizations for the first cloud key and second cloud key for the fifth cloud key, allowing the creator to indirectly control the first and second cloud keys using the fifth cloud key self-authorization.

[0124] It should be noted that when needed, the server can return the issued authorizations (such as first authorization, second authorization, self-authorization, etc.) to the corresponding clients (such as second client A, second client B, first client, etc.), or it can store them on the server side and only return the description information of the authorization, such as the authorization ID, authorization target key identifier, etc., so that the client knows which authorizations it has obtained and can use them in subsequent steps.

[0125] In some possible implementations, the service side includes, for example... Figure 2 In the case of the server and cloud key management system shown, steps S107 and S108 can be performed by the cloud key management system. Optionally, the server can store publisher records, such as description information of the sharing scenario (e.g., scenario ID), the corresponding publisher's identity information (e.g., the publisher's account registered on the server), description information of the first authorization and / or the second authorization and / or self-authorization (e.g., authorization ID), etc., for subsequent querying and use.

[0126] (III) Creating Shared Points in Sharing Scenarios

[0127] See Figure 4 , Figure 4 This is a flowchart illustrating some steps of an exemplary file secure sharing method provided in an embodiment of this application.

[0128] S201, the second client B responds to the sixth operation of the second publisher and generates the sixth request.

[0129] When a second publisher wants to create a new sharing point in a certain sharing scenario, it can perform an operation on the second client B for that sharing scenario (for ease of distinction, this is referred to as the sixth operation in this embodiment). For example, the second publisher clicks the "Create New Sharing Point" control in the user interface displayed on the second client B. In response to this operation by the second publisher, the second client B generates a sixth request.

[0130] In some possible implementations, the second client B can obtain the description information of the sharing scenario managed by the second publisher from the service side, and display some of the description information (such as scenario name, creator account, etc.) on the user interface so that the user can operate on the sharing scenario.

[0131] The sixth request is used to request the creation of a sharing point in a sharing scenario. In some possible implementations, the sixth request may include the identity information of the second publisher, such as the account registered by the second publisher on the server side or server-side, the second publisher's personal key identifier, etc. The sixth request may also include a scenario ID, a description of the second authorization, etc.

[0132] S202, the second client B sends the sixth request to the server.

[0133] S203, the server responds to the sixth request by creating a shared point in the aforementioned sharing scenario.

[0134] In some possible implementations, the service side can verify, based on the description information of the second authorization, that the initiator of the sixth request (i.e., the second publisher) does indeed possess the corresponding permissions, and then create a sharing point in the aforementioned sharing scenario. The service side can assign a unique sharing point ID to this sharing point and associate the scenario ID, the sharing point ID, and the identity information of the second publisher.

[0135] In some possible implementations, the sixth request may also include other information such as the shared point name and icon. By carrying the name and icon, the server can use these names and icons to name the created shared points and set the icons, thus allowing users to easily define the shared point's name, icon, and other interface display information.

[0136] It should be noted that one or more sharing points can be created in a sharing scenario. For ease of distinction and explanation, a sharing point created at a particular time will be referred to as the first sharing point, and this will be used as an example to illustrate the solution. It is understood that before the first sharing point is created, other sharing points may have already been created in this sharing scenario, such as the second sharing point; after the first sharing point is created, other new sharing points may also be created in this sharing scenario, such as the third sharing point, etc. This application does not limit this.

[0137] S204, The service side generates a third cloud key corresponding to the first shared point.

[0138] The authorization and issuance of a third cloud key can be controlled by the first cloud key. In other words, when a user has the right to use the first cloud key (such as the creator or the first publisher with the first authorization), they can use the first cloud key to authorize the issuance of a third cloud key for themselves or others.

[0139] The decryption and use of the third cloud key can be controlled by the second cloud key. When a user has access to the second cloud key (e.g., the creator or a second publisher with second authorization), they can access the third cloud key through the second cloud key and use it for operations such as decryption. That is, the second cloud key is allowed to access the third cloud key for at least decryption.

[0140] It is understandable that other sharing points in this sharing scenario also have their own corresponding cloud keys, and the cloud keys corresponding to different sharing points can generally be different.

[0141] S205, the server uses the third cloud key to encrypt the fourth key, thus obtaining the ciphertext of the fourth key.

[0142] The fourth key is used to encrypt files published at the first sharing point.

[0143] The fourth key can be generated by the second publisher or owner and then transmitted to the server for encryption, or it can be generated by the server. This application does not limit this.

[0144] In some possible implementations, after generating the third cloud key, the server can issue a usage authorization (hereinafter referred to as the fourth authorization) for the second cloud key. This fourth authorization indicates permission to access the third cloud key via the second cloud key for encryption and decryption, and the server returns a description of this fourth authorization to the second client B. Then, the second client B sends its generated fourth key, the description of the fourth authorization, and the second publisher's personal key identifier in a request to the server. Upon receiving this request, the server can invoke the second cloud key based on the second authorization held by the second publisher, and access the third cloud key based on the fourth authorization. It then uses the third cloud key to encrypt the fourth key, obtaining the ciphertext of the fourth key.

[0145] The fourth key ciphertext can be returned to the second client B, or it can be stored on the server side; this application does not limit this.

[0146] It should be noted that the first shared point can be created at the request of the second publisher or by the creator itself. That is, the entity executing steps S201 to S202 above can also be the first client. Shared points included in a sharing scenario can include those created by the second publisher or those created by the creator; this application does not limit this. The above steps exemplarily describe the creation process of the first shared point; the creation process of other shared points can be similar.

[0147] It should also be noted that the step of authorizing the publisher by the creator (e.g., S105 to S107) can occur before or after the creation of the first shared point (e.g., S201 to S205). This application does not limit the order of these steps. It is easy to understand that if the creator authorizes the publisher first, both the creator and the publisher may subsequently create the first shared point; however, if the creator does not authorize the publisher immediately, the creator can create the first shared point themselves first.

[0148] In some possible implementations, the service side includes, for example... Figure 2In the case of the server and cloud key management system shown, step S203 can be executed by the server, and steps S204 to S205 can be executed by the cloud key management system. Optionally, the server can store records of sharing points in the sharing scenario, such as description information of the sharing scenario (e.g., scenario ID), description information of the corresponding sharing points (e.g., sharing point ID, sharing point name), the fourth key ciphertext, and description information of the third cloud key (e.g., the key identifier of the third cloud key), for subsequent querying and use. Using this method, the fourth key used to encrypt the first file cannot be obtained by the server providing the business service; only authorized terminal users and the cloud key management system can obtain it.

[0149] (iv) A second publisher publishes a file in a shared location.

[0150] See Figure 5 and Figure 6 , Figure 5 and Figure 6 The following are flowcharts illustrating two exemplary secure file sharing methods provided in embodiments of this application.

[0151] S206, the second client B responds to the second publisher's second operation on the first shared point by generating a second request.

[0152] The term "file" in this application embodiment refers to a file in a broad sense, which may include data assets such as documents, images, videos, audio, and folders. This application does not limit the specific data format. The first file here can be a file of any possible form.

[0153] When a second publisher wants to publish a file in a shared location, it can perform an operation on that shared location on a second client B (referred to as a second operation in this embodiment for ease of distinction). For example, the second publisher clicks the "Add New Content" control in the user interface displayed on the second client B. In response to this operation by the second publisher, the second client B generates a second request.

[0154] In some possible implementations, the second client B can obtain the description information of the first sharing point in the sharing scenario managed by the second publisher from the service side, and display some of the description information (such as the name of the sharing point, the name and thumbnail of the files published in the sharing point, etc.) on the user interface so that the user can operate on the sharing point.

[0155] The second request is used to request that the first file to be published be published to the first sharing point. In some possible implementations, the second request may include the identity information of the second publisher, such as the second publisher's personal key identifier. The second request may also include descriptive information about the second authorization, such as the second authorization ID.

[0156] S207, the second client B sends a second request to the server.

[0157] S208, the server responds to the second request by storing the first file ciphertext in the first shared point. The first file ciphertext is obtained by encrypting the first file with the fourth key.

[0158] In some implementations, the second client B can send the first file to be published along with the second request to the server side, either together or separately. The server side then encrypts the file using the fourth key and stores it in the first shared point.

[0159] In other implementations, the second client can encrypt the first file to be published and send the encrypted first file to the server side either separately or in a second request.

[0160] When the fourth key exists on the second client B, the second client B can directly use the fourth key to encrypt the first file. For example, the aforementioned method further includes:

[0161] S209, Second client B uses the fourth key to encrypt the first file, obtaining the ciphertext of the first file;

[0162] S210, the second client B sends the encrypted first file to the server.

[0163] When the second client B does not have the fourth key, the server can return the fourth key to the second client B. For example, step S208 can be replaced by steps S209 to S212 below.

[0164] S211, in response to the second request, the service side, based on the second authorization held by the second publisher, accesses the third cloud key through the second cloud key, uses the third cloud key to decrypt the fourth key ciphertext, and obtains the fourth key.

[0165] S212, the server sends the fourth key to the second client B.

[0166] S209, the second client B uses the fourth key to encrypt the first file, obtaining the ciphertext of the first file.

[0167] S210, the second client B sends the encrypted first file to the server.

[0168] Optionally, after step S210, the following step may also be included: S213, whereby the server returns the storage address of the encrypted first file to the second client B.

[0169] Optionally, after receiving the first file or the encrypted first file, the service can assign a corresponding file ID to the first file and record information such as the file ID, the sharing point ID, and the storage address of the corresponding encrypted first file.

[0170] Using the above implementation method, the second publisher completes the publication of the first file. It is understood that multiple files can be published in the first shared point; these files may include those published by the publisher or those published by the creator themselves, and this application does not limit this. That is, the executing entity of steps S206, S207, S211, and S212 above can also be either the first client or the second client A. The above steps executively describe the process for the first file; the process for other files can be similar.

[0171] In some possible implementations, the service side may include, for example: Figure 2 The server and cloud key management system shown above can have steps S209 and S213 executed by the server, while steps S208 and S210 can be executed by the cloud key management system. Optionally, the server can store file records of published files, such as description information of the sharing scenario (e.g., scenario ID), description information of the corresponding sharing point (e.g., sharing point ID), file ID of the first file, and storage address of the encrypted first file, for subsequent querying and use.

[0172] In this approach, only authorized users on the terminal side, such as the creator, secondary publisher, and subsequent subscribers, can decrypt and open the first file when needed. The server stores the encrypted first file and the encrypted fourth key, but not the third cloud key, making it difficult for the server providing business services to view the specific content of the first file. While the cloud key management system stores the third cloud key and can decrypt the fourth key, it also lacks the encrypted first file, making it difficult for the cloud key management system to view its content. Therefore, this solution achieves end-to-end security, further enhancing the security and privacy of shared files.

[0173] (v) Authorization granted by the first publisher to subscribers

[0174] S214, the second client A responds to the first publisher's first operation on the first shared point and generates a first request.

[0175] When a first publisher wants to allow a user to access files in a shared location, it can perform an operation on the shared location on a second client A (referred to as a first operation in this embodiment for clarity). The first operation includes specifying subscribers. For example, the first publisher clicks the "Add Subscriber" control corresponding to the first shared location in the user interface displayed on the second client A, and then selects one or more users as subscribers. The second client A responds to this operation by the first publisher by generating a first request.

[0176] In some possible implementations, the second client A can obtain the description information of the first sharing point in the sharing scenario managed by the first publisher from the service side, and display some of the description information (such as the name of the sharing point, the name and thumbnail of the files published in the sharing point, etc.) on the user interface so that the user can perform operations on the sharing point.

[0177] The first request is used to request the issuance of authorization for the specified subscriber. In some implementations, the second client A can obtain the subscriber's identity information from the server side, such as the subscriber's account registered on the server side or server, the subscriber's personal key identifier, etc., and then put the subscriber's identity information, the key identifier of the third cloud key, the description information of the first authorization, and the first publisher's personal key identifier, etc., together in the first request.

[0178] S215, the second client A sends the first request to the server.

[0179] S216, In response to the first request, the service side, based on the first authorization held by the first publisher, calls the first cloud key to issue a third authorization for the specified subscriber.

[0180] Third-party authorization grants the subscriber permission to access a third-party cloud key on the service side. This gives the subscriber permission to open files published on the first shared location.

[0181] The structure of a third-party authorization can be similar to that of the authorization issued by the service side. For example, the target key identifier in the third-party authorization is the key identifier of the third cloud key; the personal key identifier of the authorized party is the personal key identifier of the subscriber; the personal key identifier of the authorizing party is the personal key identifier of the first publisher; and the authorization ID is the ID of the first authorization. Also for example, the authorization terms can be limited to allowing decryption, and the authorization terms may also include the authorization validity period, the number of valid authorizations, etc. The authorization validity period is used to limit the time for the subscriber to use the third-party authorization, which can be, for example, a few days, several months, several years, or indefinitely. The number of valid authorizations is used to limit the number of times the subscriber can use the third-party authorization.

[0182] Optionally, the server can use the first cloud key to sign some important information in the aforementioned third authorization, obtaining signature information, and also include the signature information in the third authorization. Using this method, when subsequent subscribers use the authorization, the server can first verify the signature information in the third authorization, and only after successful verification can it call the third cloud key for decryption.

[0183] Optionally, after S216, the service side can also return description information of the third-party license to the subscriber, such as the license ID of the third-party license, so that the subscriber knows which licenses they have.

[0184] In some possible implementations, the service side includes, for example... Figure 2 In the case of the server and cloud key management system shown, step S216 can be performed by the cloud key management system. Optionally, the server can store subscriber records, such as subscriber identity information (e.g., the subscriber's account registered on the server), description information of the corresponding shared point (e.g., shared point ID), description information of third-party authorization (e.g., authorization ID), etc.

[0185] It is understandable that when the creator has self-authorization, it can also authorize subscribers. The implementation process is similar to the aforementioned process, and steps S214 and S215 can be executed by the first client accordingly.

[0186] (vi) Subscribers can view files in the shared location.

[0187] S301, the third client responds to the subscriber's first operation on the second file in the first shared point by generating a third request.

[0188] The second file here can be any file in the first shared point, which can be the aforementioned first file or other files also published in the shared point.

[0189] When a subscriber wants to open a file in a shared location, they can perform an operation on that file on a third client (referred to as a third operation in this embodiment for clarity), such as clicking the file icon or file name control in the user interface on the third client. The third client responds to this operation by generating a third request. Subscribers who are not subscribers to the first shared location cannot even see the first shared location and its files on their own clients.

[0190] In some possible implementations, before initiating a third request, the third client can obtain description information of the shared points it has authorized (i.e., shared points it has permission to open) from the service side, and display some description information (such as the shared point name, the names and thumbnails of the files published in the shared point, etc.) on the user interface so that the user can operate on the files in the shared point.

[0191] The third request is used to request the opening of a specified second file. In some possible implementations, the third request may include the subscriber's identity information, such as the subscriber's account registered on the server side or server-side, the subscriber's personal key identifier, etc. The third request may also include description information of the third authorization (such as the authorization ID of the third authorization), the key identifier of the third cloud key, etc.

[0192] S302, the third client sends a third request to the server.

[0193] S303, the server responds to the third request by calling the third cloud key to decrypt the fourth key ciphertext based on the third authorization held by the subscriber, and obtains the fourth key.

[0194] The fourth key can be used to decrypt the ciphertext of the second file, allowing subscribers to open the second file. In some implementations, the server can directly use the fourth key to decrypt the ciphertext of the second file and return it to the third client, so that the third client can open the second file for subscribers to view. In other implementations, the third client can decrypt the ciphertext of the second file. That is, optionally, steps S304 to S306 can be included after step S301.

[0195] S304, the server returns the fourth key to the third client.

[0196] S305, the server sends the encrypted second file to the third client.

[0197] S306, the third client decrypts the ciphertext of the second file to open the second file.

[0198] In some possible implementations, since all files in a shared instance are encrypted using a fourth key, after a third client obtains the fourth key, it can be allowed to directly decrypt and open other files in that shared instance for a certain period of time. For example, during the validity period of a subscriber's single login, the third client can be allowed to use the fourth key to decrypt other files in the first shared instance; however, when the login expires, the third client needs to re-initiate a third request to the service side.

[0199] In some other possible implementations, the fourth key can be configured to be deleted after use, requiring a new request to be made each time a subscriber needs to open a file.

[0200] Optionally, the fourth key received by the third client is configured to be stored only in the memory of the third client and cannot be read out of memory.

[0201] In the above implementation, subscribers, possessing third-party authorization, can open files published in the first shared location. Other subscribers who are not authorized to use the third cloud key cannot decrypt the fourth key's ciphertext and therefore cannot open the corresponding files. In other words, this method ensures that only authorized subscribers can access files in the corresponding shared location.

[0202] In some possible implementations, the third-party client can be configured to prohibit downloading and forwarding. This allows subscribers with valid third-party authorization to open, view, and even edit the second file within the third-party client—for example, by writing notes—but they cannot download the second file to other locations or forward it to others. This approach further enhances the security of file sharing.

[0203] In some possible implementations, the service side includes, for example... Figure 2 In the case of the server and cloud key management system shown, the step in S303 of decrypting the fourth key ciphertext by calling the third cloud key based on the third authorization can be executed by the cloud key management system, and the step in S305 can be executed by the server.

[0204] (vii) Revocation of authorization

[0205] Besides adding subscribers on behalf of the creator, the primary publisher can also delete subscribers to manage sharing points within the sharing scenario. The creator has higher privileges; in addition to authorizing publishers and adding subscribers themselves, they can also delete publishers or subscribers. This approach allows both creators and publishers to exercise more granular permission allocation and management over the sharing scenario and its content.

[0206] In some implementations, the first publisher deleting a subscriber may include the following steps S217 to S219.

[0207] S217, Second client A responds to the first publisher's eighth operation for the third authorization by generating an eighth request.

[0208] When a first publisher wants to block a subscriber from accessing files in a shared location, it can perform an operation on the subscriber's authorization in that shared location on a second client A (referred to as the eighth operation in this embodiment for clarity). For example, the first publisher clicks on the subscriber list corresponding to the first shared location in the user interface displayed on the second client A, then selects the authorization of one or more subscribers, such as the aforementioned third authorization, and clicks the "Delete Authorization" control. The second client A responds to this operation by the first publisher by generating an eighth request.

[0209] In some possible implementations, the second client A can obtain the identity information and authorization description information of the subscribers of the first sharing point in the sharing scenario managed by the first publisher from the service side, and display some of the description information (such as the subscriber's account, the validity period of the authorization held by the subscriber, etc.) on the user interface so that the user can perform operations on the authorization of the subscriber.

[0210] The eighth request is used to request the removal of authorization from a specified subscriber. In some implementations, the second client A can include the subscriber's identity information, the description of the third authorization, and the first publisher's personal key identifier, along with other first publisher information and first authorization description information, in the eighth request.

[0211] S218, the second client A sends the eighth request to the server.

[0212] S219, the server responds to the eighth request, revoking the third authorization based on the first authorization.

[0213] The server can directly delete the third-party authorization, or it can change the status of the third-party authorization from valid to invalid, thereby revoking the third-party authorization.

[0214] In some implementations, the process of a creator deleting a subscriber can be similar to that of the first publisher deleting a subscriber. The main difference is that the creator may not need to provide first authorization, or may provide self-authorization that they possess.

[0215] In some implementations, the creator deleting the publisher may include the following steps S109 to S111.

[0216] S109, the first client responds to the creator's ninth operation against the publisher by generating the ninth request.

[0217] When a creator wants to delete a subscriber and prevent them from managing subscribers and / or publishing files, they can perform an operation on the first client for the sharing scenario (referred to as the ninth operation in this embodiment for clarity). For example, in the user interface displayed on the first client, a list of publishers corresponding to the sharing scenario is shown. The creator selects one or more publishers and clicks the "Delete Publisher" control. The first client responds to this operation by generating a ninth request.

[0218] In some possible implementations, the first client can obtain the description information of the sharing scenario from the server side and display some of the description information (such as the name of the sharing scenario, the number of currently authorized publishers, and the publisher's name) on the user interface so that the user can perform operations on the publisher.

[0219] The ninth request is used to request the removal of the authorization of the specified publisher. In some implementations, the first client may include the publisher's identity information, descriptions of the first and / or second authorizations, and the creator's personal key identifier, among other creator identity information, in the ninth request.

[0220] S110, the first client sends the ninth request to the server.

[0221] S111, the server revokes the publisher's authorization.

[0222] The service can directly delete the authorization held by the publisher, or it can revoke the authorization by changing its status from valid to invalid. For example, when the publisher is the first publisher and / or the second publisher, the service will set the first authorization and / or the second authorization to invalid accordingly.

[0223] In some possible implementations, the service side includes, for example... Figure 2 In the case of the server and cloud key management system shown, steps S219 and S111 can be performed by the cloud key management system. Optionally, the server can delete the corresponding subscriber and publisher records.

[0224] (viii) The creator changes the owner of the shared scenario.

[0225] S112, the first client responds to the creator's seventh operation for the sharing scenario and generates the seventh request.

[0226] When a creator wants to transfer ownership of the entire shared scenario to another user, they can perform an operation on the shared scenario on the first client (referred to as the seventh operation in this embodiment for ease of distinction). For example, the user interface displayed on the first client shows all shared scenarios belonging to the creator. The creator clicks to select one or more shared scenarios and clicks the "Change Owner" control. In response to this operation by the creator, the first client generates a seventh request.

[0227] The seventh request is used to request a change of ownership of the shared scenario to a new owner. In some implementations, the first client can include the new owner's identity information, as well as the creator's personal key identifier and other creator identity information, in the seventh request.

[0228] S113, the first client sends the seventh request to the server.

[0229] S114, the service side modifies the first cloud key and the second cloud key to belong to the new owner, or modifies the fifth cloud key to belong to the new owner.

[0230] As mentioned earlier, when creating a sharing scenario, the service side can generate a fifth cloud key to control the first and second cloud keys. Compared to directly assigning ownership of the first and second cloud keys to the creator, the indirect control method using the fifth cloud key means that when ownership of the sharing scenario needs to be changed, only the fifth cloud key needs to be modified, making the change operation more convenient.

[0231] It is understandable that, when developing an actual product, the functions implemented by the first client, second client A, second client B, and third client can be partially or fully integrated into a single client product.

[0232] The following explanation applies the solution of this application embodiment to an exemplary application scenario. For example, the aforementioned software product with data asset sharing function may include a user-facing APP and a server providing business services to the APP in the background. Additionally, the server side also includes a cloud key management system for providing cloud key-related services.

[0233] This software product allows file owners to flexibly add one or more other users as publishers as needed. These users can then add subscribers to share files, publish files, and perform other management operations, such as revoking subscribers' access to files. Of course, file owners can also manage the number and permissions of publishers, such as adding or deleting publishers as needed. This approach effectively ensures the security and controllability of shared files and improves management efficiency.

[0234] For example, user admin_A can create their own knowledge base through the app (corresponding to the aforementioned sharing scenario), and add one or more other users as publishers to manage the knowledge base on their behalf. For instance, user_P1 can be added as the first publisher, and user_P2 as the second publisher. User admin_A or user_P2 can create one or more courses in the knowledge base (corresponding to the aforementioned sharing points), and each course can publish one or more files. When wanting to share a course with user_S, user admin_A or user_P1 can add user_S as a subscriber. In this way, user_S can open all files in the courses they have permission to access within their own app. It's understood that user_S can not only view files currently published in the course, but also view any new files subsequently published in the course by administrators such as user admin_A or user_P2, without requiring re-authorization from administrators like user admin_A or user_P1 who have permission to add subscribers.

[0235] This application embodiment also provides a client, which may include:

[0236] The first storage unit is configured to store predetermined computer instructions;

[0237] The first processing unit is configured to execute the predetermined computer instructions to implement some or all of the steps implemented by the first client, second client A, second client B, or third client in any of the aforementioned implementation methods.

[0238] This application embodiment also provides a server-side system, which may include:

[0239] The second storage unit is configured to store predetermined computer instructions;

[0240] The second processing unit is configured to execute the predetermined computer instructions to implement some or all of the steps implemented by the server side in any of the aforementioned implementation methods.

[0241] Those skilled in the art will understand that, in addition to the methods, clients, and service systems described above, embodiments of this application may also be provided as computer-readable storage media or computer program products.

[0242] The methods executed by the server and client provided in the embodiments of this application can be provided as a computer-readable storage medium. Specifically, the embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, causes the processor to perform some or all of the steps in any implementation of the aforementioned processing method or verification method.

[0243] This application may also take the form of a computer program product implemented on one or more computer-readable storage media containing computer-usable program code.

[0244] Those skilled in the art will recognize that the units and steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0245] It should be understood that in the various embodiments of this application, the execution order of each step should be determined by its function and internal logic, and the size of each step number does not mean the order of execution, and does not constitute any limitation on the implementation process of the embodiments.

[0246] It should also be understood that, in order to clearly describe the technical solutions of the embodiments of this application, the terms "first" and "second" are used in the embodiments of this application to distinguish between identical or similar items with substantially the same function and effect, or concepts that have certain differences. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, and the terms "first" and "second" are not necessarily different.

[0247] The same or similar parts among the various embodiments in this specification can be referred to interchangeably. Different embodiments can be combined with each other as long as they are not logically contradictory.

Claims

1. A file security sharing method, characterized by, The service side creates a sharing scenario belonging to the creator. The sharing scenario includes a first sharing point, in which files encrypted with a fourth key are allowed to be published. The service side stores at least a first cloud key and a third cloud key. The first cloud key corresponds to the sharing scenario and belongs to the creator. The third cloud key corresponds to the first sharing point and is used to encrypt the fourth key. The authorization and issuance of the third cloud key are controlled by the first cloud key. The method includes: The service side receives a first request from the first publisher, the first request being used to request the issuance of an authorization for a specified subscriber, wherein the first publisher possesses the first authorization, the first authorization indicating that the first publisher is allowed to invoke the first cloud key of the service side; In response to the first request, the service side, based on the first authorization, invokes the first cloud key to issue a third authorization for the subscriber, thereby granting the subscriber permission to open files published in the first shared point; wherein, the third authorization indicates that the subscriber is allowed to invoke the third cloud key of the service side.

2. The method of claim 1, wherein, The third cloud key is used to encrypt the fourth key to obtain the fourth key ciphertext, and the fourth key is used to encrypt the file published in the first sharing point.

3. The method according to claim 2, characterized in that, The service side also stores a second cloud key, which corresponds to the sharing scenario and belongs to the creator. The second cloud key is allowed to access the third cloud key for at least decryption. The method includes: The service side receives a second request from the second publisher, the second request being used to request the first file to be published to be published to the first shared point, wherein the second publisher has a second authorization, the second authorization indicating that the second publisher is allowed to call the second cloud key of the service side; In response to the second request, the service side, based on the second authorization, accesses the third cloud key through the second cloud key, and uses the third cloud key to decrypt the fourth key ciphertext to obtain the fourth key; The server stores the encrypted first file in the first shared point, and the encrypted first file is obtained by encrypting the first file with the fourth key; The second publisher may be the same user as the first publisher or a different user.

4. The method of claim 3, wherein, The service side includes a server and a cloud key management system, and the first cloud key, the second cloud key, and the third cloud key are stored in the key management system; Before the step of storing the first file ciphertext in the first shared point, the method further includes: The cloud key management system returns the decrypted fourth key to the second publisher. The server receives the first encrypted file from the second publisher.

5. The method according to any one of claims 2 to 4, characterized in that, The method further includes: The server receives a third request from the subscriber, the third request being used to request the opening of a specified second file, the second file being any file in the first shared point; In response to the third request, the service side, based on the third authorization possessed by the subscriber, calls the third cloud key to decrypt the fourth key ciphertext, obtaining the fourth key. The fourth key can be used to decrypt the second file ciphertext, allowing the subscriber to open the second file.

6. The method of claim 5, wherein, The service side includes a server and a cloud key management system, and the method includes: The server sends the encrypted version of the second file to the subscriber; The cloud key management system sends the decrypted fourth key to the subscriber, enabling the subscriber to use the fourth key to decrypt the second file ciphertext, obtain and open the second file.

7. The method according to any one of claims 1 to 2, characterized in that, The method further includes: The service receives an eighth request from the first publisher or creator, the eighth request being used to request the deletion of the subscriber; The service side revokes the aforementioned third authorization.

8. The method according to any one of claims 3 to 4, characterized in that, The method further includes: The service receives a ninth request from the creator, the ninth request being used to request the deletion of the first publisher and / or the second publisher; The service side revokes the first authorization and / or the second authorization.

9. The method according to any one of claims 3 to 4, characterized in that, The service side also stores a fifth cloud key corresponding to the sharing scenario. The first cloud key and the second cloud key belong to the fifth cloud key, and the fifth cloud key belongs to the creator.

10. The method of claim 9, wherein, Also includes: The service receives a seventh request from the creator, which is used to request that the owner of the sharing scenario be changed to a new owner; The service side modifies the fifth cloud key to belong to the new owner.

11. The method according to any one of claims 3 to 4, characterized in that, Also includes: The server receives a fourth request, which is used to request the creation of a sharing scenario for the creator. In response to the fourth request, the service side creates a sharing scenario for the creator. The service side generates a first cloud key and a second cloud key corresponding to the sharing scenario.

12. The method according to any one of claims 3 to 4, characterized in that, The method further includes: The service receives a fifth request from the creator, the fifth request being used to request that the usage rights of the first cloud key and / or the second cloud key be authorized to a specified user; In response to the fifth request, the service side issues a corresponding authorization for the designated user, which indicates that the designated user is allowed to invoke the service side's first cloud key and / or second cloud key.

13. The method according to any one of claims 3 to 4, characterized in that, The method further includes: The service side issues a self-authorization to the creator, which means that the creator is allowed to call the first cloud key and / or the second cloud key.

14. The method according to any one of claims 2 to 4, characterized in that, The method further includes: The service side receives a sixth request from the second publisher or creator, the sixth request being used to request the creation of a sharing point in a sharing scenario; In response to the sixth request, the server creates a first sharing point in the sharing scenario; The service side generates a third cloud key corresponding to the first shared point; The service side uses the third cloud key to encrypt the fourth key, thus obtaining the ciphertext of the fourth key.

15. The method according to any one of claims 2 to 4, characterized in that, The service side includes a server and a cloud key management system, and the method includes: The server receives a sixth request from the second publisher or creator, the sixth request being used to request the creation of a sharing point in a sharing scenario; In response to the sixth request, the server creates a first sharing point in the sharing scenario; The cloud key management system generates a third cloud key corresponding to the first sharing point; The cloud key management system receives a fourth key from a second publisher or creator; The cloud key management system uses the third cloud key to encrypt the fourth key, thus obtaining the ciphertext of the fourth key; The server stores the fourth key ciphertext.

16. A file security sharing method, characterized by, include: The client obtains description information of the first sharing point in the sharing scenario managed by the first publisher from the service side; wherein, the sharing scenario is created by the service side and belongs to the creator; the sharing scenario has a corresponding first cloud key, which is stored on the service side and belongs to the creator; the first publisher has a first authorization, which indicates that the first publisher is allowed to call the first cloud key; the first sharing point allows the publication of files encrypted with a fourth key, the first sharing point has a corresponding third cloud key, which is stored on the service side and used to encrypt the fourth key, and the authorization and issuance of the third cloud key is controlled by the first cloud key; The client responds to the first operation of the first publisher to the first shared point by generating a first request, wherein the first operation includes an operation for a specified subscriber, and the first request is used to request the issuance of authorization for the specified subscriber; The client sends a first request to the server, so that the server responds to the first request and issues a third authorization to the subscriber by invoking the first cloud key based on the first authorization; wherein, the third authorization indicates that the subscriber is allowed to invoke the third cloud key of the server, so that the subscriber has the permission to open files in the first shared point.

17. The method of claim 16, wherein, Also includes: The client responds to the first publisher's eighth operation for the third authorization by generating an eighth request; The client sends the eighth request to the server, so that the server responds to the eighth request and revokes the third authorization based on the first authorization.

18. The method of any one of claims 16-17, wherein, The first publisher also has a second authorization, which allows the first publisher to invoke the second cloud key on the service side; The second cloud key corresponds to the sharing scenario and belongs to the creator; The method further includes: In response to the second operation of the second publisher on the first shared point, the client generates a second request, wherein the second request is used to request that the first file to be published be published to the first shared point; The client sends a second request to the server, so that the server responds to the second request and, based on the second authorization, stores the first file ciphertext in the first shared point. The first file ciphertext is obtained by encrypting the first file.

19. A file security sharing method, characterized by, include: The client obtains description information of the first sharing point in the sharing scenario managed by the second publisher from the service side; wherein, the sharing scenario is created by the service side and belongs to the creator; the sharing scenario has a corresponding second cloud key, which is stored on the service side and belongs to the creator; the second publisher has a second authorization, which indicates that the second publisher is allowed to call the second cloud key; file publishing is allowed in the first sharing point; In response to the second operation of the second publisher on the first shared point, the client generates a second request, wherein the second request is used to request that the first file to be published be published to the first shared point; The client sends a second request to the server, causing the server to respond to the second request and store the first file ciphertext in the first sharing point based on the second authorization; wherein, the first file ciphertext is obtained by encrypting the first file with a fourth key, the fourth key being obtained by the server based on the second authorization possessed by the second publisher, accessing a third cloud key corresponding to the first sharing point and stored on the server through the second cloud key, and decrypting the fourth key ciphertext using the third cloud key; the first file ciphertext can be opened by subscribers with third authorization, the third authorization indicating that the subscriber is allowed to call the third cloud key.

20. The method of claim 19, wherein, Before the step of the client obtaining the description information of the first sharing point in the sharing scenario managed by the second publisher from the server side, the following steps are also included: The client obtains description information about the sharing scenario managed by the second publisher from the server side; The client responds to the second publisher's sixth operation for the sharing scenario by generating a sixth request, wherein the sixth request is used to request the creation of a sharing point in the sharing scenario; The client sends a sixth request to the server, so that the server responds to the sixth request and creates a first sharing point in the sharing scenario; wherein the first sharing point has a corresponding third cloud key, the third cloud key is used to encrypt a fourth key, the fourth key is used to encrypt files published in the first sharing point, and the third cloud key is allowed to be accessed by a second cloud key for at least decryption.

21. The method of any one of claims 19-20, wherein, The service side includes a server and a cloud key management system, and the method further includes: The client receives a fourth key from the cloud key management system; wherein, the cloud key management system stores a second cloud key and a third cloud key, and the fourth key is obtained by the cloud key management system based on the second authorization, by accessing the third cloud key through the second cloud key, and by using the third cloud key to decrypt the ciphertext of the fourth key; The client uses the fourth key to encrypt the first file to be published, obtaining the ciphertext of the first file. The client sends the encrypted first file to the server on the service side.

22. A file security sharing method, characterized by, include: The client obtains description information of a first shared point that the subscriber has permission to open from the server side; wherein, in a sharing scenario, the first shared point has a corresponding first cloud key, which is stored on the server side and belongs to the creator; the first shared point has a corresponding third cloud key, which is stored on the server side, and the authorization and issuance of the third cloud key are controlled by the first cloud key; the first shared point allows the publication of files encrypted with a fourth key; the subscriber has a third authorization, which indicates that the subscriber is allowed to call the third cloud key, and is issued by the first publisher authorized by the creator to the subscriber by calling the first cloud key; In response to the subscriber's third operation on the second file in the first shared point, the client generates a third request, which requests to open the specified second file, which is any file in the first shared point; A third request is sent to the service side, so that the service side responds to the third request and, based on the third authorization, calls the third cloud key to decrypt the fourth key ciphertext, thereby obtaining the fourth key, which can be used to decrypt the second file ciphertext; The client opens the second file.

23. The method of claim 22, wherein, The service side includes a server and a cloud key management system, and the method further includes: The client receives a fourth key from the cloud key management system; wherein the cloud key management system stores the third cloud key, and the fourth key is obtained by the cloud key management system based on the third authorization, using the third cloud key to decrypt the ciphertext of the fourth key; The client receives the encrypted second file from the server; The client uses the fourth key to decrypt the ciphertext of the second file and obtain the second file.

24. A sharing scenario processing method for file security sharing, characterized in that, include: In response to the fourth operation, the client sends a fourth request to the server, which is used to request the creation of a sharing scenario for the creator. The client receives from the server a description of the sharing scenario created for the creator, as well as descriptions of the first cloud key and the second cloud key. The sharing scenario allows the creation of at least one sharing point, and the sharing point allows the publication of files. The first cloud key and the second cloud key correspond to the sharing scenario, belong to the creator, and are stored on the server. In response to the creator's fifth operation, the client generates a fifth request, wherein the fifth operation includes specifying at least one publisher; the fifth request is used to request that the usage rights of the first cloud key and / or the second cloud key be granted to the at least one publisher; The client sends a fifth request to the service side to enable the service side to issue a corresponding authorization for the at least one publisher. The authorization indicates that the at least one publisher is allowed to invoke the service side's first cloud key and / or second cloud key to enable the at least one publisher to issue authorizations for subscribers of the sharing point and / or publish files in the sharing point.

25. The method of claim 24, wherein, Also includes: The client responds to the creator's sixth operation for the sharing scenario by generating a sixth request, wherein the sixth request is used to request the creation of a sharing point in the sharing scenario; The client sends a sixth request to the server, so that the server responds to the sixth request and creates a first sharing point in the sharing scenario; wherein the first sharing point has a corresponding third cloud key, the third cloud key is used to encrypt a fourth key, the fourth key is used to encrypt files published in the first sharing point, and the third cloud key is allowed to be accessed by a second cloud key for at least decryption.

26. The method of any one of claims 24-25, wherein, Also includes: The client responds to the eighth operation by the creator regarding the authorization held by the subscriber by generating an eighth request; The client sends the eighth request to the server to revoke the authorization held by the subscriber; And / or, In response to the creator’s ninth action on the publisher, the client generates a ninth request, which requests the deletion of the publisher. The client sends the ninth request to the server so that the server revokes the authorization held by the publisher.

27. The method of any one of claims 24-25, wherein, The service side also stores a fifth cloud key corresponding to the sharing scenario. The first cloud key and the second cloud key belong to the fifth cloud key, which in turn belongs to the creator. The method further includes: In response to the creator's seventh operation for the sharing scenario, the client generates a seventh request, wherein the seventh request is used to request that the owner of the sharing scenario be changed to a new owner; The client sends a seventh request to the server to cause the server to change the fifth cloud key to belong to the new owner.

28. A service-side system, comprising: include: Storage unit, configured to store predetermined computer instructions; The processing unit is configured to execute the predetermined computer instructions to implement the method of any one of claims 1 to 15.

29. A client, comprising: include: Storage unit, configured to store predetermined computer instructions; The processing unit is configured to execute the predetermined computer instructions to implement the method of any one of claims 16 to 18; or to implement the method of any one of claims 19 to 21; or to implement the method of any one of claims 22 to 23; or to implement the method of any one of claims 24 to 27.

30. A computer readable storage medium storing a computer program, wherein the computer program comprises instructions that, when executed by a computer, cause the computer to perform the method of any one of claims 1-29. When the computer program is executed by a processor, it causes the processor to perform the method as described in any one of claims 1 to 15, or the method as described in any one of claims 16 to 27.

31. A computer program product comprising a computer program, characterised in that, When the computer program is run, it causes the computer to perform the method of any one of claims 1 to 15, or to perform the method of any one of claims 16 to 27.

Images