Secure file sharing method, sharing scene processing method and related products

Abstract

The invention discloses a file security sharing method, a sharing scene processing method and a related product, relates to the technical field of data security, and constructs a set of file security sharing scheme suitable for multiple roles in combination with a cloud key technology. The scheme mainly comprises the following steps: a creator owns the ownership of a sharing scene, and authorizes the use right of a first cloud key for issuing a third authorization to a subscriber and the use right of a second cloud key for publishing a file at a sharing point in the sharing scene to one or more different publishers; a publisher is enabled to issue authorization to a subscriber on behalf of a creator, and / or publish a file in a shared point. The scheme is not only suitable for an application scene containing multiple roles, but also can perform more flexible and fine authority management on the multiple roles, so that the management and control capability and management efficiency of a file owner and other possible roles on the shared file are improved, and the security and controllability of the shared file are improved.

Description

Technical Field

[0001] The present application relates to the field of data security technology, and in particular to a method for securely sharing files and a method for processing sharing scenarios. In addition, the present application also relates to a service-side system, a client, a computer-readable storage medium, and a computer program product. Background Art

[0002] Traditional file sharing technology involves relatively simple user roles. For example, in some network disk products, user U1 wants to share a file with user U2. The implementation process usually includes: user U1 uses the key to encrypt the file to be shared and upload it to the network disk, and sends the sharing link to user U2; then user U2 obtains the encrypted file from the network disk through the sharing link, receives the decryption key at the same time or separately and decrypts it, and then obtains the plain text of the file, which can be viewed, edited, etc.

[0003] In such a solution, once user U1 has shared the file, it is difficult to control the behavior of user U2, and it is difficult to ensure that the file is only shared with the intended user and not shared 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] In addition, the inventors have found that in some file sharing-related application scenarios, the user roles involved are more complex and diverse. At this time, the use of traditional file sharing technology cannot meet the needs of more sophisticated management and control of multiple roles. Summary of the invention

[0005] One purpose of this application is to provide a file sharing solution that can meet the needs of multiple roles for flexible and detailed management and control of files while ensuring that files are securely shared with designated users, thereby improving the ability to manage and control shared files.

[0006] The first aspect of the present application provides a method for secure file sharing, characterized in that a service side creates a sharing scenario belonging to a creator, the sharing scenario includes a first sharing point, and files are allowed to be published in the first sharing point; 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 comprises: the service side receives a first request from a first publisher, the first request is used to request the issuance of an authorization for a specified subscriber, wherein the first publisher has a first authorization, and the first authorization indicates that the first publisher is allowed to call the first cloud key of the service side; the service side responds to the first request, and based on the first authorization, calls the first cloud key to issue a third authorization for the subscriber, so that the subscriber has the authority to open the file published in the first sharing point; wherein the third authorization indicates that the subscriber is allowed to call the third cloud key of the service side.

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

[0008] In combination with the first aspect, in a possible implementation, the service side also stores a second cloud key, the second cloud key corresponds to the sharing scenario and belongs to the creator, and 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 a second publisher, the second request is used to request that the first file to be published be published to the first sharing point, wherein the second publisher has a second authorization, and the second authorization indicates that the second publisher is allowed to call the second cloud key of the service side; the service side responds to the second request, 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 service side stores the first file ciphertext in the first sharing point, and the first file ciphertext is 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 combination with the first aspect, in a possible implementation manner, 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;

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

[0011] In combination with the first aspect, in a possible implementation, the method also includes: the service side receives a third request from the subscriber, the third request is used to request to open a specified second file, and the second file is any file in the first sharing point; the service side responds to the third request, based on the third authorization owned by the subscriber, calls the third cloud key to decrypt the fourth key ciphertext to obtain a fourth key, and the fourth key can be used to decrypt the second file ciphertext to allow the subscriber to open the second file.

[0012] In combination with the first aspect, in a possible implementation, the service side includes a server and a cloud key management system, and the method includes: the server sends the second file ciphertext to the subscriber; the cloud key management system sends 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 combination with the first aspect, in a possible implementation, the method further includes: the service side receives an eighth request from the first publisher or creator, the eighth request being used to request deletion of the subscriber; and the service side revokes the third authorization.

[0014] In combination with the first aspect, in a possible implementation, the method also includes: the service side receives a ninth request from the creator, the ninth request is used to request deletion of the first publisher and / or the second publisher; the service side revokes the first authorization and / or the second authorization.

[0015] In combination with the first aspect, in a possible implementation, 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.

[0016] In combination with the first aspect, in a possible implementation, the method also includes: the service side receives a seventh request from the creator, the seventh request is used to request to change the owner of the sharing scene to a new owner; the service side modifies the fifth cloud key to belong to the new owner.

[0017] In combination with the first aspect, in a possible implementation, the method also includes: the service side receives a fourth request, and the fourth request is used to request to create a sharing scene for the creator; the service side responds to the fourth request and creates a sharing scene for the creator; the service side generates a first cloud key and a second cloud key corresponding to the sharing scene.

[0018] In combination with the first aspect, in a possible implementation, the method also includes: the service side receives a fifth request from the creator, and the fifth request is used to request that the use rights of the first cloud key and / or the second cloud key be authorized to a designated user; the service side responds to the fifth request and issues a corresponding authorization to the designated user, and the authorization indicates that the designated user is allowed to call the first cloud key and / or the second cloud key of the service side.

[0019] In combination with the first aspect, in a possible implementation manner, the method further includes: the service side issues a self-authorization for the creator, and the self-authorization indicates that the creator is allowed to call the first cloud key and / or the second cloud key.

[0020] In combination with the first aspect, in a possible implementation, the method also includes: the service side receives a sixth request from a second publisher or creator, and the sixth request is used to request to create a sharing point in a sharing scenario; the service side responds to the sixth request and creates a first sharing point in the sharing scenario; the service side generates a third cloud key corresponding to the first sharing point; the service side uses the third cloud key to encrypt a fourth key to obtain a fourth key ciphertext.

[0021] In combination with the first aspect, in a possible implementation, the service side includes a server and a cloud key management system, and the method includes: the server receives a sixth request from a second publisher or creator, and the sixth request is used to request to create a sharing point in a sharing scenario; the server responds to the sixth request and 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 the second publisher or creator; the cloud key management system uses the third cloud key to encrypt the fourth key to obtain a fourth key ciphertext; and the server stores the fourth key ciphertext.

[0022] The second aspect of the present application provides a method for secure file sharing, including: a client obtains 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, which is stored on the service side and belongs to the creator; the first publisher has a first authorization, and the first authorization indicates that the first publisher is allowed to call the first cloud key; files are allowed to be published in the first sharing point; the client generates a first request in response to a first operation of the first publisher on the first sharing point, wherein the first operation includes an operation of specifying a subscriber, and the first request is used to request the issuance of an authorization for the specified subscriber; the client sends a first request to the service side, so that the service side responds to the first request and calls the first cloud key based on the first authorization to issue a third authorization for the subscriber; wherein the third authorization enables the subscriber to have the authority to open files in the first sharing point.

[0023] In combination with the second aspect, in a possible implementation, the method also includes: the client generates an eighth request in response to the eighth operation of the first publisher regarding the third authorization; the client sends the eighth request to the service side, so that the service side responds to the eighth request and revokes the third authorization based on the first authorization.

[0024] In combination with the second aspect, in a possible implementation, the first publisher also has a second authorization, and the second authorization indicates that the first publisher is allowed to call the second cloud key of the service side; the second cloud key corresponds to the sharing scenario and belongs to the creator; the method also includes: the client generates a second request in response to the second operation of the second publisher on the first sharing point, wherein the second request is used to request that the first file to be published be published to the first sharing point; the client sends a second request to the service side, so that the service side responds to the second request, and based on the second authorization, stores the first file ciphertext in the first sharing point, and the first file ciphertext is obtained by encrypting the first file.

