Secure file sharing method, service side system, client, storage medium and program product

Abstract

The invention discloses a file security sharing method and a related product, and relates to the technical field of data security. According to the application, a set of file security sharing architecture is constructed in combination with a cloud key technology, and an automatic authorization mechanism is provided on this basis. The mechanism mainly comprises the following steps that: an owner of a sharing scene authorizes the use right of a first cloud key for issuing a third authorization to subscribers to a sixth key of a service side, and when the service side judges that a certain subscriber meets a preset authorization rule corresponding to a sharing point in the sharing scene, the subscriber sends the third authorization to the sharing scene; and the service side can automatically call the first cloud key through the sixth key to sign and issue the third authorization for the subscriber. In this way, the subscriber has the authority to open the file published in the first sharing point. By adopting the scheme, under the condition of ensuring that the file is safely shared to the appointed user, the process related to authorization can be simplified, the manual intervention is reduced, and the file sharing management efficiency and the user experience are improved.

Description

Technical Field

[0001] The present application relates to the field of data security technology, and in particular to a method for secure file sharing, and related products, including a service-side system, a client, a computer-readable storage medium, and a computer program product. Background Art

[0002] Traditional file sharing technology is usually done manually by the file owner. 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, when user U1 wants to share a file with multiple different users, he needs to send sharing links to these users separately, which involves many steps. Moreover, once user U1 has shared, it is difficult for him to control the behavior of these users, and it is difficult to ensure that the sharing link or file is only shared with the user who wants to share it, and will not be shared with other users. The security of the shared files is also difficult to guarantee. Summary of the invention

[0004] One purpose of the present application is to provide a file sharing solution with an automatic authorization mechanism, which can simplify manual intervention related to authorization while ensuring that files are securely shared with designated users, thereby improving the management efficiency of file sharing and user experience.

[0005] The first aspect of the present application provides a method for secure file sharing, wherein a service side creates a sharing scenario belonging to an owner, the sharing scenario includes a first sharing point, and the first sharing point allows the release of files; the sharing scenario has a corresponding first cloud key, the first cloud key is stored on the service side and belongs to the owner; the first sharing point has a corresponding third cloud key, the third cloud key is stored on the service side, and the authorization issuance of the third cloud key is controlled by the first cloud key, and the service side stores a sixth key, the sixth key is allowed to call the first cloud key to at least issue authorization. The method includes: the service side receives a subscription request, the subscription request is used to request the issuance of authorization for a specified subscriber; the service side, when determining that the subscriber meets the preset authorization rule corresponding to the first sharing point, calls the first cloud key through the sixth key to issue a third authorization for the subscriber; wherein the third authorization indicates that the subscriber is allowed to call the third cloud key of the service side, so that the subscriber has the authority to open the file published in the first sharing point.

[0006] In combination with the first aspect, in a possible implementation, the first sharing point allows publishing of encrypted files, the third cloud key is used to encrypt a fourth key, and the fourth key is used to encrypt files published in the first sharing point.

[0007] In combination with the first aspect, in a possible implementation method, the service side includes a server and a cloud key management system, the sixth key belongs to the server, and the first cloud key and the third cloud key are stored in the cloud key management system; when the service side determines that the subscriber satisfies the preset authorization rules corresponding to the first sharing point, the service side calls the first cloud key through the sixth key to issue a third authorization for the subscriber, including: the server determines whether the subscriber satisfies the preset authorization rules corresponding to the first sharing point; when the server determines that the subscriber satisfies the preset authorization rules, the server calls the cloud key management system through the sixth key, so that the cloud key management system uses the first cloud key to issue a third authorization for the subscriber.

[0008] In combination with the first aspect, in a possible implementation method, the service side includes a server and a cloud key management system, and the first cloud key and the third cloud key are stored in the cloud key management system; before the service side receives the subscription request, it also includes: the server generates a sixth key belonging to the server, and the sixth key includes a sixth private key and a sixth public key; the server sends a registration request to the cloud key management system, and the registration request includes the sixth public key; the server receives the registration result returned by the cloud key management system in response to the registration request.

[0009] In combination with the first aspect, in a possible implementation method, before the step of receiving the subscription request on the service side, it also includes: the server receives an activation request from the owner or the publisher; wherein the activation request is used to activate the automatic authorization module, the automatic authorization module corresponds to the sixth key, and the publisher is a user authorized by the owner to call the first cloud key; the server responds to the activation request, and requests the cloud key management system to issue an authorization for the automatic authorization module based on the sixth private key; the server receives the fifth authorization issued by the cloud key management system or the description information of the fifth authorization, and the fifth authorization indicates that the sixth key is allowed to call the first cloud key for at least issuing authorization.

[0010] In combination with the first aspect, in a possible implementation, the method also includes: the server receives automatic authorization setting information from the owner or publisher; wherein the automatic authorization setting information includes at least one authorization rule corresponding to the first sharing point; the server configures the at least one authorization rule as a preset authorization rule corresponding to the first sharing point.

[0011] In combination with the first aspect, in a possible implementation, the sharing scenario also has a corresponding second cloud key, the second cloud key is stored on the service side and belongs to the owner, 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 the owner or the publisher, the second request is used to request that the first file to be published be published to the first sharing point, wherein the publisher is a user authorized by the owner to call the second cloud key; the service side responds to the second request, 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.