[0025] The third aspect of the present application provides a method for secure file sharing, comprising: a client obtains 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, 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; the first sharing point allows the release of files; the client generates a second request in response to the second operation of the second publisher on the first sharing point, wherein the second request is used to request that the first file to be released be released to the first sharing point; the client sends a second request to the service side, so that the service side stores the first file ciphertext in the first sharing point in response to the second request based on the second authorization; wherein the first file ciphertext is obtained by encrypting the first file. .

[0026] In combination with the third aspect, in a possible implementation method, before the step of the client obtaining the description information of the first sharing point in the sharing scene managed by the second publisher from the service side, it also includes: the client obtaining the description information of the sharing scene managed by the second publisher from the service side; the client generates a sixth request in response to the sixth operation of the second publisher on the sharing scene, wherein the sixth request is used to request the creation of a sharing point in the sharing scene; the client sends the sixth request to the service side, so that the service side creates a first sharing point in the sharing scene in response to the sixth request; 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 allows access by the second cloud key for at least decryption.

[0027] In combination with the third aspect, in a possible implementation, the service side includes a server and a cloud key management system, and the method also includes: the client receives a fourth key from the cloud key management system; wherein the cloud key management system stores the second cloud key and the 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 using the third cloud key to decrypt the fourth key ciphertext; the client uses the fourth key to encrypt the first file to be published to obtain the first file ciphertext; the client sends the first file ciphertext to the server of the service side.

[0028] The fourth aspect of the present application provides a method for secure file sharing, characterized in that it includes: a client obtains description information of a first sharing point that a subscriber has opening authority from a service side; wherein the first sharing point has a corresponding third cloud key, the third cloud key is stored on the service side, and the first sharing point allows the publication of files encrypted by a fourth key; the subscriber has a third authorization, and the third authorization indicates that the subscriber is allowed to call the third cloud key; the client generates a third request in response to the subscriber's third operation on the second file in the first sharing point, and the third request is used to request to open a specified second file, and the second file is any file in the first sharing point; a third request is sent to the service side, so that the service side responds to the third request, based on the third authorization, calls the third cloud key to decrypt the fourth key ciphertext, and obtains the fourth key, and the fourth key can be used to decrypt the second file ciphertext; the client opens the second file.

[0029] In combination with the fourth aspect, in a possible implementation, the service side includes a server and a cloud key management system, and the method also 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 fourth key ciphertext; the client receives the second file ciphertext from the server; the client uses the fourth key to decrypt the second file ciphertext to obtain the second file.

[0030] The fifth aspect of the present application provides a sharing scenario processing method for secure file sharing, comprising: the client sends a fourth request to the service side in response to a fourth operation, the fourth request being used to request the creation of a sharing scenario for the creator; the client receives description information of the sharing scenario created for the creator from the service side, 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 the publishing of files; 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 service side; the client generates a fifth request in response to the creator's fifth operation, wherein the fifth operation includes an operation of specifying at least one publisher; the fifth request is used to request the authorization of the use right of the first cloud key and / or the second cloud key to the at least one publisher; the client sends a fifth request to the service side so that the service side issues 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 service side, so that the at least one publisher can issue authorization for the subscriber of the sharing point and / or publish files in the sharing point.

[0031] In combination with the fifth aspect, in a possible implementation, the method also includes: the client generates a sixth request in response to the creator's sixth operation on the sharing scenario, 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 service side, so that the service side creates a first sharing point in the sharing scenario in response to the sixth request; 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 allows access to the second cloud key for at least decryption.

[0032] In conjunction with the fifth aspect, in a possible implementation, the method further includes: the client generates an eighth request in response to an eighth operation of the creator on the authorization owned by the subscriber; the client sends the eighth request to the service side, so that the service side revokes the authorization owned by the subscriber;

[0033] In combination with the fifth aspect, in a possible implementation, the method also includes: the client generates a ninth request in response to the creator's ninth operation on the publisher, and the ninth request is used to request deletion of the publisher; the client sends the ninth request to the service side so that the service side revokes the authorization held by the publisher.

[0034] In combination with the fifth aspect, in a possible implementation, 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. The method also includes: the client generates a seventh request in response to the creator's seventh operation on the sharing scene, wherein the seventh request is used to request that the owner of the sharing scene be changed to a new owner; the client sends 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 the present application provides a sharing scenario processing method for secure file sharing, including: a service side receives a fourth request, the fourth request is used to request the creation of a sharing scenario for a creator; the service side responds to the fourth request and 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.

[0036] In combination with the sixth aspect, in a possible implementation manner, the method further includes: the service side sends description information of the sharing scenario, and description information of the first cloud key and the second cloud key to the client.

[0037] In combination with the sixth aspect, in a possible implementation, the method further includes: the service side issues a self-authorization for the creator, and the self-authorization indicates that the creator is allowed to call the first cloud key and / or the second cloud key.

[0038] In combination with the sixth aspect, in a possible implementation, the method also includes: the service side receives a fifth request from the creator, and the fifth request is used to request that the use rights of the first cloud key and / or the second cloud key be authorized to a designated user; the service side responds to the fifth request and issues a corresponding authorization to the designated user, and the authorization indicates that the designated user is allowed to call the first cloud key and / or the second cloud key on the service side.

[0039] In combination with the sixth aspect, in a possible implementation, the method includes: the service side receives a sixth request from a second publisher or creator, and the sixth request is used to request to create a sharing point in a sharing scenario; the service side responds to the sixth request and creates a first sharing point in the sharing scenario; the service side generates a third cloud key corresponding to the first sharing point; the service side uses the third cloud key to encrypt the fourth key to obtain a fourth key ciphertext.

[0040] In combination with the sixth aspect, in a possible implementation, the service side includes a server and a cloud key management system, and the method includes: the server receives a sixth request from the creator, and the sixth request is used to request to create a sharing point in a sharing scenario; the server responds to the sixth request and 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 the second publisher or creator; the cloud key management system uses the third cloud key to encrypt the fourth key to obtain a fourth key ciphertext; and the server stores the fourth key ciphertext.

[0041] In combination with the sixth aspect, in a possible implementation, the method also includes: the service side receives a ninth request from the creator, the ninth request is used to request deletion of the specified publisher; the service side revokes the authorization of the publisher regarding the first cloud key and / or the second cloud key.

[0042] In combination with the sixth aspect, in a possible implementation, the method also includes: the service side receives a seventh request from the creator, the seventh request is used to request to change the owner of the sharing scene to a new owner; the service side modifies the first cloud key and the second cloud key to belong to the new owner.

[0043] In combination with the sixth aspect, in a possible implementation, 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; the method also includes: the service side receives a seventh request from the creator, and the seventh request is used to request to change the owner of the sharing scene to a new owner; the service side modifies the fifth cloud key to belong to the new owner.

[0044] The seventh aspect of the present application provides a service-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 possible method of the first aspect.

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

[0046] The ninth aspect of the present application provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, the processor executes 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 the present application provides a computer program product, comprising a computer program, which, when executed, enables a computer to execute any one of the methods of the first aspect, the second aspect, the third aspect, the fourth aspect or the fifth aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0048] Figure 1 The following is a schematic diagram of the system architecture of an exemplary application scenario of the present application.

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

[0050] Figure 3 A flowchart of an exemplary processing method for a sharing scenario for secure file sharing provided in an embodiment of the present application.

[0051] Figure 4 An exemplary flowchart of creating a sharing point in a new sharing scenario is provided for an embodiment of the present application.

[0052] Figure 5 A flowchart of an exemplary method for secure file sharing provided in an embodiment of the present application.

[0053] Figure 6 A flowchart of another exemplary method for secure file sharing provided in an embodiment of the present application. DETAILED DESCRIPTION

[0054] In order to clearly and completely describe the technical solution of the present application, further explanation will be given below in conjunction with embodiments and drawings.

[0055] As mentioned above, the user roles involved in some file sharing-related application scenarios may be more complex and diverse, not just the sharing user A and the shared user B in the above example. For example, in some cases, the file owner may not have the energy to share with different users one by one and manage the shared files, but hopes to authorize part of the permissions to other people (such as user C) to share and manage on their behalf. There are at least three user roles involved in this application scenario. User A needs to assign more sufficient permissions to user C so that he can share and manage the shared files on his behalf, and also needs to retain the ability to control user C and user B. In other more complex application scenarios, there may be more than three user roles involved. The use of traditional file sharing technology cannot meet the above-mentioned needs for fine control of multiple roles.

[0056] Cloud key technology is a technology previously developed by the applicant, which mainly refers to storing keys on the service side (rather than on the terminal side) and managing key usage to improve the security of keys without affecting key usage. The file security sharing solution of this application introduces cloud key technology to improve the security of file sharing, and on this basis, further optimizes it considering the application scenarios of multiple roles, and constructs a file security sharing architecture and implementation solution based on multiple roles. This solution is not only suitable for application scenarios involving multiple roles, but also can perform more flexible and detailed permission management for multiple roles, improve the control and management capabilities and efficiency of file owners and other possible roles over shared files, and improve the security and controllability of shared files.

[0057] For ease of understanding, the following will first introduce an exemplary application scenario architecture diagram of the file sharing method of the present application, and then introduce the steps performed by each interactive terminal in the file sharing solution in the application scenario.

[0058] See also Figure 1 and Figure 2 , the application scenario may include the client side and the service side.

[0059] The client in the embodiment of the present application may be in the form of an app, a mini-program, a web page, a desktop, etc., which may be installed, set or embedded in a terminal. The terminal may include but is not limited to terminal devices such as mobile phones, tablet computers, personal computers (PCs), wearable devices, Internet of Things devices, Internet of Vehicles devices, augmented reality (AR) / virtual reality (VR) devices, personal digital assistants (PDAs), etc. The present application does not limit the specific product forms / types of the client and terminal.

[0060] Since users in an application scenario may have multiple roles, for the convenience of description and distinction, in the embodiment of the present application, 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 a specific subscriber is called the first publisher; and the user with whom the file is shared is called the subscriber.

[0061] It should be noted that the second publisher and the first publisher may be the same user or different users. In some cases, the second publisher and the first publisher are the same user, that is, the same user publishes the file and shares the file with specific subscribers. The user may also be called the publisher. Figure 1 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, the clients used by the two can be the second client B and the second client A, respectively. Figure 2 shown.

[0062] It is understandable that in some cases, the creator can publish the file himself and / or share it with specific subscribers, in which case the creator and the second publisher and / or the first publisher can be the same user. In this case, 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 can also be understood that in addition to the above-mentioned user roles and clients, other roles and corresponding clients may be involved in some application scenarios, which is not limited in this application.

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

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

[0066] The server is mainly used to provide business services to the client. For example, in a software product with a data asset sharing function, its client can be developed as an app for users to download and use, and the server provides business services to the client to realize user registration, login, creation and / or management of the user's data asset library, as well as app business functions such as file upload, download, and sharing. Different users can complete identity registration and login on the server through the client, and then use the various business functions in the client according to their respective needs. Optionally, the server can also be divided according to business functions and other conditions when necessary. For example, the server may include an authentication service module, a user service module, and the like.

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

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

[0069] For example, in order to call the services provided by the cloud key management system, the server can first register in the cloud key management system using the server key used to identify 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 for the user of the client, which can contain the user's ID and other identity information in the cloud key management system, and returns the ticket to the client. In this way, when the client needs to interact with the cloud key management system, it can carry the aforementioned ticket in the interactive 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 (UserToken). In the subsequent period of time, if the client needs to call some functional services in the cloud key management system or request the cloud key management system to perform some operations, it can carry the user token so that the cloud key management system can provide it with necessary services.

[0070] Each user, such as creators, publishers, and subscribers, can have their own personal key to identify themselves and allow other interacting parties to verify their identity and permissions. A personal key can be a pair of asymmetric keys, including a corresponding public key and a private key. Before use, the public key of the personal key can be sent to the service side and registered on the service side.

[0071] For example, Figure 2 Taking the system as an example, after a client used by a user logs in to the server, when it is necessary to register the user's 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 carries the public key in the user's personal key and the aforementioned user token in the interactive information, so that the cloud key management system registers the public key of the user's personal key, and then returns the corresponding personal key identifier (keyLabel) to the client. The personal key identifier can be, for example, a string that has been processed by the cloud key management system and signed using the private key of the cloud key management system. Subsequently, during the interaction between the client and the cloud key management system, if necessary, the personal key identifier can be carried in the interactive information to indicate its own identity and facilitate verification by the cloud key management system.

[0072] The following takes the case where the creator uses the first client, the second publisher uses the second client B, the first publisher uses the second client A, and the subscriber uses the third client as an example, and further introduces the processes of (i) creating a sharing scene, (ii) the creator authorizing the publisher, (iii) creating a sharing point in the sharing scene, (iv) the second publisher publishing files in the sharing point, (v) the first publisher authorizing the subscriber, (vii) the subscriber viewing the files in the sharing point, (vii) revoking authorization, and (viii) the creator changing the owner of the sharing scene. It should be noted that the above serial numbers are not used to limit the execution order of these processes and the steps therein, and the order in which they are executed is determined by the internal logic of the solution.

[0073] (I) Create a sharing scenario

[0074] See also Figure 3 , Figure 3 A flowchart of an exemplary processing method for a sharing scenario for secure file sharing provided in an embodiment of the present application.

[0075] S101: In response to a fourth operation, the first client sends a fourth request to the service side.

[0076] S102: The service side creates a sharing scene for the creator in response to the fourth request.

[0077] When the creator wants to create a sharing scene, he can perform an operation on the first client (for the sake of distinction, referred to as the fourth operation in the embodiment of the present application), such as clicking the "add scene" control in the client interface displayed on the first client. In response to the creator's operation, the first client sends a fourth request to the service side.

[0078] It should be noted that the operations performed by the user on the client in the embodiments of the present 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 the present application does not limit this.

[0079] The fourth request is used to request the creation of a sharing scene for the creator. In some possible implementations, the fourth request may include the identity information of the creator. The identity information of the creator may exemplarily include one or more information such as the account number registered by the creator on the service side or the server, the name of the creator, and the personal key identifier of the creator, which can uniquely identify the identity of the creator alone or in combination.

[0080] In some possible implementations, the service side establishes a sharing scene, assigns a scene ID to the sharing scene that can be used to uniquely identify the scene, and associates the scene ID of the sharing scene with the creator's identity information (such as the creator's account registered on the service side, the creator's personal key identifier, etc.), or configures the owner information of the sharing scene to the creator's identity information, thereby granting ownership of the sharing scene to the creator.

[0081] In some possible implementations, the fourth request may also include other possible information, such as the name of the sharing scene, etc. In this way, when the service side creates a sharing scene for the creator, it can use the name carried in the fourth request to name the created sharing scene, so that the user can conveniently define the name of his own sharing scene.

[0082] As mentioned above, each user can have his or her own personal key. When sending a request to the service side, 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 to the service side in the request. In this way, after receiving the request, the service side can first use the public key of the user's personal key to verify the signature carried in the request. If the verification is successful, it can be considered that the request is indeed initiated by the user, and the signed information in the request has not been tampered with. Then the service side will perform other steps required to respond to the request.

[0083] Exemplarily, the creator has his own personal key, and the first client can use the private key in the creator's personal key to sign certain information in the fourth request (such as the creator's identity information, etc.), and then send the signature to the service side in the fourth request. The service side can obtain the public key of the creator's personal 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 is indeed initiated by the creator, and the signed information in the fourth request has not been tampered with, and then create a sharing scene for the creator.