[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 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, it also includes: the cloud key management system returns the decrypted fourth key to the owner or the publisher; the server receives the first file ciphertext from the owner or the publisher.

[0013] 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.

[0014] 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.

[0015] The second aspect of the present application provides a method for secure file sharing, wherein a service side creates a sharing scenario belonging to an owner, the sharing scenario includes a first sharing point, and files are allowed to be published in the first sharing point; the sharing scenario has a corresponding first cloud key, the first cloud key is stored on the service side and belongs to the owner; the first sharing point has a corresponding third cloud key, the third cloud key is stored on the service side, and the authorization issuance of the third cloud key is controlled by the first cloud key, and the service side stores a sixth key, the sixth key is allowed to call the first cloud key for at least issuing authorization; the method comprises: a client obtains description information of the first sharing point in the sharing scenario from the service side; the client generates a subscription request in response to a first operation of a first user on the first sharing point, wherein the subscription request is used to request the issuance of authorization for a specified subscriber; the client sends a subscription request to the service side, so that the service side responds to the subscription request, and when it is determined that the subscriber meets the preset authorization rule, calls the first cloud key through the sixth key 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.

[0016] In combination with the second aspect, in a possible implementation, the first sharing point allows publishing of encrypted files, the third cloud key is used to encrypt a fourth key, and the fourth key is used to encrypt files published in the first sharing point.

[0017] In combination with the second aspect, in a possible implementation, when the first user is the designated subscriber, the method further includes: the client generates a third request in response to the third operation of the subscriber on the second file in the first sharing point, and the third request is used to request to open the designated second file, and the second file is any file in the first sharing point; the client sends a third request 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.

[0018] In combination with the second 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.

[0019] The third aspect of the present application provides a method for secure file sharing, in which a service side creates a sharing scenario belonging to an owner, the sharing scenario includes a first sharing point, in which files are allowed to be published; the sharing scenario has a corresponding first cloud key, which is stored on the service side and belongs to the owner; the first sharing point has a corresponding third cloud key, which is stored on the service side, and the authorization issuance of the third cloud key is controlled by the first cloud key; the method includes: the client generates an activation request in response to the seventh operation of the owner or publisher on the first sharing point; wherein the activation request is used to activate an automatic authorization module, and the publisher is a user authorized by the owner to call the first cloud key; the client sends an activation request to the service side, so that the service side issues a fifth authorization for the automatic authorization module, and the fifth authorization indicates that the sixth key corresponding to the automatic authorization module is allowed to call the first cloud key for at least issuing authorization, so that the automatic authorization module can issue authorization for subscribers who meet the preset authorization rules.

[0020] In combination with the third aspect, in a possible implementation, the method also includes: the client generates automatic authorization setting information in response to the tenth operation of the owner or publisher on the first sharing point; wherein the automatic authorization setting information includes at least one authorization rule corresponding to the first sharing point; the client sends the automatic authorization setting information to the service side, so that the service side configures the at least one authorization rule as a preset authorization rule corresponding to the first sharing point.

[0021] In combination with the third aspect, in a possible implementation, it also includes: the client generates an eighth request in response to the eighth operation of the owner or the publisher 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 twelfth request in response to the twelfth operation of the owner or the publisher on the automatic authorization module; the client sends the twelfth request to the service side, so that the service side revokes the fifth authorization owned by the automatic authorization module.

[0022] In combination with the third aspect, in a possible implementation, the sharing scenario also has a corresponding second cloud key, the second cloud key is stored on the service side and belongs to the owner, and the second cloud key is allowed to access the third cloud key for at least decryption; it also includes: the client generates a second request in response to the second operation of the owner or the 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, and the publisher is a user authorized by the owner to call the second cloud key; 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; wherein the first file ciphertext is obtained by encrypting the first file.

[0023] 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 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; and the client sends the first file ciphertext to the server of the service side.

[0024] The fourth 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.

[0025] The fifth 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 or the third aspect.

[0026] The sixth 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 or the third aspect.

[0027] A seventh 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 or the third aspect. BRIEF DESCRIPTION OF THE DRAWINGS

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

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

[0030] Figure 3 A flowchart of an exemplary method for creating and authorizing a sharing scenario for secure file sharing provided in an embodiment of the present application.

[0031] Figure 4 A schematic diagram of the process of creating a sharing point and publishing files in the sharing point in an exemplary file security sharing method provided in an embodiment of the present application.

[0032] Figure 5 A flowchart of activating an automatic authorization module, setting automatic authorization rules, automatically authorizing a subscriber, and a subscriber opening a file in an exemplary file security sharing method provided in an embodiment of the present application.

[0033] Figure 6 A flowchart of activating an automatic authorization module, setting automatic authorization rules, automatically authorizing a subscriber, and a subscriber opening a file in another exemplary method for secure file sharing provided in an embodiment of the present application. DETAILED DESCRIPTION

[0034] 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.

[0035] 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, so as to improve the security of keys without affecting key usage. The applicant introduced cloud key technology into the file sharing solution and built a set of file security sharing architecture and implementation solutions. While ensuring that files are securely shared with designated users, it can also meet the needs of flexible and fine management of files, thereby improving the security and controllability of shared files. On this basis, the applicant proposed an automatic authorization mechanism to automatically authorize file access rights to the sharee, reduce manual operations, improve the management efficiency of file sharing, and optimize the user experience.

[0036] 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.

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

[0038] 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.

[0039] Since there may be multiple users in the application scenario, for the convenience of description and distinction, in the embodiment of the present application, the user who owns the file is called the owner; the user who is to share the file is called the subscriber; the user who requests to grant the file access rights to the subscriber is called the first user. The client used by the owner is called the first client, the client used by the subscriber is called the third client B, and the client used by the first user is called the third client A. Figure 1 shown.

[0040] It should be noted that the first user and the subscriber may be different users or the same user. In the case where the first user and the subscriber are the same user, that is, the subscriber requests authorization for himself, the third client of the subscriber may correspondingly execute the steps executed by the third client B and the third client A, such as Figure 2 shown.

[0041] It is understandable that in addition to the above-mentioned users and clients, other users and corresponding clients may be involved in some application scenarios, and this application does not limit this. For example, the owner may not publish the file personally, but authorize other users to publish the file on his behalf. For the convenience of description and distinction, in the embodiments of this application, the user who publishes the file is called the publisher, and the client used by the publisher can be called the second client, such as Figure 2 shown.

[0042] 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.

[0043] The owner can share the file with the subscriber himself, or authorize other users (such as the publisher mentioned above) to share the file with the subscriber on his behalf, or deliver it to the service side for automatic authorization. For the convenience of description, the automatic authorization function of the service side is abstracted as the automatic authorization module.

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

[0045] 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 can include an authentication service module, a user service module, and the aforementioned automatic authorization module, etc.

[0046] 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.

[0047] 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.

[0048] 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.

[0049] Each user, such as the owner, subscriber, first user, publisher, etc., can have his or her own personal key to identify himself or herself and allow other interacting parties to verify his or her identity and authority. The personal key can be a pair of asymmetric keys, including the corresponding public key and private key. Before use, the public key of the personal key can be sent to the service side and registered on the service side.

[0050] For example, Figure 2Taking the system shown 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 of the user's personal key and the aforementioned user token in the interactive information, so that the cloud key management system can register the public key of the user's personal key and then return 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 identity and facilitate verification by the cloud key management system.

[0051] The automatic authorization module also has a corresponding key, which is referred to as the sixth key in the embodiment of the present application for the convenience of distinction. The sixth key is stored on the service side. The sixth key can be a pair of asymmetric keys, including a corresponding sixth public key and a sixth private key. It also needs to be registered on the service side before use.

[0052] For example, Figure 2 Taking the system shown as an example, the registration of the sixth key may include:

[0053] The server generates a sixth key belonging to the server, where the sixth key includes a sixth private key and a sixth public key;

[0054] The server sends a registration request to the cloud key management system, where the registration request includes the sixth public key;

[0055] The cloud key management system stores the sixth public key in response to the registration request;

[0056] The cloud key management system returns the registration result to the server.

[0057] In some possible implementations, the server may use the private key of the server key to sign the registration request or some important information in the registration request. The cloud key management system responds to the registration request and stores the sixth public key after verifying the aforementioned signature using the public key of the server key.

[0058] In some possible implementations, the registration result may include a sixth key identifier, which may be, for example, a string of characters processed by the cloud key management system and signed using the private key of the cloud key management system. Later, when the automatic authorization module on the server side needs to interact with the cloud key management system, the sixth key identifier may be carried in the interactive information if necessary to indicate its own identity and facilitate verification by the cloud key management system.

[0059] Taking the case where the owner uses the first client, the first user uses the third client A, and the subscriber uses the third client B as an example, the following further introduces the processes of (i) creating a sharing scenario, (ii) the owner authorizing the publisher, (iii) creating a sharing point in the sharing scenario, (iv) publishing files in the sharing point, (v) activating the automatic authorization module and setting preset authorization rules, (vii) automatically authorizing the subscriber, (vii) the subscriber viewing the files in the sharing point, (viii) manually authorizing the subscriber, and (ix) revoking authorization. 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.

[0060] (I) Create a sharing scenario

[0061] See also Figure 3 , Figure 3 A flowchart of an exemplary file sharing processing method provided in an embodiment of the present application.

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

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

[0064] When the owner wants to create a shared 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 owner's operation, the first client sends a fourth request to the service side.

[0065] 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 eleventh operations below, etc.) may include one operation step or multiple operation steps, and the present application does not limit this.

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

[0067] 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 owner's identity information (such as the owner's account registered on the service side, the owner's personal key identifier, etc.), or configures the owner information of the sharing scene as the owner's identity information, thereby granting ownership of the sharing scene to the owner.

[0068] 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 owner, 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.

[0069] 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.

[0070] Exemplarily, the owner has his own personal key, and the first client can use the private key in the owner's personal key to sign certain information in the fourth request (such as the owner'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 owner's personal key based on the owner's identity information, such as the owner'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 owner, and the signed information in the fourth request has not been tampered with, and then create a sharing scene for the owner.

[0071] It is understandable that in the following text, for requests initiated by the first user, subscriber, publisher and other users, the corresponding client can also sign with the private key of each of these users' personal keys. The implementation process can refer to the above introduction and will not be repeated in the following text.

[0072] 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 owner.

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

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

[0075] The first cloud key is mainly used for authorization issuance. The owner can distribute the use rights of the first cloud key to other users (for example, issuing the first authorization to the publisher), or to the service side (for example, issuing the fifth authorization to the automatic authorization module), so that the publisher or the automatic authorization module can use the first cloud key to issue the third authorization to the subscriber on behalf of the owner, so that the subscriber can decrypt the files published in the sharing scenario and then open them. Of course, in some possible implementations, when the publisher has the first authorization, it can also distribute the use rights of the first cloud key to the service side. At the same time, since the first cloud key belongs to the owner, the owner can also control the publisher and its issuance behavior by controlling the first cloud key, and can also indirectly control the third authorization issued by it.

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

[0077] It should be noted that the service side can generate the first cloud key and the second cloud key at the same time, or separately, and this application does not limit this. It is understandable that when the owner does not need to distribute the publishing authority to the publisher, it is also not necessary to generate the second cloud key, and the steps about the second cloud key below can also be omitted accordingly.

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

[0079] In some possible implementations, the service side may first generate a fifth cloud key corresponding to the sharing scenario and belonging to the owner, 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 owner, thereby indirectly realizing the function of attributing the ownership of the first cloud key and the second cloud key to the owner. Exemplarily, the service side may configure the owner information of the fifth cloud key as the owner's identity information, such as the owner's personal key identifier, 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. Compared with the method of directly attributing the ownership of the first cloud key and the second cloud key to the owner, the indirect control method through the fifth cloud key only requires modifying the fifth cloud key when the ownership of the sharing scenario needs to be changed, and the change operation is more convenient.

[0080] 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.

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

[0082] 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.

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

[0084] 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.

[0085] 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.

[0086] In some possible implementations, the service side may include: Figure 2The 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 sharing scene records, such as the owner's identity information (such as the owner's account registered on the server), the corresponding sharing scene description information (such as the scene ID), the cloud key description information (such as the key identifier of the cloud key), etc., for subsequent query and use.

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

[0088] (2) The owner authorizes the publisher