[0084] It is understandable that in the following text, for requests initiated by the first publisher, the second publisher, the subscriber and other users, the corresponding clients can also sign with the private keys of their respective personal keys. The implementation process can refer to the above introduction and will not be repeated in the following text.

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

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

[0087] The second cloud key is mainly used for data encryption. The creator can distribute the right to use the second cloud key to other users (for example, issue a second authorization to the second publisher), so that the second publisher can use the second cloud key to publish encrypted files in the sharing scenario instead of the creator. At the same time, since the second cloud key belongs to the creator, the creator can also control the second publisher and its publishing behavior by controlling the second cloud key.

[0088] The first cloud key is mainly used for authorization issuance. The creator can distribute the use rights of the first cloud key to other users (for example, issuing the first authorization to the first publisher), so that the first publisher can use the first cloud key to issue the third authorization to the subscriber instead of the creator, so that the subscriber can decrypt the files published in the sharing scenario and then open them. At the same time, since the first cloud key belongs to the creator, the creator can also control the first publisher and its issuance behavior by controlling the first cloud key, and can also indirectly control the third authorization issued by it.

[0089] Other relevant characteristics of these two cloud keys and how they are used in different processes will be further explained later.

[0090] It should be noted that the service side can generate the first cloud key and the second cloud key at the same time, or generate them separately, and this application does not limit this.

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

[0092] In some possible implementations, the service side may first generate a fifth cloud key corresponding to the sharing scenario and belonging to the creator, and then configure the generated first cloud key and second cloud key to belong to the fifth cloud key. In this way, the first cloud key and the second cloud key can be controlled by the fifth cloud key, and the fifth cloud key is controlled by the creator, thereby indirectly realizing the function of attributing the ownership of the first cloud key and the second cloud key to the creator. Exemplarily, the service side may configure the owner information of the fifth cloud key as the identity information of the creator, such as the personal key identifier of the creator, etc.; and then configure the owner information of the first cloud key and the second cloud key 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 use the fifth cloud key to generate the first cloud key and the second cloud key, and this application does not limit this.

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

[0095] S104, the service side returns the description information of the sharing scenario and the description information of the first cloud key and the second cloud key to the first client.

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

[0097] The description information of the cloud key may exemplarily include a key identifier of the cloud key, etc. It is understandable that when the implementation mode of indirect control of the fifth cloud key is adopted, the service side may also return the description information of the fifth cloud key to the first client.

[0098] The service side may return these description information to the first client separately or together, and this application does not limit this. The first client stores these description information and can use them in subsequent interactions with the service side, or display some of the information to the user of the first client when necessary, such as displaying the scene name, scene creation time, etc.

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

[0100] It should be noted that the above exemplarily introduces some implementation methods for the creator to create a sharing scene for himself. In addition, other people (such as any first user) can also request the service side to create a sharing scene for the creator. The implementation method can be similar to the above implementation method or different, and this application does not limit this. Exemplarily, the first user can use the aforementioned method to create a sharing scene for himself, and then use the method of changing the owner of the sharing scene described later to transfer the ownership of the sharing scene to the creator. Also exemplarily, the first user can perform the aforementioned fourth operation on his own client, and include the creator's identity information in the fourth request sent to the service side (of course, it can also include the first user's own identity information). In this way, after receiving the fourth request, the service side can also create a sharing scene for the creator and generate a corresponding cloud key.

[0101] (2) The creator authorizes the publisher

[0102] S105: The first client generates a fifth request in response to the creator's fifth operation.

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

[0104] The fifth request is used to request authorization of the use right of the first cloud key and / or the second cloud key to the specified user. In some implementations, the first client may obtain the identity information of the specified user from the service side, such as the account number registered by the specified user on the service side or the 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 identity information of the creator such as the personal key identifier of the creator, together in the fifth request.

[0105] S106: The first client sends a fifth request to the service side.

[0106] S107, the service side responds to the fifth request and issues a corresponding authorization to the specified user, where the authorization indicates that the specified user is allowed to call the first cloud key and / or the second cloud key of the service side.

[0107] The data structure of the authorization issued by the service side can be implemented in many ways. For example, in some implementations, the authorization includes: authorization ID, authorization target key identifier, and personal key identifier of the authorized person. The authorization may also include one or more information such as the personal key identifier of the authorizer, authorization ID, and authorization terms.

[0108] Authorization ID, mainly used to uniquely identify an authorization;

[0109] Authorization target key identifier, mainly used to describe which cloud key usage rights are authorized.

[0110] The personal key identifier of the authorized person is mainly used to describe to whom the right to use the cloud key is authorized. It can be understood that the authorized person here can be a user, a device, other keys, etc.

[0111] The personal key identifier of the authorizer, which is mainly used to describe which authorizer requested the issuance of the authorization;

[0112] Based on the authorization ID, it is mainly used to describe the authorization ID of the authorization used by the authorizer to request the issuance of the authorization, that is, the authorizer requests the issuance of the current authorization based on the authorization it owns.

[0113] Authorization terms are mainly used to describe the scope of restrictions on the authorized person's use of the cloud key, such as time information, number of times, operation restriction information, etc.

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

[0115] It can be seen that 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 correspondingly issue a first authorization to the first publisher and a second authorization to the second publisher.

[0116] The first authorization indicates that the first publisher is allowed to call the first cloud key of the service side. Exemplarily, the authorization target key identifier is the key identifier of the first cloud key; the personal key identifier of the authorized person is the personal key identifier of the first publisher; and the personal key identifier of the authorizer is the personal key identifier of the creator.

[0117] The second authorization indicates that the second publisher is allowed to call the second cloud key of the service side. Exemplarily, 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 person 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 the request is 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, the service side issues the first authorization and the second authorization to the user accordingly.

[0119] It is understandable that the creator can also use this implementation to request to authorize 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 may issue a self-authorization to the creator before issuing the authorization to the publisher. That is, after the aforementioned step S103, the following may also be included:

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

[0122] In some implementations, the self-authorization may include the first cloud key self-authorization and the second cloud key self-authorization. The first cloud key self-authorization is used to indicate that the creator is allowed to call the first cloud key on the service side; the second cloud key self-authorization is used to indicate that the creator is allowed to call the second cloud key on the service side; the first cloud key self-authorization and the second cloud key self-authorization have permissions that are obviously greater than the first authorization and the second authorization issued for the first publisher and the second publisher.

[0123] In some other implementations, when the fifth key is used for indirect control, the self-authorization includes the fifth cloud key self-authorization, which is used to indicate that the creator is allowed to call the fifth cloud key of the service side. The service side also issues the use authorization of the first cloud key and the use authorization of the second cloud key for the fifth cloud key, so that the creator can use the fifth cloud key self-authorization to indirectly control the first cloud key and the second cloud key.

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

[0125] In some possible implementations, the service side includes: 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 scene (such as scene ID), identity information of the corresponding publisher (such as an account registered by the publisher on the server), description information of the first authorization and / or the second authorization and / or self-authorization (such as authorization ID), etc., for subsequent query and use.

[0126] (III) Creating a Share Point in a Sharing Scenario

[0127] See also Figure 4 , Figure 4 A flowchart of some steps of an exemplary method for secure file sharing provided in an embodiment of the present application.

[0128] S201 : The second client B generates a sixth request in response to a sixth operation of the second publisher.

[0129] When the second publisher wants to create a new sharing point in a certain sharing scenario, he can perform an operation on the second client B for the sharing scenario (for the sake of distinction, referred to as the sixth operation in the embodiment of the present application). For example, the second publisher clicks the "New Sharing Point" control in the user interface displayed on the second client B. In response to the operation of 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 scene managed by the second publisher from the service side, and display part of the description information (such as the scene name, creator account, etc.) on the user interface so that the user can operate on the sharing scene.

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

[0132] S202: The second client B sends a sixth request to the service side.