[0089] Optionally, the Owner can authorize others to become Publishers, allowing them to create Sharepoints, publish files, and / or request licenses for designated Subscribers on their behalf.

[0090] S105: The first client generates a fifth request in response to the fifth operation of the owner.

[0091] When the owner wants to set a user as a publisher and authorize the user, the owner 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 owner 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 owner's operation, the first client generates a fifth request.

[0092] 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 owner's identity information such as the owner's personal key identifier, together in the fifth request.

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

[0094] 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.

[0095] 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.

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

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

[0098] 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.

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

[0100] 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.

[0101] 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.

[0102] 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 owner, the authorization ID can also be the ID of the self-authorization issued to the owner for controlling the cloud key.

[0103] It can be seen that if the request is to authorize the first cloud key to one publisher and the second cloud key to another publisher, the service side will issue the first authorization to one publisher and the second authorization to the other publisher accordingly. Of course, in some possible implementations, the first cloud key and the second cloud key can also be authorized to the same publisher.

[0104] The first authorization indicates that the 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 publisher; and the personal key identifier of the authorizer is the personal key identifier of the owner.

[0105] The second authorization indicates that the 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 publisher; and the personal key identifier of the authorizer is the personal key identifier of the owner.

[0106] It is understandable that the owner can also use this implementation to request to authorize the first cloud key and / or the second cloud key to other users, and other users with corresponding authorizations will become corresponding publishers. In other words, for a sharing scenario, it can be authorized to multiple publishers, and these publishers can manage the sharing scenario.

[0107] Optionally, in some possible implementations, the service side may issue a self-authorization to the owner before issuing the authorization to the publisher. That is, after the aforementioned step S103, the following may also be included:

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

[0109] 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 owner is allowed to call the first cloud key on the service side; the second cloud key self-authorization is used to indicate that the owner 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 publisher.

[0110] 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 owner 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 owner can use the fifth cloud key self-authorization to indirectly control the first cloud key and the second cloud key.

[0111] 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 client (such as the first client, the second client, etc.), or it can be saved on the service side and only return the description information of the authorization, 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.

[0112] 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.

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

[0114] The owner can create a share point in his own sharing scene, or authorize others (such as the publisher mentioned above) to create a share point in the sharing scene. The following takes the example of the owner creating a share point to further explain the process. 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.

[0115] S201: The first client generates a sixth request in response to a sixth operation.

[0116] When the owner wants to create a new sharing point in a certain sharing scenario, he or she can perform an operation on the first client 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 owner clicks the "New Sharing Point" control in the user interface displayed on the first client. In response to the owner's operation, the first client generates a sixth request.

[0117] In some possible implementations, the first client can obtain description information of the sharing scene managed by the owner from the service side, and display part of the description information (such as scene name, creation time, owner account, etc.) on the user interface so that the user can operate on the sharing scene.

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

[0119] S202: The first client sends a sixth request to the service side.

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

[0121] In some possible implementations, the service side can verify that the initiator of the sixth request (i.e., the owner) does have the corresponding authority, 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 owner's identity information.

[0122] 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.

[0123] 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.

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

[0125] The authorization issuance of the third cloud key can be controlled by the first cloud key. That is, when a user (such as the owner or publisher with the first authorization) or the automatic authorization module of the server has the right to use the first cloud key, it can issue the authorization of the third cloud key to others through the first cloud key.

[0126] The decryption use of the third cloud key can be controlled by the second cloud key. When a user (such as the owner or the publisher with the second authorization) has the right to use the second cloud key, 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.

[0127] It is understandable that for other sharing points in the sharing scenario, they also have corresponding cloud keys, and the cloud keys corresponding to different sharing points may generally be different. Files can be published in the sharing point, and by controlling the cloud key corresponding to the sharing point, it is possible to control whether the files published in the corresponding sharing point are allowed to be accessed by certain users.

[0128] Optionally, the above method also includes: S205, the service side uses the third cloud key to encrypt the fourth key to obtain the fourth key ciphertext.

[0129] The fourth key is used to encrypt the file published in the first sharing point. The fourth key can be generated by the owner or publisher and then transmitted to the service side for encryption, or can be generated by the service side, which is not limited in this application.

[0130] In some possible implementations, after generating the third cloud key, the service side can issue a use authorization for the second cloud key (hereinafter referred to as the fourth authorization for ease of distinction), the fourth authorization indicating 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 first client. Then the first client sends the generated fourth key, the description information of the fourth authorization, and the owner's personal key identifier together in a request to the service side. After receiving the request, the service side can call the second cloud key based on the owner's personal key or the owner's self-authorization, and 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.

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

[0132] It should be noted that when the first sharing point is requested to be created by the publisher, the execution subject of the above steps S201 to S202 can also be the second client. The sharing points included in a sharing scenario can include those created by the publisher or by the owner, 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 to this.

[0133] It should also be noted that the step of the owner authorizing the publisher (e.g., S105 to S107 in the above text) 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 precedence. It is not difficult to understand that if the owner first authorizes the publisher, the owner and the publisher may both create the first sharing point later, and if the owner temporarily does not authorize the publisher, the owner may create the first sharing point first.

[0134] In some possible implementations, the service side includes: Figure 2 In 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.

[0135] (IV) Publishing files in a shared point

[0136] The owner can publish files in the share point of his own sharing scenario, or authorize others (such as publishers) to publish files in the share point. The following takes the example of the owner publishing files to further explain the process. 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.

[0137] S206: The first client generates a second request in response to the owner's second operation on the first sharing point.

[0138] 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.

[0139] When the owner wants to publish a file in a share point, he can perform an operation on the first client for the share point (for the sake of distinction, referred to as the second operation in the embodiment of the present application). For example, the owner clicks the "add new content" control in the user interface displayed on the first client. In response to the owner's operation, the first client generates a second request.

[0140] In some possible implementations, the first client can obtain the description information of the first sharing point in the sharing scene managed by the owner 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.

[0141] 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 the owner's identity information, such as the owner's personal key identifier, etc. The second request may also include the owner's self-authorization description information, such as the self-authorization ID, etc.