[0133] S203: The service side creates a sharing point in the aforementioned sharing scenario in response to the sixth request.

[0134] In some possible implementations, the service side can verify that the initiator of the sixth request (i.e., the second publisher) does have the corresponding authority based on the description information of the second authorization, and then create a sharing point in the aforementioned sharing scenario. The service side can assign a sharing point ID that can be used for unique identification to the 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 possible information such as a share point name, a share point icon, etc. By carrying the name and icon, the service side can use these names and icons to name the created share point and set the icon, so that the user can easily define the name, icon and other interface display information of the share point.

[0136] It should be noted that one or more sharing points can be created in a sharing scenario. For the sake of distinction and explanation, a sharing point created at a certain time is referred to as the first sharing point, and this example is used to illustrate the solution. It is understandable that before the first sharing point is created, other sharing points, such as the second sharing point, etc., may have been created in the sharing scenario; after the first sharing point is created, other new sharing points, such as the third sharing point, etc., may also be created in the sharing scenario, and 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 issuance of the third cloud key can be controlled by the first cloud key. That is, when a user has the right to use the first cloud key (such as the creator or the first publisher with the first authorization), he can issue the authorization of the third cloud key for himself or others through the first cloud key.

[0139] The decryption use of the third cloud key can be controlled by the second cloud key. When a user has the right to use the second cloud key (such as the creator or the second publisher with the second authorization), he can access the third cloud key through the second cloud key and use the third cloud key to perform 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 the sharing scenario also have corresponding cloud keys respectively, and the cloud keys corresponding to different sharing points may generally be different.

[0141] S205, the service side uses the third cloud key to encrypt the fourth key to obtain the fourth key ciphertext.

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

[0143] The fourth key can be generated by the second publisher or owner and then transmitted to the service side for encryption, or it can be generated by the service side, which is not limited in this application.

[0144] In some possible implementations, after generating the third cloud key, the service side can issue a use authorization (hereinafter referred to as the fourth authorization for the sake of distinction) for the second cloud key. The fourth authorization indicates that the third cloud key is allowed to be accessed through the second cloud key for encryption and decryption, and the description information of the fourth authorization is returned to the second client B. Then the second client B sends the generated fourth key, the description information of the fourth authorization, and the personal key identifier of the second publisher together in a request to the service side. After receiving the request, the service side can call the second cloud key based on the second authorization owned by the second publisher, access the third cloud key based on the fourth authorization, encrypt the fourth key using the third cloud key, and obtain the fourth key ciphertext.

[0145] The fourth key ciphertext may be returned to the second client B, or may be stored on the service side, which is not limited in this application.

[0146] It should be noted that the first sharing point can be requested to be created by the second publisher or by the creator himself. That is, the execution subject of the above steps S201 to S202 can also be the first client. The sharing points included in a sharing scenario can include those created by the second publisher or by the creator, and this application does not limit this. The above steps exemplarily describe the creation process of the first sharing point, and the creation process of other sharing points can be similar.

[0147] It should also be noted that the steps of the creator authorizing the publisher (e.g., S105 to S107) can occur before the creation of the first sharing point (e.g., S201 to S205) or after the creation of the first sharing point, and this application does not limit the order of the steps. It is not difficult to understand that if the creator first authorizes the publisher, the subsequent creator and publisher may both create the first sharing point, and if the creator temporarily does not authorize the publisher, the creator may first create the first sharing point.

[0148] In some possible implementations, the service side includes: Figure 2In the case of the server and cloud key management system shown, step S203 can be performed by the server, and steps S204 to S205 can be performed by the cloud key management system. Optionally, the server can store the sharing point records in the sharing scene, such as description information of the sharing scene (such as scene ID), description information of the corresponding sharing point (such as sharing point ID, sharing point name), fourth key ciphertext, description information of the third cloud key (such as the key identifier of the third cloud key), etc., for subsequent query and use. In this way, the fourth key used to encrypt the first file cannot be obtained by the server providing business services, and can only be obtained by users on the terminal side with authority and the cloud key management system.

[0149] (IV) The second publisher publishes the file in the shared point

[0150] See also Figure 5 and Figure 6 , Figure 5 and Figure 6 A flowchart of two exemplary file security sharing methods provided in embodiments of the present application.

[0151] S206: The second client B generates a second request in response to the second operation of the second publisher on the first sharing point.

[0152] The file in the embodiment of the present application refers to a file in a broad sense, which may include data assets such as documents, pictures, videos, audios, folders, etc., and the present application does not limit its specific data format. The first file here may be a file in any possible form.