[0142] S207: The first client sends a second request to the service side.

[0143] 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.

[0144] In some implementations, the first client 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.

[0145] In some other implementations, the first client may encrypt the first file to be published to obtain the first file ciphertext, and send the first file ciphertext to the service side alone or in the second request.

[0146] When the fourth key exists on the first client, the first client can directly use the fourth key to encrypt the first file. Exemplarily, the above method also includes:

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

[0148] S210: The first client sends the ciphertext of the first file to the server.

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

[0150] S211, the service side responds to the second request, based on the owner's identity information or the owner's self-authorization, accesses the third cloud key through the second cloud key, uses the third cloud key to decrypt the fourth key ciphertext, and obtains the fourth key.

[0151] S212: The service side sends the fourth key to the first client.

[0152] S209: The first client encrypts the first file using the fourth key to obtain a ciphertext of the first file.

[0153] S210: The first client sends the ciphertext of the first file to the server.

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

[0155] 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.

[0156] By adopting the above implementation, the owner has completed 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 owner himself, and this application does not limit this. That is, the execution subject of the above steps S206, S207, S209, and S210 can also be the second client. The above steps exemplarily describe the process of the first file, and the process of other files can be similar.

[0157] In some possible implementations, the service side may include: Figure 2 The server and cloud key management system shown, the aforementioned steps S208 and S213 can be performed by the server, and the steps S2011 and S212 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.

[0158] In this way, only users with permission on the terminal side, such as the owner, 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.

[0159] (V) Activate the automatic authorization module and set preset authorization rules

[0160] The owner or the publisher who can call the first cloud key with the authorization of the owner can activate the automatic authorization module on the service side. The following takes the owner activation as an example to further illustrate the process.

[0161] S301: The first client generates an activation request in response to a seventh operation of the owner on the first sharing point.

[0162] When the owner wants to activate the automatic authorization function of a share point, he can perform an operation on the first client for the share point (for the sake of distinction, it is referred to as the seventh operation in the embodiment of the present application). For example, the owner clicks the "activate automatic authorization" control in the user interface displayed on the first client. In response to the owner's operation, the first client generates an activation request.

[0163] The activation request is used to activate the automatic authorization module on the service side, so that it can automatically issue authorization for subscribers who meet the preset authorization rules. In some possible implementations, the activation request may include the owner's identity information, such as the owner's personal key identifier, etc. The activation request may also include the owner's self-authorization description information, such as the self-authorization ID, etc.

[0164] S302: The first client sends an activation request to the service side.

[0165] S303, the service side issues a fifth authorization to the automatic authorization module in response to the activation request; wherein the fifth authorization indicates that the sixth key corresponding to the automatic authorization module is allowed to call the first cloud key for at least issuing authorization.

[0166] In some possible implementations, the service side may include: Figure 2 In the server and cloud key management system shown, the aforementioned step S303 can be replaced by:

[0167] S304, the server, in response to the activation request, requests the cloud key management system to issue authorization to the automatic authorization module based on the sixth private key;

[0168] S305, the cloud key management system issues a fifth authorization to the automatic authorization module;

[0169] S306: The server receives the fifth authorization or description information of the fifth authorization.

[0170] In some possible implementations, the server can use the sixth private key to sign the request so that the cloud key management system can use the sixth public key saved when registering the sixth key to verify the signature of the request. If the verification is successful, the cloud key management system will then issue the fifth authorization to the automatic authorization module.

[0171] The authorization rule may be preset, and the owner or the publisher with the permission to call the first cloud key may set the authorization rule for the share point. The following also takes the owner setting the authorization rule as an example to further illustrate the process.

[0172] S307: The first client generates automatic authorization setting information in response to the owner's tenth operation on the first sharing point.

[0173] The automatic authorization setting information includes at least one authorization rule corresponding to the first sharing point, and the authorization rule may be, for example, about the authorization validity period, the status that the subscriber needs to meet, etc., and the present application does not limit the specific content of the authorization rule. For example, when the automatic authorization mechanism is applied to the subscription of paid courses (corresponding to the sharing point in the embodiment of the present application), the authorization rule may include the course information that has been purchased for the subscriber.

[0174] S308: The first client sends automatic authorization setting information to the service side.

[0175] S309: The server configures at least one authorization rule in the automatic authorization setting information as a preset authorization rule corresponding to the first sharing point.

[0176] It is understandable that the authorization rules of different sharing points may be the same or different, and this application does not limit this.

[0177] It should be noted that when the publisher activates the automatic authorization module and sets the authorization rules, the execution subject of the above steps S301 to S302, S307 to S308 can also be the second client. The main difference from the above steps is that the identity information of the owner carried in the activation request and the automatic authorization setting information can be correspondingly transformed into the identity information of the publisher, and the activation request and the automatic authorization setting information can also include the description information of the first authorization owned by the publisher.

[0178] By adopting the scheme of the present application, the owner or the publisher who can call the first cloud key with the authorization of the owner can conveniently control the activation or deactivation of automatic authorization (deactivation will be further explained later), and can conveniently adjust the corresponding preset authorization rules according to different sharing scenarios and sharing points, and can adjust them before or after the sharing point is created, before or after the file is published, etc. Even if authorization has been granted to some subscribers, the preset authorization rules can be adjusted in the middle. In general, the scheme has high flexibility for the owner or publisher without affecting the security and controllability of file sharing, and has a wide range of applications.

[0179] (VI) Automatically authorize subscribers

[0180] The following takes the case where a first user subscribes to a first sharing point as a designated subscriber and the service side automatically authorizes the subscriber as an example to further illustrate the automatic authorization mechanism.

[0181] S401: The third client A obtains description information of a first sharing point in a sharing scenario from a service side.

[0182] In some possible implementations, the third client A can obtain the description information of each sharing scene and each sharing point therein that has been published from the service side, which naturally includes the description information of the first sharing point. The third client displays part of the description information (such as the sharing point name, the name and thumbnail of the file published in the sharing point, etc.) on the user interface so that the first user can operate on a certain sharing point.

[0183] S402: The third client A generates a subscription request in response to a first operation of the first user on the first sharing point.

[0184] When the first user wants to subscribe a certain share point for a certain user so that the user can access the files in the share point, he can perform an operation on the third client A for the share point (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 user clicks the "Subscribe" control corresponding to the first share point in the user interface displayed on the third client A, and then selects one or more users as subscribers. In response to the operation of the first user, the third client A generates a subscription request.

[0185] The subscription request is used to request the issuance of authorization for the specified subscriber. In some implementations, the third client A can obtain the subscriber's identity information from the service side, such as the subscriber's account 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, and the first user's personal key identifier and other identity information in the subscription request. It can be understood that when the first user is the subscriber, that is, the first user subscribes to the first sharing point for himself, the above-mentioned first user's identity information and the subscriber's identity information can be the same information.

[0186] S403: The third client A sends a subscription request to the service side.

[0187] S404, the service side responds to the subscription request, and when it is determined that the subscriber meets the preset authorization rule corresponding to the first sharing point, calls the first cloud key through the sixth key to issue a third authorization for the subscriber.

[0188] 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.

[0189] 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 key identifier of the authorizer is the key identifier of the sixth key; and the authorization ID is the ID of the fifth 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 exemplarily can 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.

[0190] 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.

[0191] Optionally, after S404, 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.

[0192] In some possible implementations, the service side includes: Figure 2In the case of the server and cloud key management system shown, the step of issuing the third authorization for the subscriber using the first cloud key can be performed by the cloud key management system, and the step of determining whether the subscriber meets the preset authorization rules can be performed by the server. Optionally, the server can store automatic authorization 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., to facilitate subsequent query and tracking.

[0193] It is understandable that in addition to automatic authorization, the owner or the publisher who is authorized by the owner to use the first cloud key can also manually authorize the subscriber, and the implementation process will be further explained in (VIII) below.

[0194] With the above solution, the owner of the sharing scenario authorizes the use right of the first cloud key used to issue the third authorization to the subscriber to the sixth key on the service side. When the service side determines that a subscriber meets the preset authorization rules corresponding to the sharing point in the sharing scenario, the service side can automatically call the first cloud key through the sixth key to issue the third authorization to the subscriber. In this way, the subscriber has the right to open the file published in the first sharing point. While ensuring the security and controllability of file sharing, this mechanism can also simplify the processes related to authorization, reduce manual intervention, and improve the management efficiency and user experience of file sharing.

[0195] (VII) Subscribers view files in the sharepoint

[0196] S501 , a third client B generates a third request in response to a third operation of a subscriber on a second file in a first sharing point.

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

[0198] When a subscriber wants to open a file in a share point, he can perform an operation on the file on the third client B (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 B. The third client B 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.

[0199] In some possible implementations, before initiating the third request, the third client B 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.

[0200] 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.

[0201] S502: The third client B sends a third request to the service side.

[0202] S503, the service side responds to the third request, and based on the third authorization owned by the subscriber, calls the third cloud key to decrypt the fourth key ciphertext to obtain the fourth key.

[0203] 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 B, so that the third client B can open the second file for the subscriber to view. In other implementations, the second file ciphertext can be decrypted by the third client B. That is, optionally, after step S501, the following steps S504 to S506 can also be included.

[0204] S504: The service side sends a fourth key to the third client B.

[0205] S505: The service side sends the second file ciphertext to the third client B.

[0206] S506: The third client B decrypts the second file ciphertext to open the second file.

[0207] 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 B needs to re-initiate the third request to the service side.

[0208] 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.

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

[0210] 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.

[0211] In some possible implementations, the third client B 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.

[0212] 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 S503 can be executed by the cloud key management system, and the step of S505 can be executed by the server.

[0213] (VIII) Manually authorize subscribers

[0214] The owner can manually authorize the subscriber, or authorize others (such as the publisher) to authorize the subscriber. The following takes the example of the publisher authorizing the subscriber to further explain the process.

[0215] S214: The second client generates an eleventh request in response to the publisher's eleventh operation on the first sharing point.

[0216] When the publisher wants to allow a user to access a file in a share point, the publisher can perform an operation on the share point on the second client (for the sake of distinction, referred to as the eleventh operation in the embodiment of the present application), and the eleventh operation includes an operation of specifying a subscriber. For example, the publisher clicks the "Add Subscriber" control corresponding to the first share point in the user interface displayed on the second client, and then selects one or more users as subscribers. In response to the publisher's operation, the second client generates the eleventh request.

[0217] In some possible implementations, the second client can obtain the description information of the first sharing point in the sharing scenario managed by the 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.

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

[0219] S215: The second client sends an eleventh request to the service side.

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

[0221] The meaning of the third authorization can refer to the above-mentioned related description paragraphs, which will not be repeated here. Optionally, after S216, the service side can also return the description information of the third authorization to the subscriber, such as the authorization ID of the third authorization, so that the subscriber can understand which authorizations he has.

[0222] In some possible implementations, the service side includes: Figure 2 In the case of the server and the cloud key management system shown, step S216 can be performed by the cloud key management system. Similarly, whether it is automatic authorization or manual authorization, the server can store subscriber records, such as the subscriber's identity information (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.

[0223] It is understandable that the owner can also authorize the subscriber, and the implementation process is similar to the aforementioned process. Steps S214 and S215 can be executed accordingly by the first client. The main difference is that the identity information of the publisher carried in the eleventh request is transformed into the identity information of the owner, and the description information of the first authorization may not be required, or may be transformed into the self-authorized description information of the owner.

[0224] (IX) Revocation of authorization

[0225] The publisher who is authorized by the owner to use the first cloud key can delete subscribers (including automatically authorized subscribers and manually authorized subscribers) to manage the sharing points in the sharing scene. The owner has higher permissions. In addition to authorizing publishers and adding subscribers personally, he can also delete publishers or subscribers (including automatically authorized subscribers and manually authorized subscribers). In this way, both the owner and the publisher can perform more detailed permission allocation and management on the sharing scene and the content therein.

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

[0227] S217: The second client generates an eighth request in response to the publisher's eighth operation on the third authorization.

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

[0229] In some possible implementations, the second client can obtain the identity information and authorization description information of the subscriber of the first sharing point in the sharing scenario managed by the 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 on the subscriber's authorization.

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

[0231] S218: The second client sends an eighth request to the service side.

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

[0233] 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.

[0234] In some implementations, the process for an owner to delete a subscriber may be similar to the way a publisher deletes a subscriber, with the main difference being that the owner may not need to provide the first authorization, or may provide a self-authorization that he or she owns.

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

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

[0237] When the owner wants to delete a publisher and not allow it to manage subscribers and / or publish files on its behalf, it can perform an operation on the first client for the sharing scenario (for the sake of distinction, it is referred to as the ninth operation in the embodiment of the present application). For example, the owner 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. The first client generates a ninth request in response to the owner's operation.

[0238] 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.

[0239] 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 owner's identity information such as the owner's personal key identifier in the ninth request.

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

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

[0242] The service side can directly delete the authorization owned by the publisher (such as the aforementioned first authorization and second authorization), or set the status of the authorization from valid to invalid, thereby revoking the authorization.

[0243] 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.

[0244] Optionally, the owner or the publisher with the permission to call the first cloud key can also turn off the automatic authorization module on the service side. The following also takes the example of the owner turning off this function to further illustrate the process.

[0245] S310, the first client generates a twelfth request in response to the owner's twelfth operation on the automatic authorization module;

[0246] S311, the first client sends a twelfth request to the service side;

[0247] S312: The service side revokes the fifth authorization owned by the automatic authorization module in response to the twelfth request.

[0248] In some implementations, the service side may directly delete the fifth authorization, thereby revoking the fifth authorization. In this way, when the subsequent automatic authorization function is reactivated, the service side or the cloud key management system needs to reissue the fifth authorization for the sixth key. Generally, the specific content of the reissued fifth authorization may be different from the previous fifth authorization. In other implementations, the service side may not delete the fifth authorization, but set the status of the fifth authorization from valid to invalid, thereby revoking the fifth authorization. In this implementation, when the subsequent automatic authorization function is reactivated, the service side or the cloud key management system only needs to re-set the status of the fifth authorization to valid.

[0249] It should be noted that when the publisher turns off the automatic authorization module, the execution subject of the above steps S310 to S311 can also be the second client. The main difference from the above steps is that the identity information of the owner carried in the twelfth request can be correspondingly transformed into the identity information of the publisher, and the twelfth request can also include the description information of the first authorization owned by the publisher.

[0250] 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 can 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 for providing cloud key related services on the service side. The software product supports the mall function, and users can purchase courses that have been listed in the mall (corresponding to the aforementioned sharing points). After the purchase, the service side can automatically issue authorizations to consumers or subscribers designated by consumers, and assign access rights to the courses. There is no need for the owner of the course or other managers to add it manually, thereby simplifying the operation process of the owner or other managers, reducing the workload, and improving management efficiency. At the same time, for consumers, subscribers can access the files in the course immediately after purchase, and the user experience is also good.

[0251] Exemplarily, user admin_A can establish his own knowledge base (corresponding to the aforementioned sharing scenario) through APP, and create one or more courses (corresponding to the aforementioned sharing points) in the knowledge base by himself or authorize other user user_C, and one or more files can be published in each course. Courses can be put on the shelves in the mall for consumers to purchase. When a course is put on the shelves in the mall, the automatic authorization module of the server can be activated by default or in response to a request from admin_A or user_C, and the preset authorization rules are set. When a user user_B buys a course for himself in the mall, the server can detect the purchase information of user_B and determine whether the subscriber designated by it, that is, user_B himself, meets the preset authorization rules. If satisfied, the server can call the cloud key management system to issue the third authorization for user_B based on the fifth authorization owned by the automatic authorization module. In this way, user_B can open all the files in the purchased course in his own APP. It is understandable that user_B can not only view the files currently published in the course, but also can view other files newly published in the course by the owner or other administrators after user_B purchases the course.

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

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

[0254] The first processing unit is configured to run 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.

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

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

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

[0258] 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.

[0259] 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.

[0260] 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.

[0261] 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.

[0262] 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.

[0263] 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.

[0264] 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 owner, the sharing scenario includes a first sharing point, and the first sharing point allows the release of files; the sharing scenario has a corresponding first cloud key, and the first cloud key is stored on the service side and belongs to the owner; The first sharing point has a corresponding third cloud key, the third cloud key is stored on the service side, and the authorization issuance of the third cloud key is controlled by the first cloud key, the service side stores a sixth key, and the sixth key is allowed to call the first cloud key for at least issuing authorization; The method comprises: The service side receives a subscription request, wherein the subscription request is used to request issuance of authorization for a specified subscriber; When the service side determines that the subscriber meets the preset authorization rules corresponding to the first sharing point, the service side calls the first cloud key through the sixth key to issue a third authorization for the subscriber; wherein the third authorization indicates that the subscriber is allowed to call the third cloud key of the service side so that the subscriber has the authority to open the files published in the first sharing point.

2. The method according to claim 1, characterized in that The first sharing point allows publishing of encrypted files, the third cloud key is used to encrypt the fourth key, and the fourth key is used to encrypt the files published in the first sharing point.

3. The method according to any one of claims 1 to 2, characterized in that: The service side includes a server and a cloud key management system, the sixth key belongs to the server, and the first cloud key and the third cloud key are stored in the cloud key management system; When the service side determines that the subscriber satisfies the preset authorization rule corresponding to the first sharing point, the step of calling the first cloud key through the sixth key to issue a third authorization for the subscriber includes: The server determines whether the subscriber satisfies a preset authorization rule corresponding to the first sharing point; When determining that the conditions are met, the server calls the cloud key management system through the sixth key, so that the cloud key management system uses the first cloud key to issue a third authorization for the subscriber.

4. The method according to any one of claims 1 to 2, characterized in that: The service side includes a server and a cloud key management system, and the first cloud key and the third cloud key are stored in the cloud key management system; Before the step of receiving the subscription request on the service side, the following steps are also included: The server generates a sixth key belonging to the server, wherein the sixth key includes a sixth private key and a sixth public key; The server sends a registration request to the cloud key management system, where the registration request includes the sixth public key; The server receives the registration result returned by the cloud key management system in response to the registration request.

5. The method according to claim 4, characterized in that Before the step of receiving the subscription request on the service side, the following steps are also included: The server receives an activation request from the owner or publisher; wherein the activation request is used to activate an automatic authorization module, the automatic authorization module corresponds to the sixth key, and the publisher is a user authorized by the owner to call the first cloud key; The server, in response to the activation request, requests the cloud key management system to issue authorization for the automatic authorization module based on the sixth private key; The server receives the fifth authorization issued by the cloud key management system or the description information of the fifth authorization, wherein the fifth authorization indicates that the sixth key is allowed to call the first cloud key for at least issuing authorization.

6. The method according to claim 5, characterized in that Also includes: The server receives automatic authorization setting information from the owner or publisher; wherein the automatic authorization setting information includes at least one authorization rule corresponding to the first sharing point; The server configures the at least one authorization rule as a preset authorization rule corresponding to the first sharing point.

7. The method according to claim 2, characterized in that: The sharing scenario also has a corresponding second cloud key, the second cloud key is stored on the service side and belongs to the owner, 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 the owner or publisher, the second request being used to request publishing the first file to be published to the first sharing point, wherein the publisher is a user authorized by the owner to call the second cloud key; The service side responds to the second request by accessing the third cloud key through the second cloud key, and decrypting the fourth key ciphertext using the third cloud key 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.

8. The method according to claim 7, 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 owner or the publisher; The server receives a first file ciphertext from the owner or the publisher.

9. The method according to claim 2, characterized in that: Also includes: 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.

10. The method according to claim 9, 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.

11. A method for secure file sharing, characterized in that: The service side creates a sharing scenario belonging to the owner, the sharing scenario includes a first sharing point, and the first sharing point allows the release of files; the sharing scenario has a corresponding first cloud key, and the first cloud key is stored on the service side and belongs to the owner; The first sharing point has a corresponding third cloud key, the third cloud key is stored on the service side, and the authorization issuance of the third cloud key is controlled by the first cloud key, the service side stores a sixth key, and the sixth key is allowed to call the first cloud key for at least issuing authorization; The method comprises: The client obtains description information of the first sharing point in the sharing scenario from the server side; The client generates a subscription request in response to a first operation of the first user on the first sharing point, wherein the subscription request is used to request issuance of authorization for a specified subscriber; The client sends a subscription request to the service side, so that the service side responds to the subscription request and, upon determining that the subscriber meets the preset authorization rules, calls the first cloud key through the sixth key 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.

12. The method according to claim 11, characterized in that The first sharing point allows publishing of encrypted files, the third cloud key is used to encrypt the fourth key, and the fourth key is used to encrypt the files published in the first sharing point.

13. The method according to claim 12, characterized in that In the case where the first user is the designated subscriber, the method further includes: 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; The client sends 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 the fourth key, and the fourth key can be used to decrypt the second file ciphertext; The client opens the second file.

14. The method according to claim 13, 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.

15. A method for secure file sharing, characterized in that: The service side creates a sharing scenario belonging to the owner, the sharing scenario includes a first sharing point, and the first sharing point allows the release of files; the sharing scenario has a corresponding first cloud key, and the first cloud key is stored on the service side and belongs to the owner; The first shared point has a corresponding third cloud key, the third cloud key is stored on the service side, and the authorization and issuance of the third cloud key is controlled by the first cloud key; The method comprises: The client generates an activation request in response to the seventh operation of the owner or publisher on the first sharing point; wherein the activation request is used to activate the automatic authorization module, and the publisher is a user authorized by the owner to call the first cloud key; The client sends an activation request to the service side so that the service side issues a fifth authorization for the automatic authorization module. The fifth authorization indicates that the sixth key corresponding to the automatic authorization module is allowed to call the first cloud key for at least issuing authorization, so that the automatic authorization module can issue authorization for subscribers who meet the preset authorization rules.

16. The method according to claim 15, characterized in that Also includes: The client generates automatic authorization setting information in response to the tenth operation of the owner or publisher on the first sharing point; wherein the automatic authorization setting information includes at least one authorization rule corresponding to the first sharing point; The client sends the automatic authorization setting information to the service side, so that the service side configures the at least one authorization rule as a preset authorization rule corresponding to the first sharing point.

17. The method according to any one of claims 15 to 16, characterized in that Also includes: The client generates an eighth request in response to an eighth operation by the owner or the publisher with respect to the authorization possessed 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 twelfth request in response to a twelfth operation of the owner or the publisher on the automatic authorization module; The client sends the twelfth request to the service side, so that the service side revokes the fifth authorization owned by the automatic authorization module.

18. The method according to any one of claims 15 to 17, characterized in that The sharing scenario also has a corresponding second cloud key, the second cloud key is stored on the service side and belongs to the owner, and the second cloud key is allowed to access the third cloud key for at least decryption; Also includes: The client generates a second request in response to a second operation of the owner or the 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, and the publisher is a user authorized by the owner to call the second cloud key; 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; wherein the first file ciphertext is obtained by encrypting the first file.

19. The method according to claim 18, 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 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.

20. 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 10.

21. A client, 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 of any one of claims 11 to 14; or to implement the method of any one of claims 15 to 19.

22. 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 10, or the method according to any one of claims 11 to 19.

23. 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 10, or the method according to any one of claims 11 to 19.

Images