[0153] When the second publisher wants to publish a file in a shared point, he can perform an operation on the shared point on the second client B (for the sake of distinction, referred to as the second operation in the embodiment of the present application). For example, the second publisher clicks the "add new content" control in the user interface displayed on the second client B. In response to the operation of 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 scene managed by the second publisher from the service side, and display part of the description information (such as the sharing point name, the name and thumbnail of the published files 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 to publish the first file to be published to the first sharing point. In some possible implementations, the second request may include identity information of the second publisher, such as a personal key identifier of the second publisher, etc. The second request may also include description information of the second authorization, such as an ID of the second authorization, etc.

[0156] S207: The second client B sends a second request to the service side.

[0157] S208: The service side stores the first file ciphertext in the first sharing point in response to the second request, where the first file ciphertext is obtained by encrypting the first file with the fourth key.

[0158] In some implementations, the second client B may carry the first file to be published in the second request and send it to the service side together or separately. The service side encrypts it using the fourth key and stores it in the first sharing point.

[0159] In some other implementations, the second client may encrypt the first file to be published, and send the ciphertext of the first file to the service side alone 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. Exemplarily, the above method also includes:

[0161] S209, the second client B encrypts the first file using the fourth key to obtain a ciphertext of the first file;

[0162] S210, the second client B sends the ciphertext of the first file to the service side.

[0163] When the second client B does not have the fourth key, the service side may return the fourth key to the second client B. Exemplarily, step S208 may be replaced by the following steps S209 to S212.

[0164] S211, the service side responds to the second request, and based on the second authorization owned by the second publisher, the service side 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.

[0165] S212: The service side sends the fourth key to the second client B.

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

[0167] S210, the second client B sends the ciphertext of the first file to the service side.

[0168] Optionally, after step S210, the following may be included: S213: the service side returns the storage address of the first file ciphertext to the second client B.

[0169] Optionally, after receiving the first file or the first file ciphertext, the service side may allocate 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 first file ciphertext.

[0170] By adopting the above implementation, the second publisher completes the publishing of the first file. It is understandable that multiple files can be published in the first sharing point, and these files may include those published by the publisher or those published by the creator himself, and this application does not limit this. That is, the execution subject of the above steps S206, S207, S211, and S212 can also be the first client or the second client A. The above steps exemplarily describe the process of the first file, and the process of other files can be similar.

[0171] In some possible implementations, the service side may include: Figure 2 The server and cloud key management system shown, the aforementioned steps S209 and S213 can be performed by the server, and the steps S208 and S210 can be performed by the cloud key management system. Optionally, the server can store the file records of the published files, such as the description information of the sharing scene (such as the scene ID), the description information of the corresponding sharing point (such as the sharing point ID), the file ID of the first file, the storage address of the first file ciphertext, etc., for subsequent query and use.

[0172] In this way, only users with permission on the terminal side, such as the creator, the second publisher, and subsequent subscribers, can decrypt and open the first file when needed; the server stores the first file ciphertext and the fourth key ciphertext, but does not have the third cloud key, so it is difficult for the server providing business services to view the specific content of the first file; although the cloud key management system stores the third cloud key and can decrypt the fourth key, it does not have the first file ciphertext, so it is also difficult for the cloud key management system to view the specific content of the first file. Therefore, the above solution can achieve end-to-end security effects and further improve the security and privacy of shared files.

[0173] (V) The first publisher authorizes the subscriber

[0174] S214: The second client A generates a first request in response to the first operation of the first publisher on the first sharing point.

[0175] When the first publisher wants to allow a user to access a file in a share point, he can perform an operation on the share point on the second client A (for the sake of distinction, referred to as the first operation in the embodiment of the present application), and the first operation includes an operation of specifying a subscriber. For example, the first publisher clicks the "Add Subscriber" control corresponding to the first share point in the user interface displayed on the second client A, and then selects one or more users as subscribers. In response to the operation of the first publisher, the second client A generates 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 scene managed by the first publisher from the service side, and display part of the description information (such as the sharing point name, the name and thumbnail of the published files in the sharing point, etc.) on the user interface so that the user can operate on the sharing point.

[0177] The first request is used to request the issuance of an authorization for a specified subscriber. In some implementations, the second client A may obtain the subscriber's identity information from the service side, such as the subscriber's account number registered on the service side or the 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 identity information such as the personal key identifier of the first publisher in the first request.

[0178] S215, the second client A sends a first request to the service side.

[0179] S216: The service side responds to the first request and, based on the first authorization owned by the first publisher, calls the first cloud key to issue a third authorization for the designated subscriber.

[0180] The third authorization indicates that the subscriber is allowed to call the third cloud key on the service side. In this way, the subscriber has the authority to open the file published in the first sharing point.

[0181] The structure of the third authorization can be similar to the authorization issued by the aforementioned service side. Exemplarily, the authorization target key identifier in the third authorization is the key identifier of the third cloud key; the personal key identifier of the authorized person is the personal key identifier of the subscriber; the personal key identifier of the authorizer is the personal key identifier of the first publisher; and the authorization ID is the ID of the first authorization. Also exemplarily, the authorization terms can be restricted to allowing decryption, and the authorization terms can also include the authorization validity period, the number of authorization validity periods, etc. Among them, the authorization validity period is used to limit the time the subscriber uses the third authorization, and can exemplarily be a few days, months, years or permanently. The number of authorization validity periods is used to limit the number of times the subscriber uses the third authorization.

[0182] Optionally, the service side can use the first cloud key to sign some important information in the third authorization, obtain signature information, and carry the signature information in the third authorization. In this way, when a subsequent subscriber uses the authorization, the service side can first verify the signature information in the third authorization, and then call the third cloud key for decryption after the verification is passed.

[0183] Optionally, after S216, the service side may also return description information of the third authorization, such as the authorization ID of the third authorization, to the subscriber, so that the subscriber can understand which authorizations the subscriber has.

[0184] In some possible implementations, the service side includes: 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 the identity information of the subscriber (such as the account registered by the subscriber on the server), the description information of the corresponding sharing point (such as the sharing point ID), the description information of the third authorization (such as the authorization ID), etc.

[0185] It is understandable that when the creator has self-authorization, he or she can also authorize the subscriber. 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 view files in the sharepoint

[0187] S301: A third client generates a third request in response to a first operation of a subscriber on a second file in a first sharing point.

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

[0189] When a subscriber wants to open a file in a share point, he can perform an operation on the file on the third client (for the sake of distinction, referred to as the third operation in the embodiment of the present application), such as clicking a file icon or a file name control in the user interface displayed on the third client. The third client generates a third request in response to the subscriber's operation. Subscribers who are not subscribers to the first share point cannot even see the first share point and the files therein on their own clients.

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

[0191] The third request is used to request to open the specified second file. In some possible implementations, the third request may include the identity information of the subscriber, such as the account number registered by the subscriber on the service side or the server, the personal key identifier of the subscriber, 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 service side.

[0193] S303: In response to the third request, the service side calls the third cloud key to decrypt the fourth key ciphertext based on the third authorization owned by the subscriber to obtain the fourth key.

[0194] The fourth key can be used to decrypt the second file ciphertext to allow the subscriber to open the second file. In some implementations, the service side can directly use the fourth key to decrypt the second file ciphertext and return it to the third client so that the third client can open the second file for the subscriber to view. In other implementations, the second file ciphertext can be decrypted by the third client. That is, optionally, after step S301, the following steps S304 to S306 can also be included.

[0195] S304: The service side returns the fourth key to the third client.

[0196] S305: The service side sends the ciphertext of the 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 point are encrypted with the fourth key, after the third client obtains the fourth key, it can be allowed to directly decrypt other files in the shared point and open them within a certain period of time. For example, during the validity period of the subscriber's single login, the third client can be allowed to use the fourth key to decrypt other files in the first shared point; and when this login fails, the third client needs to re-initiate a third request to the service side.

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

[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 the memory.

[0201] In the above implementation, the subscriber can open the file published in the first sharing point because he has the third authorization, while other subscribers who are not subscribers of the first sharing point cannot decrypt the second file ciphertext and cannot open the corresponding file because they are not allowed to call the third cloud key and cannot call the third cloud key to decrypt the fourth key ciphertext. That is, the above method can ensure that only authorized subscribers can access the files in the corresponding sharing point.

[0202] In some possible implementations, the third client can be configured to prohibit downloading and forwarding, so that the subscriber can open, view, and even edit the second file in the third client when having a valid third authorization, such as writing notes on the second file, but cannot download the second file to other locations or forward it to other people. In this way, the security of file sharing can be further increased.

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

[0204] (VII) Revocation of Authorization

[0205] In addition to adding subscribers on behalf of the creator, the first publisher can also delete subscribers to manage the sharing points in the sharing scene. The creator has higher permissions. In addition to authorizing the publisher and adding subscribers personally, he can also delete the publisher or subscribers. In this way, both the creator and the publisher can perform more detailed permission allocation and management on the sharing scene and the content therein.

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

[0207] S217: The second client A generates an eighth request in response to the first issuer's eighth operation on the third authorization.

[0208] When the first publisher wants to prohibit a subscriber from accessing files in a share point, it can perform an operation on the second client A for the authorization of the subscriber in the share point (for the sake of distinction, it is referred to as the eighth operation in the embodiment of the present application). For example, the first publisher clicks on the subscriber list corresponding to the first share point in the user interface displayed on the second client A, and then selects one or more authorizations of the subscribers, such as selecting the aforementioned third authorization, and clicking the "Delete Authorization" control. In response to the operation of the first publisher, the second client A generates an eighth request.

[0209] In some possible implementations, the second client A can obtain the identity information and authorization description information of the subscriber 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 authorization validity period of the subscriber, etc.) on the user interface so that the user can perform operations based on the subscriber's authorization.

[0210] The eighth request is used to request to delete the authorization of the specified subscriber. In some implementations, the second client A can put the identity information of the subscriber, the description information of the third authorization, and the identity information of the first publisher such as the personal key identifier of the first publisher and the description information of the first authorization in the eighth request.

[0211] S218, the second client A sends an eighth request to the service side.

[0212] S219: The service side responds to the eighth request and revokes the third authorization based on the first authorization.

[0213] The service side may directly delete the third authorization, or may set the status of the third authorization from valid to invalid, thereby revoking the third authorization.

[0214] In some implementations, the process of a creator deleting a subscriber may be similar to the way the first publisher deletes a subscriber, with the main difference being that the creator may not need to provide the first authorization, or may provide a self-authorization that it owns.

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

[0216] S109: The first client generates a ninth request in response to the creator's ninth operation on the publisher.

[0217] When the creator wants to delete a subscriber and not allow the subscriber to manage subscribers and / or publish files on his behalf, he can perform an operation on the first client for the sharing scenario (for the sake of distinction, this is referred to as the ninth operation in the embodiment of the present application). For example, the creator clicks to select one or more publishers in the list of publishers corresponding to the sharing scenario in the user interface displayed on the first client, and clicks the "Delete Publisher" control. In response to the creator's operation, the first client generates a ninth request.

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

[0219] The ninth request is used to request to delete the authorization of the specified publisher. In some implementations, the first client can put the publisher's identity information, the description information of the first authorization and / or the second authorization, and the creator's identity information such as the creator's personal key identifier in the ninth request.

[0220] S110, the first client sends a ninth request to the service side.

[0221] S111, the service side revokes the authorization held by the publisher.

[0222] The service side can directly delete the authorization owned by the publisher, or set the status of the authorization from valid to invalid, thereby revoking the authorization. Exemplarily, when the publisher is the first publisher and / or the second publisher, the service side sets the first authorization and / or the second authorization to invalid accordingly.

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

[0224] (VIII) The creator changes the owner of the shared scene

[0225] S112: The first client generates a seventh request in response to the creator's seventh operation on the sharing scene.

[0226] When the creator wants to transfer the ownership of the entire sharing scene to other users, he or she can perform an operation on the sharing scene on the first client (for the sake of distinction, it is referred to as the seventh operation in the embodiment of the present application). For example, the user interface displayed on the first client displays all the sharing scenes belonging to the creator, and the creator clicks to select one or more sharing scenes and clicks the "Change Owner" control. In response to the creator's operation, the first client generates the seventh request.

[0227] The seventh request is used to request to change the owner of the shared scene to a new owner. In some implementations, the first client may put the identity information of the new owner and the identity information of the creator, such as the personal key identifier of the creator, in the seventh request.

[0228] S113, the first client sends a seventh request to the service side.

[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 above, when creating a sharing scenario, the service side can generate a fifth cloud key to control the first cloud key and the second cloud key. Compared with the method of directly attributing the ownership of the first cloud key and the second cloud key to the creator, the indirect control method through the fifth cloud key means that when the ownership of the sharing scenario needs to be changed, only the fifth cloud key needs to be modified, and the change operation is more convenient.

[0231] It is understandable that, when developing actual products, the functions implemented by the first client, the second client A, the second client B, and the third client may be partially or completely integrated into one client product.

[0232] The following is a supplementary explanation of the solution of the embodiment of the present application applied to an exemplary application scenario. For example, the aforementioned software product with data asset sharing function may include a user-oriented APP and a server that provides business services to the APP in the background. In addition, there is also a cloud key management system on the service side for providing cloud key related services.

[0233] This software product supports the file owner to flexibly add one or more other users as publishers according to actual needs, so that they can add subscribers on behalf of the file owner to share files, publish files on behalf of the file owner, and perform other possible management operations, such as revoking the subscriber's permission to open the file. Of course, the file owner can also manage the number and permissions of publishers, such as adding and deleting publishers according to actual needs. This approach can effectively ensure the security and controllability of shared files and improve management efficiency.

[0234] Exemplarily, user admin_A can establish his own knowledge base (corresponding to the aforementioned sharing scenario) through APP, and add one or more other users as publishers, so that they can manage the knowledge base on his behalf, for example, add user user_P1 as the first publisher and add user user_P2 as the second publisher. User admin_A or user user_P2 can create one or more courses in the knowledge base (corresponding to the aforementioned sharing points), and one or more files can be published in each course. When you want to share a course with a user user_S, user admin_A or user user_P1 can add the user user_S as a subscriber. In this way, user_S can open all the files in the course that he has the right to open in his own APP. It is understandable that user_S can not only view the files that have been currently published in the course, but also if the administrators who have the right to publish files, such as user admin_A or user user_P2, publish other files in the course, user_S can also view them without the need for administrators who have the right to add subscribers, such as user admin_A or user user_P1, to re-authorize.

[0235] The present application also provides a client, which may include:

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

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

[0238] The present application also provides a service-side system, which may include:

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

[0240] The second processing unit is configured to run the predetermined computer instructions to implement part or all of the steps implemented by the service side in any of the aforementioned implementations.

[0241] Those skilled in the art should understand that, in addition to the methods, clients, and service systems described above, the embodiments of the present application may also be provided as a computer-readable storage medium or a computer program product.

[0242] The methods performed by the service side and the client provided in the embodiments of the present application can be provided as a computer-readable storage medium. That is, a computer-readable storage medium is also provided in the embodiments of the present application, storing a computer program, which, when executed by a processor, enables the processor to perform some or all of the steps in any implementation of the aforementioned processing method or verification method.

[0243] The present application may also take the form of a computer program product embodied on one or more computer readable storage media having computer usable program code embodied therein.

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

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

[0246] It should also be understood that, in order to facilitate the clear description of the technical solutions of the embodiments of the present application, the words "first", "second", etc. are used in the embodiments of the present application to distinguish between the same items or similar items with substantially the same functions and effects, or concepts with certain differences. Those skilled in the art can understand that the words "first", "second", etc. do not limit the quantity and execution order, and the words "first", "second", etc. do not necessarily limit the difference.

[0247] The same or similar parts between the various embodiments in this specification can be referred to each other. As long as there is no logical contradiction, different embodiments can be combined with each other.

Claims

1. A method for secure file sharing, characterized in that: The service side creates a sharing scenario belonging to the creator, the sharing scenario includes a first sharing point, and the first sharing point allows the release of files; 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 and issuance of the third cloud key is controlled by the first cloud key; The method comprises: The service side receives a first request from a first publisher, where the first request is used to request issuance of authorization for a specified subscriber, wherein the first publisher has a first authorization, and the first authorization indicates that the first publisher is allowed to call the first cloud key of the service side; The service side responds to the first request and, based on the first authorization, calls the first cloud key to issue a third authorization for the subscriber, so that the subscriber has the authority to open the file published in the first sharing point; wherein the third authorization indicates that the subscriber is allowed to call the third cloud key of the service side.

2. The method according to claim 1, characterized in that The third cloud key is used to encrypt the fourth key to obtain a 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, the second cloud key corresponds to the sharing scenario and belongs to the creator, and the second cloud key is allowed to access the third cloud key for at least decryption; The method comprises: The service side receives a second request from a second publisher, wherein the second request is used to request to publish a first file to be published to the first sharing point, wherein the second publisher has a second authorization, and the second authorization indicates that the second publisher is allowed to call the second cloud key of the service side; The service side responds to the second request and, 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 service side stores the first file ciphertext in the first sharing point, where the first file ciphertext is obtained by encrypting the first file with the fourth key; The second publisher and the first publisher are the same or different users.

4. The method according to claim 3, characterized in that 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 sharing point, the method further includes: The cloud key management system returns the fourth key obtained by decryption to the second publisher; The server receives the first file ciphertext from the second publisher.

5. The method according to any one of claims 2 to 4, characterized in that: The method further comprises: The service side receives a third request from the subscriber, wherein the third request is used to request to open a specified second file, where the second file is any file in the first sharing point; The service side responds to the third request and, based on the third authorization possessed by the subscriber, calls the third cloud key to decrypt the fourth key ciphertext to obtain the fourth key, and the fourth key can be used to decrypt the second file ciphertext to allow the subscriber to open the second file.

6. The method according to claim 5, characterized in that The service side includes a server and a cloud key management system, and the method includes: The server sends the second file ciphertext to the subscriber; The cloud key management system sends the fourth key obtained by decryption to the subscriber, so that the subscriber can 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 6, characterized in that: The method further comprises: The service side receives an eighth request from the first publisher or creator, wherein the eighth request is used to request deletion of the subscriber; The service side revokes the third authorization; and / or, The service side receives a ninth request from the creator, wherein the ninth request is used to request to delete the first publisher and / or the second publisher; The service side revokes the first authorization and / or the second authorization.

8. The method according to any one of claims 1 to 7, 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.

9. The method according to claim 8, characterized in that Also includes: The service side receives a seventh request from the creator, wherein the seventh request is used to request to change the owner of the sharing scene to a new owner; The service side modifies the fifth cloud key to belong to the new owner.

10. The method according to any one of claims 1 to 9, characterized in that: Also includes: The service side receives a fourth request, where the fourth request is used to request creation of a sharing scene for the creator; The service side creates a sharing scene for the creator in response to the fourth request; The service side generates a first cloud key and a second cloud key corresponding to the sharing scenario.

11. The method according to any one of claims 1 to 10, characterized in that: The method further comprises: The service side receives a fifth request from the creator, wherein the fifth request is used to request authorization of the use right of the first cloud key and / or the second cloud key to a specified user; In response to the fifth request, the service side issues a corresponding authorization for the designated user, where the authorization indicates that the designated user is allowed to call the first cloud key and / or the second cloud key of the service side.

12. The method according to any one of claims 1 to 11, characterized in that: The method further comprises: The service side issues a self-authorization for the creator, where the self-authorization indicates that the creator is allowed to call the first cloud key and / or the second cloud key.

13. The method according to any one of claims 2 to 12, characterized in that: The method further comprises: The service side receives a sixth request from the second publisher or creator, the sixth request being used to request creation of a sharing point in the sharing scenario; The service side creates a first sharing point in the sharing scenario in response to the sixth request; 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 to obtain the fourth key ciphertext.

14. The method according to any one of claims 2 to 12, 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, wherein the sixth request is used to request to create a sharing point in the sharing scene; The server creates a first sharing point in the sharing scenario in response to the sixth request; The cloud key management system generates a third cloud key corresponding to the first shared point; The cloud key management system receives a fourth key from the second publisher or creator; The cloud key management system encrypts the fourth key using the third cloud key to obtain a fourth key ciphertext; The server stores the fourth key ciphertext.

15. A method for secure file sharing, characterized in that: include: The client obtains description information of a first sharing point in a sharing scene managed by a first publisher from a service side; wherein the sharing scene is created by the service side and belongs to the creator; the sharing scene 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; and the first sharing point allows publishing files; The client generates a first request in response to a first operation of the first publisher on the first sharing point, wherein the first operation includes an operation of specifying a subscriber, and the first request is used to request issuance of authorization for the specified subscriber; The client sends a first request to the service side, so that the service side responds to the first request and calls the first cloud key based on the first authorization to issue a third authorization for the subscriber; wherein the third authorization enables the subscriber to have the authority to open the file in the first sharing point.

16. The method according to claim 15, characterized in that Also includes: The client generates an eighth request in response to an eighth operation of the first issuer for the third authorization; The client sends the eighth request to the service side, so that the service side responds to the eighth request and revokes the third authorization based on the first authorization.

17. The method according to any one of claims 15 to 16, characterized in that The first publisher also has a second authorization, where the second authorization indicates that the first publisher is allowed to call 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 comprises: The client generates a second request in response to the second operation of the second publisher on the first sharing point, wherein the second request is used to request to publish the first file to be published to the first sharing point; The client sends a second request to the service side, so that the service side responds to the second request and stores the first file ciphertext in the first sharing point based on the second authorization, where the first file ciphertext is obtained by encrypting the first file.

18. A method for secure file sharing, characterized in that: include: The client obtains description information of a first sharing point in a sharing scene managed by a second publisher from a service side; wherein the sharing scene is created by the service side and belongs to the creator; the sharing scene 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; and the first sharing point allows publishing files; The client generates a second request in response to the second operation of the second publisher on the first sharing point, wherein the second request is used to request to publish the first file to be published to the first sharing point; The client sends a second request to the service side, so that the service side responds to the second request and stores 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.

19. The method according to claim 18, characterized in that Before the step of the client acquiring the description information of the first sharing point in the sharing scene managed by the second publisher from the service side, the method further includes: The client obtains description information of the sharing scenario managed by the second publisher from the service side; The client generates a sixth request in response to the sixth operation of the second publisher on the sharing scene, wherein the sixth request is used to request to create a sharing point in the sharing scene; The client sends a sixth request to the service side, so that the service side creates a first sharing point in the sharing scenario in response to the sixth request; 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 allows access to the second cloud key for at least decryption.

20. The method according to any one of claims 18 to 19, characterized in that 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 second cloud key and the third cloud key, and the fourth key is obtained by the cloud key management system accessing the third cloud key through the second cloud key based on the second authorization, and decrypting the fourth key ciphertext using the third cloud key; The client encrypts the first file to be published using the fourth key to obtain a ciphertext of the first file; The client sends the first file ciphertext to the server on the service side.

21. A method for secure file sharing, characterized in that: include: The client obtains description information of a first sharing point that the subscriber has the right to open from the service side; wherein the first sharing point has a corresponding third cloud key, the third cloud key is stored on the service side, and the first sharing point allows the release of files encrypted by the fourth key; the subscriber has a third authorization, and the third authorization indicates that the subscriber is allowed to call the third cloud key; The client generates a third request in response to the third operation of the subscriber on the second file in the first sharing point, wherein the third request is used to request to open a specified second file, where the second file is any file in the first sharing point; Sending a third request 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 to obtain a fourth key, where the fourth key can be used to decrypt the second file ciphertext; The client opens the second file.

22. The method according to claim 21, characterized in that 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 and by using the third cloud key to decrypt the fourth key ciphertext; The client receives the second file ciphertext from the server; The client uses the fourth key to decrypt the second file ciphertext to obtain the second file.

23. A sharing scenario processing method for secure file sharing, characterized in that: include: In response to the fourth operation, the client sends a fourth request to the service side, where the fourth request is used to request creation of a sharing scene for the creator; The client receives, from the service side, description information of a 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 the publishing of files; 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 service side; The client generates a fifth request in response to the fifth operation of the creator, wherein the fifth operation includes an operation of specifying at least one publisher; the fifth request is used to request authorization of the use right of the first cloud key and / or the second cloud key to the at least one publisher; The client sends a fifth request to the service side so that the service side issues a corresponding authorization for the at least one publisher, and the authorization indicates that the at least one publisher is allowed to call the first cloud key and / or the second cloud key of the service side, so that the at least one publisher can issue authorization for subscribers of the sharing point and / or publish files in the sharing point.

24. The method according to claim 23, characterized in that Also includes: The client generates a sixth request in response to the creator's sixth operation on the sharing scene, wherein the sixth request is used to request to create a sharing point in the sharing scene; The client sends a sixth request to the service side, so that the service side creates a first sharing point in the sharing scenario in response to the sixth request; 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 allows access to the second cloud key for at least decryption.

25. The method according to any one of claims 23 to 24, characterized in that Also includes: The client generates an eighth request in response to an eighth operation of the creator on the authorization owned by the subscriber; The client sends the eighth request to the service side, so that the service side revokes the authorization owned by the subscriber; and / or, The client generates a ninth request in response to the creator's ninth operation on the publisher, wherein the ninth request is used to request deletion of the publisher; The client sends the ninth request to the service side, so that the service side revokes the authorization owned by the publisher.

26. The method according to any one of claims 23 to 25, 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. The method further comprises: The client generates a seventh request in response to the creator's seventh operation on the sharing scene, wherein the seventh request is used to request to change the owner of the sharing scene to a new owner; The client sends a seventh request to the service side, so that the service side modifies the fifth cloud key to belong to the new owner.

27. A service-side system, characterized in that: include: a storage unit configured to store predetermined computer instructions; A processing unit configured to execute the predetermined computer instructions to implement the method according to any one of claims 1 to 14.

28. A client, characterized in that: include: a storage unit configured to store predetermined computer instructions; A processing unit configured to run the predetermined computer instructions to implement the method of any one of claims 15 to 17; or, to implement the method of any one of claims 18 to 20; or, to implement the method of any one of claims 21 to 22; or, to implement the method of any one of claims 23 to 26.

29. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the processor is caused to perform the method according to any one of claims 1 to 14, or the method according to any one of claims 15 to 26.

30. A computer program product comprising a computer program, characterized in that When the computer program is executed, the computer is enabled to execute the method according to any one of claims 1 to 14, or the method according to any one of claims 15 to 26.

Images